From owner-atom-syntax@mail.imc.org  Thu Jul  1 00:19: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 AAA13943
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 00:19: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 i6146E0l099473;
	Wed, 30 Jun 2004 21: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 i6146EQs099472;
	Wed, 30 Jun 2004 21:06:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6146Cgt099397
	for <atom-syntax@imc.org>; Wed, 30 Jun 2004 21:06:13 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 1 Jul 2004 14:10:26 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Thu, 01 Jul 2004 14:05:42 +1000
Subject: Re: PacePutIpAddrInEntry
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD09CAB6.1C80A%eric.scheid@ironclad.net.au>
In-Reply-To: <opsafcyepguvpchu@quark>
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 i6146Egt099467
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 1/7/04 6:38 AM, "Asbjørn Ulsberg" <asbjorn@tigerstaden.no> wrote:

>> I'm hoping Atom gets used for feeds of status alerts from hosts, for
>> example. In that case, an IP address or a DNS name are reasonable
>> identifiers.
> 
> Speaking of... Is there a common designation for IP addresses and DNS
> names we could use instead of 'ipaddr' or 'ip-address'? Both DNS names and
> IP addresses should be possible to use to point to a node of origin, but
> I'm not sure what name the element should have to fit both. Any ideas?

ModWiki uses <host>

    http://www.usemod.com/cgi-bin/mb.pl?ModWiki

e.




From owner-atom-syntax@mail.imc.org  Thu Jul  1 05:20:28 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07634
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 05:20:27 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i618ex2u083921;
	Thu, 1 Jul 2004 01:40: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 i618exFo083920;
	Thu, 1 Jul 2004 01:40:59 -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 i618ewc0083888
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 01:40:59 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 56616 messnum 236387 invoked from network[83.70.35.17/83-70-35-17.bas2.prp.dublin.eircom.net]); 1 Jul 2004 08:40:52 -0000
Received: from 83-70-35-17.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.35.17)
  by mail09.svc.cra.dublin.eircom.net (qp 56616) with SMTP; 1 Jul 2004 08:40:52 -0000
Message-ID: <40E3CE13.8070301@dehora.net>
Date: Thu, 01 Jul 2004 09:40:51 +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: PacePutIpAddrInEntry
References: <BD08C96B.11E0F%mint@franklinmint.fm>
In-Reply-To: <BD08C96B.11E0F%mint@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:

> It does seem odd that Mark N. is saying that an IP address is not useful as
> an identity datapoint, but also suggesting that it constitutes an additional
> privacy concern.

What I don't understand is why ipaddr should to be an element in the 
format.

As presented, it's data for reverse-engineering an identity, not 
identity.  For a Person construct, IP address consitutes a 
fantastically "weak" identifier - you use it as evidence to help 
make a guess as to who wrote/did something (an abductive inference 
in logic jargon).

Paul Hoffman mentioned an alerting use case. I have work lined up 
that will use Atom for just that. In designing it I have been using 
   atom:name not atom:ipaddr.

I suspect use cases for ipaddr falls under security and 
countermeasures, not identity.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Thu Jul  1 06: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 GAA12068
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 06:26: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 i61A5b9U013787;
	Thu, 1 Jul 2004 03:05:37 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i61A5bho013786;
	Thu, 1 Jul 2004 03:05:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail-relay-2.tiscali.it (mail-relay-2.tiscali.it [212.123.84.92])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i61A5VRN013703
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 03:05:36 -0700 (PDT)
	(envelope-from danny666@virgilio.it)
Received: from virgilio.it (62.11.120.111) by mail-relay-2.tiscali.it (7.1.021.3)
        id 40D9B22D002ABF6A; Thu, 1 Jul 2004 12:05:21 +0200
Message-ID: <40E3E17A.8040704@virgilio.it>
Date: Thu, 01 Jul 2004 12:03:38 +0200
From: Danny Ayers <danny666@virgilio.it>
Reply-To: danny666@virgilio.it
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sam Ruby <rubys@intertwingly.net>
CC: atom-syntax <atom-syntax@imc.org>
Subject: Re: PacePutIpAddrInEntry
References: <40DFF80B.6070105@dehora.net> <2FB4EC3C-CA5A-11D8-B7F4-000A95BD86C0@mnot.net> <40E27354.9000804@dehora.net> <5A336AEE-CAAC-11D8-B7F4-000A95BD86C0@mnot.net> <40E2EE3E.2030200@intertwingly.net> <40E2F338.4080100@franklinmint.fm> <40E3091B.8060202@intertwingly.net>
In-Reply-To: <40E3091B.8060202@intertwingly.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


Sam Ruby wrote:

> I track and publish[1] IP addresses on my weblog.  It has cut down 
> significantly on "spoofing".
>
> I discussed a case[2] recently where somebody "anonymously" updated 
> the wiki.  Somebody proporting to be Bill de hÓra stepped forward and 
> claimed responsibility.  


I think the use case is strong enough to warrant inclusion of 
atom:ipaddr in the spec. But the implied meaning is wrong whether it 
appears at feed, entry or author level - it's not necessarily the IP 
address of any of these. I don't think the use case is strong enough to 
warrant extra structural elements to supply more info that way, and 
ipaddr seems the best label. Given that the primary use is to /assist/ 
in identification of the author, I think it would probably be most 
appropriate at that level. But given the inaccuracy of the intuitive 
interpretation it definitely calls for an explanatory note in  the spec 
prose - something like: "there is no guarantee of a strong association 
between the value of atom:ipaddr and the author of the entry".

> Truth be told, I personally trust the ip addresses information more 
> than the SMTP headers.


There are politicians I could say the same about.

Cheers,
Danny.

-- 

Raw
http://dannyayers.com



From owner-atom-syntax@mail.imc.org  Thu Jul  1 06: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 GAA13923
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 06:53: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 i61AgYLO022729;
	Thu, 1 Jul 2004 03: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 i61AgYOl022728;
	Thu, 1 Jul 2004 03:42:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i61AgXb5022719
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 03:42:33 -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 1Bfz1S-0001eS-HD; Thu, 01 Jul 2004 10:42:30 +0000
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Thu, 01 Jul 2004 06:42:35 -0400
Subject: Re: PaceIntrospection: Is another file format really needed?
From: Robert Sayre <mint@franklinmint.fm>
To: <kwark.1511609@bloglines.com>, Atom Syntax <atom-syntax@imc.org>
CC: <millennium@spoonybards.net>
Message-ID: <BD0962DB.11E2D%mint@franklinmint.fm>
In-Reply-To: <1088676981.2820158052.16996.sendItem@bloglines.com>
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: <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 7/1/04 6:16 AM, "kwark.1511609@bloglines.com"
<kwark.1511609@bloglines.com> wrote:

> 
> Big +1 to Beechers proposal to reuse the <feed> format for introspection.
> 
> 
> As he has clearly demonstrated there is no conceptual difference between
> a feed format and an introspection format [1].
> 
> "When it smells like it,
> feels like it and looks like it, you call it what it is: <feed>".
> 

Should be obvious that it's not a feed. A feed is a frame of a pushed
stream. Introspection is comprehensive.

What problem is solved by making feed the root element for both purposes?
Why does it matter?

> I see <feed>
> as a general container for a list/bag of items.

I see WebDAV collections as the general case.

Robert Sayre



From owner-atom-syntax@mail.imc.org  Thu Jul  1 07: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 GAA12069
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 06:26: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 i61AGKRg018263;
	Thu, 1 Jul 2004 03:16: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 i61AGKju018262;
	Thu, 1 Jul 2004 03:16:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from w03.bloglines.com ([216.148.212.185])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i61AGK3j018254
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 03:16:20 -0700 (PDT)
	(envelope-from kwark.1511609@bloglines.com)
Received: (qmail 16999 invoked by uid 99); 1 Jul 2004 10:16:21 -0000
Message-ID: <1088676981.2820158052.16996.sendItem@bloglines.com>
Date: 1 Jul 2004 10:16:21 -0000
From: kwark.1511609@bloglines.com
To: atom-syntax@imc.org
CC: millennium@spoonybards.net
Subject: Re: PaceIntrospection: Is another file format really needed?
MIME-Version: 1.0
Content-Type: text/plain
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


Big +1 to Beechers proposal to reuse the <feed> format for introspection.


As he has clearly demonstrated there is no conceptual difference between
a feed format and an introspection format [1].

"When it smells like it,
feels like it and looks like it, you call it what it is: <feed>".

Some
people argue that <feed> SHOULD be reserved exclusively for syndication [2]
and that urls pointing to <feed> documents SHOULD be subscribable.
Newsflash:
in the current API proposal, <feed> is already reused for browsing a list
of editable entries (draft and/or published posts). This type of <feed> can
even contain special <link> tags with @rel="start", "next" or "prev", which
are clearly browsing oriented. It makes no sense to subscribe to such a "next"
url.

Also, one of the original requirements, that has gotten this whole
atom thing started, was to come up with an archival format for weblogs. If
we follow the arguments of some of Beechers opponents, we should not use <feed>
format for this, but come up with another format, f.e. <archive>, because
an archive is clearly not intended for syndication.

Not limiting <feed>
for non-syndication related stuff, comes with an additional advantage, comparable
with view-sourceability. You can easily drop the non-syndicated <feed> in
your aggregator and have it parsed and rendered for you. Using a different
format requires your aggregator to explicitly support it.

I see <feed>
as a general container for a list/bag of items.
I don't want any restrictions
on the type of items in the feed: classic weblog posts, uploaded images, favorite
songs, description of API endpoints, classic linklog to other content. 
I
also don't want any semantic restrictions on <feed> itself. Whether it represents
a classical syndicated list of the latest reverse chronological weblog posts,
a list search results implicitly ordered by relevance, a list of my favorite
songs (top10) or a list of my API endpoints (no significant order) does not
matter.

If we really want to reserve <feed> for a classical syndicated
list, then we should write up a pace to change the spec and also be consistent
and come up with a different container element for the API post browsing format
and the archive browsing format.

It looks more to me that some people would
like to be able to differentiate between different types of lists.
I see
two possibilities:
1) extend <feed> with a @type attribute. This has the
same problems/benefits as link@rel: will the list of possible types be closed
or extensible?
2) introduce a base <list> or <collection> tag and have other
tags inherit from it: <feed>, <introspection>, <archive>, ... like in OO systems.

Not that I'm in favor of any of these suggestions. 
Locking down the semantics
of <feed> too much, negatively impacts future innovation 

Regards,

Peter


[1] http://www.imc.org/atom-syntax/mail-archive/msg06104.html
[2] http://www.imc.org/atom-syntax/mail-archive/msg06059.html




From owner-atom-syntax@mail.imc.org  Thu Jul  1 07:59: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 HAA17776
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 07: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 i61Bk09N031021;
	Thu, 1 Jul 2004 04:46: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 i61Bk0PU031020;
	Thu, 1 Jul 2004 04:46:00 -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.188])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i61BjuHZ031002
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 04:45:59 -0700 (PDT)
	(envelope-from sewe@rbg.informatik.tu-darmstadt.de)
Received: from [212.227.126.208] (helo=mrelayng.kundenserver.de)
	by moutng.kundenserver.de with esmtp (Exim 3.35 #1)
	id 1Bg00o-00076y-00; Thu, 01 Jul 2004 13:45:54 +0200
Received: from [62.158.15.11] (helo=baron)
	by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1)
	id 1Bg00o-0008LY-00; Thu, 01 Jul 2004 13:45:54 +0200
Message-ID: <001501c45f61$0c6c3120$0b0f9e3e@baron>
From: "Andreas Sewe" <sewe@rbg.informatik.tu-darmstadt.de>
To: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
Cc: "[Atom]" <atom-syntax@imc.org>
References: <40DFF80B.6070105@dehora.net> <2FB4EC3C-CA5A-11D8-B7F4-000A95BD86C0@mnot.net> <40E27354.9000804@dehora.net> <5A336AEE-CAAC-11D8-B7F4-000A95BD86C0@mnot.net> <40E2EE3E.2030200@intertwingly.net> <1F4FB643-CAB8-11D8-B7F4-000A95BD86C0@mnot.net> <p06110417bd08aaafcf67@[10.20.30.249]> <04D9418B-CAC1-11D8-B7F4-000A95BD86C0@mnot.net> <p0611041abd08b4a825b3@[10.20.30.249]> <opsafcyepguvpchu@quark>
Subject: Re: PacePutIpAddrInEntry
Date: Thu, 1 Jul 2004 13:46:22 +0200
Organization: Fachbereich Informatik, TU Darmstadt
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:275eb74a6eb9feb006a62452721ee94c
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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:
> Paul Hoffman / IMC wrote:
>> I'm hoping Atom gets used for feeds of status alerts from hosts, for
>> example. In that case, an IP address or a DNS name are reasonable
>> identifiers.

> Speaking of... Is there a common designation for IP addresses and DNS
> names we could use instead of 'ipaddr' or 'ip-address'? Both DNS names and
> IP addresses should be possible to use to point to a node of origin, but
> I'm not sure what name the element should     have to fit both. Any ideas?

What about 'host', the DNS name being the host name, the IP address its
address? And it's a single word, so one doesn't have to argue about the case
convention to use. ;-)

Regards,

Andreas Sewe



From owner-atom-syntax@mail.imc.org  Thu Jul  1 08:00: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 IAA17860
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 08:00: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 i61BmGPa031224;
	Thu, 1 Jul 2004 04:48: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 i61BmG3c031223;
	Thu, 1 Jul 2004 04:48:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from w03.bloglines.com ([216.148.212.185])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i61BmGso031216
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 04:48:16 -0700 (PDT)
	(envelope-from kwark.1511609@bloglines.com)
Received: (qmail 2679 invoked by uid 99); 1 Jul 2004 11:48:18 -0000
Message-ID: <1088682498.3099226561.2678.sendItem@bloglines.com>
Date: 1 Jul 2004 11:48:18 -0000
From: kwark.1511609@bloglines.com
To: atom-syntax@imc.org
Subject: Re: PaceIntrospection: Is another file format really needed?
MIME-Version: 1.0
Content-Type: text/plain
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


--- Robert Sayre <mint@franklinmint.fm wrote:
> A feed is a frame of a pushed
stream. 

-1

A feed of search results, does not fit this limiting definition
of <feed>.

The usage link@rel="next" in the Atom API spec cannot be reconciled
with this definition of feed.
Dereferencing the "next" url, will return a
<feed> which does not comply to that definition.

Peter



From owner-atom-syntax@mail.imc.org  Thu Jul  1 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 IAA19328
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 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 i61CBc1l034973;
	Thu, 1 Jul 2004 05:11: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 i61CBcDH034972;
	Thu, 1 Jul 2004 05:11:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i61CBbTU034966
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 05:11: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 1Bg0Ph-0003bB-AT; Thu, 01 Jul 2004 12:11:37 +0000
Message-ID: <40E3FF75.50906@franklinmint.fm>
Date: Thu, 01 Jul 2004 08:11:33 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: kwark.1511609@bloglines.com
CC: atom-syntax@imc.org
Subject: Re: PaceIntrospection: Is another file format really needed?
References: <1088682498.3099226561.2678.sendItem@bloglines.com>
In-Reply-To: <1088682498.3099226561.2678.sendItem@bloglines.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


kwark.1511609@bloglines.com wrote:

>--- Robert Sayre <mint@franklinmint.fm wrote:
>  
>
>>A feed is a frame of a pushed
>>    
>>
>stream. 
>
>-1
>
>A feed of search results, does not fit this limiting definition
>of <feed>.
>
>  
>

How so? I'm subscribed to "Robert Sayre" on pubsub. Seems like a stream 
to me. Or did you mean typing a term in and getting a search results 
back? I would probably use an HTML page for that.

>The usage link@rel="next" in the Atom API spec cannot be reconciled
>with this definition of feed.
>Dereferencing the "next" url, will return a
><feed> which does not comply to that definition.
>

You're right. It doesn't.

Let's turn back to the more interesting questions:
What problem is solved by making feed the root element for both 
purposes? Why does it matter?

Robert Sayre



From owner-atom-syntax@mail.imc.org  Thu Jul  1 08: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 IAA19401
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 08:24: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 i61CD4Zm035135;
	Thu, 1 Jul 2004 05:13:04 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i61CD4Tl035134;
	Thu, 1 Jul 2004 05:13: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 (mproxy.gmail.com [216.239.56.252])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i61CD4ie035126
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 05:13:04 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so3946504cwc
        for <atom-syntax@imc.org>; Thu, 01 Jul 2004 05:13:03 -0700 (PDT)
Received: by 10.11.116.22 with SMTP id o22mr76322cwc;
        Thu, 01 Jul 2004 05:13:03 -0700 (PDT)
Message-ID: <3f1451f50407010513393f1cb3@mail.gmail.com>
Date: Thu, 1 Jul 2004 08:13:03 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Eric Scheid <eric.scheid@ironclad.net.au>
Subject: Re: PacePersonRef posted
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <BD09C408.1C7EB%eric.scheid@ironclad.net.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
References: <BD09C408.1C7EB%eric.scheid@ironclad.net.au>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i61CD4ie035129
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 Thu, 01 Jul 2004 13:37:12 +1000, Eric Scheid
<eric.scheid@ironclad.net.au> wrote:
> 
> 
> On 1/7/04 6:53 AM, "Asbjørn Ulsberg" <asbjorn@tigerstaden.no> wrote:
> 
> >> In most feeds, the author is the same for many, if not all, entries,
> >> leading to repetition of author metadata. This can be avoided by
> >> specifying the metadata in one place in the feed and referring to it
> >> from other parts of the feed.
> >
> > Would it be possible to extend this Pace to also include external
> > referring authors, which could be, e.g. a FOAF file? The file could of
> > course also be a centrally stored XML file with an <author> document in
> > it, but when referring externally, I guess it makes more sense to refer to
> > something more useful, like FOAF.
> 
> change the data type of @ref to URI, and we can refer to defined authors
> like this:
> 
>     <author ref="#someauthorinthisfeedinstance" />
>     <!-- note the simple extra bit of "#" -->

Reduce, reuse, recycle:

<author xlink:href="#someauthorinthisfeedinstance" />

Of course any sort of 'id' referencing gets you into 
the quagmire of XML ids, that is, the ability of processors 
to identify an XML element by an explicit identifier 
("IDness") has depended upon *validation*[1].
Unless we want to have a *mandatory* DTD and/or
Schema for Atom then xml:id[2], though only a 
working draft, is your best bet.

    -joe

[1] http://www.w3.org/TR/2003/WD-xml-id-req-20030806/
[2] http://www.w3.org/TR/2004/WD-xml-id-20040407/



From owner-atom-syntax@mail.imc.org  Thu Jul  1 09:22: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 JAA23080
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 09: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 i61D87Id042334;
	Thu, 1 Jul 2004 06:08: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 i61D872l042333;
	Thu, 1 Jul 2004 06:08:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from w03.bloglines.com ([216.148.212.185])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i61D86Kn042327
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 06:08:06 -0700 (PDT)
	(envelope-from kwark.1511609@bloglines.com)
Received: (qmail 19538 invoked by uid 99); 1 Jul 2004 13:08:09 -0000
Message-ID: <1088687289.3263635584.19535.sendItem@bloglines.com>
Date: 1 Jul 2004 13:08:09 -0000
From: kwark.1511609@bloglines.com
To: atom-syntax@imc.org
Subject: Re: PaceIntrospection: Is another file format really needed?
MIME-Version: 1.0
Content-Type: text/plain
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


--- mint@franklinmint.fm wrote:
> >A feed of search results, does not fit
this limiting definition
> >of <feed>.
> >
> How so? I'm subscribed to
"Robert Sayre" on pubsub. Seems like a stream 
> to me. Or did you mean typing
a term in and getting a search results 
> back? I would probably use an HTML
page for that.
> 

At Feedster you can also subscribe to search results
for a specific term. You can either sort the results by date or by relevance.
The first type of search fits your definition of <feed>, the second does not.


compare:

http://feedster.com/rss.php?q=duck&sort=&type=echo&ie=UTF-8&limit=15


and:

http://feedster.com/rss.php?q=duck&sort=&type=echo&ie=UTF-8&limit=15&sort=relevance


Another example of another "non-conforming" feed:

http://www.daypop.com/blogrank/rss.xml


The items in this <feed> are ordered according to ranking and hence this
feed does not represent a frame of pushed stack.

> Let's turn back to the
more interesting questions:
> What problem is solved by making feed the root
element for both purposes? 

It avoids introduction of a new <introspection>
format for representing information, which can be represented just as well
by <feed>, without the need for shoe-horning, if the definition of <feed>
 is not limited.

It avoids the need for constant reinventing of a new format,
whenever you come across something, which does not fit the notion of "frame"
of a pushed stack. 
F.e. I want to be able to have a list of the templates
used by my Blogging account. I'd use <feed> for that too. What would you use?


> Why does it matter?

Nothing really matters, but I'd say: simplicity,
elegance, innovation friendly.

Could you also please answers the same two
questions, for the opposite case where a seperate <introspection> format is
necessary?

Peter



From owner-atom-syntax@mail.imc.org  Thu Jul  1 09: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 JAA26986
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 09: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 i61DdlOB045442;
	Thu, 1 Jul 2004 06: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 i61Ddl4d045441;
	Thu, 1 Jul 2004 06:39:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i61Ddk4t045435
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 06:39:46 -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 1Bg1n0-0005pL-UR; Thu, 01 Jul 2004 13:39:47 +0000
Message-ID: <40E4141E.2070308@franklinmint.fm>
Date: Thu, 01 Jul 2004 09:39:42 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: kwark.1511609@bloglines.com
CC: atom-syntax@imc.org
Subject: Re: PaceIntrospection: Is another file format really needed?
References: <1088687289.3263635584.19535.sendItem@bloglines.com>
In-Reply-To: <1088687289.3263635584.19535.sendItem@bloglines.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


kwark.1511609@bloglines.com wrote:

>http://feedster.com/rss.php?q=duck&sort=&type=echo&ie=UTF-8&limit=15&sort=relevance
>
>
>Another example of another "non-conforming" feed:
>
>http://www.daypop.com/blogrank/rss.xml
>
>
>The items in this <feed> are ordered according to ranking and hence this
>feed does not represent a frame of pushed stack.
>
>  
>

Both of these fit just fine. The only difference is that they might show 
you entirely new content each time. My aggregator would probably build 
up a history of it anyway.

>It avoids introduction of a new <introspection>
>format for representing information...
>
>It avoids the need for constant reinventing of a new format...
>
>F.e. I want to be able to have a list of the templates
>used by my Blogging account. I'd use <feed> for that too. What would you use?
>
>  
>

Could I subscribe to your templates? That would be useful :/
It seems you want <feed> to replace all XML elements that contain child 
sequences. I think that's of dubious utility.

Feeds are not collections in the general sense. They are resources you 
"subscribe" to in order to receive batched push updates.

>Could you also please answers the same two
>questions, for the opposite case where a seperate <introspection> format is
>necessary?
>

No, I can't. When we're done specifying the introspection capabilities 
we're going to support, we'll take a look at folding it back into the 
feed format. There's no reason to try and deal with them as one format 
right now-- the only  reason you gave was "avoid another format".

Robert Sayre



From owner-atom-syntax@mail.imc.org  Thu Jul  1 10:18: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 KAA02211
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 10:18: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 i61DmxNk046273;
	Thu, 1 Jul 2004 06:48: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 i61DmxaJ046272;
	Thu, 1 Jul 2004 06:48:59 -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 i61Dmwfx046257
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 06:48: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 (sccrmhc13) with SMTP
          id <2004070113485301600k8same>; Thu, 1 Jul 2004 13:48:53 +0000
Date: Thu, 1 Jul 2004 07:48:44 -0600
Subject: Re: PacePersonRef posted
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v553)
From: Antone Roundy <antone@geckotribe.com>
To: atom-syntax@imc.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <BD09C408.1C7EB%eric.scheid@ironclad.net.au>
Message-Id: <5E468506-CB65-11D8-9B2F-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 Wednesday, June 30, 2004, at 09:37  PM, Eric Scheid wrote:
>> Would it be possible to extend this Pace to also include external
>> referring authors, which could be, e.g. a FOAF file? The file could of
>> course also be a centrally stored XML file with an <author> document 
>> in
>> it, but when referring externally, I guess it makes more sense to 
>> refer to
>> something more useful, like FOAF.
>
> change the data type of @ref to URI, and we can refer to defined 
> authors
> like this:
>
>     <author ref="#someauthorinthisfeedinstance" />
>     <!-- note the simple extra bit of "#" -->
>
>     <author ref="http://example.org/foo.foaf#fred"
>         type="application/xml+foaf" />
>
> I'm in two minds for this: it provides an extensibility path, but it 
> opens
> awkward questions about what happens if the referenced element is not a
> <person> construct
Yeah, it would not contain the required elements of a Person construct 
(either a name or an email address or...).

I myself would be opposed to allowing external references because, with 
the exception of binary resources, I'm in favor of a feed being 
self-contained.  This is partly a result of my background--my 
connection to Atom is that I'm the author of a PHP script for 
processing RSS feeds.  I'd like to be able to load just the feed and 
get all the data I need to present it as HTML.  I want to be able to 
use HTML to instruct the viewer's browser to load anything that's not 
in the feed, like images.

>> 4.5.1.1 id Attribute
>> 3.2.1 "ref" attribute
>
> we need some extra language to explain that any given <person> 
> construct can
> have @id or @ref but NOT both.
Good point.  I've updated the proposal to state that a <person> element 
MUST NOT have a ref attribute.  Since the id attribute is listed under 
the <person> element (and not the Person construct), there is (should 
be!) no need to point out that other Person constructs cannot have an 
id attribute.



From owner-atom-syntax@mail.imc.org  Thu Jul  1 10:24: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 KAA03403
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 10:23: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 i61DrXQS046767;
	Thu, 1 Jul 2004 06: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 i61DrXtX046766;
	Thu, 1 Jul 2004 06:53:33 -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 i61DrX3H046755
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 06:53: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 (sccrmhc11) with SMTP
          id <2004070113532901100j5i5ke>; Thu, 1 Jul 2004 13:53:30 +0000
Date: Thu, 1 Jul 2004 07:53:28 -0600
Subject: Re: PacePersonRef posted
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v553)
From: Antone Roundy <antone@geckotribe.com>
To: atom-syntax@imc.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <3f1451f50407010513393f1cb3@mail.gmail.com>
Message-Id: <07EC2531-CB66-11D8-9B2F-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 Thursday, July 1, 2004, at 06:13  AM, Joe Gregorio wrote:
>> change the data type of @ref to URI, and we can refer to defined 
>> authors
>> like this:
>>
>>     <author ref="#someauthorinthisfeedinstance" />
>>     <!-- note the simple extra bit of "#" -->
>
> Reduce, reuse, recycle:
>
> <author xlink:href="#someauthorinthisfeedinstance" />
>
> Of course any sort of 'id' referencing gets you into
> the quagmire of XML ids, that is, the ability of processors
> to identify an XML element by an explicit identifier
> ("IDness") has depended upon *validation*[1].
> Unless we want to have a *mandatory* DTD and/or
> Schema for Atom then xml:id[2], though only a
> working draft, is your best bet.
>
xml:id sounds good to me.  Comments on xlink:href, anyone?

As mentioned elsewhere, I'm not in favor or allowing references to 
externally defined Person constructs, so if xlink:href were used (and 
my preference were to prevail!), we'd need to specify that constraint.  
I don't suppose there's a generic referencing mechanism already defined 
for local-only references, is there?



From owner-atom-syntax@mail.imc.org  Thu Jul  1 10: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 KAA03531
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 10: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 i61E92br047886;
	Thu, 1 Jul 2004 07:09: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 i61E92sf047885;
	Thu, 1 Jul 2004 07:09:02 -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 i61E91IU047868
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 07:09:01 -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 <20040701140858015007f3mbe>; Thu, 1 Jul 2004 14:08:58 +0000
Date: Thu, 1 Jul 2004 08:08:57 -0600
Subject: Re: PaceIntrospection: Is another file format really needed?
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: <40E4141E.2070308@franklinmint.fm>
Message-Id: <3176032A-CB68-11D8-9B2F-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 Thursday, July 1, 2004, at 07:39  AM, Robert Sayre wrote:
> Feeds are not collections in the general sense. They are resources you 
> "subscribe" to in order to receive batched push updates.

It looks like we could save ourselves a considerable amount of 
discussion if we were to nail down a conceptual model of what a feed 
is, what an entry is (what a person is), etc.  If you do a title search 
on the wiki for "Model", a number of pages come up.  Does anyone whose 
been around longer than I have know whether any of these have been 
"officially" adopted?  If so, let's refer to them, and when questions 
arise that aren't answered by them, augment them so that we can move 
forward.

I for one do see feeds as being more generalized collections.  Or at 
least as being usable as generalized collections, though their primary 
use is as reverse sequential lists of ... some sort of data.  A pencil 
is usually used for writing, but I don't have a problem with people 
using them as defensive weapons or decorations or whatever else they 
might work just fine for.  If it can do the job without making people 
jump through hoops, then a "better" solution isn't needed.  And if it 
saves jumping though hoops, then maybe it is the best solution.

>> Could you also please answers the same two
>> questions, for the opposite case where a seperate <introspection> 
>> format is
>> necessary?
>
> No, I can't. When we're done specifying the introspection capabilities 
> we're going to support, we'll take a look at folding it back into the 
> feed format. There's no reason to try and deal with them as one format 
> right now.

If we need to specify capabilities first, then arguments against 
reusing the feed format are no more productive than arguments in favor 
of doing so.  So what capabilities do we need?  To find the endpoints 
for things like posting and editing, to discover which capabilities a 
server supports.  Anything else?



From owner-atom-syntax@mail.imc.org  Thu Jul  1 10:45:58 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06355
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 10:45:57 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i61EStal050007;
	Thu, 1 Jul 2004 07:28: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 i61EStgt050006;
	Thu, 1 Jul 2004 07:28: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 i61EStRP050000
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 07:28:55 -0700 (PDT)
	(envelope-from mint@franklinmint.fm)
Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94])
	by web02.designerslab.net with asmtp (Exim 4.34)
	id 1Bg2YY-0007L6-QX; Thu, 01 Jul 2004 14:28:54 +0000
Message-ID: <40E41FA3.5000602@franklinmint.fm>
Date: Thu, 01 Jul 2004 10:28:51 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Antone Roundy <antone@geckotribe.com>
CC: atom-syntax@imc.org
Subject: Re: PaceIntrospection: Is another file format really needed?
References: <3176032A-CB68-11D8-9B2F-003065EA6144@geckotribe.com>
In-Reply-To: <3176032A-CB68-11D8-9B2F-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:

> If we need to specify capabilities first, then arguments against 
> reusing the feed format are no more productive than arguments in favor 
> of doing so.

Yes, they so are. We have unagreed upon requirements that may or may not 
be a good fit for <feed>.

http://c2.com/cgi/wiki?PrematureGeneralization

Robert Sayre



From owner-atom-syntax@mail.imc.org  Thu Jul  1 11:15: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 LAA08876
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 11: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 i61F3TFL052360;
	Thu, 1 Jul 2004 08:03:29 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i61F3T8i052359;
	Thu, 1 Jul 2004 08:03: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 (pop.gmx.de [213.165.64.20])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i61F3RNG052351
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 08:03:28 -0700 (PDT)
	(envelope-from derhoermi@gmx.net)
Received: (qmail 21591 invoked by uid 65534); 1 Jul 2004 15:03:20 -0000
Received: from dsl-082-082-076-081.arcor-ip.net (EHLO localhost) (82.82.76.81)
  by mail.gmx.net (mp001) with SMTP; 01 Jul 2004 17:03:20 +0200
X-Authenticated: #723575
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Ezra Cooper <ezra@sixapart.com>
Cc: atom-syntax@imc.org
Subject: Re: PaceSecurityServices & Digest auth
Date: Thu, 01 Jul 2004 17:03:07 +0200
Message-ID: <40e424a2.905610158@smtp.bjoern.hoehrmann.de>
References: <37DF50E8-CB00-11D8-8081-000A95CFF6CC@sixapart.com>
In-Reply-To: <37DF50E8-CB00-11D8-8081-000A95CFF6CC@sixapart.com>
X-Mailer: Forte Agent 1.92/32.572
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


* Ezra Cooper wrote:
>I see three issues to be addressed with Digest:
>
>   (1) Some web-servers remove the WWW-Authenticate header before 
>passing it to a CGI program.

The relevant header is the "Authorization" request header,
WWW-Authenticate is a response header which a CGI program
would normally not see but rather emit.

>========
>An Atom client MAY authenticate itself to an Atom server by sending an 
>X-Atom-Authenticate HTTP header, in the same form as for the 
>WWW-Authenticate header [RFC2617]. If an Atom client sends a 
>WWW-Authenticate header, it SHOULD have the same value as the 
>X-Atom-Authenticate header.
>========

So this does not really make sense to me. It seems the server would
send an Atom-Authenticate header, but then I ask why it is not e.g.
'WWW-Authenticate: Atom' since clients should not have a problem
generating such a header. So, do you mean clients should send an
Atom-Authorization header that would replicate an Authorization
header that the client would send, too, to bypass the security
mechanism that some web servers employ to hide the Authorization
header? An example communication transcript would we useful.



From owner-atom-syntax@mail.imc.org  Thu Jul  1 11:16: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 LAA09029
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 11:16: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 i61F1ovP052271;
	Thu, 1 Jul 2004 08:01: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 i61F1or2052270;
	Thu, 1 Jul 2004 08:01:50 -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 i61F1nYs052257
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 08:01:50 -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 i61F1i53002749
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 10:01:44 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i61F1iQr002745;
	Thu, 1 Jul 2004 10:01:44 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: atom-syntax <atom-syntax@imc.org>
Subject: Re: PacePutIpAddrInEntry
References: <40DFF80B.6070105@dehora.net>
	<2FB4EC3C-CA5A-11D8-B7F4-000A95BD86C0@mnot.net>
	<40E27354.9000804@dehora.net>
	<5A336AEE-CAAC-11D8-B7F4-000A95BD86C0@mnot.net>
	<40E2EE3E.2030200@intertwingly.net> <40E2F338.4080100@franklinmint.fm>
	<40E3091B.8060202@intertwingly.net>
	<8B69B46A-CACD-11D8-B7F4-000A95BD86C0@mnot.net>
	<14be96d3040630154143084428@mail.gmail.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 01 Jul 2004 10:01:44 -0500
In-Reply-To: <14be96d3040630154143084428@mail.gmail.com>
Message-ID: <m3u0wru5yf.fsf@bitsko.slc.ut.us>
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: <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> writes:

> I am in favor of atom:author:ipaddr in the core spec, because it
> would be immediately useful to a known class of existing
> Atom-enabled implementations, including our own wiki.

Given the proposal that this will be a core element that we will test
interoperability on, the test case for this element will go something
along the following lines, correct?


    Fully populated Person construct

        <author>
            <name>Jane Doe</name>
            <email>jane@example.com</name>
            <url>http://example.com/</url>
            <ipaddr>10.0.0.1</ipaddr>
        </author>

        If the consumer supports atom:ipaddr display when other Person
        construct elements are present, atom:ipaddr 10.0.0.1 will be
        displayed.

    Person construct only containing atom:ipaddr

        <author>
            <ipaddr>10.0.0.1</ipaddr>
        </author>

        If the consumer supports display of atom:ipaddr, atom:ipaddr
        10.0.0.1 will be displayed as the only author-identifying
        information.

Test results here are "pass", "fail", and "not applicable".  Note
additional test cases for IPv6 and improperly formed values.

Note: I wavered on whether the consumer processing requirements were
"must display" or "should display" and picked "should display" which
explains the wording of "if ... supports" above.  If the processing
requirement is "must display", the wording would change accordingly.
Note that it is possible that the first case could be "should display"
even if the second case were "must display [in absense of ...]".

  -- Ken



From owner-atom-syntax@mail.imc.org  Thu Jul  1 11:23:30 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09773
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 11:23:30 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i61F9EAE052948;
	Thu, 1 Jul 2004 08:09: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 i61F9EqI052947;
	Thu, 1 Jul 2004 08:09: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 i61F9DZX052932
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 08:09:13 -0700 (PDT)
	(envelope-from derhoermi@gmx.net)
Received: (qmail 25508 invoked by uid 65534); 1 Jul 2004 15:09:10 -0000
Received: from dsl-082-082-076-081.arcor-ip.net (EHLO localhost) (82.82.76.81)
  by mail.gmx.net (mp005) with SMTP; 01 Jul 2004 17:09:10 +0200
X-Authenticated: #723575
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Joe Gregorio <joe.gregorio@gmail.com>
Cc: atom-syntax@imc.org
Subject: Re: PacePersonRef posted
Date: Thu, 01 Jul 2004 17:08:58 +0200
Message-ID: <40fa2813.906491626@smtp.bjoern.hoehrmann.de>
References: <BD09C408.1C7EB%eric.scheid@ironclad.net.au> <3f1451f50407010513393f1cb3@mail.gmail.com>
In-Reply-To: <3f1451f50407010513393f1cb3@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: <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


* Joe Gregorio wrote:
>Of course any sort of 'id' referencing gets you into 
>the quagmire of XML ids, that is, the ability of processors 
>to identify an XML element by an explicit identifier 
>("IDness") has depended upon *validation*[1].

Validation is not really relevant here, a processor only needs to read
the relevant schema information, which can be an external DTD subset or
an internal DTD subset. Or a schema reference. Or a built-in schema. We
could say, for example, that Atom implementations must consider specific
attributes as ID attributes as defined in the XML Recommendation. That
would not work for generic processors, but any IDness that does not come
from the internal DTD subset is not guranteed to work in such processors
anyway.



From owner-atom-syntax@mail.imc.org  Thu Jul  1 11:34:37 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11234
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 11:34: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 i61FFdnD053530;
	Thu, 1 Jul 2004 08:15: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 i61FFdKU053529;
	Thu, 1 Jul 2004 08:15:39 -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 i61FFbHf053519
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 08:15:38 -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 i61FFZ53003052
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 10:15:35 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i61FFZsN003048;
	Thu, 1 Jul 2004 10:15:35 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: atom-syntax <atom-syntax@imc.org>
Subject: Re: PacePutIpAddrInEntry
References: <40DFF80B.6070105@dehora.net>
	<2FB4EC3C-CA5A-11D8-B7F4-000A95BD86C0@mnot.net>
	<40E27354.9000804@dehora.net>
	<5A336AEE-CAAC-11D8-B7F4-000A95BD86C0@mnot.net>
	<40E2EE3E.2030200@intertwingly.net> <40E2F338.4080100@franklinmint.fm>
	<40E3091B.8060202@intertwingly.net>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 01 Jul 2004 10:15:35 -0500
In-Reply-To: <40E3091B.8060202@intertwingly.net>
Message-ID: <m3pt7fu5bc.fsf@bitsko.slc.ut.us>
Lines: 21
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 i61FFcHf053524
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


Sam Ruby <rubys@intertwingly.net> writes:

> I track and publish IP addresses on my weblog.  It has cut down
> significantly on "spoofing".
> 
> I discussed a case recently where somebody "anonymously" updated the
> wiki.  Somebody proporting to be Bill de hÓra stepped forward and
> claimed responsibility.  Truth be told, I personally trust the ip
> addresses information more than the SMTP headers.

I recognize the use case for why hosts should have this information
and make it available on their site for these purposes.

Could you please confirm that the requirement being stated here is
explicitly for the purpose of enabling consumers to display this
information (for similar purposes that the host does)?

This would be separate from a use case for using core Atom format for
archiving this information.

  -- Ken



From owner-atom-syntax@mail.imc.org  Thu Jul  1 11: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 LAA12017
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 11:42: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 i61FT6Ff054592;
	Thu, 1 Jul 2004 08:29: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 i61FT614054591;
	Thu, 1 Jul 2004 08:29:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (pop.gmx.de [213.165.64.20])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i61FT5YL054583
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 08:29:05 -0700 (PDT)
	(envelope-from derhoermi@gmx.net)
Received: (qmail 4373 invoked by uid 65534); 1 Jul 2004 15:29:02 -0000
Received: from dsl-082-082-076-081.arcor-ip.net (EHLO localhost) (82.82.76.81)
  by mail.gmx.net (mp003) with SMTP; 01 Jul 2004 17:29:02 +0200
X-Authenticated: #723575
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Antone Roundy <antone@geckotribe.com>
Cc: atom-syntax@imc.org
Subject: Re: PacePersonRef posted
Date: Thu, 01 Jul 2004 17:28:49 +0200
Message-ID: <40fb292e.906774302@smtp.bjoern.hoehrmann.de>
References: <2932EE92-CAAC-11D8-B980-003065EA6144@geckotribe.com>
In-Reply-To: <2932EE92-CAAC-11D8-B980-003065EA6144@geckotribe.com>
X-Mailer: Forte Agent 1.92/32.572
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


* Antone Roundy wrote:
>* Rationale
>
>In most feeds, the author is the same for many, if not all, entries, 
>leading to repetition of author metadata. This can be avoided by 
>specifying the metadata in one place in the feed and referring to it 
>from other parts of the feed.

But your proposal still requires repetition, not the meta data, but
one has to repeat the reference again and again. Do I understand
correctly that your proposal makes the feed creator meta data non-
inheritable so that if all entries and the feed share the same
creator, one would have to state that for each entry again?

Another question, how would an Atom implementation resolve the
ambiguity auf creator meta data? Names for example are not unique
so this seems to encourage guessing which is likely to break. So
I am not sure whether it is worth to attempt to optimize for the
case where several authors each created several entries. The case
where the feed creator also created the entries however is some-
thing that would benefit from optimization, which should be done
through inheritance. We can provide control over the inheritance
if the entry author element is made optional and the case of an
entry without specified author becomes "ambiguous".



From owner-atom-syntax@mail.imc.org  Thu Jul  1 11:47: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 LAA12515
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 11:47: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 i61FZaXN054962;
	Thu, 1 Jul 2004 08:35: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 i61FZapu054961;
	Thu, 1 Jul 2004 08:35:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from w01.bloglines.com (w01.bloglines.com [216.148.212.183])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i61FZaLS054952
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 08:35:36 -0700 (PDT)
	(envelope-from kwark.1511609@bloglines.com)
Received: (qmail 17195 invoked by uid 99); 1 Jul 2004 15:35:34 -0000
Message-ID: <1088696134.3664773123.17193.sendItem@bloglines.com>
Date: 1 Jul 2004 15:35:34 -0000
From: kwark.1511609@bloglines.com
To: atom-syntax@imc.org
Subject: Re: PaceIntrospection: Is another file format really needed?
MIME-Version: 1.0
Content-Type: text/plain
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


--- mint@franklinmint.fm wrote:
> What does the oh-so-limiting PaceIntrospection
stop you from doing, exactly?

You are putting words in my mouth. I never
referred to PaceIntroSpection as limiting. I only referred to your definition
of <feed> as "a frame of a pushed stream" as limiting and that this definition
is inconsistent with current practices, f.e. Atom API spec.

I agree, that
to move forward we first need to pin down the conceptual model of a feed,
because there is clearly some disagreement there.

But I do have an answer
to your question: "What does the PaceIntrospection stop you from doing, exactly?"


The proposed introspection format does not allow me to subscribe to the
introspection file containing my blog sites, with any of the current aggregators.
;-)

Peter



From owner-atom-syntax@mail.imc.org  Thu Jul  1 12:09: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 MAA14297
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 12:09: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 i61FuwSw056334;
	Thu, 1 Jul 2004 08: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 i61FuwWO056333;
	Thu, 1 Jul 2004 08:56:58 -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 i61FuwKY056325
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 08:56:58 -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 <20040701155655015007e10re>; Thu, 1 Jul 2004 15:56:55 +0000
Date: Thu, 1 Jul 2004 09:56:54 -0600
Subject: Re: PacePersonRef posted
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v553)
From: Antone Roundy <antone@geckotribe.com>
To: atom-syntax@imc.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <40fb292e.906774302@smtp.bjoern.hoehrmann.de>
Message-Id: <466512F8-CB77-11D8-9B2F-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 Thursday, July 1, 2004, at 09:28  AM, Bjoern Hoehrmann wrote:
> * Antone Roundy wrote:
>> * Rationale
>>
>> In most feeds, the author is the same for many, if not all, entries,
>> leading to repetition of author metadata. This can be avoided by
>> specifying the metadata in one place in the feed and referring to it
>> from other parts of the feed.
>
> But your proposal still requires repetition, not the meta data, but
> one has to repeat the reference again and again. Do I understand
> correctly that your proposal makes the feed creator meta data non-
> inheritable so that if all entries and the feed share the same
> creator, one would have to state that for each entry again?
Yes, it makes the meta data non-inheritable.  Some people have 
expressed the opinion that it shouldn't be inheritable, and this 
proposal provides a mechanism for minimizing the size of the feed if 
inheritance is removed from the spec.  But I certainly wouldn't say we 
have consensus on that.  If the consensus ends up being that it be 
inheritable, then that provision of the proposal can be severed.

> Another question, how would an Atom implementation resolve the
> ambiguity auf creator meta data? Names for example are not unique
> so this seems to encourage guessing which is likely to break.
If you're saying that this proposal would make that situation worse, 
then I'm not following you.

> We can provide control over the inheritance
> if the entry author element is made optional and the case of an
> entry without specified author becomes "ambiguous".
I don't follow you.  If an entry has no author and we ARE using 
inheritance, then it inherits from the feed, and is only ambiguous if 
the feed also doesn't have an author, right?

So, the questions for debate on this proposal (...when it gets to the 
Proceed list? Yeah, I keep responding too)--I think I'll add a section 
for these to the proposal:

1) Do we want a mechanism for specifying Person metadata once and 
referring to it from elsewhere in the feed?
2) Do we want entries to inherit the author from the feed if they don't 
specify one?
3) Do we want to define our own attributes (id and ref) or use common 
attributes (xml:id and xlink:href, for example).
4) Do we want to be able to refer to externally defined Person 
constructs, or must the data be local?  (This is not the same question 
as "do we want a Person construct to be extendable to refer to 
externally defined and possibly externally stored resources?", which is 
beyond the scope of this proposal.)



From owner-atom-syntax@mail.imc.org  Thu Jul  1 12:15:14 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14573
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 12:15:13 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i61G1nic056612;
	Thu, 1 Jul 2004 09:01:49 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i61G1ndP056611;
	Thu, 1 Jul 2004 09:01:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i61G1ll9056600;
	Thu, 1 Jul 2004 09:01:48 -0700 (PDT)
	(envelope-from jasnell@us.ibm.com)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11])
	by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i61G1Sur634148;
	Thu, 1 Jul 2004 12:01:28 -0400
Received: from d03nm122.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 i61G1RfN411326;
	Thu, 1 Jul 2004 10:01:27 -0600
In-Reply-To: <40E3E17A.8040704@virgilio.it>
To: danny666@virgilio.it
Cc: atom-syntax <atom-syntax@imc.org>, owner-atom-syntax@mail.imc.org,
        Sam Ruby <rubys@intertwingly.net>
MIME-Version: 1.0
Subject: Re: PacePutIpAddrInEntry
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
From: James M Snell <jasnell@us.ibm.com>
X-MIMETrack: S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/01/2004 08:55:09 AM,
	Serialize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/01/2004 08:55:09 AM,
	Serialize complete at 07/01/2004 08:55:09 AM,
	Itemize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/01/2004 08:55:09 AM,
	S/MIME Sign complete at 07/01/2004 08:55:09 AM,
	S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/01/2004 09:01:23 AM,
	S/MIME Sign complete at 07/01/2004 09:01:23 AM,
	Serialize by Router on D03NM122/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at
 07/01/2004 10:01:27,
	Serialize complete at 07/01/2004 10:01:27
Message-ID: <OF9B0EE984.AACE991A-ON88256EC4.00573089-88256EC4.00580471@us.ibm.com>
Date: Thu, 1 Jul 2004 10:01:25 -0600
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z33668_boundary_sign
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>


This is an S/MIME signed message.

---------z33668_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 0057726E88256EC4_="

This is a multipart message in MIME format.
--=_alternative 0057726E88256EC4_=
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

owner-atom-syntax@mail.imc.org wrote on 07/01/2004 03:03:38 AM:

>=20
> Sam Ruby wrote:
>=20
> > I track and publish[1] IP addresses on my weblog.  It has cut down=20
> > significantly on "spoofing".
> >
> > I discussed a case[2] recently where somebody "anonymously" updated=20
> > the wiki.  Somebody proporting to be Bill de h=D3ra stepped forward and=
=20
> > claimed responsibility.=20
>=20
>=20
> I think the use case is strong enough to warrant inclusion of=20
> atom:ipaddr in the spec. But the implied meaning is wrong whether it=20
> appears at feed, entry or author level - it's not necessarily the IP=20
> address of any of these. I don't think the use case is strong enough to=20
> warrant extra structural elements to supply more info that way, and=20
> ipaddr seems the best label. Given that the primary use is to /assist/=20

Perhaps using a term like "origin-ip-addr" instead would be better in this =

case? The reasoning is that the element is being used to identify the=20
network address where the entry originated.=20

> in identification of the author, I think it would probably be most=20
> appropriate at that level. But given the inaccuracy of the intuitive=20

+1 on the ip-addr being on the author level.

> interpretation it definitely calls for an explanatory note in  the spec=20
> prose - something like: "there is no guarantee of a strong association=20
> between the value of atom:ipaddr and the author of the entry".
>=20
> > Truth be told, I personally trust the ip addresses information more=20
> > than the SMTP headers.
>=20
>=20
> There are politicians I could say the same about.
>=20
> Cheers,
> Danny.
>=20
> --=20
>=20
> Raw
> http://dannyayers.com
>=20


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

--=_alternative 0057726E88256EC4_=
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable


<br><font size=3D2><tt>owner-atom-syntax@mail.imc.org wrote on 07/01/2004
03:03:38 AM:<br>
<br>
&gt; <br>
&gt; Sam Ruby wrote:<br>
&gt; <br>
&gt; &gt; I track and publish[1] IP addresses on my weblog. &nbsp;It has
cut down <br>
&gt; &gt; significantly on &quot;spoofing&quot;.<br>
&gt; &gt;<br>
&gt; &gt; I discussed a case[2] recently where somebody &quot;anonymously&q=
uot;
updated <br>
&gt; &gt; the wiki. &nbsp;Somebody proporting to be Bill de h=D3ra stepped
forward and <br>
&gt; &gt; claimed responsibility. &nbsp;<br>
&gt; <br>
&gt; <br>
&gt; I think the use case is strong enough to warrant inclusion of <br>
&gt; atom:ipaddr in the spec. But the implied meaning is wrong whether
it <br>
&gt; appears at feed, entry or author level - it's not necessarily the
IP <br>
&gt; address of any of these. I don't think the use case is strong enough
to <br>
&gt; warrant extra structural elements to supply more info that way, and
<br>
&gt; ipaddr seems the best label. Given that the primary use is to /assist/
<br>
</tt></font>
<br><font size=3D2><tt>Perhaps using a term like &quot;origin-ip-addr&quot;
instead would be better in this case? The reasoning is that the element
is being used to identify the network address where the entry originated.
&nbsp;</tt></font>
<br>
<br><font size=3D2><tt>&gt; in identification of the author, I think it wou=
ld
probably be most <br>
&gt; appropriate at that level. But given the inaccuracy of the intuitive
<br>
</tt></font>
<br><font size=3D2><tt>+1 on the ip-addr being on the author level.</tt></f=
ont>
<br>
<br><font size=3D2><tt>&gt; interpretation it definitely calls for an expla=
natory
note in &nbsp;the spec <br>
&gt; prose - something like: &quot;there is no guarantee of a strong associ=
ation
<br>
&gt; between the value of atom:ipaddr and the author of the entry&quot;.<br>
&gt; <br>
&gt; &gt; Truth be told, I personally trust the ip addresses information
more <br>
&gt; &gt; than the SMTP headers.<br>
&gt; <br>
&gt; <br>
&gt; There are politicians I could say the same about.<br>
&gt; <br>
&gt; Cheers,<br>
&gt; Danny.<br>
&gt; <br>
&gt; -- <br>
&gt; <br>
&gt; Raw<br>
&gt; http://dannyayers.com<br>
&gt; <br>
</tt></font>
<br>
<br><font size=3D2 face=3D"sans-serif">- James M Snell<br>
 &nbsp;jasnell@us.ibm.com<br>
 &nbsp;http://www.ibm.com<br>
 &nbsp;(877) 511-5082 / Office<br>
 &nbsp;930-1979 / Tie Line</font>
<br>
--=_alternative 0057726E88256EC4_=--

---------z33668_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIIUOAIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIISWDCCAtow
ggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1
aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAy
MDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA629xc49NpAPz
cAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7glzJKgPkPzlTZZfznznGbmAWVnNBQ
lyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnwNclOnnP2sKufuPzbTImQTTi5c8JZNZcM
J0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEEBAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1Ud
DgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAPBgNVHRMBAf8EBTADAQH/MDEGA1UdJQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUH
AwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvu
jQupk2oCScMd3FIHLE7hOfu8YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14ke
McF9ViNdewEoBGiAycUq8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIC2jCCAkOgAwIB
AgIDAxS2MA0GCSqGSIb3DQEBBAUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwMTE0MjIw
NzExWhcNMTExMjMxMjIwNzExWjBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25h
bCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrb3Fzj02kA/NwCy5KFMiY
tFgyTJ6kMSQLVSs9uwVHIAVkqy/enDQwZ9b/7uCXMkqA+Q/OVNll/OfOcZuYBZWc0FCXI9qw60KO
J/rTd65FdF4dwp8cw8si0qjOJtYg8cm46fA1yU6ec/awq5+4/NtMiZBNOLlzwlk1lwwnRgXNNwID
AQABo4GqMIGnMBEGCWCGSAGG+EIBAQQEAwIAhzAOBgNVHQ8BAf8EBAMCAcYwHQYDVR0OBBYEFK5U
DpLqqDOpKyQtx8hvMNze80pAMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMA8GA1Ud
EwEB/wQFMAMBAf8wMQYDVR0lBCowKAYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYB
BQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAMnJ7c2YLyrY/PKlFl+7sm8NENfWtFxqdm+6NC6mTagJJ
wx3cUgcsTuE5+7xh9+/G0tTfLzA1qZAQ5GNMPXvmoB9+vJfKnC2JWMFQpIOUEJDXiR4xwX1WI117
ASgEaIDJxSrxHcuuV/hMIO9bgZ6C41MUVmdLTKBgBOImTuIPK8QwggMgMIICiaADAgECAgQ13vTP
MA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQL
EyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0MTUxWhcN
MTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMk
RXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKKlQRkrPFr
U18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkwrFEeO68r
1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOgYaRfMF0x
CzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBD
ZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAxODA4MjIx
NjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAdBgNV
HQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0HQQAEDTAL
GwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwlMQ0AppJu
f7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn00DbOyZY
sih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMgMIICiaADAgEC
AgQ13vTPMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0
MTUxWhcNMTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsG
A1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKK
lQRkrPFrU18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkw
rFEeO68r1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOg
YaRfMF0xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNl
Y3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAx
ODA4MjIxNjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAdBgNVHQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0H
QQAEDTALGwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwl
MQ0AppJuf7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn
00DbOyZYsih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMmMIIC
j6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIxNjM2NTRaMIGFMQsw
CQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEXMBUGA1UEAxMOSmFt
ZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkqhkiG9w0BCQEWEmph
c25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwKpbDG3zMatEuuOT
FYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSyd+7nwqAvbBfPj+0S
vcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7tBJlLrwDRCMoNlPuQ
Kg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQW
BBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOgFAwSamFzbmVs
bEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pAMCcGA1UdJQQgMB4G
CCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAZMKevB7dFfb9
23OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY8BjwVHxiYgG4xkxf
B1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOIzj3lz3xd+uOzqRFg
/Wsg/VMwggMmMIICj6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAy
BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNV
BAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIx
NjM2NTRaMIGFMQswCQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEX
MBUGA1UEAxMOSmFtZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkq
hkiG9w0BCQEWEmphc25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
wKpbDG3zMatEuuOTFYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSy
d+7nwqAvbBfPj+0SvcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7t
BJlLrwDRCMoNlPuQKg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQD
AgXgMB0GA1UdDgQWBBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcU
AgOgFAwSamFzbmVsbEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA
MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQAD
gYEAZMKevB7dFfb923OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY
8BjwVHxiYgG4xkxfB1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOI
zj3lz3xd+uOzqRFg/Wsg/VMxggG7MIIBtwIBATBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJ
bnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0g
Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwF+kzAJBgUrDgMCGgUAoIGiMBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDcwMTE1NTUwOVowIwYJKoZIhvcNAQkEMRYE
FJhL+IPwuFApiMx/ARC4exSO/g1/MEMGCSqGSIb3DQEJDzE2MDQwBwYFKw4DAh0wDgYIKoZIhvcN
AwICAgCAMAoGCCqGSIb3DQMHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAABV5chZq
2Ig24T77ZORDWovnzyDAf3EKChfDaCSCfbrr/swl8EFODoafiLrHRbw7ARWjXli3IW8KI67FZGRa
M5kKmtdL9WEbrHhYR/U0wj2qknC3fkHk7Y4ELTapg693Iua6p+vBeHYVX21+ck5d6xemPLVpUmPz
p1aCpPG1UdMAAAAA

---------z33668_boundary_sign--



From owner-atom-syntax@mail.imc.org  Thu Jul  1 12:18: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 MAA14724
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 12:18: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 i61G266w056639;
	Thu, 1 Jul 2004 09:02: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 i61G26l2056638;
	Thu, 1 Jul 2004 09:02:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from ixion.tartarus.org (ixion.tartarus.org [195.149.39.210])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i61G25bp056630
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 09:02:06 -0700 (PDT)
	(envelope-from james@ixion.tartarus.org)
Received: from james by ixion.tartarus.org with local (Exim 3.35 #1 (Debian))
	for atom-syntax@imc.org
	id 1Bg40k-00027g-00; Thu, 01 Jul 2004 17:02:06 +0100
Date: Thu, 1 Jul 2004 17:02:06 +0100
From: James Aylett <james@tartarus.org>
To: atom-syntax@imc.org
Subject: Re: PaceIntrospection: Is another file format really needed?
Message-ID: <20040701160206.GM1591@tartarus.org>
Mail-Followup-To: James Aylett <james@tartarus.org>, atom-syntax@imc.org
References: <1088696134.3664773123.17193.sendItem@bloglines.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1088696134.3664773123.17193.sendItem@bloglines.com>
User-Agent: Mutt/1.3.28i
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


On Thu, Jul 01, 2004 at 03:35:34PM -0000, kwark.1511609@bloglines.com wrote:

> But I do have an answer
> to your question: "What does the PaceIntrospection stop you from doing, exactly?"
> 
> The proposed introspection format does not allow me to subscribe to the
> introspection file containing my blog sites, with any of the current aggregators.
> ;-)

I've only just read PaceIntrospection, because I didn't think it would
be that interesting or contentious, and I don't really have the right
background to contribute without thinking much (:-). But now I have
and I think that this entire argument is bogus, and due to
a misconception of what the introspection (at least as it was when
originally debated pre-IETF) was for.

You introspect a feed to find its service API points.

PaceIntrospection seems to want to provide a single file that allows
you to find out information about /several/ feeds in one go. In my
view that (a) shouldn't be called introspection; (b) shouldn't
actually happen. (It doesn't help that it reminds me a little of P3P,
which is always guaranteed to make me shudder.)

What's the problem with having each feed point to an introspection
file which lists its service API points (URIs)? We have a way of any
web page that is associated with the feed to point to the Atom feed;
then the feed points to the introspection file; that tells you how to
edit the feed (and perhaps the underlying resource group, depending on
what you're doing). It's disadvantage is mostly in the number of
requests required, but without bloating either the HTML page or the
Atom feed, that looks unavoidable.

If we want to roll up several feeds in one so people can easily keep
track of (for instance) the feeds a site publishes, that is a
different issue and should be addressed separately.

James

-- 
/--------------------------------------------------------------------------\
  James Aylett                                                  xapian.org
  james@tartarus.org                               uncertaintydivision.org



From owner-atom-syntax@mail.imc.org  Thu Jul  1 12:39: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 MAA15801
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 12: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 i61GPQj5057848;
	Thu, 1 Jul 2004 09:25: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 i61GPQNH057847;
	Thu, 1 Jul 2004 09:25:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i61GPQKl057841
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 09:25:26 -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 1Bg4NK-0003Gq-Tl; Thu, 01 Jul 2004 16:25:27 +0000
Message-ID: <40E43AF3.4000206@franklinmint.fm>
Date: Thu, 01 Jul 2004 12:25:23 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: James Aylett <james@tartarus.org>
CC: atom-syntax@imc.org
Subject: Re: PaceIntrospection: Is another file format really needed?
References: <1088696134.3664773123.17193.sendItem@bloglines.com> <20040701160206.GM1591@tartarus.org>
In-Reply-To: <20040701160206.GM1591@tartarus.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: <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


James Aylett wrote:

>What's the problem with having each feed point to an introspection
>file which lists its service API points (URIs)? 
>

PaceIntrospection seems to be about "site" or "account" introspection.

Using your method, how would I find out where the endpoints are for my 
Typepad blinks, photo galleries, main blog, and template feeds are?

Robert Sayre



From owner-atom-syntax@mail.imc.org  Thu Jul  1 12: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 MAA16416
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 12:46: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 i61GXVvD058272;
	Thu, 1 Jul 2004 09:33: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 i61GXVxd058271;
	Thu, 1 Jul 2004 09:33:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from ixion.tartarus.org (ixion.tartarus.org [195.149.39.210])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i61GXVTC058265
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 09:33:31 -0700 (PDT)
	(envelope-from james@ixion.tartarus.org)
Received: from james by ixion.tartarus.org with local (Exim 3.35 #1 (Debian))
	for atom-syntax@imc.org
	id 1Bg4VB-0005Bd-00; Thu, 01 Jul 2004 17:33:33 +0100
Date: Thu, 1 Jul 2004 17:33:33 +0100
From: James Aylett <james@tartarus.org>
To: atom-syntax@imc.org
Subject: Re: PaceIntrospection: Is another file format really needed?
Message-ID: <20040701163333.GN1591@tartarus.org>
Mail-Followup-To: James Aylett <james@tartarus.org>, atom-syntax@imc.org
References: <1088696134.3664773123.17193.sendItem@bloglines.com> <20040701160206.GM1591@tartarus.org> <40E43AF3.4000206@franklinmint.fm>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <40E43AF3.4000206@franklinmint.fm>
User-Agent: Mutt/1.3.28i
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


On Thu, Jul 01, 2004 at 12:25:23PM -0400, Robert Sayre wrote:

> >What's the problem with having each feed point to an introspection
> >file which lists its service API points (URIs)? 
> 
> PaceIntrospection seems to be about "site" or "account" introspection.

Yes, which I don't understand the need for. Please enlighten me :-)
 
> Using your method, how would I find out where the endpoints are for my 
> Typepad blinks, photo galleries, main blog, and template feeds are?

I'd have thought you find them through the Typepad blinks, photo
gallery, main blog and so forth. It's likely I'm missing something
about how you need to operate (I have no idea what a template feed is
- I mean, I understand the words, but I don't know why you're rolling
templates into a feed) - is there a blow-by-blow description of what
job we want to do with this 'account introspection'?

Certainly I'd have thought that the photo gallery and the main blog
would have their own 'normal' URI presence, with (probably) HTML
behind it, or (if not) JPEG or something that we can embed RDF in via
XMP or whatever it is that Adobe are coming up with. Either way we can
link to the Atom feed as appropriate, which can link to the
introspection file so you can edit them.

For Typepad blinks, to be honest - I'm not sure. I'm not 100% clear
how the architecture is supposed to be viewed here. A blink feed is a
separate feed which happens to be aggregated into the display page of
another blog, right? In which case we maybe need to consider how to
express that at the HTML -> Atom feed stage.

But I'm probably wrong, of course :-)

James

-- 
/--------------------------------------------------------------------------\
  James Aylett                                                  xapian.org
  james@tartarus.org                               uncertaintydivision.org



From owner-atom-syntax@mail.imc.org  Thu Jul  1 13:06: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 NAA17506
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 13:06: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 i61GrCCb059599;
	Thu, 1 Jul 2004 09:53: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 i61GrCdB059598;
	Thu, 1 Jul 2004 09:53: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 (mail.gmx.de [213.165.64.20])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i61GrBUm059590
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 09:53:11 -0700 (PDT)
	(envelope-from derhoermi@gmx.net)
Received: (qmail 6388 invoked by uid 65534); 1 Jul 2004 16:53:08 -0000
Received: from dsl-082-082-076-081.arcor-ip.net (EHLO localhost) (82.82.76.81)
  by mail.gmx.net (mp001) with SMTP; 01 Jul 2004 18:53:08 +0200
X-Authenticated: #723575
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Antone Roundy <antone@geckotribe.com>
Cc: atom-syntax@imc.org
Subject: Re: PacePersonRef posted
Date: Thu, 01 Jul 2004 18:52:53 +0200
Message-ID: <40fd3d99.912001578@smtp.bjoern.hoehrmann.de>
References: <40fb292e.906774302@smtp.bjoern.hoehrmann.de> <466512F8-CB77-11D8-9B2F-003065EA6144@geckotribe.com>
In-Reply-To: <466512F8-CB77-11D8-9B2F-003065EA6144@geckotribe.com>
X-Mailer: Forte Agent 1.92/32.572
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


* Antone Roundy wrote:
>> Another question, how would an Atom implementation resolve the
>> ambiguity auf creator meta data? Names for example are not unique
>> so this seems to encourage guessing which is likely to break.
>
>If you're saying that this proposal would make that situation worse, 
>then I'm not following you.

I think so, it seems more difficult to infer from

  <author>
    <name>Mark</name>
  </author>
  ...
  <author>
    <name>Mark</name>
  </author>

that this is the same Mark as it would be from

  <author ref="x0001" />
  ...
  <author ref="x0001" />

so the proposal seems to make the format less intuitive and improper use
easier. If you'd actually generate two different person constructs for
the same meta data and thus use

  <author id="x0001">
    <name>Mark</name>
  </author>
  ...
  <author id="x0002">
    <name>Mark</name>
  </author>
  ...
  <author ref="x0001" />
  ...
  <author ref="x0002" />

what you safe in terms of bytes is rather insignificant so I am not
convinced that this would be very useful. Why do you re-use the author
element here? It would make more sense to me, as <author> would be
unstructured, to reference the author from the <entry> like

  <entry by = "x0001">...</entry>

>> We can provide control over the inheritance
>> if the entry author element is made optional and the case of an
>> entry without specified author becomes "ambiguous".
>
>I don't follow you.  If an entry has no author and we ARE using 
>inheritance, then it inherits from the feed, and is only ambiguous if 
>the feed also doesn't have an author, right?

Yes. Otherwise it is not really ambiguous but rather impossible to
specify anonymous authorship so the fact that everything would be
well-defined is not really helpful in that case.



From owner-atom-syntax@mail.imc.org  Thu Jul  1 13:37:07 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19826
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 13:37: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 i61HIMRQ061660;
	Thu, 1 Jul 2004 10: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 i61HIMT8061656;
	Thu, 1 Jul 2004 10:18:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i61HIK4D061637
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 10:18:20 -0700 (PDT)
	(envelope-from mint@franklinmint.fm)
Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94])
	by web02.designerslab.net with asmtp (Exim 4.34)
	id 1Bg5CX-0005Rw-Me; Thu, 01 Jul 2004 17:18:21 +0000
Message-ID: <40E4475A.4050901@franklinmint.fm>
Date: Thu, 01 Jul 2004 13:18:18 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: James Aylett <james@tartarus.org>
CC: atom-syntax@imc.org
Subject: Re: PaceIntrospection: Is another file format really needed?
References: <1088696134.3664773123.17193.sendItem@bloglines.com> <20040701160206.GM1591@tartarus.org> <40E43AF3.4000206@franklinmint.fm> <20040701163333.GN1591@tartarus.org>
In-Reply-To: <20040701163333.GN1591@tartarus.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: <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


James Aylett wrote:

>On Thu, Jul 01, 2004 at 12:25:23PM -0400, Robert Sayre wrote:
>
>  
>
>>>What's the problem with having each feed point to an introspection
>>>file which lists its service API points (URIs)? 
>>>      
>>>
>>PaceIntrospection seems to be about "site" or "account" introspection.
>>    
>>
>
>Yes, which I don't understand the need for. Please enlighten me :-)
> 
>  
>

I think PaceIntrospection is a simple version of WSDL.  Look at it from 
a use case perspective:

1.) I sign up for typepad.com
2.) I try out the web interface, but decide I would rather use my slick 
OS X Cocoa authoring program
3.) Where can I point my program so that I don't have to enter 
everything individually?

I've never used WSDL for anything other than SOAP, so I don't know how 
fully baked its ReST description capabilities are [1].

This proposal would seem to offer an alternative approach.

Robert Sayre

[1] http://www.w3.org/TR/2003/WD-wsdl12-bindings-20030611/#_http



From owner-atom-syntax@mail.imc.org  Thu Jul  1 13:58: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 NAA21307
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 13:58: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 i61HgYoK063907;
	Thu, 1 Jul 2004 10: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 i61HgYnq063906;
	Thu, 1 Jul 2004 10:42:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.250])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i61HgXQ7063900
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 10:42:33 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so4537209cwc
        for <atom-syntax@imc.org>; Thu, 01 Jul 2004 10:42:34 -0700 (PDT)
Received: by 10.11.116.8 with SMTP id o8mr113353cwc;
        Thu, 01 Jul 2004 10:42:34 -0700 (PDT)
Message-ID: <3f1451f504070110426546d6b4@mail.gmail.com>
Date: Thu, 1 Jul 2004 13:42:34 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Subject: Re: PacePersonRef posted
Cc: atom-syntax@imc.org
In-Reply-To: <40fa2813.906491626@smtp.bjoern.hoehrmann.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <BD09C408.1C7EB%eric.scheid@ironclad.net.au> <3f1451f50407010513393f1cb3@mail.gmail.com> <40fa2813.906491626@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 Thu, 01 Jul 2004 17:08:58 +0200, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
> 
> * Joe Gregorio wrote:
> >Of course any sort of 'id' referencing gets you into
> >the quagmire of XML ids, that is, the ability of processors
> >to identify an XML element by an explicit identifier
> >("IDness") has depended upon *validation*[1].
> 
> Validation is not really relevant here, a processor only needs to read
> the relevant schema information, which can be an external DTD subset or
> an internal DTD subset. Or a schema reference. Or a built-in schema. We
> could say, for example, that Atom implementations must consider specific
> attributes as ID attributes as defined in the XML Recommendation. That
> would not work for generic processors, but any IDness that does not come
> from the internal DTD subset is not guranteed to work in such processors
> anyway.

From "xml:id Requirements" [1]
-----
Since XML 1.0, the ability of processors to identify an XML element by
an explicit identifier ("IDness") has depended upon validation. Both
DTDs and [XML Schema] have mechanisms to identify the structures
containing unique identifiers. But neither XML Schema nor DTDs are
required by all processors. A common processor type does not perform
validation, nor fetch external resources for the purpose of
acertaining whether the document contains unique identifiers.

This document sets out the requirements for a mechanism for
determining "IDness" applicable to all classes of XML processors.
-----

[1]

    -joe



From owner-atom-syntax@mail.imc.org  Thu Jul  1 14:11:15 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22219
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 14:11: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 i61Huwlv065275;
	Thu, 1 Jul 2004 10: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 i61HuwpU065274;
	Thu, 1 Jul 2004 10:56: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 (mproxy.gmail.com [216.239.56.245])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i61Huv7d065268
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 10:56:57 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so4570079cwc
        for <atom-syntax@imc.org>; Thu, 01 Jul 2004 10:57:01 -0700 (PDT)
Received: by 10.11.116.8 with SMTP id o8mr115610cwc;
        Thu, 01 Jul 2004 10:57:01 -0700 (PDT)
Message-ID: <3f1451f504070110574ee7bee@mail.gmail.com>
Date: Thu, 1 Jul 2004 13:57:01 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: James Aylett <james@tartarus.org>
Subject: Re: PaceIntrospection: Is another file format really needed?
Cc: atom-syntax@imc.org
In-Reply-To: <20040701160206.GM1591@tartarus.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <1088696134.3664773123.17193.sendItem@bloglines.com> <20040701160206.GM1591@tartarus.org>
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 Thu, 1 Jul 2004 17:02:06 +0100, James Aylett <james@tartarus.org> wrote:
> 
> 
> On Thu, Jul 01, 2004 at 03:35:34PM -0000, kwark.1511609@bloglines.com wrote:
> 
> > But I do have an answer
> > to your question: "What does the PaceIntrospection stop you from doing, exactly?"
> >
> > The proposed introspection format does not allow me to subscribe to the
> > introspection file containing my blog sites, with any of the current aggregators.
> > ;-)
> 
> I've only just read PaceIntrospection, because I didn't think it would
> be that interesting or contentious, and I don't really have the right
> background to contribute without thinking much (:-). But now I have
> and I think that this entire argument is bogus, and due to
> a misconception of what the introspection (at least as it was when
> originally debated pre-IETF) was for.
> 
> You introspect a feed to find its service API points.
> 
> PaceIntrospection seems to want to provide a single file that allows
> you to find out information about /several/ feeds in one go. 

It allows you to find the facets of several 'sites' at one time.

> In my  view that (a) shouldn't be called introspection; (b) shouldn't
> actually happen. (It doesn't help that it reminds me a little of P3P,
> which is always guaranteed to make me shudder.)

Unfortunately it already does happen, at the end of the Pace it 
outlines where TypePad and Blogger *are already doing this*.
The solution *already deployed* has some ambiguity and this 
Pace is designed to remove that ambiguity and place this 
obviously needed functionality into the spec.

 
> If we want to roll up several feeds in one so people can easily keep
> track of (for instance) the feeds a site publishes, that is a
> different issue and should be addressed separately.

+1 

    -joe



From owner-atom-syntax@mail.imc.org  Thu Jul  1 14:52: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 OAA24912
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 14:52: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 i61IZ5sT071599;
	Thu, 1 Jul 2004 11:35: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 i61IZ5kQ071598;
	Thu, 1 Jul 2004 11:35: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 i61IZ49h071588
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 11:35: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 699C47C115; Thu,  1 Jul 2004 21:31:26 +0200 (CEST)
Date: Thu, 01 Jul 2004 20:38:00 +0200
To: "Beecher Greenman" <millennium@spoonybards.net>
Subject: Re: PaceIntrospection: Is another file format really needed?
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <40DC2066.1070100@spoonybards.net>	<m3lliaxf10.fsf@bitsko.slc.ut.us> <40DF403D.5050808@spoonybards.net>	<1C98E8B4-C928-11D8-B7C2-000A95B09B46@google.com>	<m33c4fwfwh.fsf@bitsko.slc.ut.us> <40E1A28B.6090302@aol.com>	<40E1EFFB.4090602@spoonybards.net> <m3isd9vk7k.fsf@bitsko.slc.ut.us> <40E2D7AD.3070404@virgilio.it> <opsae8biqruvpchu@quark> <40E37DB8.9040403@spoonybards.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: <opsag11mk4uvpchu@quark>
In-Reply-To: <40E37DB8.9040403@spoonybards.net>
User-Agent: Opera M2/7.51 (Win32, build 3798)
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 Wed, 30 Jun 2004 22:58:00 -0400, Beecher Greenman  
<millennium@spoonybards.net> wrote:

>> There's  no real point in reusing atom:feed and atom:entry if what  
>> we're trying to  do with them is totally different from the element's  
>> original purpose.
>
> Except that introspection exactly fits the element's original purpose. I  
> offer the following as proof:

Ok, I see your points in that the Atom feed can be overloaded, and that  
its initial «intention text» wasn't clarifying enough to separate issues  
as introspection from regular resource-subscription. I think, however,  
that it is a huge difference. No one is going to subscribe to a  
introspection file. It will probably be updated at most once a year.  
There's no dynamic information in it, so there's no need for a tool to  
re-read it once it's first read.

The use-pattern of an introspection file is completely different from that  
of an ordinary subscription-based feed, so I don't think the <feed>  
element should be overloaded. It would be nice if you could provide an  
example (on the Wiki) of how you think such a introspection feed should  
look like, 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 Jul  1 15:52: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 PAA28910
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 15:52:53 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i61JdtDl077125;
	Thu, 1 Jul 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 i61Jdt3H077124;
	Thu, 1 Jul 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 smtpgateway.itweb.no ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i61Jds2O077115
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 12:39: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 5DF197C115; Thu,  1 Jul 2004 22:36:21 +0200 (CEST)
To: "Ezra Cooper" <ezra@sixapart.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceSecurityServices & Digest auth
References: <37DF50E8-CB00-11D8-8081-000A95CFF6CC@sixapart.com>
Message-ID: <opsag42attuvpchu@quark>
Date: Thu, 01 Jul 2004 21:43:12 +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: <37DF50E8-CB00-11D8-8081-000A95CFF6CC@sixapart.com>
User-Agent: Opera M2/7.51 (Win32, build 3798)
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 Wed, 30 Jun 2004 18:44:40 -0700, Ezra Cooper <ezra@sixapart.com> wrote:

> I'd like to express support for specifying some authentication method(s)  
> for use with Atom

As a matter of fact, I think Atom not only should, but must provide some  
sort of security guidelines, including authentication (but maybe stuff  
including encryption of sensitive information etc as well). Why? As RFC  
3470 says:

   Given the lack of security services in XML, it is imperative that
   protocol specifications mandate additional security services to
   counter common threats and attacks; the specific required services
   will depend on the protocol's threat model.

So, Atom SHOULD define some sort of authentication method in the  
specification, or at least give some references.

-- 
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 Jul  1 16:09: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 QAA29577
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 16:09: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 i61JsQFs079190;
	Thu, 1 Jul 2004 12:54: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 i61JsQt6079189;
	Thu, 1 Jul 2004 12:54: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 i61Jrtll079128
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 12:54: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 83DC47C115; Thu,  1 Jul 2004 22:50:22 +0200 (CEST)
Date: Thu, 01 Jul 2004 21:57:17 +0200
To: "Antone Roundy" <antone@geckotribe.com>
Subject: Re: PacePersonRef posted
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <07EC2531-CB66-11D8-9B2F-003065EA6144@geckotribe.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: <opsag5prnauvpchu@quark>
In-Reply-To: <07EC2531-CB66-11D8-9B2F-003065EA6144@geckotribe.com>
User-Agent: Opera M2/7.51 (Win32, build 3798)
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 Thu, 1 Jul 2004 07:53:28 -0600, Antone Roundy <antone@geckotribe.com>  
wrote:

> xml:id sounds good to me.

+1.

> Comments on xlink:href, anyone?

I think the whole 'href', 'hreflang', 'lang' and 'base' attribute soup  
should be sorted out, as I've stated in another e-mail[1] to this list.

Until we've sorted it out, we should imho just use 'href' as is, just as  
we're using <link> as is, until we've figured out the whole LinkConstruct  
debacle.

> As mentioned elsewhere, I'm not in favor or allowing references to  
> externally defined Person constructs, so if xlink:href were used (and my  
> preference were to prevail!), we'd need to specify that constraint.

I think using @href instead of @ref, and then prefix internally referenced  
authors with '#', would do the trick. Adding a @type would allow for other  
person identification formats than FOAF externally. E.g.:

   <author type="application/rdf+xml" href="http://example.com/me.foaf" />

This could, of course, be:

   <link rel="author" type="application/rdf+xml"
     href="http://example.com/me.foaf" />

as well, but that will be sorted out when the link discussion reaches  
consensus (on whatever). Here's an example of an internal reference:

   <author xml:id="author1">
     <name>Asbjørn Ulsberg</name>
   </author>

   <author href="#author1" />

> I don't suppose there's a generic referencing mechanism already
> defined for local-only references, is there?

Not for local-only, afaik, but prefixing local references with '#' is a  
standard mechanism.

____
[1] <url: http://www.imc.org/atom-syntax/mail-archive/msg06048.html>

-- 
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 Jul  1 16:15: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 QAA29693
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 16:15:10 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i61K0wpc079586;
	Thu, 1 Jul 2004 13:00: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 i61K0wCf079585;
	Thu, 1 Jul 2004 13:00: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 ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i61K0v7O079578
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 13:00: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 D64D67C117; Thu,  1 Jul 2004 22:57:23 +0200 (CEST)
To: "Eric Scheid" <eric.scheid@ironclad.net.au>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PacePutIpAddrInEntry
References: <BD09CAB6.1C80A%eric.scheid@ironclad.net.au>
Message-ID: <opsag51ir2uvpchu@quark>
Date: Thu, 01 Jul 2004 22:04:20 +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: <BD09CAB6.1C80A%eric.scheid@ironclad.net.au>
User-Agent: Opera M2/7.51 (Win32, build 3798)
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 Thu, 01 Jul 2004 14:05:42 +1000, Eric Scheid  
<eric.scheid@ironclad.net.au> wrote:

>> Speaking of... Is there a common designation for IP addresses and DNS
>> names we could use instead of 'ipaddr' or 'ip-address'?
>
> ModWiki uses <host>

+1 on <host>, then. It might be a bit ambiguous, or at least somewhat hard  
to understand, but what it's for will be written in the spec., so it's no  
big issue. <host> is at least better than both <ipaddr> and <ip-address>,  
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  Thu Jul  1 16:27:29 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00026
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 16:27:28 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i61K1xNV079650;
	Thu, 1 Jul 2004 13:01:59 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i61K1xDu079649;
	Thu, 1 Jul 2004 13:01:59 -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 i61K1x9U079639
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 13:01: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 (rwcrmhc11) with SMTP
          id <2004070120015601300bavije>; Thu, 1 Jul 2004 20:01:56 +0000
Date: Thu, 1 Jul 2004 14:01:54 -0600
Subject: Re: PacePersonRef posted
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v553)
From: Antone Roundy <antone@geckotribe.com>
To: atom-syntax@imc.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <40fd3d99.912001578@smtp.bjoern.hoehrmann.de>
Message-Id: <802BB3AA-CB99-11D8-9B2F-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 Thursday, July 1, 2004, at 10:52  AM, Bjoern Hoehrmann wrote:
> * Antone Roundy wrote:
>>> Another question, how would an Atom implementation resolve the
>>> ambiguity auf creator meta data? Names for example are not unique
>>> so this seems to encourage guessing which is likely to break.
>> If you're saying that this proposal would make that situation worse,
>> then I'm not following you.
> I think so, it seems more difficult to infer from
>
>   <author>
>     <name>Mark</name>
>   </author>
>   ...
>   <author>
>     <name>Mark</name>
>   </author>
>
> that this is the same Mark as it would be from
>
>   <author ref="x0001" />
>   ...
>   <author ref="x0001" />

Okay, I see what you're saying now.  But I'd have to say it doesn't 
worry me too much.  If someone is concerned enough about their identity 
being properly understood, they should probably put a little more data 
in their author records.  And as they do, the probability of two 
different people having identical information in one feed will drop 
precipitously.

> so the proposal seems to make the format less intuitive and improper 
> use
> easier. If you'd actually generate two different person constructs for
> the same meta data and thus use
>
>   <author id="x0001">
>     <name>Mark</name>
>   </author>
>   ...
>   <author id="x0002">
>     <name>Mark</name>
>   </author>
>   ...
>   <author ref="x0001" />
>   ...
>   <author ref="x0002" />

If you know that the people are different, this probably is what I 
would expect to have done (except that the first elements in the 
example would be <person> rather than <author>...but that's not 
relevant to our current discussion).

If this proposal may make the mistake of thinking two different people 
are the same people more probable.  But conversely, it makes it 
POSSIBLE to unambiguously differentiate between two people with 
identical author metadata.

> what you safe in terms of bytes is rather insignificant so I am not
> convinced that this would be very useful.
If the Person construct contains nothing but a 4 letter name, the id is 
5 letters long, and each person authored less than 4 entries, then 
yeah, you'd actually use more bytes.  But in this case:

<person id="1">
	<name>Antone Roundy</name>
	<url>http://www.geckotribe.com/</url>
</person>

<author ref="1" />

...the reference requires just over 1/5 as many characters as the full 
Person construct would have.  As additional information gets added to 
Person constructs, the savings grow even faster.

> Why do you re-use the author
> element here? It would make more sense to me, as <author> would be
> unstructured, to reference the author from the <entry> like
>
>   <entry by = "x0001">...</entry>
If size savings were the ONLY concern, that would be the way to go, and 
in fact, we'd put just about everything into <entry> as an attribute.  
But then, as others have said, if size savings were our primary concern 
we wouldn't be using XML at all.  The line between what goes into 
attributes and what goes into child elements has to be drawn somewhere, 
and I for one think that <author> and <contributor> information goes on 
the other side of the line.

>>> We can provide control over the inheritance
>>> if the entry author element is made optional and the case of an
>>> entry without specified author becomes "ambiguous".
>>
>> I don't follow you.  If an entry has no author and we ARE using
>> inheritance, then it inherits from the feed, and is only ambiguous if
>> the feed also doesn't have an author, right?
>
> Yes. Otherwise it is not really ambiguous but rather impossible to
> specify anonymous authorship so the fact that everything would be
> well-defined is not really helpful in that case.
>
I'm afraid I still don't entirely follow.  I suppose there are two 
issues: anonymous authorship and unknown authorship.  I don't see that 
this proposal affects anonymous authorship in any way--it's currently 
impossible to indicate that (other than to say something like 
<author><name>anonymous</name></author>, which doesn't entirely work, 
because what if the author's name (or nickname) really is 
"anonymous"?)--and this proposal doesn't change that.  Currently, there 
is likewise no way to specify an unknown author--if author were 
optional, that could be done by specifying neither a feed-level author 
nor an entry-level author, but making the entry author optional would 
only make the author unknown if no feed author were specified.  This 
proposal makes unknown authorship possible to indicate by omitting the 
entry author.



From owner-atom-syntax@mail.imc.org  Thu Jul  1 16:27: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 QAA00044
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 16:27: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 i61KAWME080380;
	Thu, 1 Jul 2004 13: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 i61KAWj0080379;
	Thu, 1 Jul 2004 13:10: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 ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i61KAVvp080370
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 13:10:31 -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 C28B37C115; Thu,  1 Jul 2004 23:06:57 +0200 (CEST)
To: mint@franklinmint.fm
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceIntrospection: Is another file format really needed?
References: <1088682498.3099226561.2678.sendItem@bloglines.com> <40E3FF75.50906@franklinmint.fm>
Message-ID: <opsag6hisxuvpchu@quark>
Date: Thu, 01 Jul 2004 22:13:56 +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: <40E3FF75.50906@franklinmint.fm>
User-Agent: Opera M2/7.51 (Win32, build 3798)
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 Thu, 01 Jul 2004 08:11:33 -0400, Robert Sayre <mint@franklinmint.fm>  
wrote:

> Or did you mean typing a term in and getting a search results back? I  
> would probably use an HTML page for that.

Hopefully not, at least not in the future:

<url: http://www.intertwingly.net/wiki/pie/RestEchoSearchApi>

> What problem is solved by making feed the root element for both  
> purposes? Why does it matter?

I would really like an answer to this question 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 Jul  1 16:31: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 QAA00175
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 16:31: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 i61KITnw081011;
	Thu, 1 Jul 2004 13:18: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 i61KITlK081010;
	Thu, 1 Jul 2004 13:18:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rongo.sixapart.com (dsl081-057-015.sfo1.dsl.speakeasy.net [64.81.57.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i61KITFi081002
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 13:18:29 -0700 (PDT)
	(envelope-from ezra@sixapart.com)
Received: from [192.168.100.239] (Aphrodite.sm.sixapart.com [192.168.100.239])
	by rongo.sixapart.com (Postfix) with ESMTP
	id 5FAAE47E9C; Thu,  1 Jul 2004 12:16:00 -0700 (PDT)
In-Reply-To: <40e424a2.905610158@smtp.bjoern.hoehrmann.de>
References: <37DF50E8-CB00-11D8-8081-000A95CFF6CC@sixapart.com> <40e424a2.905610158@smtp.bjoern.hoehrmann.de>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <D00D0FEB-CB9B-11D8-8C15-000A95CFF6CC@sixapart.com>
Content-Transfer-Encoding: 7bit
Cc: atom-syntax@imc.org
From: Ezra Cooper <ezra@sixapart.com>
Subject: Re: PaceSecurityServices & Digest auth
Date: Thu, 1 Jul 2004 13:18:27 -0700
To: Bjoern Hoehrmann <derhoermi@gmx.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>
Content-Transfer-Encoding: 7bit


On Jul 1, 2004, at 8:03 AM, Bjoern Hoehrmann wrote:

> The relevant header is the "Authorization" request header,
> WWW-Authenticate is a response header which a CGI program
> would normally not see but rather emit.

Right, sorry, I got this backwards. The text should read:

========
An Atom client MAY authenticate itself to an Atom server by sending an 
X-Atom-Authorization HTTP header, in the same form as for the 
Authorization header [RFC2617]. If an Atom client sends an 
Authorization header, it SHOULD have the same value as the 
X-Atom-Authorization header.
========

An (abbreviated) example communication would be something like the 
following. Messages sent by the server are prefixed by S: and those 
sent by the client are prefixed by C:

================= first request =================
C: POST /some/atom/resource HTTP/1.1
C: Host: some-atom-server.com
C: Content-length: [length of message-body]
C:
C: [some XML]
S: 401 Unauthorized
S: WWW-Authenticate: Digest realm=myrealm@some-atom-server.com, 
nonce=6Fg8k+ah4t1p/A86az=, algorithm=MD5
================ second request ================
C: POST /some/atom/resource HTTP/1.1
C: X-Atom-Authorization: Digest username=ezra, 
realm=myrealm@some-atom-server.com, nonce=6Fg8k+ah4t1p/A86az=, 
uri=http://some-atom-server.com/some/atom/resource, 
response=deadbeefdeadbeefdeadbeefdeadbeef, algorithm=MD5
C:
C: [some XML]
S: 201 Created
S: [further headers, response message-body]
============================================

It should be clear that the syntax and semantics of this header 
(X-Atom-Authorization) would be exactly those of the usual 
Authorization header, simply renamed in order to get past certain 
troublesome web servers.

Ezra



From owner-atom-syntax@mail.imc.org  Thu Jul  1 17:39: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 RAA02875
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 17:39: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 i61LOwMH085509;
	Thu, 1 Jul 2004 14:24: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 i61LOwYP085508;
	Thu, 1 Jul 2004 14:24: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 ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i61LOvt0085490
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 14:24: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 8EF327C115; Fri,  2 Jul 2004 00:21:23 +0200 (CEST)
To: "Antone Roundy" <antone@geckotribe.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PacePersonRef posted
References: <802BB3AA-CB99-11D8-9B2F-003065EA6144@geckotribe.com>
Message-ID: <opsag9x0iiuvpchu@quark>
Date: Thu, 01 Jul 2004 23:28: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: <802BB3AA-CB99-11D8-9B2F-003065EA6144@geckotribe.com>
User-Agent: Opera M2/7.51 (Win32, build 3798)
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 Thu, 1 Jul 2004 14:01:54 -0600, Antone Roundy <antone@geckotribe.com>  
wrote:

> <person id="1">

An 'id', in HTML and XML terms, should start with a letter.

> <author ref="1" />

Internal references should start with '#', and I really don't see the need  
for @ref when we already use @href everywhere.

-- 
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 Jul  1 17:44: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 RAA03078
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 17:44: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 i61LV2nA085918;
	Thu, 1 Jul 2004 14:31: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 i61LV24K085917;
	Thu, 1 Jul 2004 14:31:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from vspmail.nscp.aoltw.net (h-64-236-138-233.aoltw.net [64.236.138.233])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i61LV1wq085904
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 14:31:01 -0700 (PDT)
	(envelope-from jpanzer@AOL.NET)
Received: from h-10-169-146-121.nscp.aoltw.net (h-10-169-146-121.nscp.aoltw.net [10.169.146.121])
	by vspmail.nscp.aoltw.net (8.11.6/8.11.6) with ESMTP id i61LYWs17291;
	Thu, 1 Jul 2004 14:34:32 -0700
Date: Thu, 1 Jul 2004 14:29:38 -0700
From: "John Panzer" <jpanzer@aol.net>
Subject: Re: PaceIntrospection - A use case.  (was Re: PaceIntrospection: Is another
 file format really needed?)
To: "Joe Gregorio" <joe.gregorio@gmail.com>
cc: "James Aylett" <james@tartarus.org>, atom-syntax@imc.org
In-Reply-To: <3f1451f504070110574ee7bee@mail.gmail.com>
Message-ID: <40E48242.8070205@AOL.NET>
References: <1088696134.3664773123.17193.sendItem@bloglines.com> <20040701160206.GM1591@tartarus.org> <3f1451f504070110574ee7bee@mail.gmail.com>
X-Mailer: AOL Communicator (20030919.3 Win)
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>




Joe Gregorio wrote on 7/1/2004, 10:57 AM:

 >
 > On Thu, 1 Jul 2004 17:02:06 +0100, James Aylett <james@tartarus.org>
 > wrote:
 > >
 > >
 > > On Thu, Jul 01, 2004 at 03:35:34PM -0000,
 > kwark.1511609@bloglines.com wrote:
 > >
 > > > But I do have an answer
 > > > to your question: "What does the PaceIntrospection stop you from
 > doing, exactly?"
 > > >
 > > > The proposed introspection format does not allow me to subscribe
 > to the
 > > > introspection file containing my blog sites, with any of the
 > current aggregators.
 > > > ;-)
 > >
 > > I've only just read PaceIntrospection, because I didn't think it would
 > > be that interesting or contentious, and I don't really have the right
 > > background to contribute without thinking much (:-). But now I have
 > > and I think that this entire argument is bogus, and due to
 > > a misconception of what the introspection (at least as it was when
 > > originally debated pre-IETF) was for.
 > >
 > > You introspect a feed to find its service API points.
 > >
 > > PaceIntrospection seems to want to provide a single file that allows
 > > you to find out information about /several/ feeds in one go.
 >
 > It allows you to find the facets of several 'sites' at one time.
 >
 > > In my  view that (a) shouldn't be called introspection; (b) shouldn't
 > > actually happen. (It doesn't help that it reminds me a little of P3P,
 > > which is always guaranteed to make me shudder.)
 >
 > Unfortunately it already does happen, at the end of the Pace it
 > outlines where TypePad and Blogger *are already doing this*.
 > The solution *already deployed* has some ambiguity and this
 > Pace is designed to remove that ambiguity and place this
 > obviously needed functionality into the spec.
 >
 >
 > > If we want to roll up several feeds in one so people can easily keep
 > > track of (for instance) the feeds a site publishes, that is a
 > > different issue and should be addressed separately.
 >
 > +1
 >

I have a use case for combining the two:  AOL Journals lets a user 
create as many blogs as they want to; the main pages for these blogs are 
always under http://journals.aol.com/username/blogname.  We have to 
provide a standard way to provide a list of the blogs that's easily 
discoverable given the username.  This list is dynamic and can change 
from hour to hour, though usually it'd be pretty stable.  The contents 
of the list, in our case, can change depending on the _requestor_ of the 
list -- anonymous requests would get only public blogs, whereas 
authenticated users would get a list of both public blogs and private 
blogs to which the requestor has been granted access.

The data that a client would want includes an endpoint for getting a 
list of entries (the <feed>), a URI to the corresponding HTML page if 
one exists, and perhaps endpoints such as post, comment, etc. This 
enables software to offer status information (e.g., last post date), 
subscription, posting, commenting, etc. services.

It seems useful to me to combine the query-to-get-the-list with the 
query-to-get-the-endpoints, because they will in reality be combined for 
this use case.  It could save dozens of HTTP round trips to the server 
to gather all of the information, which could be a significant win in 
terms of latency.

We are wrestling with these issues right now for AOL Journals, so these 
are not just theoretical considerations.

Note that in this _particular_ use case, the 'introspection' file is 
really a dynamic feed-like-thing.  One could imagine, for example, 
software that lets you say 'let me know whenever Joe Gregorio creates a 
new blog!' and uses a feed-like mechanism for polling for this.  We'd 
want to re-use the Atom authentication mechanisms, polling time hinting, 
HTTP caching, etc. etc. for this data just as we would for an 
entry-based feed.  So I think there's some justification for treating it 
like a feed.

(There are other, more blue sky, use cases.  Consider a feed of 
endpoints for all new blogs created by people you know, whether or not 
you've ever subscribed to any of their blogs.)

John Panzer
http://journals.aol.com/panzerjohn/abstractioneer




From owner-atom-syntax@mail.imc.org  Thu Jul  1 18: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 SAA05641
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 18: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 i61M7sR0088114;
	Thu, 1 Jul 2004 15:07: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 i61M7svU088113;
	Thu, 1 Jul 2004 15:07:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from lakermmtao02.cox.net (lakermmtao02.cox.net [68.230.240.37])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i61M7rio088106
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 15:07:53 -0700 (PDT)
	(envelope-from millennium@spoonybards.net)
Received: from [10.0.1.2] (really [68.105.186.6]) by lakermmtao02.cox.net
          (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with ESMTP
          id <20040701220753.YJRZ923.lakermmtao02.cox.net@[10.0.1.2]>
          for <atom-syntax@imc.org>; Thu, 1 Jul 2004 18:07:53 -0400
Message-ID: <40E48B38.1000308@spoonybards.net>
Date: Thu, 01 Jul 2004 18:07:52 -0400
From: Beecher Greenman <millennium@spoonybards.net>
User-Agent: Mozilla Thunderbird 0.7 (Macintosh/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceIntrospection: Is another file format really needed?
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


 >>>>>> There's no real point in reusing atom:feed and atom:entry if 
what we're trying
 >>>>>> to do with them is totally different from the element's original 
purpose.
 >>
 >>>> Except that introspection exactly fits the element's original purpose.
 >>>> I offer the following as proof:


 >> Ok, I see your points in that the Atom feed can be overloaded, and 
that its initial
 >> «intention text» wasn't clarifying enough to separate issues as 
introspection from
 >> regular resource-subscription. I think, however, that it is a huge 
difference. No one
 >> is going to subscribe to a introspection file.


I admit to not seeing much use to it myself, but I wouldn't go to such 
extremes.

Let us suppose, for example, that some large site decided to keep a list 
of its
most popular services. Depending on a huge variety of factors, this list 
could very
well change daily. Suppose they wanted to offer this list in Atom. This 
seems like
a reasonable use for a syndication feed. But this is a list of sites, 
not a list
of articles; if a feed can be used for such a purpose, then a feed must 
also be
usable for introspection as well.


 >> It will probably be updated at most once a year.
 >> There's no dynamic information in it, so there's
 >> no need for a tool to re-read it once it's first read.


Again, I would not go to these extremes. It is true that a typical 
introspection
file will seldom be updated, and so there will not be much need for a 
tool to
re-read it once it is first read. If a tool should try, then the server 
can simply
send HTTP status code 304, 'Not Modified', just as it would for a 
syndication feed.


 >> The use-pattern of an introspection file is completely different 
from that of an
 >> ordinary subscription-based feed, so I don't think the <feed> 
element should be
 >> overloaded. It would be nice if you could provide an example (on the 
Wiki) of how
 >> you think such a introspection feed should look like, though.


I sent one example to the list already, which included capabilities. 
There has recently
been some discussion on this list arguing that a service list should not 
include
capabilities; my example can be pared down to do this as well.

I will add these both to the Wiki tonight; should I add it to 
PaceIntrospection,
or should I create a new pace for it, perhaps PaceServiceList, and drop 
this out of
PaceIntrospection altogether, since there is some debate on whether this 
should be
called "introspection" anyway?

- Beecher Greenman



From owner-atom-syntax@mail.imc.org  Thu Jul  1 18:20: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 SAA05659
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 18: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 i61M7Bbj088089;
	Thu, 1 Jul 2004 15:07:11 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i61M7B6L088088;
	Thu, 1 Jul 2004 15:07:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from lakermmtao03.cox.net (lakermmtao03.cox.net [68.230.240.36])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i61M7A2u088074
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 15:07:10 -0700 (PDT)
	(envelope-from millennium@spoonybards.net)
Received: from [10.0.1.2] (really [68.105.186.6]) by lakermmtao03.cox.net
          (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with ESMTP
          id <20040701220709.SCKH3786.lakermmtao03.cox.net@[10.0.1.2]>
          for <atom-syntax@imc.org>; Thu, 1 Jul 2004 18:07:09 -0400
Message-ID: <40E48B0C.6080708@spoonybards.net>
Date: Thu, 01 Jul 2004 18:07:08 -0400
From: Beecher Greenman <millennium@spoonybards.net>
User-Agent: Mozilla Thunderbird 0.7 (Macintosh/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceIntrospection: Is another file format really needed?
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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 Thu, Jul 01, 2004 at 03:35:34PM -0000, 
kwark.1511609@xxxxxxxxxxxxx wrote:
 >>
 >>> > But I do have an answer
 >>> > to your question: "What does the PaceIntrospection stop you from 
doing, exactly?"
 >>> >
 >>> > The proposed introspection format does not allow me to subscribe 
to the
 >>> > introspection file containing my blog sites, with any of the 
current aggregators.
 >>> >  ;-)
 >>
 >> I've only just read PaceIntrospection, because I didn't think it would
 >> be that interesting or contentious, and I don't really have the right
 >> background to contribute without thinking much (:-). But now I have
 >> and I think that this entire argument is bogus, and due to
 >> a misconception of what the introspection (at least as it was when
 >> originally debated pre-IETF) was for.

I have seen these original drafts. Although the name "introspection" 
might be poorly given, the concept behind PaceIntrospection -the ability 
to find out the sites for which a given user is responsible- remains 
something for which there is a real-world need.

It is true that if either PaceIntrospection or my feed-based proposal is 
used along with the current spec as written, a certain amount of data is 
duplicated: namely, the links to discover each service's API points. 
PaceIntrospection and my feed-based introspection proposal both call for 
these to be included in the introspection file via <link> tags, and the 
current specification calls for these links to be included in the 
service's main HTML, again via <link> tags.

At this point in time -just judging from the requirements of 
PaceIntrospection, which I understand are not agreed upon yet- any 
service being introspected will have between one and four <link> tags in 
the introspection file (again, whichever format is being used):
   - Almost all services should have a <link rel="alternate" />, which 
points to the service itself. Without a link to the service, there is 
little point in having it in an introspection file in the first place.
   - Most services -those which can be syndicated, including sites, 
articles within sites, and such- should have a <link rel="service.feed" 
/> tag. The only example I can think of at the moment which might not 
have this tag, actually, would be a comment within an article on a site.
   - Those services to which "entries" can be added should have a <link 
rel="service.post" /> tag. This might include a site where entries 
represent articles, or an article within a site, where entries represent 
comments. Theoretically this could be extended to a user where entries 
represent sites, allowing Atom to be used to create or delete new sites 
-Weblogs, for example- but that's outside the scope of these proposals.
   - Those services which can be edited directly should have a <link 
rel="service.edit" /> tag. This would include articles within a site or 
comments within an article. Theoretically this could be extended to 
templates within a site as well. I don't immediately see any use for 
directly editing a site itself, but I see no reason to exclude it 
either; no doubt someone will come up with a use I haven't thought of.

Of these, up to three tags might be duplicated in the HTML (or other 
applicable markup language) of the service itself. The first one on the 
list, which points to the service itself, doesn't make sense for 
duplication in the service, since the user-agent is by definition 
already pointing there. This seems to be the kind of introspection that 
you're talking about, such that a user-agent could find a site's 
service.feed, service.edit, and service.post links by looking at the 
service itself.

 >> You introspect a feed to find its service API points.

You don't introspect a feed at all, because a feed is not a "thing" to 
be introspected. You could introspect sites, entries, users, or whatever 
else, but a feed is a representation of something, not the thing itself. 
What exactly a feed can represent is at the core of this debate, but I 
don't think there's any argument that a feed is an actual object instead 
of a representation.

 >> PaceIntrospection seems to want to provide a single file that allows
 >> you to find out information about /several/ feeds in one go. In my
 >> view that (a) shouldn't be called introspection; (b) shouldn't
 >> actually happen. (It doesn't help that it reminds me a little of P3P,
 >> which is always guaranteed to make me shudder.)

You're not finding out information about several feeds in one go; you're 
finding out information about several services in one go. A feed 
represents a service but it is not the service itself.

Anyway, an honest question, first: why should this not be called 
introspection? Although the user is performing it against an author 
rather than a service, the principle seems to still apply.

Second: why should this not happen? There is certainly a real need to 
list the services for which a user is responsible; this necessity is at 
the core of both PaceIntrospection and my feed-based introspection 
proposal. A common use case comes to mind: a publishing tool where a 
user logs in and is presented with a list of his services, from which he 
may then choose one or several to update. Should this process also 
reveal information on each service's capabilities? This is, admittedly, 
debatable.

If we decide that capabilities should not be revealed in such a list, 
then the <link rel="service.xxxxx" /> links could be cut out of the 
files (the <link rel="alternate" /> links would need to remain). In that 
case, then things seem much more appropriate to my feed-based 
"introspection" proposal, though you're right that it shouldn't really 
be called introspection at that point. If, however, we decide that 
capabilities should be revealed in such a list, then the question of 
which proposal is more appropriate becomes less obvious. I believe that 
my proposal is still the more appropriate choice, as it takes advantage 
of the power of an existing Atom technology rather than reinventing the 
wheel, but I can see where my opposition might not believe this.

For the record, I believe that revealing capability introspection in a 
service list would be highly useful. Although there are use cases for a 
user-agent which simply lists the services and presents a user with Web 
links to each one, most user-agents are likely to want to actually do 
something with one or more of these services. Keep in mind that the 
content of the service request is likely to be larger than the 
introspection file, and most of the content of that request cannot be 
used by Atom anyway. Requiring the client to request the service to get 
its capabilities will at least double network overhead in most cases, 
and most of that extra overhead will be wasted. In this age of broadband 
that extra bandwidth may not mean much on the client end, where 
everything is measured in seconds per request, but it makes a world of 
difference on the server end, where things are more often measured in 
requests per second.

Does this mean that introspection links should be taken out of the 
service itself, leaving only a service.introspection or service.feed 
link? I don't know. The current method does embed a little data into 
each service request whether or not Atom is involved, and that does mean 
that we create overhead even outside of Atom. A little overhead of this 
type -for the link to an introspection file, if nothing else- is 
unavoidable, but there is a school of thought saying that we should 
minimize this. At the same time, let us consider the overhead for Atom 
itself. For small deployments, particularly those where there is only 
one service per user, it is unclear whether any bandwidth can really be 
saved by keeping this information in the service. For larger 
deployments, however, when one user might be responsible for many sites, 
the bandwidth savings for in-service introspection are clear, since a 
request for an introspection file may involve many services, only one of 
which the user may want.

It seems to me, then, as though if we want to have minimal impact on the 
network, it is probably safest to include the capability information in 
both places: an introspection-capable file and the service itself. Each 
place has unique advantages that the other cannot duplicate, and in both 
cases the bandwidth advantage actually goes to showing this data in both 
areas. The separate file is useful when we only know which user is 
accessing the system, but not what service he might want to update, and 
this is a more common scenario than might initially be believed. 
Meanwhile, the in-service introspection links are more useful when we 
know which service we want to update, because we do not waste bandwidth 
on other services that we know we don't want.

 >> What's the problem with having each feed point to an introspection
 >> file which lists its service API points (URIs)? We have a way of any
 >> web page that is associated with the feed to point to the Atom feed;
 >> then the feed points to the introspection file; that tells you how to
 >> edit the feed (and perhaps the underlying resource group, depending on
 >> what you're doing). It's disadvantage is mostly in the number of
 >> requests required, but without bloating either the HTML page or the
 >> Atom feed, that looks unavoidable.

Indeed, it's unavoidable, but is it necessarily bloat? It seems that 
putting the information in both places actually ends up doing less 
damage overall than putting the data in only one place. It's not good 
database theory, but we're not a database; we're an API which has to 
communicate over a medium where latency is still relatively high. It's 
not uncommon nowadays to hear that the biggest problem with Web-based 
applications is the inherently high-latency interfaces with which we 
must interact; we cannot completely solve this problem, but this can 
still go a fair way towards alleviating the worst of it.

 >> If we want to roll up several feeds in one so people can easily keep
 >> track of (for instance) the feeds a site publishes, that is a
 >> different issue and should be addressed separately.

Again, we're not talking about feeds; we're talking about services which 
may or may not publish feeds of their own.

- Beecher Greenman



From owner-atom-syntax@mail.imc.org  Thu Jul  1 18:21:36 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05766
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 18:21:36 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i61M2rUb087807;
	Thu, 1 Jul 2004 15:02: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 i61M2rvU087806;
	Thu, 1 Jul 2004 15:02:53 -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 i61M2r1p087797
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 15:02: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 (rwcrmhc12) with SMTP
          id <2004070122025201400o4a29e>; Thu, 1 Jul 2004 22:02:53 +0000
Date: Thu, 1 Jul 2004 16:02:51 -0600
Subject: Re: PacePersonRef posted
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Mime-Version: 1.0 (Apple Message framework v553)
From: Antone Roundy <antone@geckotribe.com>
To: atom-syntax@imc.org
In-Reply-To: <opsag9x0iiuvpchu@quark>
Message-Id: <657A0E26-CBAA-11D8-9B2F-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 i61M2r1p087801
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 Thursday, July 1, 2004, at 03:28  PM, Asbjørn Ulsberg wrote:
>> <author ref="1" />
> Internal references should start with '#', and I really don't see the 
> need for @ref when we already use @href everywhere.
If we decide to allow external references, then href will make more 
sense.  If not, it might be better to use something that won't suggest 
to people that they can use external references.  Whether or not to 
begin with "#" might follow the same logic.



From owner-atom-syntax@mail.imc.org  Thu Jul  1 23:30: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 XAA19049
	for <atompub-archive@lists.ietf.org>; Thu, 1 Jul 2004 23:30: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 i623CrJR005093;
	Thu, 1 Jul 2004 20:12: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 i623CraI005092;
	Thu, 1 Jul 2004 20:12: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 (mproxy.gmail.com [216.239.56.244])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i623CqGp005086
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 20:12:52 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so5809334cwc
        for <atom-syntax@imc.org>; Thu, 01 Jul 2004 20:12:45 -0700 (PDT)
Received: by 10.11.116.72 with SMTP id o72mr19289cwc;
        Thu, 01 Jul 2004 20:12:44 -0700 (PDT)
Message-ID: <3f1451f5040701201220a889fe@mail.gmail.com>
Date: Thu, 1 Jul 2004 23:12:44 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Ezra Cooper <ezra@sixapart.com>
Subject: Re: PaceSecurityServices & Digest auth
Cc: atom-syntax@imc.org
In-Reply-To: <37DF50E8-CB00-11D8-8081-000A95CFF6CC@sixapart.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <37DF50E8-CB00-11D8-8081-000A95CFF6CC@sixapart.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 Wed, 30 Jun 2004 18:44:40 -0700, Ezra Cooper <ezra@sixapart.com> wrote:
> To address the third issue, I'd like to propose some alternative
> "algorithms" (in the sense of RFC 2617) for Digest auth. In particular
> I'd like to offer new functions to take the role of the H and KD
> functions used in RFC 2617, sections 3.2.2.1 and 3.2.2.2. I'm happy to
> propose these in a separate RFC, or help work them into the Atom spec.
> I do believe that they would have usefulness outside of Atom, and yet
> my immediate goal is to achieve interoperable Atom implementations.

Agreed. I believe the digest mechanism Mark and I  outlined does have the 
capability to handle the problems you have outlined. The initial
challenge from the server could indicate the desired hashing 
mechanism via 'algorithm'. I believe settling on just 3 (MD5, SHA1, and 
crypt with a given salt) would probably cover the vast majority of all cases.
The ability to handle different hashing schemes in Digest is present in the
spec but not implemented.

One thing I would like to stress is that the authentication
outlined in [1] is nothing more that RFC 2617 Digest with
some headers renamed to get around Apache's handling 
of authentication based headers and CGIs.  

In addition I would like to see implementations that 
used 'auth-int', yet another nice
feature of digest to prevent man in the middle
attacks that is currently under implemented
in digest (read: not at all).

    Thanks,


[1]  http://bitworking.org/news/New_AtomAPI_Implementation_Release2

> 
> Thanks,
> Ezra
> 
> References
> [1] http://bitworking.org/news/New_AtomAPI_Implementation_Release2
> 
>



From owner-atom-syntax@mail.imc.org  Fri Jul  2 02:05: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 CAA29301
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 02:05: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 i620CWIK094631;
	Thu, 1 Jul 2004 17: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 i620CWXK094630;
	Thu, 1 Jul 2004 17:12:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i620CPEP094594
	for <atom-syntax@imc.org>; Thu, 1 Jul 2004 17:12:27 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 2 Jul 2004 10:16:37 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Fri, 02 Jul 2004 09:41:11 +1000
Subject: Re: PaceIntrospection: Is another file format really needed?
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD0ADE37.1CB15%eric.scheid@ironclad.net.au>
In-Reply-To: <20040701163333.GN1591@tartarus.org>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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 2/7/04 2:33 AM, "James Aylett" <james@tartarus.org> wrote:

> I'd have thought you find them through the Typepad blinks, photo
> gallery, main blog and so forth.

so a site author, or contributor[1], would need to scour the entire website
just to retrieve account information? Even then, there might be some feeds
which do not have a direct front end presence such as a feed of
images/resources which get repurposed/referenced by entries in other feeds,
or are interface widgets like "quote of the day". Just because something
could have it's feed data exposed doesn't mean that it will, and I already
know of at least one site that withholds their blinks feed for members only,
no public access except via the website.

e.


[1] which is the stronger use case - invited contributors won't necessarily
have intimate knowledge of the site set up.



From owner-atom-syntax@mail.imc.org  Fri Jul  2 08:45: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 IAA02387
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 08:45: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 i62CX2JT050287;
	Fri, 2 Jul 2004 05:33: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 i62CX2Ln050286;
	Fri, 2 Jul 2004 05:33:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from ixion.tartarus.org (ixion.tartarus.org [195.149.39.210])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i62CX1tY050280
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 05:33:02 -0700 (PDT)
	(envelope-from james@ixion.tartarus.org)
Received: from james by ixion.tartarus.org with local (Exim 3.35 #1 (Debian))
	for atom-syntax@imc.org
	id 1BgNDz-0001iR-00; Fri, 02 Jul 2004 13:33:03 +0100
Date: Fri, 2 Jul 2004 13:33:03 +0100
From: James Aylett <james@tartarus.org>
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceIntrospection: Is another file format really needed?
Message-ID: <20040702123303.GG5957@tartarus.org>
Mail-Followup-To: James Aylett <james@tartarus.org>,
	Atom Syntax <atom-syntax@imc.org>
References: <20040701163333.GN1591@tartarus.org> <BD0ADE37.1CB15%eric.scheid@ironclad.net.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BD0ADE37.1CB15%eric.scheid@ironclad.net.au>
User-Agent: Mutt/1.3.28i
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


On Fri, Jul 02, 2004 at 09:41:11AM +1000, Eric Scheid wrote:

> > I'd have thought you find them through the Typepad blinks, photo
> > gallery, main blog and so forth.
> 
> so a site author, or contributor[1], would need to scour the entire website
> just to retrieve account information? Even then, there might be some feeds
> which do not have a direct front end presence such as a feed of
> images/resources which get repurposed/referenced by entries in other feeds,
> or are interface widgets like "quote of the day". Just because something
> could have it's feed data exposed doesn't mean that it will, and I already
> know of at least one site that withholds their blinks feed for members only,
> no public access except via the website.

Got it, thank you :-)

So if a feed pointed to an introspection file that listed facets for
several feeds, this requirement would be satisfied, yes?

I still don't see why anyone would want to squeeze this into the Atom
XML elements being used for the feeds themselves. There isn't a
semantic match there that I can see.

James

-- 
/--------------------------------------------------------------------------\
  James Aylett                                                  xapian.org
  james@tartarus.org                               uncertaintydivision.org



From owner-atom-syntax@mail.imc.org  Fri Jul  2 08:45: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 IAA02407
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 08:45: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 i62CTtJG049949;
	Fri, 2 Jul 2004 05: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 i62CTtDo049948;
	Fri, 2 Jul 2004 05:29:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from ixion.tartarus.org (ixion.tartarus.org [195.149.39.210])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i62CTrU7049942
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 05:29:54 -0700 (PDT)
	(envelope-from james@ixion.tartarus.org)
Received: from james by ixion.tartarus.org with local (Exim 3.35 #1 (Debian))
	for atom-syntax@imc.org
	id 1BgNAs-0001FD-00; Fri, 02 Jul 2004 13:29:50 +0100
Date: Fri, 2 Jul 2004 13:29:50 +0100
From: James Aylett <james@tartarus.org>
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceIntrospection: Is another file format really needed?
Message-ID: <20040702122950.GF5957@tartarus.org>
Mail-Followup-To: James Aylett <james@tartarus.org>,
	Atom-Syntax <atom-syntax@imc.org>
References: <40E48B0C.6080708@spoonybards.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <40E48B0C.6080708@spoonybards.net>
User-Agent: Mutt/1.3.28i
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


On Thu, Jul 01, 2004 at 06:07:08PM -0400, Beecher Greenman wrote:

> >> You introspect a feed to find its service API points.
> 
> You don't introspect a feed at all, because a feed is not a "thing" to 
> be introspected.

My thinking is as follows:

 * a feed is a collection of entries
 * we provide a serialisation of this feed's state in Atom XML
 * this (the Atom document) is a resource, in that it has a URL

So 'feed' is part of the conceptual model, just like 'entry', so it's
equally something you can introspect against.

> You could introspect sites, entries, users, or whatever 
> else, but a feed is a representation of something, not the thing
> itself. 

I'd argue that the feed is a group of entries, and that the Atom XML
document is the resource representation of that feed. I think this is
mostly a difference in how we're using the words though, rather than a
real difference in opinion.

> What exactly a feed can represent is at the core of this debate, but I 
> don't think there's any argument that a feed is an actual object instead 
> of a representation.

I think there is. Further, I think that the argument on these lines
descends into TAG territory, which probably means we aren't going to
resolve it in the lifetime of atompub :-)
 
> You're not finding out information about several feeds in one go; you're 
> finding out information about several services in one go. A feed 
> represents a service but it is not the service itself.

That's a little too metaphysical for me :-)
 
> Anyway, an honest question, first: why should this not be called 
> introspection? Although the user is performing it against an author 
> rather than a service, the principle seems to still apply.

You're not introspecting the author (which is a person, possibly), but
looking at a resource representing the collection of some of the feeds
that author can access.

You're not even introspecting the res rep of the /author/, because the
service points that you get from the introspection are not intrinsic
to the author, they are intrinsic to the feeds that the author can
access.
 
> Second: why should this not happen?

I accept that it is. (I accept this now, because I now understand what
the use case for it is.)

> >> If we want to roll up several feeds in one so people can easily keep
> >> track of (for instance) the feeds a site publishes, that is a
> >> different issue and should be addressed separately.
> 
> Again, we're not talking about feeds; we're talking about services which 
> may or may not publish feeds of their own.

I have an issue with this view, namely that we don't have a model for
such services.

If we introspect on a feed, and get a list of service points for that
feed (how to post, edit, delete, comment, whatever) then it's simple
and clear what's going on. We can possibly expand that to have the
introspection file contain labelled information about /several/ feeds;
and if we link to this introspection file from an HTML page, we (I
think) get the effects most people seem to want.

I'd be opposed to explicitly talking about a 'service' behind one or
more feeds, and heavily opposed to doing so unless we have a very
clear idea of what we mean by that. (The best I can think of is that
you could consider a MovableType installation as a service - that's an
example however, not a definition.)

James

-- 
/--------------------------------------------------------------------------\
  James Aylett                                                  xapian.org
  james@tartarus.org                               uncertaintydivision.org



From owner-atom-syntax@mail.imc.org  Fri Jul  2 09:04: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 JAA03391
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 09:04: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 i62Cpcuf052018;
	Fri, 2 Jul 2004 05: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 i62CpckL052017;
	Fri, 2 Jul 2004 05:51:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from ixion.tartarus.org (ixion.tartarus.org [195.149.39.210])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i62CpbBI052004
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 05:51:37 -0700 (PDT)
	(envelope-from james@ixion.tartarus.org)
Received: from james by ixion.tartarus.org with local (Exim 3.35 #1 (Debian))
	for atom-syntax@imc.org
	id 1BgNVz-0002S8-00; Fri, 02 Jul 2004 13:51:39 +0100
Date: Fri, 2 Jul 2004 13:51:39 +0100
From: James Aylett <james@tartarus.org>
To: atom-syntax@imc.org
Subject: Re: PaceIntrospection - A use case.  (was Re: PaceIntrospection: Is another file format really needed?)
Message-ID: <20040702125139.GH5957@tartarus.org>
Mail-Followup-To: James Aylett <james@tartarus.org>, atom-syntax@imc.org
References: <1088696134.3664773123.17193.sendItem@bloglines.com> <20040701160206.GM1591@tartarus.org> <3f1451f504070110574ee7bee@mail.gmail.com> <40E48242.8070205@AOL.NET>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <40E48242.8070205@AOL.NET>
User-Agent: Mutt/1.3.28i
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


On Thu, Jul 01, 2004 at 02:29:38PM -0700, John Panzer wrote:

> I have a use case for combining the two:  AOL Journals lets a user 
> create as many blogs as they want to; the main pages for these blogs are 
> always under http://journals.aol.com/username/blogname.  We have to 
> provide a standard way to provide a list of the blogs that's easily 
> discoverable given the username.  This list is dynamic and can change 
> from hour to hour, though usually it'd be pretty stable.  The contents 
> of the list, in our case, can change depending on the _requestor_ of the 
> list -- anonymous requests would get only public blogs, whereas 
> authenticated users would get a list of both public blogs and private 
> blogs to which the requestor has been granted access.

So this is for other people (users and non-users) to gain access to
blogs published by 'username'?
 
> The data that a client would want includes an endpoint for getting a 
> list of entries (the <feed>), a URI to the corresponding HTML page if 
> one exists, and perhaps endpoints such as post, comment, etc. This 
> enables software to offer status information (e.g., last post date), 
> subscription, posting, commenting, etc. services.

I understand why you want the feed URI and the HTML page URI. I'm not
sure I see why you need the comment facet given you surely can't
comment until you've read something to comment on - so you need to
fetch the feed or HTML page. Perhaps the comment facet should be in
the feed (particularly as it might be entry-specific)?
 
> It seems useful to me to combine the query-to-get-the-list with the 
> query-to-get-the-endpoints, because they will in reality be combined for 
> this use case.

I'd have thought most users just needed the feed URI and HTML URI, and
nothing else. Do you have the ability to allow authenticated users to
post to some of your own blogs? So a tool would be pointed to
http://journals.aol.com/username/, would fetch the introspection file
(with possible authentication), and know all the blogs it can read
/or/ write to?

> Note that in this _particular_ use case, the 'introspection' file is 
> really a dynamic feed-like-thing.  One could imagine, for example, 
> software that lets you say 'let me know whenever Joe Gregorio creates a 
> new blog!' and uses a feed-like mechanism for polling for this.  We'd 
> want to re-use the Atom authentication mechanisms, polling time hinting, 
> HTTP caching, etc. etc. for this data just as we would for an 
> entry-based feed.  So I think there's some justification for treating it 
> like a feed.

I think /that/ is a good use-case for using an Atom feed file. But I
think it's very different from "give me the facets so I can edit <this
thing>". That's why I don't see the fit.
 
> (There are other, more blue sky, use cases.  Consider a feed of 
> endpoints for all new blogs created by people you know, whether or not 
> you've ever subscribed to any of their blogs.)

Again, why do you need more than just the feed URI and HTML URI? At
most; if you're inside your happy aggregator world, you might not want
the HTML URI.

It's a cool idea, but I don't see why it applies to the introspection
needs.

James

-- 
/--------------------------------------------------------------------------\
  James Aylett                                                  xapian.org
  james@tartarus.org                               uncertaintydivision.org



From owner-atom-syntax@mail.imc.org  Fri Jul  2 11:17: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 LAA12690
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 11: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 i62F2XS4061878;
	Fri, 2 Jul 2004 08:02: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 i62F2XZ6061877;
	Fri, 2 Jul 2004 08:02:33 -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 i62F2WTv061870
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 08:02:32 -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 i62F2m8X004338
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 11:02:48 -0400
Message-ID: <40E57909.4040808@intertwingly.net>
Date: Fri, 02 Jul 2004 11:02:33 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Validing parser required?
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


In the interest of being "cleanly and thoroughly specified", the AtomPub 
Working Group should decide whether consumers should be required to use 
validating XML parsers in order to consistently and correctly handle the 
Atom feed and protocol.

First, here is a relevant portion of the XML specification[1]:

> For maximum reliability in interoperating between different XML
> processors, applications which use non-validating processors should
> not rely on any behaviors not required of such processors.
> Applications which require facilities such as the use of default
> attributes or internal entities which are declared in external
> entities should use validating XML processors.

Now for historical benefit, the Netscape RSS 0.91 spec, revision 3 
contains the following text[2]:

> Files must be 100% valid XML. We're trying to move towards a more
> standard format, and to this end we have included several tags from
> the popular <scriptingNews> format. We have also ensured that this
> version is 100% valid XML. We did this by requiring that a DOCTYPE
> tag be included, and validating each RSS document against that DTD.
> This means that it is not enough for an RSS document to be
> "well-formed". It must also be "valid" with respect to its DTD.

The requirement for a DTD was dropped in both the UserLand 0.91 spec[3] 
(and has not reappeared in subsequent revisions derived from this spec), 
nor was is it present in the RSS 1.0 spec[4].

  - - -

As I said, I would like to see Atom "cleanly and thoroughly specified". 
  People should not be required to use a validating parser simply 
because the spec is silent on whether this is allowed or not, and 
therefore must be allowed.

One way to handle this is the way SOAP[5] does :

> A SOAP message MUST NOT contain a Document Type Declaration.

That seems pretty clear, and certainly is very effective.

However, if someone is interested in crafting more surgical language 
which only addresses the issue of validation and does not prevent, for 
example, inline DTDs, I will gladly defer to them.  Otherwise, I will 
write up a Pace to include something like the sentence above into the 
Atom specifications and such a Pace will eventually get scheduled and 
disposed of.

- Sam Ruby

[1]<http://www.w3.org/TR/2000/REC-xml-20001006#safe-behavior>
[2]<http://my.netscape.com/publish/formats/rss-spec-0.91.html>
[3]<http://backend.userland.com/rss091>
[4]<http://web.resource.org/rss/1.0/spec>
[5]<http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383492>



From owner-atom-syntax@mail.imc.org  Fri Jul  2 11:47: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 LAA14408
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 11:47: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 i62FVRTC063820;
	Fri, 2 Jul 2004 08:31: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 i62FVRHs063819;
	Fri, 2 Jul 2004 08:31:27 -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 i62FVPRW063809
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 08:31:27 -0700 (PDT)
	(envelope-from antone@geckotribe.com)
Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134])
          by comcast.net (rwcrmhc11) with SMTP
          id <2004070215312001300ba258e>; Fri, 2 Jul 2004 15:31:21 +0000
Date: Fri, 2 Jul 2004 09:31:18 -0600
Mime-Version: 1.0 (Apple Message framework v553)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Subject: PaceServiceElement created
From: Antone Roundy <antone@geckotribe.com>
To: atom-syntax@imc.org
Content-Transfer-Encoding: 7bit
Message-Id: <DD1905F6-CC3C-11D8-B0A4-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


I've posted PaceServiceElement on the wiki.  Since it's not scheduled 
for discussion yet, I'll just post the first little bit so that you'll 
know what it's about when it gets to the Proceed list.  (Note however 
that it is related to PaceIntrospection, which is currently under 
discussion).

Abstract

	This proposal defines a new element to be used in place of 
link[@rel="service.*"].

Related and Conflicting Proposals

     * PaceLinkPurpose
     * PaceLinkConstruct
     * PaceIntrospection

Rationale

	If PaceLinkPurpose is adopted, then link[@rel="service.post"] and 
link[@rel="service.edit"] will be clearly outside of the boundaries set 
for the link element (neither is an appropriate value for a clickable 
link), and thus will need a new element. Even if PaceLinkPurpose is not 
adopted, moving this logical group of @rel values to their own element 
would help to avoid excessive overloading of the link element.

Antone



From owner-atom-syntax@mail.imc.org  Fri Jul  2 12:15: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 MAA16812
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 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 i62G2PR5065563;
	Fri, 2 Jul 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 i62G2PHS065562;
	Fri, 2 Jul 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 ixion.tartarus.org (ixion.tartarus.org [195.149.39.210])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i62G2OcL065555
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 09:02:24 -0700 (PDT)
	(envelope-from james@ixion.tartarus.org)
Received: from james by ixion.tartarus.org with local (Exim 3.35 #1 (Debian))
	for atom-syntax@imc.org
	id 1BgQUY-00016H-00; Fri, 02 Jul 2004 17:02:22 +0100
Date: Fri, 2 Jul 2004 17:02:22 +0100
From: James Aylett <james@tartarus.org>
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Validing parser required?
Message-ID: <20040702160222.GO5957@tartarus.org>
Mail-Followup-To: James Aylett <james@tartarus.org>,
	Atom-Syntax <atom-syntax@imc.org>
References: <40E57909.4040808@intertwingly.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <40E57909.4040808@intertwingly.net>
User-Agent: Mutt/1.3.28i
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


On Fri, Jul 02, 2004 at 11:02:33AM -0400, Sam Ruby wrote:

> I would like to see Atom "cleanly and thoroughly specified". 
> People should not be required to use a validating parser simply 
> because the spec is silent on whether this is allowed or not, and 
> therefore must be allowed.
> 
> One way to handle this is the way SOAP[5] does :
> 
> >A SOAP message MUST NOT contain a Document Type Declaration.
> 
> That seems pretty clear, and certainly is very effective.

I have two thoughts on this:

 (1) a DocType declaration could be of use in /creating/ an Atom
     document, because it allows a producer to validate immediately on
     production. However if we're stating that an Atom document
     must be able to be understood entirely by a non-validating
     parser, there is no other use of a DocType declaration (at least,
     that I can see) - except for named entity declarations, which
     are only really of use if you're writing this stuff by hand.

 (2) the language to express that will be difficult to make clear. The
     best I've come up with is: 

       An Atom document MUST be expressed such that its meaning is
       identical whether a validating or non-validating XML parser is
       used.

     And I'm not terribly happy with that phrasing in all sorts of
     ways.
 
And of course we can suggest using a schema, not a DTD, for validity
checks. So I'd probably be happy with outlawing DocType declarations
in Atom.

James

-- 
/--------------------------------------------------------------------------\
  James Aylett                                                  xapian.org
  james@tartarus.org                               uncertaintydivision.org



From owner-atom-syntax@mail.imc.org  Fri Jul  2 12:19: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 MAA17014
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 12:19: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 i62G6xwG065740;
	Fri, 2 Jul 2004 09:06:59 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i62G6xA7065739;
	Fri, 2 Jul 2004 09:06:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtp016.mail.yahoo.com (smtp016.mail.yahoo.com [216.136.174.113])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i62G6xAk065733
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 09:06:59 -0700 (PDT)
	(envelope-from mc@xegesis.org)
Received: from unknown (HELO ?192.168.1.100?) (mcraigchampion@68.40.14.49 with plain)
  by smtp016.mail.yahoo.com with SMTP; 2 Jul 2004 16:07:00 -0000
Mime-Version: 1.0 (Apple Message framework v618)
In-Reply-To: <40E57909.4040808@intertwingly.net>
References: <40E57909.4040808@intertwingly.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <D508373B-CC41-11D8-A3E7-000A95CCC59E@xegesis.org>
Content-Transfer-Encoding: 7bit
From: Michael Champion <mc@xegesis.org>
Subject: Re: Validing parser required?
Date: Fri, 2 Jul 2004 12:06:52 -0400
To: Atom-Syntax Syntax <atom-syntax@imc.org>
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>
Content-Transfer-Encoding: 7bit



On Jul 2, 2004, at 11:02 AM, Sam Ruby wrote:

>
> As I said, I would like to see Atom "cleanly and thoroughly 
> specified".  People should not be required to use a validating parser 
> simply because the spec is silent on whether this is allowed or not, 
> and therefore must be allowed.
>
> One way to handle this is the way SOAP[5] does :

SOAP 1.2 has much more explicit language about the non-requirement for 
runtime validation that you may wish to borrow. 
http://www.w3.org/TR/soap12-part1/#reltoxml

>
>> A SOAP message MUST NOT contain a Document Type Declaration.

At least in SOAP 1.2, this is not to prevent a requirement for runtime 
validation but to align SOAP on a subset of XML that does not contain 
entity declarations or references to any other then the built-in XML 
entities.  That is for performance and security reasons that may or may 
not apply to Atom.  This is the mother of permathreads in the SOAP 
world -- while I will strongly defend the removal of entities from 
SOAP, I am not prepared to do that for Atom.  On the other hand, you 
may wish to consider the "billion laughs" XML denial of service attack 
http://www.securityfocus.com/archive/1/303509/2002-12-13/2002-12-19/0 
and determine how / whether to address it in Atom.  Forbidding DTDs is 
at least a simple way of doing this, but again the cost for Atom is 
probably prohibitive.  (Anticipating much stronger statement of this 
from Elliotte Rusty Harold  ... <grin> )



From owner-atom-syntax@mail.imc.org  Fri Jul  2 12: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 MAA18497
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 12: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 i62GOWeL067768;
	Fri, 2 Jul 2004 09:24: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 i62GOWkh067767;
	Fri, 2 Jul 2004 09:24: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 i62GOVJT067759
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 09:24:31 -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 1BgQpy-0005SH-7r; Fri, 02 Jul 2004 16:24:30 +0000
Message-ID: <40E58C3C.7010908@franklinmint.fm>
Date: Fri, 02 Jul 2004 12:24:28 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: James Aylett <james@tartarus.org>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Validing parser required?
References: <40E57909.4040808@intertwingly.net> <20040702160222.GO5957@tartarus.org>
In-Reply-To: <20040702160222.GO5957@tartarus.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: <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


James Aylett wrote:

> (2) the language to express that will be difficult to make clear. The
>     best I've come up with is: 
>
>       An Atom document MUST be expressed such that its meaning is
>       identical whether a validating or non-validating XML parser is
>       used.
>  
>

How about the following?

Cribbing a bit from the section 5.2 of the XML spec:

"Atom documents can be processed by non-validating XML processors. An 
Atom document MUST NOT rely on any behaviors not required of such 
processors."

Robert Sayre



From owner-atom-syntax@mail.imc.org  Fri Jul  2 12:44: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 MAA19181
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 12:44: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 i62GT8CM068037;
	Fri, 2 Jul 2004 09: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 i62GT8bH068036;
	Fri, 2 Jul 2004 09:29:08 -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 i62GT8FP068021
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 09:29:08 -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 i62GT5r08031
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 09:29:05 -0700 (PDT)
Received: from aol.net ([10.169.192.58]) by judge.mcom.com
          (Netscape Messaging Server 4.15) with ESMTP id I08GGG02.A0W;
          Fri, 2 Jul 2004 09:29:04 -0700 
Message-ID: <40E58D53.8020507@aol.net>
Date: Fri, 02 Jul 2004 09:29:07 -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: James Aylett <james@tartarus.org>
CC: atom-syntax@imc.org
Subject: Re: PaceIntrospection - A use case.  (was Re: PaceIntrospection:
 Is another file format really needed?)
References: <1088696134.3664773123.17193.sendItem@bloglines.com> <20040701160206.GM1591@tartarus.org> <3f1451f504070110574ee7bee@mail.gmail.com> <40E48242.8070205@AOL.NET> <20040702125139.GH5957@tartarus.org>
In-Reply-To: <20040702125139.GH5957@tartarus.org>
Content-Type: multipart/alternative;
 boundary="------------040404040208060900010305"
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>


This is a multi-part message in MIME format.
--------------040404040208060900010305
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

James Aylett wrote:

>On Thu, Jul 01, 2004 at 02:29:38PM -0700, John Panzer wrote:
>
>  
>
>>I have a use case for combining the two:  AOL Journals lets a user 
>>create as many blogs as they want to; the main pages for these blogs are 
>>always under http://journals.aol.com/username/blogname.  We have to 
>>provide a standard way to provide a list of the blogs that's easily 
>>discoverable given the username.  This list is dynamic and can change 
>>from hour to hour, though usually it'd be pretty stable.  The contents 
>>of the list, in our case, can change depending on the _requestor_ of the 
>>list -- anonymous requests would get only public blogs, whereas 
>>authenticated users would get a list of both public blogs and private 
>>blogs to which the requestor has been granted access.
>>    
>>
>
>So this is for other people (users and non-users) to gain access to
>blogs published by 'username'?
> 
>  
>
Yes, it's available for anyone to query but the results you get depend 
on who you are.

>>The data that a client would want includes an endpoint for getting a 
>>list of entries (the <feed>), a URI to the corresponding HTML page if 
>>one exists, and perhaps endpoints such as post, comment, etc. This 
>>enables software to offer status information (e.g., last post date), 
>>subscription, posting, commenting, etc. services.
>>    
>>
>
>I understand why you want the feed URI and the HTML page URI. I'm not
>sure I see why you need the comment facet given you surely can't
>comment until you've read something to comment on - so you need to
>fetch the feed or HTML page. Perhaps the comment facet should be in
>the feed (particularly as it might be entry-specific)?
> 
>  
>
Sorry, strike "commenting" above; you're right, it needs an entry 
context.  I was thinking of feed-level endpoints only (including 
extensions which people might want to add).

>>It seems useful to me to combine the query-to-get-the-list with the 
>>query-to-get-the-endpoints, because they will in reality be combined for 
>>this use case.
>>    
>>
>
>I'd have thought most users just needed the feed URI and HTML URI, and
>nothing else. Do you have the ability to allow authenticated users to
>post to some of your own blogs? So a tool would be pointed to
>http://journals.aol.com/username/, would fetch the introspection file
>(with possible authentication), and know all the blogs it can read
>/or/ write to?
>
>  
>
Yes, exactly.  So in some cases you see a "post" button next to the blog 
name, in others you don't.

A specific use case here is where you're displaying a dashboard of all 
the blogs you own.

>>Note that in this _particular_ use case, the 'introspection' file is 
>>really a dynamic feed-like-thing.  One could imagine, for example, 
>>software that lets you say 'let me know whenever Joe Gregorio creates a 
>>new blog!' and uses a feed-like mechanism for polling for this.  We'd 
>>want to re-use the Atom authentication mechanisms, polling time hinting, 
>>HTTP caching, etc. etc. for this data just as we would for an 
>>entry-based feed.  So I think there's some justification for treating it 
>>like a feed.
>>    
>>
>
>I think /that/ is a good use-case for using an Atom feed file. But I
>think it's very different from "give me the facets so I can edit <this
>thing>". That's why I don't see the fit.
> 
>  
>
Here's what I might want to see as a result of this feed-like-thing:

My Cat Picture Blog    [post]
My Other Blog    [post]
A Shared Community Blog  [post] (last updated: [Today])
My Friend's Blog   (last updated: [Today])
My Friend's Cat's Blog  (last updated: [5/1/04])

...with appropriate hyperlinks for each element.

(Actually, this is starting to look a little bit like a weird synthetic 
feed.  Except that this feed filters out the entries....)

>>(There are other, more blue sky, use cases.  Consider a feed of 
>>endpoints for all new blogs created by people you know, whether or not 
>>you've ever subscribed to any of their blogs.)
>>    
>>
>
>Again, why do you need more than just the feed URI and HTML URI? At
>most; if you're inside your happy aggregator world, you might not want
>the HTML URI.
>
>  
>
The idea is to provide the feed-level information that a user agent 
might need.  This might include the post URI as described above, as well 
as extension URIs.  The reason for returning them all at once instead of 
having the user agent get just each feed URI in turn and then query 
_that_ to get the other URIs is because this could greatly increase 
latency (consider a list of 50 feeds).

If you need to return two URIs per feed, you might as well return N URIs 
per feed and allow for extensions.

>It's a cool idea, but I don't see why it applies to the introspection
>needs.
>  
>
I think that introspection is a bad term for this.  That is, 
introspection is a _part_ of these needs, but is not necessarily the 
primary issue.  But it is intertwined for the reasons given above.

-John Panzer


--------------040404040208060900010305
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
James Aylett wrote:<br>
<blockquote cite="mid20040702125139.GH5957@tartarus.org" type="cite">
  <pre wrap="">On Thu, Jul 01, 2004 at 02:29:38PM -0700, John Panzer wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">I have a use case for combining the two:  AOL Journals lets a user 
create as many blogs as they want to; the main pages for these blogs are 
always under <a class="moz-txt-link-freetext" href="http://journals.aol.com/username/blogname">http://journals.aol.com/username/blogname</a>.  We have to 
provide a standard way to provide a list of the blogs that's easily 
discoverable given the username.  This list is dynamic and can change 
from hour to hour, though usually it'd be pretty stable.  The contents 
of the list, in our case, can change depending on the _requestor_ of the 
list -- anonymous requests would get only public blogs, whereas 
authenticated users would get a list of both public blogs and private 
blogs to which the requestor has been granted access.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
So this is for other people (users and non-users) to gain access to
blogs published by 'username'?
 
  </pre>
</blockquote>
Yes, it's available for anyone to query but the results you get depend
on who you are.<br>
<blockquote cite="mid20040702125139.GH5957@tartarus.org" type="cite">
  <blockquote type="cite">
    <pre wrap="">The data that a client would want includes an endpoint for getting a 
list of entries (the &lt;feed&gt;), a URI to the corresponding HTML page if 
one exists, and perhaps endpoints such as post, comment, etc. This 
enables software to offer status information (e.g., last post date), 
subscription, posting, commenting, etc. services.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I understand why you want the feed URI and the HTML page URI. I'm not
sure I see why you need the comment facet given you surely can't
comment until you've read something to comment on - so you need to
fetch the feed or HTML page. Perhaps the comment facet should be in
the feed (particularly as it might be entry-specific)?
 
  </pre>
</blockquote>
Sorry, strike "commenting" above; you're right, it needs an entry
context.&nbsp; I was thinking of feed-level endpoints only (including
extensions which people might want to add).<br>
<blockquote cite="mid20040702125139.GH5957@tartarus.org" type="cite">
  <blockquote type="cite">
    <pre wrap="">It seems useful to me to combine the query-to-get-the-list with the 
query-to-get-the-endpoints, because they will in reality be combined for 
this use case.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I'd have thought most users just needed the feed URI and HTML URI, and
nothing else. Do you have the ability to allow authenticated users to
post to some of your own blogs? So a tool would be pointed to
<a class="moz-txt-link-freetext" href="http://journals.aol.com/username/">http://journals.aol.com/username/</a>, would fetch the introspection file
(with possible authentication), and know all the blogs it can read
/or/ write to?

  </pre>
</blockquote>
Yes, exactly.&nbsp; So in some cases you see a "post" button next to the
blog name, in others you don't.<br>
<br>
A specific use case here is where you're displaying a dashboard of all
the blogs you own.<br>
<blockquote cite="mid20040702125139.GH5957@tartarus.org" type="cite">
  <pre wrap=""></pre>
  <blockquote type="cite">
    <pre wrap="">Note that in this _particular_ use case, the 'introspection' file is 
really a dynamic feed-like-thing.  One could imagine, for example, 
software that lets you say 'let me know whenever Joe Gregorio creates a 
new blog!' and uses a feed-like mechanism for polling for this.  We'd 
want to re-use the Atom authentication mechanisms, polling time hinting, 
HTTP caching, etc. etc. for this data just as we would for an 
entry-based feed.  So I think there's some justification for treating it 
like a feed.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I think /that/ is a good use-case for using an Atom feed file. But I
think it's very different from "give me the facets so I can edit &lt;this
thing&gt;". That's why I don't see the fit.
 
  </pre>
</blockquote>
Here's what I might want to see as a result of this feed-like-thing:<br>
<br>
My Cat Picture Blog&nbsp;&nbsp;&nbsp; [post]<br>
My Other Blog&nbsp;&nbsp;&nbsp; [post]<br>
A Shared Community Blog&nbsp; [post] (last updated: [Today])<br>
My Friend's Blog&nbsp;&nbsp; (last updated: [Today])<br>
My Friend's Cat's Blog&nbsp; (last updated: [5/1/04])<br>
<br>
...with appropriate hyperlinks for each element.<br>
<br>
(Actually, this is starting to look a little bit like a weird synthetic
feed.&nbsp; Except that this feed filters out the entries....)<br>
<blockquote cite="mid20040702125139.GH5957@tartarus.org" type="cite">
  <blockquote type="cite">
    <pre wrap="">(There are other, more blue sky, use cases.  Consider a feed of 
endpoints for all new blogs created by people you know, whether or not 
you've ever subscribed to any of their blogs.)
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Again, why do you need more than just the feed URI and HTML URI? At
most; if you're inside your happy aggregator world, you might not want
the HTML URI.

  </pre>
</blockquote>
The idea is to provide the feed-level information that a user agent
might need.&nbsp; This might include the post URI as described above, as
well as extension URIs.&nbsp; The reason for returning them all at once
instead of having the user agent get just each feed URI in turn and
then query _that_ to get the other URIs is because this could greatly
increase latency (consider a list of 50 feeds).<br>
<br>
If you need to return two URIs per feed, you might as well return N
URIs per feed and allow for extensions.<br>
<blockquote cite="mid20040702125139.GH5957@tartarus.org" type="cite">
  <pre wrap="">It's a cool idea, but I don't see why it applies to the introspection
needs.
  </pre>
</blockquote>
I think that introspection is a bad term for this.&nbsp; That is,
introspection is a _part_ of these needs, but is not necessarily the
primary issue.&nbsp; But it is intertwined for the reasons given above.<br>
<br>
-John Panzer<br>
<br>
</body>
</html>

--------------040404040208060900010305--



From owner-atom-syntax@mail.imc.org  Fri Jul  2 12:46:30 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19268
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 12: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 i62GT1T9068018;
	Fri, 2 Jul 2004 09:29: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 i62GT1h8068017;
	Fri, 2 Jul 2004 09:29: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 i62GSxN5067998
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 09:29:00 -0700 (PDT)
	(envelope-from julian.reschke@gmx.de)
Received: (qmail 26788 invoked by uid 65534); 2 Jul 2004 16:28:52 -0000
Received: from p508257B1.dip0.t-ipconnect.de (EHLO [192.168.1.15]) (80.130.87.177)
  by mail.gmx.net (mp021) with SMTP; 02 Jul 2004 18:28:52 +0200
X-Authenticated: #1915285
Message-ID: <40E58D3E.8090402@gmx.de>
Date: Fri, 02 Jul 2004 18:28:46 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sam Ruby <rubys@intertwingly.net>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Validing parser required?
References: <40E57909.4040808@intertwingly.net>
In-Reply-To: <40E57909.4040808@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:

> 
> In the interest of being "cleanly and thoroughly specified", the AtomPub 
> Working Group should decide whether consumers should be required to use 
> validating XML parsers in order to consistently and correctly handle the 
> Atom feed and protocol.
 > ...

I think this discussion is pointless unless there'll be a normative 
schema (in the generic sense) that *can* be used to validate Atom. As 
far as I understand namespace usage and extension rules already rule out 
DTDs and XML Schema.

Are we prepared to require something else like RNG? I doubt so.

On the other hand (as others pointed out), allowing document types 
introduces several kinds of Denial-of-Service attacks, and generally 
makes little sense, unless the recipient *always* validates against it's 
own copy of the DTD instead of the one reference in the request.

WebDAV faces a similar problem, and the current consensus seems to be:

- recipients MUST NOT attempt to validate the message, and
- recipients MAY reject certain DTD subsets in requests (such as when 
external entities are referenced, or the recipient detects situations 
like the one called the "billion laughs attack"

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From owner-atom-syntax@mail.imc.org  Fri Jul  2 12: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 MAA19834
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 12:54: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 i62Ghdrt069008;
	Fri, 2 Jul 2004 09: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 i62Ghduj069007;
	Fri, 2 Jul 2004 09:43: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 i62Ghcqi068999
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 09:43:38 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.3] (unknown [63.96.163.9])
	by mail.mnot.net (Postfix) with ESMTP id BAD4E727D
	for <atom-syntax@imc.org>; Fri,  2 Jul 2004 09:43:41 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <F925141D-CC46-11D8-B7F4-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: PaceNoInfoSet
Date: Fri, 2 Jul 2004 09:43:40 -0700
To: Atom Syntax <atom-syntax@imc.org>
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>
Content-Transfer-Encoding: 7bit


What is "an application of XML 1.0 and XML Namespaces"? That's like 
saying something is "an application of ASCII."

Does this proposal have any affect on implementations or conformance?

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Fri Jul  2 12:56: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 MAA19873
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 12:56: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 i62Gg3bq068885;
	Fri, 2 Jul 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 i62Gg34Q068884;
	Fri, 2 Jul 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 mproxy.gmail.com (mproxy.gmail.com [216.239.56.247])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i62Gg3Us068873
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 09:42:03 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so6656610cwc
        for <atom-syntax@imc.org>; Fri, 02 Jul 2004 09:41:59 -0700 (PDT)
Received: by 10.11.116.72 with SMTP id o72mr101023cwc;
        Fri, 02 Jul 2004 09:41:59 -0700 (PDT)
Message-ID: <3f1451f5040702094139e2a483@mail.gmail.com>
Date: Fri, 2 Jul 2004 12:41:59 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Antone Roundy <antone@geckotribe.com>
Subject: Re: PaceServiceElement created
Cc: atom-syntax@imc.org
In-Reply-To: <DD1905F6-CC3C-11D8-B0A4-003065EA6144@geckotribe.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <DD1905F6-CC3C-11D8-B0A4-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 Fri, 2 Jul 2004 09:31:18 -0600, Antone Roundy <antone@geckotribe.com> wrote:
> 
> 
> I've posted PaceServiceElement on the wiki.  Since it's not scheduled
> for discussion yet, I'll just post the first little bit so that you'll
> know what it's about when it gets to the Proceed list.  (Note however
> that it is related to PaceIntrospection, which is currently under
> discussion).
> 

Interesting. Any reason for not creating an AtomAPI namespace?
For example:

<feed xmlnx:atomapi="http://purl.org/atom/api/ns#" ..

  <atomapi:post>http://...</atomapi:post>
  <atomapi:edit>http://...</atomapi:edit>



From owner-atom-syntax@mail.imc.org  Fri Jul  2 12:59: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 MAA20026
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 12:59: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 i62Gj7JC069118;
	Fri, 2 Jul 2004 09:45: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 i62Gj7ie069117;
	Fri, 2 Jul 2004 09:45:07 -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 i62Gj6f0069109
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 09:45:06 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 29186 messnum 9351416 invoked from network[62.77.172.85/62-77-172-85.customer.eircom.net]); 2 Jul 2004 16:45:03 -0000
Received: from 62-77-172-85.customer.eircom.net (HELO ?200.200.200.38?) (62.77.172.85)
  by mail10.svc.cra.dublin.eircom.net (qp 29186) with SMTP; 2 Jul 2004 16:45:03 -0000
Message-ID: <40E5910A.3010600@dehora.net>
Date: Fri, 02 Jul 2004 17:44:58 +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: Validing parser required?
References: <40E57909.4040808@intertwingly.net>
In-Reply-To: <40E57909.4040808@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:

> 
> In the interest of being "cleanly and thoroughly specified", the AtomPub 
> Working Group should decide whether consumers should be required to use 
> validating XML parsers in order to consistently and correctly handle the 
> Atom feed and protocol.
>
 > [...]
>
> The requirement for a DTD was dropped in both the UserLand 0.91 spec[3] 
> (and has not reappeared in subsequent revisions derived from this spec), 
> nor was is it present in the RSS 1.0 spec[4].

Inline DTDs aside, a DTD for Atom itself doesn't sound feasible 
given the current spec wording on ordering [1].

cheers
Bill

[1] http://www.intertwingly.net/wiki/pie/PaceElementOrder




From owner-atom-syntax@mail.imc.org  Fri Jul  2 13: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 NAA20145
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 13: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 i62Gn3Pn069290;
	Fri, 2 Jul 2004 09:49: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 i62Gn3BL069289;
	Fri, 2 Jul 2004 09:49:03 -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 i62Gn3SF069283
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 09:49:03 -0700 (PDT)
	(envelope-from markn@bea.com)
Received: from ussjfe02.amer.bea.com (ussjfe02b.bea.com [172.16.120.56])
	by ussjmh01.bea.com (Switch-3.0.5/Switch-3.0.0) with ESMTP id i62Gn64Q022965
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 09:49:06 -0700
Received: from USSFEX01.amer.bea.com ([10.32.0.56]) by ussjfe02.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Fri, 2 Jul 2004 09:49:06 -0700
Received: from [10.0.1.3] ([192.168.11.156]) by USSFEX01.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Fri, 2 Jul 2004 09:49:06 -0700
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <BA72FC2A-CC47-11D8-B7F4-000A95BD86C0@bea.com>
Content-Transfer-Encoding: 7bit
X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg
From: Mark Nottingham <mark.nottingham@bea.com>
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: PaceXmlBaseEverywhere
Date: Fri, 2 Jul 2004 09:49:05 -0700
To: Atom Syntax <atom-syntax@imc.org>
X-Mailer: Apple Mail (2.618)
X-OriginalArrivalTime: 02 Jul 2004 16:49:06.0346 (UTC) FILETIME=[7CF978A0:01C46054]
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


Doesn't this proposal effectively require xml:base to be considered in 
the processing of ALL atom elements, attributes and extensions? Whether 
or not the extension author wants it to be? Whether or not the 
processor is aware of the semantics of the extension?

Does is require schema information for both Atom as well as extensions?

Shouldn't module authors crisply specify when xml:base is and is not 
used, so that it's crystal-clear when it's to be used?

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems



From owner-atom-syntax@mail.imc.org  Fri Jul  2 13:02: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 NAA20165
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 13:02: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 i62GlXEL069219;
	Fri, 2 Jul 2004 09: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 i62GlXY6069218;
	Fri, 2 Jul 2004 09:47:33 -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 i62GlWHF069212
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 09:47:32 -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 i62Glo8D009280;
	Fri, 2 Jul 2004 12:47:50 -0400
Message-ID: <40E591A6.5040509@intertwingly.net>
Date: Fri, 02 Jul 2004 12:47:34 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Julian Reschke <julian.reschke@gmx.de>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Validing parser required?
References: <40E57909.4040808@intertwingly.net> <40E58D3E.8090402@gmx.de>
In-Reply-To: <40E58D3E.8090402@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:

> Sam Ruby wrote:
> 
>>
>> In the interest of being "cleanly and thoroughly specified", the 
>> AtomPub Working Group should decide whether consumers should be 
>> required to use validating XML parsers in order to consistently and 
>> correctly handle the Atom feed and protocol.
> 
>  > ...
> 
> I think this discussion is pointless unless there'll be a normative 
> schema (in the generic sense) that *can* be used to validate Atom.

I don't understand what you are trying to say.

What I would like to see is some normative text that I can use to 
justify adding a check in the feedvalidator[1].  My preference is that 
such normative text promotes interoperability by discouraging or 
outright prohibiting features which pre-req a validating parser.

Does this make sense?

- Sam Ruby

P.S.  If it is relevant, the current incarnation of the feedvalidator is 
written in Python.  It is open source, and can be found at [2].

[1] http://feedvalidator.org/
[2] http://sourceforge.net/projects/feedvalidator



From owner-atom-syntax@mail.imc.org  Fri Jul  2 13: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 NAA20468
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 13:05: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 i62Gr4c6069601;
	Fri, 2 Jul 2004 09:53: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 i62Gr4Dg069600;
	Fri, 2 Jul 2004 09:53:04 -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 i62Gr3R2069590
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 09:53:03 -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 D5A2A7C117
	for <atom-syntax@imc.org>; Fri,  2 Jul 2004 19:49:14 +0200 (CEST)
To: Atom-Syntax <atom-syntax@imc.org>
Subject: PaceSimpleResourcePosting and PUT
Date: Fri, 02 Jul 2004 18:55:44 +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
Message-ID: <opsairy6o1uvpchu@quark>
User-Agent: Opera M2/7.51 (Win32, build 3798)
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


PaceSimpleResourcePosting says:

   If a client has a hard requirement to control the URIs of the
   resources it uploads, WebDAV is probably the answer.

Why can't PUT be used with Atom? I assume this will be WebDAV supportive,  
but yet defined in the Atom specification. I think  
PaceSimpleResourcePosting should define a model for both POST and PUT. I  
at least can't see why it shouldn't.

-- 
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 Jul  2 13:05: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 NAA20487
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 13:05: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 i62Gp8B4069472;
	Fri, 2 Jul 2004 09:51: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 i62Gp8rA069471;
	Fri, 2 Jul 2004 09:51:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail06.svc.cra.dublin.eircom.net (mail06.svc.cra.dublin.eircom.net [159.134.118.22])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i62Gp7O4069459
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 09:51:07 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 26431 messnum 2880027 invoked from network[62.77.172.85/62-77-172-85.customer.eircom.net]); 2 Jul 2004 16:51:05 -0000
Received: from 62-77-172-85.customer.eircom.net (HELO ?200.200.200.38?) (62.77.172.85)
  by mail06.svc.cra.dublin.eircom.net (qp 26431) with SMTP; 2 Jul 2004 16:51:05 -0000
Message-ID: <40E59276.9030609@dehora.net>
Date: Fri, 02 Jul 2004 17:51:02 +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: PaceNoInfoSet
References: <F925141D-CC46-11D8-B7F4-000A95BD86C0@mnot.net>
In-Reply-To: <F925141D-CC46-11D8-B7F4-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: <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:
> 
> What is "an application of XML 1.0 and XML Namespaces"? That's like 
> saying something is "an application of ASCII."

I guess it's meant to entail "not an application of the XML 
Infoset". Closed world Assumption and all that.

> Does this proposal have any affect on implementations or conformance?

Perhaps it's meant to stop people calling a non-XML serialization of 
Atom, "Atom". Binary XML Brand Management Permathread and all that.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Fri Jul  2 13: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 NAA21095
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 13:18: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 i62H31dI070531;
	Fri, 2 Jul 2004 10:03:01 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i62H31vt070530;
	Fri, 2 Jul 2004 10:03: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.net [213.165.64.20])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i62H2xir070520
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 10:03:00 -0700 (PDT)
	(envelope-from julian.reschke@gmx.de)
Received: (qmail 19888 invoked by uid 65534); 2 Jul 2004 17:02:57 -0000
Received: from p508257B1.dip0.t-ipconnect.de (EHLO [192.168.1.15]) (80.130.87.177)
  by mail.gmx.net (mp011) with SMTP; 02 Jul 2004 19:02:57 +0200
X-Authenticated: #1915285
Message-ID: <40E59539.1030005@gmx.de>
Date: Fri, 02 Jul 2004 19:02:49 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sam Ruby <rubys@intertwingly.net>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Validing parser required?
References: <40E57909.4040808@intertwingly.net> <40E58D3E.8090402@gmx.de> <40E591A6.5040509@intertwingly.net>
In-Reply-To: <40E591A6.5040509@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:

> I don't understand what you are trying to say.

Talking about using a validating parser implies that their exists a 
normative DTD/XML Schema/RNG Schema/Whatever against which Atom *can* be 
validated. Futhermore, in the strict sense defined by the XML REC, that 
would need to be a DTD (the XML REC itself does not define any other 
validation method).

> What I would like to see is some normative text that I can use to 
> justify adding a check in the feedvalidator[1].  My preference is that 
> such normative text promotes interoperability by discouraging or 
> outright prohibiting features which pre-req a validating parser.
> 
> Does this make sense?

Yes (sort of :-).

I think we need to distinguish between (at least) two things:

1) Validation of XML in the sense of using a DTD/Schema whatever to add 
specific constraints on the allowable content and

2) the ability to use internal DTD subsets to define external inclusions 
or entities.

I think 1) is only possible if there is a normative Schema (in whatever 
schema language) that actually *can* be used to validate Atom.

For 2), I think the spec should allow recipients to reject/ignore 
certains parts of an internal DTD subset, thereby requiring producers 
not to use those.

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From owner-atom-syntax@mail.imc.org  Fri Jul  2 13: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 NAA21114
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 13: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 i62H5RLi070670;
	Fri, 2 Jul 2004 10:05: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 i62H5Rlk070669;
	Fri, 2 Jul 2004 10:05: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 i62H5Qpi070662
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 10:05: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 i62H5iBn010211;
	Fri, 2 Jul 2004 13:05:45 -0400
Message-ID: <40E595D9.2010605@intertwingly.net>
Date: Fri, 02 Jul 2004 13:05:29 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Validing parser required?
References: <40E57909.4040808@intertwingly.net> <40E5910A.3010600@dehora.net>
In-Reply-To: <40E5910A.3010600@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:

> Sam Ruby wrote:
> 
>> In the interest of being "cleanly and thoroughly specified", the 
>> AtomPub Working Group should decide whether consumers should be 
>> required to use validating XML parsers in order to consistently and 
>> correctly handle the Atom feed and protocol.
>>
>  > [...]
> 
>> The requirement for a DTD was dropped in both the UserLand 0.91 
>> spec[3] (and has not reappeared in subsequent revisions derived from 
>> this spec), nor was is it present in the RSS 1.0 spec[4].
> 
> Inline DTDs aside, a DTD for Atom itself doesn't sound feasible given 
> the current spec wording on ordering [1].

There's a difference between "a full and general purpose DTD isn't 
feasible" and "usage of DTDs for specific purposes are not allowed".

An example of an attempt to use a DTD for the purpose of importing a set 
of predefined character references is described here:

http://philringnalda.com/blog/2004/07/ah_sweet_irony.php

I either want to identify this as something that is clearly legal (and 
therefore something a conformance test should be written for), or 
discouraged/illegal (and therefore something that the feedvalidator 
should detect).

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Fri Jul  2 13:18: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 NAA21149
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 13:18: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 i62H1tC8070497;
	Fri, 2 Jul 2004 10: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 i62H1tmS070496;
	Fri, 2 Jul 2004 10:01: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 i62H1s5K070485
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 10:01: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 931317C117; Fri,  2 Jul 2004 19:58:11 +0200 (CEST)
Date: Fri, 02 Jul 2004 19:04:42 +0200
To: "Sam Ruby" <rubys@intertwingly.net>
Subject: Re: Validing parser required?
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <40E57909.4040808@intertwingly.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: <opsaisd4ttuvpchu@quark>
In-Reply-To: <40E57909.4040808@intertwingly.net>
User-Agent: Opera M2/7.51 (Win32, build 3798)
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, 02 Jul 2004 11:02:33 -0400, Sam Ruby <rubys@intertwingly.net>  
wrote:

> In the interest of being "cleanly and thoroughly specified", the AtomPub  
> Working Group should decide whether consumers should be required to use  
> validating XML parsers in order to consistently and correctly handle the  
> Atom feed and protocol.

I think that Atom SHOULD NOT use a DOCTYPE or DTD to validate. I'm not  
sure it should be enforced validated at all, but if it should, the way to  
do it is with XSD, RNG or some other more updated definition language.

So, I'd say a clear and bastant «no» to DOCTYPE's and DTD's, but a «dunno»  
to other validation mechanisms. I think a normative XSD would be nice, but  
how we would knit it into the specification is something I have no clue  
about.

-- 
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 Jul  2 13:25: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 NAA21577
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 13:25: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 i62H9h56070929;
	Fri, 2 Jul 2004 10: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 i62H9h2a070928;
	Fri, 2 Jul 2004 10:09:43 -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 i62H9hEs070913
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 10:09: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 KAA21035
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 10:09:39 -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 KAA01202
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 10:09:39 -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, 02 Jul 2004 10:09:38 -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 <0I080094AIC2U2@shazam.verity.com> for atom-syntax@imc.org; Fri,
 02 Jul 2004 10:09:38 -0700 (PDT)
Date: Fri, 02 Jul 2004 10:14:36 -0700
From: Walter Underwood <wunder@verity.com>
Subject: Re: Validing parser required?
In-reply-to: <20040702160222.GO5957@tartarus.org>
To: Atom-Syntax <atom-syntax@imc.org>
Message-id: <A6E0CEEBB30A0208C3AD370C@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: <40E57909.4040808@intertwingly.net>
 <20040702160222.GO5957@tartarus.org>
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, July 02, 2004 05:02:22 PM +0100 James Aylett 
<james@tartarus.org> wrote:
>
>        An Atom document MUST be expressed such that its meaning is
>        identical whether a validating or non-validating XML parser is
>        used.

That is pretty good. Here is a simpler version. We should be specific
about what this means, though. This is a profile of XML, right?

  The meaning of an Atom document MUST be the same whether processed
  with a validating or non-validating XML parser.

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek



From owner-atom-syntax@mail.imc.org  Fri Jul  2 13:27: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 NAA21729
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 13:27: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 i62H9eIj070920;
	Fri, 2 Jul 2004 10: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 i62H9eRA070919;
	Fri, 2 Jul 2004 10:09: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 i62H9cQ2070911
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 10:09: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 BDF7E7C117; Fri,  2 Jul 2004 20:05:55 +0200 (CEST)
Date: Fri, 02 Jul 2004 19:12:28 +0200
To: "Mark Nottingham" <mnot@mnot.net>
Subject: Re: PaceNoInfoSet
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <F925141D-CC46-11D8-B7F4-000A95BD86C0@mnot.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: <opsaisq2j9uvpchu@quark>
In-Reply-To: <F925141D-CC46-11D8-B7F4-000A95BD86C0@mnot.net>
User-Agent: Opera M2/7.51 (Win32, build 3798)
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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, 2 Jul 2004 09:43:40 -0700, Mark Nottingham <mnot@mnot.net> wrote:

> What is "an application of XML 1.0 and XML Namespaces"? That's like  
> saying something is "an application of ASCII."

I agree. The wording is really odd. Also, I can't see what we gain from  
disallowing other serializatin methods than XML 1.0. What happens when XML  
2.0 arrives? What if someone wants to define an RFC for Enamel  
serialization of Atom?

> Does this proposal have any affect on implementations or conformance?

I think it reflects the current state of affairs, because Atom is almost  
solely defined in syntax and not in an abstract model. I don't think the  
syntax definition rules out other serializations than XML, 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  Fri Jul  2 13:27: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 NAA21751
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 13:27: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 i62HCpxL071431;
	Fri, 2 Jul 2004 10:12: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 i62HCpQY071430;
	Fri, 2 Jul 2004 10:12: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 (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i62HCo63071411
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 10:12: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 46CE77C117; Fri,  2 Jul 2004 20:09:07 +0200 (CEST)
To: "Mark Nottingham" <mark.nottingham@bea.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceXmlBaseEverywhere
References: <BA72FC2A-CC47-11D8-B7F4-000A95BD86C0@bea.com>
Message-ID: <opsaiswfiiuvpchu@quark>
Date: Fri, 02 Jul 2004 19:15:41 +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: <BA72FC2A-CC47-11D8-B7F4-000A95BD86C0@bea.com>
User-Agent: Opera M2/7.51 (Win32, build 3798)
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, 2 Jul 2004 09:49:05 -0700, Mark Nottingham  
<mark.nottingham@bea.com> wrote:

> Shouldn't module authors crisply specify when xml:base is and is not  
> used, so that it's crystal-clear when it's to be used?

Just as with 'xml:lang'[1], I think it's obvious that 'xml:base' should be  
defined as a part of the Content Construct. Then, we don't need to go  
through the hoops and loops to say what elements it should and should not  
exist on, because that is implied with all the elements defined as Content  
Constructs.

____
[1] <url: http://www.intertwingly.net/wiki/pie/PaceLang>

-- 
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 Jul  2 13: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 NAA21947
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 13: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 i62HHChY071758;
	Fri, 2 Jul 2004 10: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 i62HHCGD071757;
	Fri, 2 Jul 2004 10:17: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 i62HHBBU071751
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 10:17: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 i62HHHT8010708;
	Fri, 2 Jul 2004 13:17:17 -0400
Message-ID: <40E5988E.6090900@intertwingly.net>
Date: Fri, 02 Jul 2004 13:17:02 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Julian Reschke <julian.reschke@gmx.de>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Validing parser required?
References: <40E57909.4040808@intertwingly.net> <40E58D3E.8090402@gmx.de> <40E591A6.5040509@intertwingly.net> <40E59539.1030005@gmx.de>
In-Reply-To: <40E59539.1030005@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:

> Sam Ruby wrote:
> 
>> I don't understand what you are trying to say.
> 
> 
> Talking about using a validating parser implies that their exists a 
> normative DTD/XML Schema/RNG Schema/Whatever against which Atom *can* be 
> validated. Futhermore, in the strict sense defined by the XML REC, that 
> would need to be a DTD (the XML REC itself does not define any other 
> validation method).
> 
>> What I would like to see is some normative text that I can use to 
>> justify adding a check in the feedvalidator[1].  My preference is that 
>> such normative text promotes interoperability by discouraging or 
>> outright prohibiting features which pre-req a validating parser.
>>
>> Does this make sense?
> 
> 
> Yes (sort of :-).
> 
> I think we need to distinguish between (at least) two things:
> 
> 1) Validation of XML in the sense of using a DTD/Schema whatever to add 
> specific constraints on the allowable content and
> 
> 2) the ability to use internal DTD subsets to define external inclusions 
> or entities.
> 
> I think 1) is only possible if there is a normative Schema (in whatever 
> schema language) that actually *can* be used to validate Atom.
> 
> For 2), I think the spec should allow recipients to reject/ignore 
> certains parts of an internal DTD subset, thereby requiring producers 
> not to use those.

In order to help focus on specifics, take a look at the following feed:

http://www.oreillynet.com/meerkat/?_fl=rss10&t=ALL&c=47

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Fri Jul  2 13:32: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 NAA21975
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 13:32: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 i62HEdoc071601;
	Fri, 2 Jul 2004 10:14: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 i62HEdNO071600;
	Fri, 2 Jul 2004 10:14:39 -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 i62HEcbP071590
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 10:14:38 -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 i62HEat12290
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 10:14:36 -0700 (PDT)
Received: from aol.net ([10.169.192.58]) by judge.mcom.com
          (Netscape Messaging Server 4.15) with ESMTP id I08IKC03.C10;
          Fri, 2 Jul 2004 10:14:36 -0700 
Message-ID: <40E597FF.8020808@aol.net>
Date: Fri, 02 Jul 2004 10:14:39 -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: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceSimpleResourcePosting and PUT
References: <opsairy6o1uvpchu@quark>
In-Reply-To: <opsairy6o1uvpchu@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:

>
> PaceSimpleResourcePosting says:
>
>   If a client has a hard requirement to control the URIs of the
>   resources it uploads, WebDAV is probably the answer.
>
> Why can't PUT be used with Atom? I assume this will be WebDAV 
> supportive,  but yet defined in the Atom specification. I think  
> PaceSimpleResourcePosting should define a model for both POST and PUT. 
> I  at least can't see why it shouldn't.
>
I like PUT and DELETE too.  I didn't put them into 
PaceSimpleResourcePosting because I didn't think they were necessary and 
they need some more work to be properly defined.  I'm frankly really 
lazy and want someone else to do the work.  Asbjørn, would you like to 
volunteer? :^)

Here are some of the questions I'd raise about PUT and DELETE:

o These apply to the resource itself.  Can all Atom servers support PUT 
and DELETE on resources?  This is a serious question -- some people have 
said that they are restricted to CGI scripts and cannot modify their 
servers; we're talking about workarounds for passing authentication 
information to CGI scripts because of this.  So my first question is, is 
this supportable by all Atom-enabled servers?

o Not all users can PUT and DELETE all resources (consider access 
controls, shared blogs, etc.).  So you need a way to query as to whether 
you can perform an operation.  The Allowed: and Public: response headers 
(http://www.w3.org/Protocols/HTTP/Object_Headers.html#z6) seem like the 
natural way to do this and I believe this is compatible with WebDAV.  
For example, Allowed: GET HEAD PUT DELETE means that you, the user 
making the HEAD request, can perform a PUT to the resource.  Is this 
supportable by all Atom-enabled servers?

o Do we want to ensure that whatever Atom does in this area is "upward 
compatible" with WebDAV?  (I think this is the consensus, but I don't 
know if anyone has looked at the details for things like PUT and DELETE.)

o Is PUT transactional? 

(http://www.intertwingly.net/wiki/pie/PaceNonEntryResources also calls 
for PUT and DELETE.)

-John Panzer



From owner-atom-syntax@mail.imc.org  Fri Jul  2 13:36: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 NAA22153
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 13: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 i62HMkF9072384;
	Fri, 2 Jul 2004 10: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 i62HMkCK072383;
	Fri, 2 Jul 2004 10: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.net [213.165.64.20])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i62HMim7072374
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 10:22:45 -0700 (PDT)
	(envelope-from julian.reschke@gmx.de)
Received: (qmail 6845 invoked by uid 65534); 2 Jul 2004 17:22:42 -0000
Received: from p508257B1.dip0.t-ipconnect.de (EHLO [192.168.1.15]) (80.130.87.177)
  by mail.gmx.net (mp015) with SMTP; 02 Jul 2004 19:22:42 +0200
X-Authenticated: #1915285
Message-ID: <40E599E1.9020506@gmx.de>
Date: Fri, 02 Jul 2004 19:22:41 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sam Ruby <rubys@intertwingly.net>
CC: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>,
        Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Validing parser required?
References: <40E57909.4040808@intertwingly.net> <40E5910A.3010600@dehora.net> <40E595D9.2010605@intertwingly.net>
In-Reply-To: <40E595D9.2010605@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:

> There's a difference between "a full and general purpose DTD isn't 
> feasible" and "usage of DTDs for specific purposes are not allowed".
> 
> An example of an attempt to use a DTD for the purpose of importing a set 
> of predefined character references is described here:
> 
> http://philringnalda.com/blog/2004/07/ah_sweet_irony.php
> 
> I either want to identify this as something that is clearly legal (and 
> therefore something a conformance test should be written for), or 
> discouraged/illegal (and therefore something that the feedvalidator 
> should detect).

 From an pure XML Rec point of view, using an internal DTD subset 
clearly is legal. However, you can't rely on the parser to actually 
resolve externals, so producing content that becomes illformed when not 
definitively is an incredibly stupid thing to do.

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From owner-atom-syntax@mail.imc.org  Fri Jul  2 13: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 NAA23356
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 13: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 i62HlIIm074505;
	Fri, 2 Jul 2004 10: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 i62HlIX6074504;
	Fri, 2 Jul 2004 10:47:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.251])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i62HlIa6074496
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 10:47:18 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id w29so4359988cwb
        for <atom-syntax@imc.org>; Fri, 02 Jul 2004 10:47:16 -0700 (PDT)
Received: by 10.11.99.49 with SMTP id w49mr100123cwb;
        Fri, 02 Jul 2004 10:47:16 -0700 (PDT)
Message-ID: <3f1451f504070210475215e6fb@mail.gmail.com>
Date: Fri, 2 Jul 2004 13:47:16 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: "Asbjørn Ulsberg" <asbjorn@tigerstaden.no>
Subject: Re: PaceNoInfoSet
Cc: Mark Nottingham <mnot@mnot.net>, Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <opsaisq2j9uvpchu@quark>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
References: <F925141D-CC46-11D8-B7F4-000A95BD86C0@mnot.net> <opsaisq2j9uvpchu@quark>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i62HlIa6074499
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, 02 Jul 2004 19:12:28 +0200, Asbjørn Ulsberg
<asbjorn@tigerstaden.no> wrote:
> 
> On Fri, 2 Jul 2004 09:43:40 -0700, Mark Nottingham <mnot@mnot.net> wrote:
> 
> > What is "an application of XML 1.0 and XML Namespaces"? That's like
> > saying something is "an application of ASCII."
> 
> I agree. The wording is really odd. Also, I can't see what we gain from
> disallowing other serializatin methods than XML 1.0. 

You gain interoperability.

> What happens when XML 2.0 arrives? 

You don't use it with Atom until a follow-up
RFC obsoletes this one.

> What if someone wants to define an RFC for Enamel
> serialization of Atom?

Then write an RFC for it, but don't 
use the application/atom+xml media-type.

    -joe



From owner-atom-syntax@mail.imc.org  Fri Jul  2 14: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 OAA24902
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 14: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 i62HuZdY075292;
	Fri, 2 Jul 2004 10:56: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 i62HuZqc075291;
	Fri, 2 Jul 2004 10:56: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 (mproxy.gmail.com [216.239.56.243])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i62HuZlj075223
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 10:56:35 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so6731761cwc
        for <atom-syntax@imc.org>; Fri, 02 Jul 2004 10:56:33 -0700 (PDT)
Received: by 10.11.99.30 with SMTP id w30mr114607cwb;
        Fri, 02 Jul 2004 10:56:33 -0700 (PDT)
Message-ID: <3f1451f5040702105640de1ac7@mail.gmail.com>
Date: Fri, 2 Jul 2004 13:56:33 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: John Panzer <jpanzer@aol.net>
Subject: Re: PaceSimpleResourcePosting and PUT
Cc: "Asbjørn Ulsberg" <asbjorn@tigerstaden.no>,
        Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <40E597FF.8020808@aol.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
References: <opsairy6o1uvpchu@quark> <40E597FF.8020808@aol.net>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i62HuZlj075286
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, 02 Jul 2004 10:14:39 -0700, John Panzer <jpanzer@aol.net> wrote:
> 
> 
> Asbjørn Ulsberg wrote:
> 
> >
> > PaceSimpleResourcePosting says:
> >
> >   If a client has a hard requirement to control the URIs of the
> >   resources it uploads, WebDAV is probably the answer.
> >
> > Why can't PUT be used with Atom? I assume this will be WebDAV
> > supportive,  but yet defined in the Atom specification. I think
> > PaceSimpleResourcePosting should define a model for both POST and PUT.
> > I  at least can't see why it shouldn't.
> >
> I like PUT and DELETE too.  I didn't put them into
> PaceSimpleResourcePosting because I didn't think they were necessary and
> they need some more work to be properly defined.  I'm frankly really
> lazy and want someone else to do the work.  Asbjørn, would you like to
> volunteer? :^)
> 
> Here are some of the questions I'd raise about PUT and DELETE:
> 
> o These apply to the resource itself.  Can all Atom servers support PUT
> and DELETE on resources?  This is a serious question -- some people have
> said that they are restricted to CGI scripts and cannot modify their
> servers; we're talking about workarounds for passing authentication
> information to CGI scripts because of this.  So my first question is, is
> this supportable by all Atom-enabled servers?


http://intertwingly.net/wiki/pie/CarrotVsOrange#head-656ecf72eccf403df5368dd110da502137cd7658

> o Not all users can PUT and DELETE all resources (consider access
> controls, shared blogs, etc.).  So you need a way to query as to whether
> you can perform an operation.  The Allowed: and Public: response headers
> (http://www.w3.org/Protocols/HTTP/Object_Headers.html#z6) seem like the
> natural way to do this and I believe this is compatible with WebDAV.
> For example, Allowed: GET HEAD PUT DELETE means that you, the user
> making the HEAD request, can perform a PUT to the resource.  Is this
> supportable by all Atom-enabled servers?

I have seen no problems in adding headers to responses
on any server platform.

    -joe



From owner-atom-syntax@mail.imc.org  Fri Jul  2 14:17: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 OAA25248
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 14:17: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 i62I5KFr075726;
	Fri, 2 Jul 2004 11: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 i62I5KAX075725;
	Fri, 2 Jul 2004 11:05: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 i62I5Jqf075716
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 11:05: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 i62I3L53002527
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 12:03:21 -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 <0I08005HPKWWP2@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Fri, 02 Jul 2004 12:05:20 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0800KZQKWV3N@mail.sun.net> for atom-syntax@imc.org; Fri,
 02 Jul 2004 12:05:20 -0600 (MDT)
Date: Fri, 02 Jul 2004 11:05:42 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Validing parser required?
In-reply-to: <40E58C3C.7010908@franklinmint.fm>
To: mint@franklinmint.fm
Cc: James Aylett <james@tartarus.org>, Atom-Syntax <atom-syntax@imc.org>
Message-id: <6EC38B00-CC52-11D8-A54F-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: <40E57909.4040808@intertwingly.net>
 <20040702160222.GO5957@tartarus.org> <40E58C3C.7010908@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 Jul 2, 2004, at 9:24 AM, Robert Sayre wrote:

> Cribbing a bit from the section 5.2 of the XML spec:
>
> "Atom documents can be processed by non-validating XML processors. An 
> Atom document MUST NOT rely on any behaviors not required of such 
> processors."

+1.

And on the SOAP approach (forbidding <!DOCTYPE>); that explicitly flies 
in the face of RFC3470 and if we want to try that, we're going to have 
to come up with persuasive language as to why we're doing something 
that an IETF Best Current Practice says you SHOULD NOT do.  I think 
Robert Sayre's language hits the sweet spot.  Walter's retake is OK too 
if people prefer that.  -Tim



From owner-atom-syntax@mail.imc.org  Fri Jul  2 14:21: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 OAA25433
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 14:21: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 i62IBEPu075994;
	Fri, 2 Jul 2004 11:11: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 i62IBEFi075993;
	Fri, 2 Jul 2004 11:11: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 i62IBCUc075985
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 11:11:13 -0700 (PDT)
	(envelope-from julian.reschke@gmx.de)
Received: (qmail 25130 invoked by uid 65534); 2 Jul 2004 18:11:10 -0000
Received: from pD9535630.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.86.48)
  by mail.gmx.net (mp008) with SMTP; 02 Jul 2004 20:11:10 +0200
X-Authenticated: #1915285
Message-ID: <40E5A53B.5000609@gmx.de>
Date: Fri, 02 Jul 2004 20:11:07 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: John Panzer <jpanzer@aol.net>
CC: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>,
        Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceSimpleResourcePosting and PUT
References: <opsairy6o1uvpchu@quark> <40E597FF.8020808@aol.net>
In-Reply-To: <40E597FF.8020808@aol.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


John Panzer wrote:
> ...
> o Not all users can PUT and DELETE all resources (consider access 
> controls, shared blogs, etc.).  So you need a way to query as to whether 
> you can perform an operation.  The Allowed: and Public: response headers 
> (http://www.w3.org/Protocols/HTTP/Object_Headers.html#z6) seem like the 
> natural way to do this and I believe this is compatible with WebDAV.  
> For example, Allowed: GET HEAD PUT DELETE means that you, the user 
> making the HEAD request, can perform a PUT to the resource.  Is this 
> supportable by all Atom-enabled servers?

That's not the way WebDAV sees it. In general, the OPTIONS method isn't 
supposed to take access privileges into account. The Allow: header lists 
the methods for which you're guaranteed to get a 405 (Not Allowed) 
response. However, when you're not privileged to execute a specific 
method, you would usually get a 403 (Forbidden).

WebDAV defines a much more complex Access Control Protocol (RFC3744); 
however I think it would be overkill to requires this for Atom.

> o Do we want to ensure that whatever Atom does in this area is "upward 
> compatible" with WebDAV?  (I think this is the consensus, but I don't 
> know if anyone has looked at the details for things like PUT and DELETE.)

I would hope so. To rephrase it, it MUST be possible to implement a 
server in such a way as it conforms both to RFC2518 and Atom.

> o Is PUT transactional?

What's the issue here?

> (http://www.intertwingly.net/wiki/pie/PaceNonEntryResources also calls 
> for PUT and DELETE.)

Best regards, Julian


-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From owner-atom-syntax@mail.imc.org  Fri Jul  2 14: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 OAA26559
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 14:29: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 i62IJIPS076528;
	Fri, 2 Jul 2004 11:19: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 i62IJIbX076527;
	Fri, 2 Jul 2004 11:19: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 i62IJH8I076517
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 11:19:17 -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 LAA28607
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 11:19:16 -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 LAA18415
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 11:19:15 -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, 02 Jul 2004 11:19:14 -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 <0I08009KQLK0U2@shazam.verity.com> for atom-syntax@imc.org; Fri,
 02 Jul 2004 11:19:14 -0700 (PDT)
Date: Fri, 02 Jul 2004 11:19:14 -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: Validing parser required?
In-reply-to: <40E5988E.6090900@intertwingly.net>
To: Atom-Syntax <atom-syntax@imc.org>
Message-id: <9FE57F8410936E5FF74207BF@[192.168.168.164]>
MIME-version: 1.0
X-Mailer: Mulberry/3.1.5 (Mac OS X)
Content-type: text/plain; charset=iso-8859-1; format=flowed
Content-disposition: inline
References: <40E57909.4040808@intertwingly.net> <40E58D3E.8090402@gmx.de>
 <40E591A6.5040509@intertwingly.net> <40E59539.1030005@gmx.de>
 <40E5988E.6090900@intertwingly.net>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i62IJH8I076521
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 Friday, July 2, 2004 1:17 PM -0400 Sam Ruby <rubys@intertwingly.net> wrote:
>
> In order to help focus on specifics, take a look at the following feed:
>
> http://www.oreillynet.com/meerkat/?_fl=rss10&t=ALL&c=47

Amusing. They specifically allow the latin 1 entities, but the
feed is pure ASCII, with an ASCII apostrophe for "O'Reilly" and
" -- " for the em dash. Those aren't in Latin 1, but they could use
something outside of ASCII.

Here is a Meerkat feed which uses a numeric ref for ã, which is
in Latin 1.

  <http://www.oreillynet.com/meerkat/?_fl=rss10&t=ALL&c=5800>

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Fri Jul  2 14:42: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 OAA27761
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 14: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 i62IUU53077784;
	Fri, 2 Jul 2004 11:30: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 i62IUUYQ077783;
	Fri, 2 Jul 2004 11:30: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 i62IUUuN077772
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 11:30: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 LAA29375
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 11:30: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 LAA20126
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 11:30:28 -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, 02 Jul 2004 11:30: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 <0I08009SDM2RU2@shazam.verity.com> for atom-syntax@imc.org; Fri,
 02 Jul 2004 11:30:27 -0700 (PDT)
Date: Fri, 02 Jul 2004 11:35:26 -0700
From: Walter Underwood <wunder@verity.com>
Subject: Re: Validing parser required?
In-reply-to: <6EC38B00-CC52-11D8-A54F-000A95A51C9E@sun.com>
To: Atom-Syntax <atom-syntax@imc.org>
Message-id: <6B213038F79C59914203DE57@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: <40E57909.4040808@intertwingly.net>
 <20040702160222.GO5957@tartarus.org> <40E58C3C.7010908@franklinmint.fm>
 <6EC38B00-CC52-11D8-A54F-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


I prefer this wording, but with MAY instead of "can". --wunder

--On Friday, July 02, 2004 11:05:42 AM -0700 Tim Bray <Tim.Bray@Sun.COM> 
wrote:

>
> On Jul 2, 2004, at 9:24 AM, Robert Sayre wrote:
>
>> Cribbing a bit from the section 5.2 of the XML spec:
>>
>> "Atom documents can be processed by non-validating XML processors. An
>> Atom document MUST NOT rely on any behaviors not required of such
>> processors."
>
> +1.
>
> And on the SOAP approach (forbidding <!DOCTYPE>); that explicitly flies
> in the face of RFC3470 and if we want to try that, we're going to have to
> come up with persuasive language as to why we're doing something that an
> IETF Best Current Practice says you SHOULD NOT do.  I think Robert
> Sayre's language hits the sweet spot.  Walter's retake is OK too if
> people prefer that.  -Tim
>



--
Walter Underwood
Principal Architect
Verity Ultraseek



From owner-atom-syntax@mail.imc.org  Fri Jul  2 14: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 OAA28077
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 14:46: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 i62IYrxm078107;
	Fri, 2 Jul 2004 11:34: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 i62IYr3B078106;
	Fri, 2 Jul 2004 11:34: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 SMTP id i62IYqpH078099
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 11:34:52 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id 55so487545rni
        for <atom-syntax@imc.org>; Fri, 02 Jul 2004 11:34:52 -0700 (PDT)
Received: by 10.38.92.63 with SMTP id p63mr57704rnb;
        Fri, 02 Jul 2004 11:34:52 -0700 (PDT)
Message-ID: <14be96d304070211344905c91@mail.gmail.com>
Date: Fri, 2 Jul 2004 14:34:52 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Walter Underwood <wunder@verity.com>
Subject: Re: Validing parser required?
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <9FE57F8410936E5FF74207BF@192.168.168.164>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <40E57909.4040808@intertwingly.net> <40E58D3E.8090402@gmx.de>
 <40E591A6.5040509@intertwingly.net> <40E59539.1030005@gmx.de>
 <40E5988E.6090900@intertwingly.net> <9FE57F8410936E5FF74207BF@192.168.168.164>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


On Fri, 02 Jul 2004 11:19:14 -0700, Walter Underwood <wunder@verity.com> wrote:
> --On Friday, July 2, 2004 1:17 PM -0400 Sam Ruby <rubys@intertwingly.net> wrote:
> > http://www.oreillynet.com/meerkat/?_fl=rss10&t=ALL&c=47
> 
> Amusing. They specifically allow the latin 1 entities, but the
> feed is pure ASCII

$ curl -sI "http://www.oreillynet.com/meerkat/?_fl=rss10&t=ALL&c=47" |
grep "Content-Type"
Content-Type: text/xml

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Fri Jul  2 16:16: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 QAA04274
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 16:16: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 i62JvFfc084629;
	Fri, 2 Jul 2004 12:57: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 i62JvEwI084628;
	Fri, 2 Jul 2004 12:57:14 -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 i62JvEt4084621
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 12:57:14 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.3] (unknown [63.96.163.9])
	by mail.mnot.net (Postfix) with ESMTP
	id 42C4C7288; Fri,  2 Jul 2004 12:57:18 -0700 (PDT)
In-Reply-To: <opsaiswfiiuvpchu@quark>
References: <BA72FC2A-CC47-11D8-B7F4-000A95BD86C0@bea.com> <opsaiswfiiuvpchu@quark>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <05119649-CC62-11D8-B7F4-000A95BD86C0@mnot.net>
Cc: Atom-Syntax <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: Re: PaceXmlBaseEverywhere
Date: Fri, 2 Jul 2004 12:57:17 -0700
To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
X-Mailer: Apple Mail (2.618)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i62JvEt4084622
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 Jul 2, 2004, at 10:15 AM, Asbjørn Ulsberg wrote:

> On Fri, 2 Jul 2004 09:49:05 -0700, Mark Nottingham 
> <mark.nottingham@bea.com> wrote:
>
>> Shouldn't module authors crisply specify when xml:base is and is not 
>> used, so that it's crystal-clear when it's to be used?
>
> Just as with 'xml:lang'[1], I think it's obvious that 'xml:base' 
> should be defined as a part of the Content Construct. Then, we don't 
> need to go through the hoops and loops to say what elements it should 
> and should not exist on, because that is implied with all the elements 
> defined as Content Constructs.

That sounds much more reasonable -- I'm only worried about saying that 
"everything" has xml:base processing applied, because it's so 
imprecise.

--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org  Fri Jul  2 16: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 QAA05200
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 16: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 i62KOstn086411;
	Fri, 2 Jul 2004 13:24: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 i62KOsaC086410;
	Fri, 2 Jul 2004 13:24: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 i62KOr33086388
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 13:24: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 3A4847C117; Fri,  2 Jul 2004 23:21:03 +0200 (CEST)
To: "Mark Nottingham" <mnot@mnot.net>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceXmlBaseEverywhere
References: <BA72FC2A-CC47-11D8-B7F4-000A95BD86C0@bea.com> <opsaiswfiiuvpchu@quark> <05119649-CC62-11D8-B7F4-000A95BD86C0@mnot.net>
Message-ID: <opsai1tmg8uvpchu@quark>
Date: Fri, 02 Jul 2004 22:28:24 +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: <05119649-CC62-11D8-B7F4-000A95BD86C0@mnot.net>
User-Agent: Opera M2/7.51 (Win32, build 3798)
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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, 2 Jul 2004 12:57:17 -0700, Mark Nottingham <mnot@mnot.net> wrote:

>> Just as with 'xml:lang'[1], I think it's obvious that 'xml:base' should  
>> be defined as a part of the Content Construct.
>
> That sounds much more reasonable

Yup. We probably need an alternative Pace, then, won't we?

> I'm only worried about saying that "everything" has xml:base processing
> applied, because it's so imprecise.

I totally agree. I can't see why one would ever want 'xml:base' on  
atom:issued either.

-- 
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 Jul  2 16:42: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 QAA05293
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 16:42:22 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i62KUHWS086911;
	Fri, 2 Jul 2004 13:30: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 i62KUHpx086910;
	Fri, 2 Jul 2004 13:30: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 i62KUGsH086887
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 13:30: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 6F2A47C117; Fri,  2 Jul 2004 23:26:32 +0200 (CEST)
Date: Fri, 02 Jul 2004 22:33:54 +0200
To: "Joe Gregorio" <joe.gregorio@gmail.com>
Subject: Re: PaceNoInfoSet
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <F925141D-CC46-11D8-B7F4-000A95BD86C0@mnot.net> <opsaisq2j9uvpchu@quark> <3f1451f504070210475215e6fb@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: <opsai12skpuvpchu@quark>
In-Reply-To: <3f1451f504070210475215e6fb@mail.gmail.com>
User-Agent: Opera M2/7.51 (Win32, build 3798)
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, 2 Jul 2004 13:47:16 -0400, Joe Gregorio <joe.gregorio@gmail.com>  
wrote:

>> I can't see what we gain from disallowing other serializatin
>> methods than XML 1.0.
>
> You gain interoperability.

True.

>> What happens when XML 2.0 arrives?
>
> You don't use it with Atom until a follow-up RFC obsoletes this
> one.

Right.

>> What if someone wants to define an RFC for Enamel
>> serialization of Atom?
>
> Then write an RFC for it, but don't use the
> application/atom+xml media-type.

That wouldn't be the idea, either. If the intent of the Pace is to  
disallow other formats than XML to be transmitted with the mime type  
'application/atom+xml', I think requiring no infoset and no other  
serializations is to shoot flies with artillery.

Can't we just say somewhere in the specification that for  
'application/atom+xml' no other format than XML (which I think is very  
strongly implied in the MIME type, anyway) should be served? If someone  
wants to transmit Atom as Enamel, they should create a MIME type for it,  
e.g. 'application/atom+nml'.

-- 
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 Jul  2 16:57: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 QAA06231
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 16:57: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 i62Kfwvp088741;
	Fri, 2 Jul 2004 13:41:58 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i62KfwmE088740;
	Fri, 2 Jul 2004 13:41:58 -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 i62KfvJU088626
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 13:41:57 -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 i62Kfu53029539
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 15:41:56 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i62Kft37029535;
	Fri, 2 Jul 2004 15:41:55 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: atom-syntax@imc.org
Subject: PaceIntrospection: @title vs. <title>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 02 Jul 2004 15:41:55 -0500
Message-ID: <m38ye2ta3w.fsf@bitsko.slc.ut.us>
Lines: 9
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


PaceIntrospection's <site> has a title attribute following the pattern
of a <link> element rather than a <title> element following the
pattern of the <Feed> and <entry> elements.

Since <site> seems more like a metadata container similar to <feed>
and <entry> (as discussed more strongly in the "new file format"
thread), I propose changing @title to <title>.

  -- Ken



From owner-atom-syntax@mail.imc.org  Fri Jul  2 17:03:32 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06547
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 17:03:32 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i62Kksst089287;
	Fri, 2 Jul 2004 13:46: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 i62Kksen089286;
	Fri, 2 Jul 2004 13:46:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i62Kkr9p089273
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 13:46:53 -0700 (PDT)
	(envelope-from antone@geckotribe.com)
Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134])
          by comcast.net (sccrmhc11) with SMTP
          id <2004070220465101100j0apee>; Fri, 2 Jul 2004 20:46:52 +0000
Date: Fri, 2 Jul 2004 14:46:50 -0600
Subject: Re: PaceXmlBaseEverywhere
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: <05119649-CC62-11D8-B7F4-000A95BD86C0@mnot.net>
Message-Id: <F166A3FB-CC68-11D8-B0A4-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


>> Shouldn't module authors crisply specify when xml:base is and is not 
>> used, so that it's crystal-clear when it's to be used?
> Just as with 'xml:lang'[1], I think it's obvious that 'xml:base' 
> should be defined as a part of the Content Construct. Then, we don't 
> need to go through the hoops and loops to say what elements it should 
> and should not exist on, because that is implied with all the elements 
> defined as Content Constructs.
>
...and link.  And service (if PaceServiceElement is adopted).  I think 
we need to consider each element to be sure we don't accidentally 
forget any, and then list specifically which elements it applies to.  
If someone wants to make a wiki page to keep track of elements where 
we've decided that xml:base processing DOESN'T apply, that would save 
us periodically running through the whole list after new elements are 
added (but I don't think that list necessarily needs to be in the spec).

I think it most cases, it will be obvious where xml:base doesn't apply 
because most elements don't have URIs anywhere in them.  We only need 
clarification are places like:

* XHTML inside <content>
* HTML inside <content>
* if we use URIs to extend attributes like link/@rel, then there



From owner-atom-syntax@mail.imc.org  Fri Jul  2 17:22: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 RAA07585
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 17:22: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 i62L9bqV091872;
	Fri, 2 Jul 2004 14: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 i62L9bSZ091871;
	Fri, 2 Jul 2004 14:09: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 i62L9akF091856
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 14:09:36 -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 i62L9Z53030061
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 16:09:35 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i62L9ZxQ030057;
	Fri, 2 Jul 2004 16:09:35 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: AtomSyntax <atom-syntax@imc.org>
Subject: Re: Q: modfied vs issued vs created
References: <40E5C9C2.4060507@jonasgalvez.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 02 Jul 2004 16:09:35 -0500
In-Reply-To: <40E5C9C2.4060507@jonasgalvez.com>
Message-ID: <m34qoqt8ts.fsf@bitsko.slc.ut.us>
Lines: 31
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


Jonas Galvez <jg@jonasgalvez.com> writes:

>      0.3 Draft, Section 4.13.8
> 
>      "If atom:created is not present, its content MUST considered to be
>      the same as that of atom:modified."
> 
> I quite don't understand the difference between "issued" and
> "created".  I thought that "created" was the same as "issued", but
> apparently, it is the same as "modified"? Sorry if I'm distracting
> other more important threads, but I just think this point in the
> spec might be confusing for non native english speakers like
> me. Perhaps a special note detailing the actual meaning of these
> elements would clear it.

<issued> is nominally a user-provided value whereas <created> and
<modified> are publishing system provided values.

<issued> can be in the future, for example, to indicate, to a
publishing systems that supports it, that the entry should be
published at a future time.  <created> would still reflect the time
the entry was created.

<created> is logically the first value ever of <modified>, but if it's
missing you can use any current value of <modified>

This topic comes up often enough that it should be clarified in the
spec, particularly as clarifies interoperable behavior for clients and
servers.

  -- Ken



From owner-atom-syntax@mail.imc.org  Fri Jul  2 17:22: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 RAA07647
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 17:22: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 i62L8XYo091807;
	Fri, 2 Jul 2004 14:08: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 i62L8XXq091806;
	Fri, 2 Jul 2004 14:08: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 i62L8XWi091789
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 14:08: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 <20040702210830015007djese>; Fri, 2 Jul 2004 21:08:30 +0000
Date: Fri, 2 Jul 2004 15:08:29 -0600
Subject: Re: Q: modfied vs issued vs created
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: <40E5C9C2.4060507@jonasgalvez.com>
Message-Id: <F76BFBEC-CC6B-11D8-B0A4-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 Friday, July 2, 2004, at 02:46  PM, Jonas Galvez wrote:
>     0.3 Draft, Section 4.13.8
>
>     "If atom:created is not present, its content MUST considered to be
>     the same as that of atom:modified."
>
> I quite don't understand the difference between "issued" and "created".
> I thought that "created" was the same as "issued", but apparently, it
> is the same as "modified"?

Correct me if I'm wrong, but I think created is when the entry was 
first created, even if it wasn't published in the feed at that time.  
Issued is when the entry was first published in the feed.  Modified is 
when the last (non-trivial) change was made to the entry.  (This isn't 
entirely clear even to native English speakers).

While I'm writing, a few more questions for those who've been around 
longer than me.

* Why are the time zone requirements different for issued (time zone 
may be omitted--why allow that?) than created and modified?

* Why SHOULD the time zone be UTC?  If the author's time zone is used, 
that would imply where the author is located.  That could be considered 
overloading the meaning of the element, and it wouldn't be entirely 
reliable (is it the server's time zone or the author's?), but I don't 
see why it would hurt.

* Why are both issued and modified required? How common is it for an 
entry to be modified after it is first issued? I'm sure it's far from 
unheard of, but requiring both in all cases, whether they're the same 
or not, doesn't make sense to me.



From owner-atom-syntax@mail.imc.org  Fri Jul  2 17:44:39 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06232
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 16:57: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 i62KckF4088121;
	Fri, 2 Jul 2004 13:38:46 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i62Kckko088120;
	Fri, 2 Jul 2004 13:38:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from garland.duramedia.net (garland.duramdedia.net [209.51.131.138] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i62KckQa088112
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 13:38:46 -0700 (PDT)
	(envelope-from jg@jonasgalvez.com)
Received: from 200-206-135-201.dsl.telesp.net.br ([200.206.135.201])
	by garland.duramedia.net with esmtp (Exim 4.34)
	id 1BgUo6-00024R-SH
	for atom-syntax@imc.org; Fri, 02 Jul 2004 16:38:51 -0400
Message-ID: <40E5C9C2.4060507@jonasgalvez.com>
Date: Fri, 02 Jul 2004 17:46:58 -0300
From: Jonas Galvez <jg@jonasgalvez.com>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: AtomSyntax <atom-syntax@imc.org>
Subject: Q: modfied vs issued vs created
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 - garland.duramedia.net
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - jonasgalvez.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


     0.3 Draft, Section 4.13.8

     "If atom:created is not present, its content MUST considered to be
     the same as that of atom:modified."

I quite don't understand the difference between "issued" and "created".
I thought that "created" was the same as "issued", but apparently, it
is the same as "modified"? Sorry if I'm distracting other more important
threads, but I just think this point in the spec might be confusing for
non native english speakers like me. Perhaps a special note detailing
the actual meaning of these elements would clear it.



\\ jonas galvez
// jonasgalvez.com



From owner-atom-syntax@mail.imc.org  Fri Jul  2 17:58: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 RAA09012
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 17:58: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 i62Lgg73095894;
	Fri, 2 Jul 2004 14:42: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 i62Lgg4g095893;
	Fri, 2 Jul 2004 14:42: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 (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i62Lgg66095884
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 14:42: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 E12487C117; Sat,  3 Jul 2004 00:38:58 +0200 (CEST)
Date: Fri, 02 Jul 2004 23:45:30 +0200
To: "John Panzer" <jpanzer@aol.net>
Subject: Re: PaceSimpleResourcePosting and PUT
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <opsairy6o1uvpchu@quark> <40E597FF.8020808@aol.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: <opsai5d4uouvpchu@quark>
In-Reply-To: <40E597FF.8020808@aol.net>
User-Agent: Opera M2/7.51 (Win32, build 3798)
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, 02 Jul 2004 10:14:39 -0700, John Panzer <jpanzer@aol.net> wrote:

> I like PUT and DELETE too.

Cool. :-)

> I didn't put them into PaceSimpleResourcePosting because I didn't
> think they were necessary and they need some more work to be properly
> defined.

They are properly defined, at least in HTTP. And they're already in use in  
the Atom API[1], so I don't see a problem in using them elsewhere.

> I'm frankly really lazy and want someone else to do the work.

What work? The writeup on the Pace?

> Asbjørn, would you like to volunteer? :^)

When I know what to volunteer for; sure. :-)

> Can all Atom servers support PUT and DELETE on resources?

No. It depends on what control you have of the web server and if you can  
do CGI or similar stuff on it. If you can't, Atom API is probably not for  
you, anyway. The format should be more than enough. There is ongoing work  
to find more deployment-friendly ways to support PUT and DELETE, though,  
one of them being SOAP.

> So my first question is, is this supportable by all Atom-enabled
> servers?

I haven't read any requirements list for what it takes to be an  
Atom-enabled server, but I would say that one of the requirements SHOULD  
be to accept PUT and DELETE.

> o Not all users can PUT and DELETE all resources (consider access  
> controls, shared blogs, etc.). So you need a way to query as to whether  
> you can perform an operation.  The Allowed: and Public: response headers  
> (http://www.w3.org/Protocols/HTTP/Object_Headers.html#z6) seem like the  
> natural way to do this and I believe this is compatible with WebDAV.

The correct way should be to use OPTIONS on the resource, but as Apache  
doesn't hand OPTIONS requests to CGI's (research done by Ken MacLeod), a  
fallback solution might be to do HEAD instead, and get a 'Allowed' header  
with the available methods in return.

> For example, Allowed: GET HEAD PUT DELETE means that you, the user  
> making the HEAD request, can perform a PUT to the resource.  Is this  
> supportable by all Atom-enabled servers?

It should be, if the server claims to be Atom-enabled. We need to make a  
requirement-list, it seems. Ordinary servers don't support anything but  
GET and POST out of the box, though. They need tweaking and customization  
to actually do something with other verbs, but it's far from impossible.

> o Do we want to ensure that whatever Atom does in this area is "upward  
> compatible" with WebDAV?  (I think this is the consensus, but I don't  
> know if anyone has looked at the details for things like PUT and DELETE.)

I think we should, but as I haven't even read the whole WebDAV  
specification, I'm not the right monkey to enforce that. I hope someone  
else will take that responsibility, because it would be rather neat if  
Atom could work flawlessly over WebDAV, whenever that's enabled on the web  
server.

> o Is PUT transactional?

No. All HTTP methods act REST-ish, that is, each request is atomic and  
independant of previous or future requests.

____
[1] <url:  
http://bitworking.org/projects/atom/draft-gregorio-09.html#rfc.section.4.3>

-- 
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 Jul  2 17:58: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 RAA09030
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 17:58: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 i62Ll4dh096236;
	Fri, 2 Jul 2004 14:47: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 i62Ll4gF096235;
	Fri, 2 Jul 2004 14:47: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 i62Ll34f096224
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 14:47: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 OAA17352
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 14:47:03 -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 OAA02450
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 14:47:02 -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, 02 Jul 2004 14:47:02 -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 <0I08009GGV6DU2@shazam.verity.com> for atom-syntax@imc.org; Fri,
 02 Jul 2004 14:47:02 -0700 (PDT)
Date: Fri, 02 Jul 2004 14:52:01 -0700
From: Walter Underwood <wunder@verity.com>
Subject: Re: Q: modfied vs issued vs created
In-reply-to: <F76BFBEC-CC6B-11D8-B0A4-003065EA6144@geckotribe.com>
To: atom-syntax@imc.org
Message-id: <FAE3F2EF07344BB930979071@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: <F76BFBEC-CC6B-11D8-B0A4-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 Friday, July 02, 2004 03:08:29 PM -0600 Antone Roundy 
<antone@geckotribe.com> wrote:
>
> * Why SHOULD the time zone be UTC?  If the author's time zone is used,
> that would imply where the author is located.  That could be considered
> overloading the meaning of the element, and it wouldn't be entirely
> reliable (is it the server's time zone or the author's?), but I don't see
> why it would hurt.

There might be some use for a native timezone for the blog, but
making sense of all that is a mess. Maybe I live in Atlanta, use
a blog service hosted in California, I'm in Australia on travel,
and you are reading the blog in Norway. What time is it when I post?
Is summer time in effect (N vs. S hemisphere)? Heck, what day is it?

I'd be willing to make UTC a MUST. A .NET implementation may need
to use UTC anyway, because System.DateTime doesn't have a time zone.
That is the official type for SOAP DateTime, so SOAP protocols
always need to use UTC for safe transfer of data. See:

 http://msdn.microsoft.com/library/en-us/cpref/html/frlrfSystemDateTimeClassT
opic.asp

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek



From owner-atom-syntax@mail.imc.org  Fri Jul  2 18:03: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 SAA09315
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 18:03: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 i62LjTvU096129;
	Fri, 2 Jul 2004 14:45: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 i62LjTjH096128;
	Fri, 2 Jul 2004 14:45: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-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 i62LjSUM096122
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 14:45:28 -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 i62LhY53006360
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 15:43:34 -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 <0I08005QUV3XP2@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Fri, 02 Jul 2004 15:45:33 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0800KXGV3W3Q@mail.sun.net> for atom-syntax@imc.org; Fri,
 02 Jul 2004 15:45:33 -0600 (MDT)
Date: Fri, 02 Jul 2004 14:45:55 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceXmlBaseEverywhere
In-reply-to: <BA72FC2A-CC47-11D8-B7F4-000A95BD86C0@bea.com>
To: Mark Nottingham <mark.nottingham@bea.com>
Cc: Atom Syntax <atom-syntax@imc.org>
Message-id: <327469D8-CC71-11D8-BA50-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: <BA72FC2A-CC47-11D8-B7F4-000A95BD86C0@bea.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 Jul 2, 2004, at 9:49 AM, Mark Nottingham wrote:

>
> Doesn't this proposal effectively require xml:base to be considered in 
> the processing of ALL atom elements, attributes and extensions? 
> Whether or not the extension author wants it to be? Whether or not the 
> processor is aware of the semantics of the extension?uh

Yes, and I think that's the intent.  You set xml:base saying "this is 
the base URI of the feed" (or of the entry or whatever, depending) and 
that means people who put relative URIs into Atom feeds, unless they 
provide their own value for xml:base, are counting on whatever the 
relative URI happens to be.  And people who write and use extensions 
should be aware of this.

> Does is require schema information for both Atom as well as extensions?

Huh?  Don't understand.

> Shouldn't module authors crisply specify when xml:base is and is not 
> used, so that it's crystal-clear when it's to be used?

Any time you embed a relative URI in a resource representation, you 
either make it absolute or you rely on how that resource representation 
goes about making a base URI.  That's why the Pace is worded in terms 
relative to the RFCs that govern those issues.

Summary: I think the Pace is pretty OK as it stands. -Tim



From owner-atom-syntax@mail.imc.org  Fri Jul  2 18:06: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 SAA09600
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 18:06: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 i62LqAHC096530;
	Fri, 2 Jul 2004 14: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 i62LqAW8096529;
	Fri, 2 Jul 2004 14:52: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 (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i62Lq9WY096521
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 14:52: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 609237C117; Sat,  3 Jul 2004 00:48:25 +0200 (CEST)
Date: Fri, 02 Jul 2004 23:54:57 +0200
To: "Antone Roundy" <antone@geckotribe.com>
Subject: Re: Q: modfied vs issued vs created
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <F76BFBEC-CC6B-11D8-B0A4-003065EA6144@geckotribe.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: <opsai5tvmvuvpchu@quark>
In-Reply-To: <F76BFBEC-CC6B-11D8-B0A4-003065EA6144@geckotribe.com>
User-Agent: Opera M2/7.51 (Win32, build 3798)
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, 2 Jul 2004 15:08:29 -0600, Antone Roundy <antone@geckotribe.com>  
wrote:

> Correct me if I'm wrong, but I think created is when the entry was first  
> created, even if it wasn't published in the feed at that time.  Issued  
> is when the entry was first published in the feed.

Not necessarily «in the feed», imho. <issued> indicates when the resource  
was first publicly available, either the first-class representation of it  
is an HTML document, PDF file, or an Atom entry. In large parts, I think  
one can assume that the Atom entry is considered a second-class  
representation of a resource, rather than the resource itself.  
Nonetheless, <issued> indicates when this resource (no matter what or  
where that resource is) was first made publicly available.

> Modified is when the last (non-trivial) change was made to the entry.

Correct. This is how I've explained the difference in numerous e-mails  
earlier:

The difference beetween 'issued' and 'created' is that an article can be  
created, edited for six years, and then published to a public web site.  
'created' is then the initial creation date, and 'issued' is the date of  
when the article was publicly available (created + six years in this case).

If you've ever used Movable Type, it has this feature. You create an entry  
(the 'created' date gets set), edit it for a couple of days, and then save  
it with the status «publish» (the 'issued' date gets set).

> * Why are the time zone requirements different for issued (time zone may  
> be omitted--why allow that?) than created and modified?

Dunno.

> * Why SHOULD the time zone be UTC?

Because UTC dates is a lot simpler to work with. Working forth and back  
with different time zones is a real mess if you don't keep your tounge  
straight. Storing the date as UTC and then rather just convert it to a  
local date on display, is much cleaner.

> If the author's time zone is used, that would imply where the author
> is located.

I don't find that very useful. GeoURL[1] or Bizg[2] are better solutions  
for locating feeds (or authors), imho.

> * Why are both issued and modified required?

Because they are interesting pieces of information. If you never modify  
the entry, it's no fuzz, is it? Just keep the <modified> element  
unchanged. If you never keep a local copy for updates before you make it  
publicly available, then <created> and <issued> will most likely always be  
the same. If you never modify the entry either, all three dates will stay  
the same. Does that hurt?

> How common is it for an entry to be modified after it is first issued?

Seeing how often I get rather old entries at the top of my subscription  
lists in my aggregator, I'd say rather often.

____
[1] <url: http://geourl.org/>
[2] <url: http://www.blizg.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  Fri Jul  2 18:13: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 SAA10685
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 18:13: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 i62Ls4jn096598;
	Fri, 2 Jul 2004 14: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 i62Ls4KK096597;
	Fri, 2 Jul 2004 14:54:04 -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 i62Ls3AD096590
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 14:54:03 -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 795D77C117; Sat,  3 Jul 2004 00:50:19 +0200 (CEST)
To: "Ken MacLeod" <ken@bitsko.slc.ut.us>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceIntrospection: @title vs. <title>
References: <m38ye2ta3w.fsf@bitsko.slc.ut.us>
Message-ID: <opsai5w2weuvpchu@quark>
Date: Fri, 02 Jul 2004 23:56:52 +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: <m38ye2ta3w.fsf@bitsko.slc.ut.us>
User-Agent: Opera M2/7.51 (Win32, build 3798)
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 02 Jul 2004 15:41:55 -0500, Ken MacLeod <ken@bitsko.slc.ut.us> wrote:

> Since <site> seems more like a metadata container similar to <feed>
> and <entry> (as discussed more strongly in the "new file format"
> thread), I propose changing @title to <title>.

+1. <title> instead of @title -- although it's probably not intended --  
actually adheres better to the SyntaxGuidelines 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  Fri Jul  2 18:19: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 SAA11537
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 18:19: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 i62M5Ol4097336;
	Fri, 2 Jul 2004 15: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 i62M5Onc097335;
	Fri, 2 Jul 2004 15:05:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i62M5NDJ097326
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 15:05:23 -0700 (PDT)
	(envelope-from stevej@google.com)
Received: from [172.24.72.132] (gpsi1.corp.google.com [10.3.0.251])
	(authenticated bits=0)
	by 216-239-45-4.google.com (8.12.11/8.12.9) with ESMTP id i62M5H4U027067
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO)
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 15:05:18 -0700
Mime-Version: 1.0 (Apple Message framework v613)
Content-Transfer-Encoding: 7bit
Message-Id: <E6AA8A31-CC73-11D8-BC04-000A95B09B46@google.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: atom syntax list <atom-syntax@imc.org>
From: steve jenson <stevej@google.com>
Subject: PaceIntrospection: add <id> to <site>
Date: Fri, 2 Jul 2004 15:05:17 -0700
X-Mailer: Apple Mail (2.613)
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


Gang,

For the proposed update to Introspection, I suggest adding <id> to 
<site>. id provides a unique key for the client to keep track of even 
if the blog's URI or title changes.

Thanks,
Steve



From owner-atom-syntax@mail.imc.org  Fri Jul  2 18:25: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 SAA11756
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 18:25: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 i62M6ivl097516;
	Fri, 2 Jul 2004 15: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 i62M6itW097515;
	Fri, 2 Jul 2004 15:06: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 i62M6hGv097508
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 15:06: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 6149B7C117; Sat,  3 Jul 2004 01:03:00 +0200 (CEST)
Date: Sat, 03 Jul 2004 00:09:35 +0200
To: "Antone Roundy" <antone@geckotribe.com>
Subject: Re: PaceXmlBaseEverywhere
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <F166A3FB-CC68-11D8-B0A4-003065EA6144@geckotribe.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: <opsai6h9vjuvpchu@quark>
In-Reply-To: <F166A3FB-CC68-11D8-B0A4-003065EA6144@geckotribe.com>
User-Agent: Opera M2/7.51 (Win32, build 3798)
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, 2 Jul 2004 14:46:50 -0600, Antone Roundy <antone@geckotribe.com>  
wrote:

>> Just as with 'xml:lang'[1], I think it's obvious that 'xml:base' should  
>> be defined as a part of the Content Construct.
>>
> ...and link.  And service (if PaceServiceElement is adopted).

Yes, true.

> I think we need to consider each element to be sure we don't accidentally
> forget   any, and then list specifically which elements it applies to.

Correct. I think we agree that it shouldn't be defined as «everywhere», at  
least. Stick it into the correct constructs, and springle it around the  
other elements that needs it. Be explicit. Do we need a pace for each and  
every one of them, you think, or should we create PaceCommonAttributes or  
something?

> If someone wants to make a wiki page to keep track of elements where  
> we've decided that xml:base processing DOESN'T apply, that would save us  
> periodically running through the whole list after new elements are added  
> (but I don't think that list necessarily needs to be in the spec).

It's just to remember that when you add an element, you loop through the  
list of common attributes and see if they fit on the element. If they do,  
specify it. This could be added as a reminder to section 7 in the format  
specification.

If we either go with a «don't use here» or «use here» list, it will need  
to be updated, and I think it's more intuitive to tell someone that they  
can use an attribute than that they can't. Not mentioning something should  
at least imply that it isn't available.

-- 
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 Jul  2 18:41: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 SAA12468
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 18:41: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 i62MSgdx099257;
	Fri, 2 Jul 2004 15: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 i62MSgLI099256;
	Fri, 2 Jul 2004 15:28:42 -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 i62MSZEY099250;
	Fri, 2 Jul 2004 15:28:38 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p0611041fbd0b91db0f7a@[10.20.30.249]>
In-Reply-To: <40E5C9C2.4060507@jonasgalvez.com>
References: <40E5C9C2.4060507@jonasgalvez.com>
Date: Fri, 2 Jul 2004 15:28:41 -0700
To: Jonas Galvez <jg@jonasgalvez.com>, AtomSyntax <atom-syntax@imc.org>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: Q: modfied vs issued vs created
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 5:46 PM -0300 7/2/04, Jonas Galvez wrote:
>Sorry if I'm distracting other more important
>threads, but I just think this point in the spec might be confusing for
>non native english speakers like me.

Please don't apologize. If the spec is unclear on this (and as a 
native speaker of English, even I have a hard time keeping the three 
straight), it's perfectly reasonable to ask for clarification.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Fri Jul  2 18:42: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 SAA12511
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 18:42: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 i62MTSdR099305;
	Fri, 2 Jul 2004 15:29: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 i62MTSfd099304;
	Fri, 2 Jul 2004 15:29:28 -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 i62MTSuA099298
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 15:29:28 -0700 (PDT)
	(envelope-from danbri@w3.org)
Received: by homer.w3.org (Postfix, from userid 13522)
	id 8369C4F12B; Fri,  2 Jul 2004 18:29:33 -0400 (EDT)
Date: Fri, 2 Jul 2004 18:29:33 -0400
From: Dan Brickley <danbri@w3.org>
To: =?iso-8859-15?Q?Asbj=F8rn?= Ulsberg <asbjorn@tigerstaden.no>
Cc: Ken MacLeod <ken@bitsko.slc.ut.us>, Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceIntrospection: @title vs. <title>
Message-ID: <20040702222933.GB16686@homer.w3.org>
References: <m38ye2ta3w.fsf@bitsko.slc.ut.us> <opsai5w2weuvpchu@quark>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <opsai5w2weuvpchu@quark>
User-Agent: Mutt/1.5.6+20040523i
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 <asbjorn@tigerstaden.no> [2004-07-02 23:56+0200]
> 
> On 02 Jul 2004 15:41:55 -0500, Ken MacLeod <ken@bitsko.slc.ut.us> wrote:
> 
> >Since <site> seems more like a metadata container similar to <feed>
> >and <entry> (as discussed more strongly in the "new file format"
> >thread), I propose changing @title to <title>.
> 
> +1. <title> instead of @title -- although it's probably not intended --  
> actually adheres better to the SyntaxGuidelines as well. ;)

+1 

(has markup in titles been discussed to death already? am thinking of 
http://www.w3.org/TR/2001/REC-ruby-20010531/ for example).

Dan



From owner-atom-syntax@mail.imc.org  Fri Jul  2 18:53: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 SAA12910
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 18:53: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 i62MOhCp098844;
	Fri, 2 Jul 2004 15:24: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 i62MOhJq098843;
	Fri, 2 Jul 2004 15:24:43 -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 i62MOgna098835
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 15:24:42 -0700 (PDT)
	(envelope-from danbri@w3.org)
Received: by homer.w3.org (Postfix, from userid 13522)
	id 9E8724F18F; Fri,  2 Jul 2004 18:24:46 -0400 (EDT)
Date: Fri, 2 Jul 2004 18:24:46 -0400
From: Dan Brickley <danbri@w3.org>
To: Tim Bray <Tim.Bray@Sun.COM>
Cc: Mark Nottingham <mark.nottingham@bea.com>,
        Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceXmlBaseEverywhere
Message-ID: <20040702222446.GA16686@homer.w3.org>
References: <BA72FC2A-CC47-11D8-B7F4-000A95BD86C0@bea.com> <327469D8-CC71-11D8-BA50-000A95A51C9E@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <327469D8-CC71-11D8-BA50-000A95A51C9E@sun.com>
User-Agent: Mutt/1.5.6+20040523i
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> [2004-07-02 14:45-0700]
> 
> 
> On Jul 2, 2004, at 9:49 AM, Mark Nottingham wrote:
> 
> >
> >Doesn't this proposal effectively require xml:base to be considered in 
> >the processing of ALL atom elements, attributes and extensions? 
> >Whether or not the extension author wants it to be? Whether or not the 
> >processor is aware of the semantics of the extension?uh
> 
> Yes, and I think that's the intent.  You set xml:base saying "this is 
> the base URI of the feed" (or of the entry or whatever, depending) and 
> that means people who put relative URIs into Atom feeds, unless they 
> provide their own value for xml:base, are counting on whatever the 
> relative URI happens to be.  And people who write and use extensions 
> should be aware of this.
> 
> >Does is require schema information for both Atom as well as extensions?
> 
> Huh?  Don't understand.

Is the idea that extension elements/attributes from other namespaces
might get deployed inside Atom, and that (without some presumably schema-carried
info) we won't know which element/attribute content carries (possibly
local) URI references? Nor which of those are to be interpreted in the
light of the current xml:base. 

Dan



From owner-atom-syntax@mail.imc.org  Fri Jul  2 19: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 TAA13716
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 19: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 i62MqcKa000964;
	Fri, 2 Jul 2004 15:52: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 i62MqcGL000963;
	Fri, 2 Jul 2004 15:52:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from garland.duramedia.net (garland.duramdedia.net [209.51.131.138] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i62MqXAo000937
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 15:52:37 -0700 (PDT)
	(envelope-from jg@jonasgalvez.com)
Received: from 200-206-135-201.dsl.telesp.net.br ([200.206.135.201])
	by garland.duramedia.net with esmtp (Exim 4.34)
	id 1BgWtb-0005Qb-Cx
	for atom-syntax@imc.org; Fri, 02 Jul 2004 18:52:39 -0400
Message-ID: <40E5E922.1070909@jonasgalvez.com>
Date: Fri, 02 Jul 2004 20:00:50 -0300
From: Jonas Galvez <jg@jonasgalvez.com>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: AtomSyntax <atom-syntax@imc.org>
Subject: Re: Q: modfied vs issued vs created
References: <40E5C9C2.4060507@jonasgalvez.com> <m34qoqt8ts.fsf@bitsko.slc.ut.us>
In-Reply-To: <m34qoqt8ts.fsf@bitsko.slc.ut.us>
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 - garland.duramedia.net
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - jonasgalvez.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


Ken MacLeod wrote:
 > <issued> is nominally a user-provided value whereas <created> and
 > <modified> are publishing system provided values.
 >
 > <issued> can be in the future, for example, to indicate, to a
 > publishing systems that supports it, that the entry should be
 > published at a future time.  <created> would still reflect the time
 > the entry was created.
 >
 > <created> is logically the first value ever of <modified>, but if
 > it's missing you can use any current value of <modified>
 >
 > This topic comes up often enough that it should be clarified in the
 > spec, particularly as clarifies interoperable behavior for clients
 > and servers.

Asbjørn Ulsberg wrote:
 > This has been explained on numerous occasions, but I'll do it again:
 > The difference between 'issued' and 'created' is that an article can
 > be created, edited for six years, and then published to a public web
 > site. 'created' is then the initial creation date, and 'issued' is
 > the date of when the article was publicly available (created + six
 > years in this case).

Paul Hoffman / IMC wrote:
 > Please don't apologize. If the spec is unclear on this (and as a
 > native speaker of English, even I have a hard time keeping the three
 > straight), it's perfectly reasonable to ask for clarification.


Thanks all, it makes sense to me now.

I think this explanation should definitely go into the spec.



\\ jonas galvez
// jonasgalvez.com



From owner-atom-syntax@mail.imc.org  Fri Jul  2 20:08:04 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15749
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 20:08: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 i62NmevL005148;
	Fri, 2 Jul 2004 16:48: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 i62Nme9P005147;
	Fri, 2 Jul 2004 16:48:40 -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 i62Nmd2T005120
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 16:48:40 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 3 Jul 2004 09:52:53 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sat, 03 Jul 2004 09:48:05 +1000
Subject: Re: PaceXmlBaseEverywhere
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD0C3155.1CEC2%eric.scheid@ironclad.net.au>
In-Reply-To: <opsai1tmg8uvpchu@quark>
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 i62Nme2T005142
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 3/7/04 6:28 AM, "Asbjørn Ulsberg" <asbjorn@tigerstaden.no> wrote:

> I totally agree. I can't see why one would ever want 'xml:base' on
> atom:issued either.

<issued somens:href="foo.dat">datestring</issued>

??




From owner-atom-syntax@mail.imc.org  Fri Jul  2 20:31: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 UAA16624
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 20:31: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 i6306G4d006014;
	Fri, 2 Jul 2004 17:06:16 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6306GLt006013;
	Fri, 2 Jul 2004 17:06:16 -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 i6306F3d006007
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 17:06:15 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [172.17.31.214] (sj-ez-63-96-162-1.bea.com [63.96.162.1])
	by mail.mnot.net (Postfix) with ESMTP
	id 5383E727D; Fri,  2 Jul 2004 17:06:21 -0700 (PDT)
In-Reply-To: <20040702222446.GA16686@homer.w3.org>
References: <BA72FC2A-CC47-11D8-B7F4-000A95BD86C0@bea.com> <327469D8-CC71-11D8-BA50-000A95A51C9E@sun.com> <20040702222446.GA16686@homer.w3.org>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <CF9D211D-CC84-11D8-B7F4-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: Atom Syntax <atom-syntax@imc.org>, Tim Bray <Tim.Bray@Sun.COM>
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: PaceXmlBaseEverywhere
Date: Fri, 2 Jul 2004 17:06:19 -0700
To: Dan Brickley <danbri@w3.org>
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>
Content-Transfer-Encoding: 7bit



On Jul 2, 2004, at 3:24 PM, Dan Brickley wrote:

> Is the idea that extension elements/attributes from other namespaces
> might get deployed inside Atom, and that (without some presumably 
> schema-carried
> info) we won't know which element/attribute content carries (possibly
> local) URI references? Nor which of those are to be interpreted in the
> light of the current xml:base.

Exactly.

If you want your infrastructure to apply XML Base for you, it has to 
know where to apply it. In a container format like Atom, that doesn't 
work very well, unless you have good Schema information.

So, you end up needing to apply XML Base on a case-by-case basis. Since 
you're already applying it at the level of the module, rather than in 
the XML infrastructure, it seems odd to require all Atom modules for 
all time to use XML Base (which is effectively what this does).

I'm not strongly against it, just seems like an unnecessary constraint 
upon modules, especially since they're going to need to remind 
developers of the need to consider XML Base (when they use it) anyway.

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Fri Jul  2 20:35: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 UAA16831
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 20:35: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 i630IMxO006381;
	Fri, 2 Jul 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 i630IM0F006380;
	Fri, 2 Jul 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 smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i630IKQO006373
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 17:18: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 9E9797C117; Sat,  3 Jul 2004 03:14:32 +0200 (CEST)
To: "Dan Brickley" <danbri@w3.org>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceIntrospection: @title vs. <title>
References: <m38ye2ta3w.fsf@bitsko.slc.ut.us> <opsai5w2weuvpchu@quark> <20040702222933.GB16686@homer.w3.org>
Message-ID: <opsajcmedruvpchu@quark>
Date: Sat, 03 Jul 2004 02:21:40 +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: <20040702222933.GB16686@homer.w3.org>
User-Agent: Opera M2/7.51 (Win32, build 3798)
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, 2 Jul 2004 18:29:33 -0400, Dan Brickley <danbri@w3.org> wrote:

> (has markup in titles been discussed to death already? am thinking of
> http://www.w3.org/TR/2001/REC-ruby-20010531/ for example).

Currently, <title>[1] is defined as a Content Construct[2], which can  
contain markup when the correct @mode and @type is provided. This is very  
likely to change in the near future, though, due to the wide consensus on  
simplifying the <content> model. This simplification will have  
consequences for all Content Constructs, I'd presume.

____
[1] <url:  
http://www.mnot.net/drafts/draft-nottingham-atom-format-02.html#rfc.section.4.13.1>
[2] <url:  
http://www.mnot.net/drafts/draft-nottingham-atom-format-02.html#rfc.section.3.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  Fri Jul  2 21: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 VAA18189
	for <atompub-archive@lists.ietf.org>; Fri, 2 Jul 2004 21: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 i630lM6n010504;
	Fri, 2 Jul 2004 17: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 i630lMJQ010503;
	Fri, 2 Jul 2004 17:47: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.45])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i630lMns010497
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 17:47:22 -0700 (PDT)
	(envelope-from dtcd@mac.com)
Received: from webmail01.mac.com (webmail01-en1 [10.13.11.143])
	by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i630lSAv005721
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 17:47:28 -0700 (PDT)
Received: from webmail01 (localhost [127.0.0.1])
	by webmail01.mac.com (8.12.6/8.12.2) with ESMTP id i630lSf4009897
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 17:47:28 -0700 (PDT)
Message-ID: <13704684.1088815647983.JavaMail.dtcd@mac.com>
Date: Sat, 03 Jul 2004 01:47:27 +0100
From: Graham Parks <dtcd@mac.com>
To: atom-syntax@imc.org
Subject: Re: Q: modfied vs issued vs created
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: <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


http://www.intertwingly.net/wiki/pie/PaceEntryDates solves all of these problems (though the text about when atom:issued may be updated needs work).

Graham Parks



From owner-atom-syntax@mail.imc.org  Sat Jul  3 01:22: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 BAA28969
	for <atompub-archive@lists.ietf.org>; Sat, 3 Jul 2004 01:22: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 i6359KMu065810;
	Fri, 2 Jul 2004 22:09: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 i6359K2H065808;
	Fri, 2 Jul 2004 22:09:20 -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 i6359KY5065793
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 22:09:20 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.6] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id 7E7B4727D; Fri,  2 Jul 2004 22:09:27 -0700 (PDT)
In-Reply-To: <40E59276.9030609@dehora.net>
References: <F925141D-CC46-11D8-B7F4-000A95BD86C0@mnot.net> <40E59276.9030609@dehora.net>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <27C3E61C-CCAF-11D8-B7F4-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: Atom Syntax <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: Re: PaceNoInfoSet
Date: Fri, 2 Jul 2004 22:09:26 -0700
To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.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>
Content-Transfer-Encoding: 7bit


How about:

"Atom's data model is described in terms of the XML Information Set 
[ref] and serialised as XML 1.0 [ref]."


--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Sat Jul  3 02:07: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 CAA08639
	for <atompub-archive@lists.ietf.org>; Sat, 3 Jul 2004 02:07: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 i635t0Sa093230;
	Fri, 2 Jul 2004 22:55:00 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i635t0UX093229;
	Fri, 2 Jul 2004 22:55:00 -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 i635t0wS093097
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 22:55:00 -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 i635swt12821
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 22:54:58 -0700 (PDT)
Received: from aol.net ([10.169.192.27]) by judge.mcom.com
          (Netscape Messaging Server 4.15) with ESMTP id I09HRM00.519;
          Fri, 2 Jul 2004 22:54:58 -0700 
Message-ID: <40E64A34.5060406@aol.net>
Date: Fri, 02 Jul 2004 22:55:00 -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: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceSimpleResourcePosting and PUT
References: <opsairy6o1uvpchu@quark> <40E597FF.8020808@aol.net> <opsai5d4uouvpchu@quark>
In-Reply-To: <opsai5d4uouvpchu@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 Fri, 02 Jul 2004 10:14:39 -0700, John Panzer <jpanzer@aol.net> wrote:
> ...
>
>> Can all Atom servers support PUT and DELETE on resources?
>
>
> No. It depends on what control you have of the web server and if you 
> can  do CGI or similar stuff on it. If you can't, Atom API is probably 
> not for  you, anyway. The format should be more than enough. There is 
> ongoing work  to find more deployment-friendly ways to support PUT and 
> DELETE, though,  one of them being SOAP.
>
I don't think anyone assumes that you can implement Atom without at 
least the equivalent of CGI scripts. :)

Beyond that, I'm a bit confused.  When I say "on resources", I mean to 
ask the following:  I have a URI like this:  
http://example.org/resources/mycat.jpg.  When I do a GET on this URI, I 
retrieve the image/jpeg data.  When I do a PUT to this URI, I replace 
the image/jpeg data.  When I DELETE the URI, I delete the image/jpeg data.

Can all Atom servers, even ones implemented with CGI scripts, handle this? 

I _think_ so.  Some Atom implementations may need to use URIs like 
http://example.org/cgi-bin/resources?name=mycat.jpg, so that their CGI 
scripts can get control on HEAD, GET, PUT, and DELETE.

This is actually important to the context of both 
PaceSimpleResourcePosting and PaceNonEntryResources, because both assume 
that you can take a single URI and use it for both simple GETs (e.g., 
when using an XHTML img[@src]) and for any subsequent PUTs or DELETEs.  
If that assumption works for even CGI-limited servers, I think 
everything would be fine.  If not, then the two Paces above might have 
some issues.

> ...
>
>> o Not all users can PUT and DELETE all resources (consider access  
>> controls, shared blogs, etc.). So you need a way to query as to 
>> whether  you can perform an operation.  The Allowed: and Public: 
>> response headers  
>> (http://www.w3.org/Protocols/HTTP/Object_Headers.html#z6) seem like 
>> the  natural way to do this and I believe this is compatible with 
>> WebDAV.
>
>
> The correct way should be to use OPTIONS on the resource, but as 
> Apache  doesn't hand OPTIONS requests to CGI's (research done by Ken 
> MacLeod), a  fallback solution might be to do HEAD instead, and get a 
> 'Allowed' header  with the available methods in return.

Dumb question:  I assume Apache does hand HEAD requests to CGIs?  :^)

>
>> For example, Allowed: GET HEAD PUT DELETE means that you, the user  
>> making the HEAD request, can perform a PUT to the resource.  Is this  
>> supportable by all Atom-enabled servers?
>
>
> It should be, if the server claims to be Atom-enabled. We need to make 
> a  requirement-list, it seems. Ordinary servers don't support anything 
> but  GET and POST out of the box, though. They need tweaking and 
> customization  to actually do something with other verbs, but it's far 
> from impossible.
>
It's pretty easy if you have control over the server itself (by which I 
mean the ability to remap URLs to your own code).  It sounds like this 
is supportable even for CGI based services too, assuming that web 
servers will just hand the darn verbs to the scripts.

>> o Do we want to ensure that whatever Atom does in this area is 
>> "upward  compatible" with WebDAV?  (I think this is the consensus, 
>> but I don't  know if anyone has looked at the details for things like 
>> PUT and DELETE.)
>
>
> I think we should, but as I haven't even read the whole WebDAV  
> specification, I'm not the right monkey to enforce that. I hope 
> someone  else will take that responsibility, because it would be 
> rather neat if  Atom could work flawlessly over WebDAV, whenever 
> that's enabled on the web  server.
>
>> o Is PUT transactional?
>
>
> No. All HTTP methods act REST-ish, that is, each request is atomic 
> and  independant of previous or future requests.
>
Sorry, what I meant to ask was whether PUT should be required to be 
atomic: When your PUT fails midway through the 1MB cat video upload, is 
the prior content untouched? 

-John Panzer



From owner-atom-syntax@mail.imc.org  Sat Jul  3 02: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 CAA16036
	for <atompub-archive@lists.ietf.org>; Sat, 3 Jul 2004 02: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 i63615Fb097633;
	Fri, 2 Jul 2004 23:01: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 i63615aR097632;
	Fri, 2 Jul 2004 23:01:05 -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 i636144J097571
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 23:01:05 -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 i63617t13096
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 23:01:07 -0700 (PDT)
Received: from aol.net ([10.169.192.27]) by judge.mcom.com
          (Netscape Messaging Server 4.15) with ESMTP id I09I1V02.G19;
          Fri, 2 Jul 2004 23:01:07 -0700 
Message-ID: <40E64BA6.5070402@aol.net>
Date: Fri, 02 Jul 2004 23:01:10 -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: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceSimpleResourcePosting and PUT
References: <opsairy6o1uvpchu@quark>
In-Reply-To: <opsairy6o1uvpchu@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:

>
> PaceSimpleResourcePosting says:
>
>   If a client has a hard requirement to control the URIs of the
>   resources it uploads, WebDAV is probably the answer.
>
> Why can't PUT be used with Atom? I assume this will be WebDAV 
> supportive,  but yet defined in the Atom specification. I think  
> PaceSimpleResourcePosting should define a model for both POST and PUT. 
> I  at least can't see why it shouldn't.
>
I answered the general PUT/DELETE question earlier, but I missed 
something.  The question above might really be, why can't a client use 
PUT to tell a server to create a resource at an arbitrary location?

My answer is:  Because an Atom server implemented through CGI scripts 
may not be able to support client-specified arbirary URIs.  That is, CGI 
scripts may not be able to field HTTP requests unless the URIs in the 
HTTP requests include "/cgi-bin/scriptname" or similar; so, they can't 
field PUTs to arbitrary URIs.

But they _can_ support PUT and DELETE if the server gets to specify the 
URI for resources, for example 
http://example.org/cgi-bin/resources.pl?res=mycat.jpg.

-John Panzer
http://journals.aol.com/panzerjohn/abstractioneer




From owner-atom-syntax@mail.imc.org  Sat Jul  3 02:37:29 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16352
	for <atompub-archive@lists.ietf.org>; Sat, 3 Jul 2004 02:37: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 i636J0as006828;
	Fri, 2 Jul 2004 23:19: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 i636J01R006827;
	Fri, 2 Jul 2004 23:19: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.net [213.165.64.20])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i636IxsZ006770
	for <atom-syntax@imc.org>; Fri, 2 Jul 2004 23:18:59 -0700 (PDT)
	(envelope-from julian.reschke@gmx.de)
Received: (qmail 2603 invoked by uid 65534); 3 Jul 2004 06:18:53 -0000
Received: from pD9FF02EB.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.2.235)
  by mail.gmx.net (mp020) with SMTP; 03 Jul 2004 08:18:53 +0200
X-Authenticated: #1915285
Message-ID: <40E64FC9.4070800@gmx.de>
Date: Sat, 03 Jul 2004 08:18:49 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: John Panzer <jpanzer@aol.net>
CC: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>,
        Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceSimpleResourcePosting and PUT
References: <opsairy6o1uvpchu@quark> <40E597FF.8020808@aol.net> <opsai5d4uouvpchu@quark> <40E64A34.5060406@aol.net>
In-Reply-To: <40E64A34.5060406@aol.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


John Panzer wrote:

>> No. All HTTP methods act REST-ish, that is, each request is atomic 
>> and  independant of previous or future requests.
>>
> Sorry, what I meant to ask was whether PUT should be required to be 
> atomic: When your PUT fails midway through the 1MB cat video upload, is 
> the prior content untouched?
> -John Panzer

I think RFC2616 is silent about that topic, so it seems to be a 
qualify-of-implementation issue. In real life, some servers that map 
directly to filesystem I/O *will* fail to do this properly.

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From owner-atom-syntax@mail.imc.org  Sat Jul  3 03:52:51 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19570
	for <atompub-archive@lists.ietf.org>; Sat, 3 Jul 2004 03:52:51 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i637f12J045055;
	Sat, 3 Jul 2004 00:41: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 i637f1wq045054;
	Sat, 3 Jul 2004 00:41:01 -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 i637f1As045014
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 00:41:01 -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 i637emt16400
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 00:40:48 -0700 (PDT)
Received: from aol.net ([10.169.192.27]) by judge.mcom.com
          (Netscape Messaging Server 4.15) with ESMTP id I09MNZ01.L14;
          Sat, 3 Jul 2004 00:40:47 -0700 
Message-ID: <40E66302.6030701@aol.net>
Date: Sat, 03 Jul 2004 00:40:50 -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: Julian Reschke <julian.reschke@gmx.de>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceSimpleResourcePosting and PUT
References: <opsairy6o1uvpchu@quark> <40E597FF.8020808@aol.net> <40E5A53B.5000609@gmx.de>
In-Reply-To: <40E5A53B.5000609@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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:

>
> John Panzer wrote:
>
>> ...
>> o Not all users can PUT and DELETE all resources (consider access 
>> controls, shared blogs, etc.).  So you need a way to query as to 
>> whether you can perform an operation.  The Allowed: and Public: 
>> response headers 
>> (http://www.w3.org/Protocols/HTTP/Object_Headers.html#z6) seem like 
>> the natural way to do this and I believe this is compatible with 
>> WebDAV.  For example, Allowed: GET HEAD PUT DELETE means that you, 
>> the user making the HEAD request, can perform a PUT to the resource.  
>> Is this supportable by all Atom-enabled servers?
>
>
> That's not the way WebDAV sees it. In general, the OPTIONS method 
> isn't supposed to take access privileges into account. The Allow: 
> header lists the methods for which you're guaranteed to get a 405 (Not 
> Allowed) response. However, when you're not privileged to execute a 
> specific method, you would usually get a 403 (Forbidden).
>
> WebDAV defines a much more complex Access Control Protocol (RFC3744); 
> however I think it would be overkill to requires this for Atom.

Totally agreed.  And thanks, I think I was reading the wrong thing about 
Allow:.  (I assume you mean "guaranteed NOT to get a 405" :^) ).

-John



From owner-atom-syntax@mail.imc.org  Sat Jul  3 04:22: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 EAA20571
	for <atompub-archive@lists.ietf.org>; Sat, 3 Jul 2004 04: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 i637reIj050352;
	Sat, 3 Jul 2004 00:53:40 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i637reet050351;
	Sat, 3 Jul 2004 00:53:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.246])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i637rd3m050341
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 00:53:39 -0700 (PDT)
	(envelope-from rtomayko@gmail.com)
Received: by mproxy.gmail.com with SMTP id w29so163431cwb
        for <atom-syntax@imc.org>; Sat, 03 Jul 2004 00:53:39 -0700 (PDT)
Received: by 10.11.116.22 with SMTP id o22mr185994cwc;
        Sat, 03 Jul 2004 00:53:39 -0700 (PDT)
Message-ID: <f732822d0407030053186491b6@mail.gmail.com>
Date: Sat, 3 Jul 2004 03:53:39 -0400
From: Ryan Tomayko <rtomayko@gmail.com>
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceSimpleResourcePosting and PUT
Cc: "Asbjørn Ulsberg" <asbjorn@tigerstaden.no>, John Panzer <jpanzer@aol.net>
In-Reply-To: <40E64BA6.5070402@aol.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <opsairy6o1uvpchu@quark> <40E64BA6.5070402@aol.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 Fri, 02 Jul 2004 23:01:10 -0700, John Panzer <jpanzer@aol.net> wrote:
> My answer is:  Because an Atom server implemented through CGI scripts
> may not be able to support client-specified arbirary URIs.  That is, CGI
> scripts may not be able to field HTTP requests unless the URIs in the
> HTTP requests include "/cgi-bin/scriptname" or similar; so, they can't
> field PUTs to arbitrary URIs.
> 
> But they _can_ support PUT and DELETE if the server gets to specify the
> URI for resources, for example
> http://example.org/cgi-bin/resources.pl?res=mycat.jpg.

I know of no web serving environment that does not support the
PATH_INFO variable (or its equivalent for non-CGI based environments).

From http://hoohoo.ncsa.uiuc.edu/cgi/env.html

  PATH_INFO

  The extra path information, as given by 
  the client. In other words, scripts can be 
  accessed by their virtual pathname, followed 
  by extra information at the end of this path. 
  The extra information is sent as PATH_INFO. 
  This information should be decoded by the 
  server if it comes from a URL before it is 
  passed to the CGI script."

So, the following should be possible on all systems:

http://example.org/cgi-bin/resources.pl/mycat.jpg

Also, I may be wrong about this but I don't believe using query
parameters instead of PATH_INFO will make a URI any less URIy. You can
specify query parameters to a POST or PUT along with a request body
carrying application/atom+xml. Query parameters are not
second-class-citizens.

Giving everything a URI does not necessarily mean giving everything a
URI without query parameters. One publishing system may have
service.edit URIs like:

http://example.com/mycat.jpg

and another may have service.edit URIs like:

http://example.com/resource.pl?resource=mycat.jpg

PUT and DELETE requests to either of these URIs should operate on the
logical "mycat.jpg" resource exactly like a GET would. Just because
the second example uses query parameters doesn't make it any less of a
URI and doesn't make it less useful to methods other than GET. The
first example is "prettier" to look at; that's the only difference I
can establish. Am I missing (possibly a lot of) something here?

Ryan

> -John Panzer
> http://journals.aol.com/panzerjohn/abstractioneer



From owner-atom-syntax@mail.imc.org  Sat Jul  3 06: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 GAA23416
	for <atompub-archive@lists.ietf.org>; Sat, 3 Jul 2004 06:02: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 i639bBSG086841;
	Sat, 3 Jul 2004 02:37: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 i639bBaS086840;
	Sat, 3 Jul 2004 02:37:11 -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 [212.123.84.93])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i639b9cP086795
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 02:37:10 -0700 (PDT)
	(envelope-from danny666@virgilio.it)
Received: from virgilio.it (62.11.120.151) by mail-relay-3.tiscali.it (7.1.021.3)
        id 40D9B1FB0035BBA6; Sat, 3 Jul 2004 11:38:08 +0200
Message-ID: <40E67DD4.10600@virgilio.it>
Date: Sat, 03 Jul 2004 11:35:16 +0200
From: Danny Ayers <danny666@virgilio.it>
Reply-To: danny666@virgilio.it
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
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: Validing parser required?
References: <40E57909.4040808@intertwingly.net> <20040702160222.GO5957@tartarus.org> <A6E0CEEBB30A0208C3AD370C@diva.verity.com>
In-Reply-To: <A6E0CEEBB30A0208C3AD370C@diva.verity.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


Walter Underwood wrote:

>
> --On Friday, July 02, 2004 05:02:22 PM +0100 James Aylett 
> <james@tartarus.org> wrote:
>
>>
>>        An Atom document MUST be expressed such that its meaning is
>>        identical whether a validating or non-validating XML parser is
>>        used.
>
>
> That is pretty good. Here is a simpler version. We should be specific
> about what this means, though. This is a profile of XML, right?
>
>  The meaning of an Atom document MUST be the same whether processed
>  with a validating or non-validating XML parser.


I don't see how this could work. Say an element's missing. Part of the 
meaning obtained using a validating parser would be the flag 'invalid'. 
The non-validating parser presumably wouldn't be providing this 
information, the value of the element being null or empty. Or to put it 
another way, the meaning of the document doesn't change, only the 
interpretation ;-)

If I read the spec (5.1) correctly then internal DTDs have to be 
respected whatever, so I'm not sure whether it makes sense to forbid 
importation of external entity definitions (this seems to me to be a 
slightly different issue than that of validation per se).

If a imported set of entities breaks the well-formedness, the feed's 
broken, period. If it doesn't, what's the problem?

Generally I've a feeling the approach where validation is kind-of 
discouraged may be a step too far. There may be apps for which an extra 
level of validation (in the general sense) is required, and checking 
against an e.g. XML Schema could offer that.

Returning to Sam's original query, he says:
[[
As I said, I would like to see Atom "cleanly and thoroughly specified". 
 People should not be required to use a validating parser simply because 
the spec is silent on whether this is allowed or not, and therefore must 
be allowed.
]]

Big +1 to the first sentence, but I think it unlikely anyone would 
interpret the spec being silent on the issue as implying that a 
validating parser is required. But ok, just in case, why not then simply 
add the sentence: "Validation is not a requirement of an Atom processor.".

Regarding the Feed Validator, I don't think there's any extra action needed.

Cheers,
Danny.

-- 

Raw
http://dannyayers.com



From owner-atom-syntax@mail.imc.org  Sat Jul  3 07:21: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 HAA25890
	for <atompub-archive@lists.ietf.org>; Sat, 3 Jul 2004 07:21: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 i63B9inA001440;
	Sat, 3 Jul 2004 04:09: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 i63B9i4Y001439;
	Sat, 3 Jul 2004 04:09:44 -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 i63B9hRq001430
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 04:09:43 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 96914 messnum 4340322 invoked from network[83.70.35.17/83-70-35-17.bas2.prp.dublin.eircom.net]); 3 Jul 2004 11:09:38 -0000
Received: from 83-70-35-17.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.35.17)
  by mail05.svc.cra.dublin.eircom.net (qp 96914) with SMTP; 3 Jul 2004 11:09:38 -0000
Message-ID: <40E693ED.7030402@dehora.net>
Date: Sat, 03 Jul 2004 12:09:33 +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: PaceNoInfoSet
References: <F925141D-CC46-11D8-B7F4-000A95BD86C0@mnot.net> <40E59276.9030609@dehora.net> <27C3E61C-CCAF-11D8-B7F4-000A95BD86C0@mnot.net>
In-Reply-To: <27C3E61C-CCAF-11D8-B7F4-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: <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:

> How about:
> 
> "Atom's data model is described in terms of the XML Information Set 
> [ref] and serialised as XML 1.0 [ref]."

+1, that's very clear.

cheers
Bill




From owner-atom-syntax@mail.imc.org  Sat Jul  3 10: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 KAA02534
	for <atompub-archive@lists.ietf.org>; Sat, 3 Jul 2004 10: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 i63ESjPp014969;
	Sat, 3 Jul 2004 07:28: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 i63ESjUu014968;
	Sat, 3 Jul 2004 07:28:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i63ESicQ014962
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 07:28:44 -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 i63EQl53019294
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 08:26:47 -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 <0I0A007C05JY2V@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sat, 03 Jul 2004 08:28:46 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0A00CP75JWE1@mail.sun.net> for atom-syntax@imc.org; Sat,
 03 Jul 2004 08:28:45 -0600 (MDT)
Date: Sat, 03 Jul 2004 07:29:09 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceNoInfoSet
In-reply-to: <27C3E61C-CCAF-11D8-B7F4-000A95BD86C0@mnot.net>
To: Mark Nottingham <mnot@mnot.net>
Cc: Atom Syntax <atom-syntax@imc.org>,
        =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>
Message-id: <58E465B4-CCFD-11D8-BA50-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: <F925141D-CC46-11D8-B7F4-000A95BD86C0@mnot.net>
 <40E59276.9030609@dehora.net> <27C3E61C-CCAF-11D8-B7F4-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 Jul 2, 2004, at 10:09 PM, Mark Nottingham wrote:

> "Atom's data model is described in terms of the XML Information Set 
> [ref] and serialised as XML 1.0 [ref]."

I can live with that, I'd prefer something like

"Atom data is interchanged in the form of XML 1.0 documents [ref].  In 
this specification, the XML Information Set [ref] is used to specify 
the allowable syntax of these documents."

Reasons being
(a) I don't have any concern if someone, in the bowels of their CMS, 
serializes Atom data as a bunch of relational tables or whatever; the 
important thing whenever Atom data is *interchanged*, it's in XML 1.0 
docs.  I guarantee there are going to be language lawyers who are going 
to flame away at some poor vendor who uses an efficient non-XML 
datastore for Atom in a totally harmless way.
(b) It seems to me the *real* usefulness of the Infoset is to provide a 
handy way to specify which elements and attributes you're going to use, 
and which order they appear in.

   -Tim



From owner-atom-syntax@mail.imc.org  Sat Jul  3 12:24:06 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06060
	for <atompub-archive@lists.ietf.org>; Sat, 3 Jul 2004 12: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 i63GBrb6023210;
	Sat, 3 Jul 2004 09:11: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 i63GBrY5023209;
	Sat, 3 Jul 2004 09:11:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i63GBmYU023199;
	Sat, 3 Jul 2004 09:11:49 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p0611040abd0c8b0dbfa1@[10.20.30.249]>
In-Reply-To: <58E465B4-CCFD-11D8-BA50-000A95A51C9E@sun.com>
References: <F925141D-CC46-11D8-B7F4-000A95BD86C0@mnot.net>
 <40E59276.9030609@dehora.net>
 <27C3E61C-CCAF-11D8-B7F4-000A95BD86C0@mnot.net>
 <58E465B4-CCFD-11D8-BA50-000A95A51C9E@sun.com>
Date: Sat, 3 Jul 2004 09:11:54 -0700
To: Tim Bray <Tim.Bray@Sun.COM>, Mark Nottingham <mnot@mnot.net>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: PaceNoInfoSet
Cc: Atom Syntax <atom-syntax@imc.org>,
        Bill de =?iso-8859-1?Q?h=D3ra?=  <bill@dehora.net>
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:29 AM -0700 7/3/04, Tim Bray wrote:
>"Atom data is interchanged in the form of XML 1.0 documents [ref]. 
>In this specification, the XML Information Set [ref] is used to 
>specify the allowable syntax of these documents."

+1, because...

>I guarantee there are going to be language lawyers who are going to 
>flame away at some poor vendor who uses an efficient non-XML 
>datastore for Atom in a totally harmless way.

This has happened before in other contexts. Vendors say the dumbest 
things about how bad their competitors are, knowing that the press 
prefers conflict to boredom.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Sat Jul  3 13:56: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 NAA08751
	for <atompub-archive@lists.ietf.org>; Sat, 3 Jul 2004 13:56: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 i63HiCjK028188;
	Sat, 3 Jul 2004 10:44:12 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i63HiCp8028187;
	Sat, 3 Jul 2004 10:44:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.248])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i63HiBvV028181
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 10:44:11 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so673637cwc
        for <atom-syntax@imc.org>; Sat, 03 Jul 2004 10:44:10 -0700 (PDT)
Received: by 10.11.99.30 with SMTP id w30mr204409cwb;
        Sat, 03 Jul 2004 10:44:10 -0700 (PDT)
Message-ID: <3f1451f5040703104455b1a096@mail.gmail.com>
Date: Sat, 3 Jul 2004 13:44:10 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Tim Bray <tim.bray@sun.com>
Subject: Re: PaceNoInfoSet
Cc: Mark Nottingham <mnot@mnot.net>, Atom Syntax <atom-syntax@imc.org>,
        "Bill de hÓra" <bill@dehora.net>
In-Reply-To: <58E465B4-CCFD-11D8-BA50-000A95A51C9E@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <F925141D-CC46-11D8-B7F4-000A95BD86C0@mnot.net>
 <40E59276.9030609@dehora.net> <27C3E61C-CCAF-11D8-B7F4-000A95BD86C0@mnot.net> <58E465B4-CCFD-11D8-BA50-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 Sat, 03 Jul 2004 07:29:09 -0700, Tim Bray <tim.bray@sun.com> wrote:
> 
> On Jul 2, 2004, at 10:09 PM, Mark Nottingham wrote:
> 
> > "Atom's data model is described in terms of the XML Information Set
> > [ref] and serialised as XML 1.0 [ref]."
> 
> I can live with that, I'd prefer something like
> 
> "Atom data is interchanged in the form of XML 1.0 documents [ref].  In
> this specification, the XML Information Set [ref] is used to specify
> the allowable syntax of these documents."

+1

   -joe



From owner-atom-syntax@mail.imc.org  Sat Jul  3 14:21: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 OAA09499
	for <atompub-archive@lists.ietf.org>; Sat, 3 Jul 2004 14:21: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 i63I3XeU029071;
	Sat, 3 Jul 2004 11:03: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 i63I3XRI029070;
	Sat, 3 Jul 2004 11:03:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtp102.mail.sc5.yahoo.com (smtp102.mail.sc5.yahoo.com [216.136.174.140])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i63I3XBJ029064
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 11:03:33 -0700 (PDT)
	(envelope-from mc@xegesis.org)
Received: from unknown (HELO ?192.168.1.103?) (mcraigchampion@68.40.14.49 with plain)
  by smtp102.mail.sc5.yahoo.com with SMTP; 3 Jul 2004 18:03:11 -0000
Mime-Version: 1.0 (Apple Message framework v618)
In-Reply-To: <58E465B4-CCFD-11D8-BA50-000A95A51C9E@sun.com>
References: <F925141D-CC46-11D8-B7F4-000A95BD86C0@mnot.net> <40E59276.9030609@dehora.net> <27C3E61C-CCAF-11D8-B7F4-000A95BD86C0@mnot.net> <58E465B4-CCFD-11D8-BA50-000A95A51C9E@sun.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <3C16EE15-CD1B-11D8-A3E7-000A95CCC59E@xegesis.org>
Content-Transfer-Encoding: 7bit
From: Michael Champion <mc@xegesis.org>
Subject: Re: PaceNoInfoSet
Date: Sat, 3 Jul 2004 14:03:06 -0400
To: Atom Syntax <atom-syntax@imc.org>
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>
Content-Transfer-Encoding: 7bit



On Jul 3, 2004, at 10:29 AM, Tim Bray wrote:

>
> On Jul 2, 2004, at 10:09 PM, Mark Nottingham wrote:
>
>> "Atom's data model is described in terms of the XML Information Set 
>> [ref] and serialised as XML 1.0 [ref]."
>
> I can live with that, I'd prefer something like
>
> "Atom data is interchanged in the form of XML 1.0 documents [ref].  In 
> this specification, the XML Information Set [ref] is used to specify 
> the allowable syntax of these documents."

That doesn't sound quite right ... the Infoset specifies the allowable 
logical structure, not the "syntax," no?
>
> Reasons being
> (a) I don't have any concern if someone, in the bowels of their CMS, 
> serializes Atom data as a bunch of relational tables or whatever; the 
> important thing whenever Atom data is *interchanged*, it's in XML 1.0 
> docs.

What about those who expose Atom feeds via XQuery?  Isn't this 
"interchange" via the XQuery data model rather than the XML 
serialization?  (Granted that the Infoset is not the same as the XQuery 
data model, but I am assuming that we are talking about the "Infoset" 
as any abstract XML data model  , and XQuery's data model is one of 
them ....)


> (b) It seems to me the *real* usefulness of the Infoset is to provide 
> a handy way to specify which elements and attributes you're going to 
> use, and which order they appear in.
>

Well, again if we are talking about the Infoset as an abstract data 
model, the XPath data model is an "infoset" which will have a very 
concrete use for Atom users who wish to transform it to HTML or some 
other XML structure.

  I like Mark Nottingham's formulation: "Atom's data model is described 
in terms of the XML Information Set [ref] and serialised as XML 1.0 
[ref]. " because it emphasizes that Atom is both an abstract model that 
can be queried and manipulated with XPath, XSLT, and XQuery; and a 
concrete XML syntax that can be exchanged over a wire and 
parsed/manipulated with an immense number of standardized tools.



From owner-atom-syntax@mail.imc.org  Sat Jul  3 14: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 OAA10327
	for <atompub-archive@lists.ietf.org>; Sat, 3 Jul 2004 14: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 i63IYMMB030351;
	Sat, 3 Jul 2004 11:34: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 i63IYMRP030350;
	Sat, 3 Jul 2004 11:34: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 i63IYLUb030343
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 11:34: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 3BCF47C120; Sat,  3 Jul 2004 21:30:24 +0200 (CEST)
Date: Sat, 03 Jul 2004 20:37:18 +0200
To: "Graham Parks" <dtcd@mac.com>
Subject: Re: Q: modfied vs issued vs created
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <13704684.1088815647983.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: <opsakrcgqcuvpchu@quark>
In-Reply-To: <13704684.1088815647983.JavaMail.dtcd@mac.com>
User-Agent: Opera M2/7.51 (Win32, build 3798)
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, 03 Jul 2004 01:47:27 +0100, Graham Parks <dtcd@mac.com> wrote:

> http://www.intertwingly.net/wiki/pie/PaceEntryDates solves all of these  
> problems

«If an entry has been made available on several distinct occasions, this  
represents the date of the latest re-issue». I think this needs to be  
rephrased. If 'issued' is supposed to exist as an alternative to  
'created', then 'issued' can _never_ change, whether the entry is  
re-issued a thousand times.

I think 'created' is probably a better alternative for 'issued' than the  
other way around, and thus should 'issued' be the optional element, not  
'created'. It's a lot more interesting for an aggregator to know when the  
entry was first created than to know when it was first issued. Who would  
ever be interested in when the entry was _last_ issued, anyway?

-- 
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 Jul  3 15:05: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 PAA11334
	for <atompub-archive@lists.ietf.org>; Sat, 3 Jul 2004 15:05: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 i63IpirY031138;
	Sat, 3 Jul 2004 11:51:44 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i63IpiVB031137;
	Sat, 3 Jul 2004 11:51:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i63IphAr031131
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 11:51: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 i63Ipjil015652
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 12:51:45 -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 <0I0A008KEHQ8L0@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sat, 03 Jul 2004 12:51:45 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0A00KOPHQ73N@mail.sun.net> for atom-syntax@imc.org; Sat,
 03 Jul 2004 12:51:44 -0600 (MDT)
Date: Sat, 03 Jul 2004 11:52:08 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceNoInfoSet
In-reply-to: <3C16EE15-CD1B-11D8-A3E7-000A95CCC59E@xegesis.org>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <15A0CA58-CD22-11D8-BA50-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: <F925141D-CC46-11D8-B7F4-000A95BD86C0@mnot.net>
 <40E59276.9030609@dehora.net> <27C3E61C-CCAF-11D8-B7F4-000A95BD86C0@mnot.net>
 <58E465B4-CCFD-11D8-BA50-000A95A51C9E@sun.com>
 <3C16EE15-CD1B-11D8-A3E7-000A95CCC59E@xegesis.org>
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 Jul 3, 2004, at 11:03 AM, Michael Champion wrote:

>> "Atom data is interchanged in the form of XML 1.0 documents [ref].  
>> In this specification, the XML Information Set [ref] is used to 
>> specify the allowable syntax of these documents."
>
> That doesn't sound quite right ... the Infoset specifies the allowable 
> logical structure, not the "syntax," no?

When Atom is interchanged, it is interchanged as XML documents.   What 
the infoset specifies is which elements and attributes are used and in 
which order.  Whether you want to call that a "logical structure" or a 
"syntax" doesn't seem that big a deal... but I lean in favor of syntax 
because interoperation, in particular across a network, takes place at 
the level of syntax.

>> (a) I don't have any concern if someone, in the bowels of their CMS, 
>> serializes Atom data as a bunch of relational tables or whatever; the 
>> important thing whenever Atom data is *interchanged*, it's in XML 1.0 
>> docs.
>
> What about those who expose Atom feeds via XQuery?  Isn't this 
> "interchange" via the XQuery data model rather than the XML 
> serialization?  (Granted that the Infoset is not the same as the 
> XQuery data model, but I am assuming that we are talking about the 
> "Infoset" as any abstract XML data model  , and XQuery's data model is 
> one of them ....)

If someone wants to support querying Atom via XQuery or SQL or any 
other query facility, that's fine with me, and the spec shouldn't get 
in the way.  I don't think the proposed language does.  And when we say 
say Infoset, we don't mean "any abstract data model", we mean Infoset.

>  I like Mark Nottingham's formulation: "Atom's data model is described 
> in terms of the XML Information Set [ref] and serialised as XML 1.0 
> [ref]. " because it emphasizes that Atom is both an abstract model 
> that can be queried and manipulated with XPath, XSLT, and XQuery; and 
> a concrete XML syntax that can be exchanged over a wire and 
> parsed/manipulated with an immense number of standardized tools.

The reason the specification exists is to support programmers in 
building software which interoperates across the network.  All they can 
be sure of is that they will get messages which are XML 1.0 documents 
and whose syntax is constrained in a way that's conveniently described 
using the Infoset.  The logical model they choose to construct inside 
their software to deal with this is none of our concern, and if it 
looks totally unlike the XML Infoset, that's fine and we shouldn't give 
anyone help in claiming that it isn't.  -Tim



From owner-atom-syntax@mail.imc.org  Sat Jul  3 15:08: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 PAA11834
	for <atompub-archive@lists.ietf.org>; Sat, 3 Jul 2004 15:08: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 i63Imr2d031001;
	Sat, 3 Jul 2004 11: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 i63ImrW4031000;
	Sat, 3 Jul 2004 11:48:53 -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 i63Imqub030993
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 11:48:52 -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 i63ImuOo000521;
	Sat, 3 Jul 2004 11:48:56 -0700 (PDT)
Received: from [12.40.111.129] (wireless-12-40-111-129.bryantpark.org [12.40.111.129] (may be forged))
	(authenticated bits=0)
	by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id i63Imthp027192;
	Sat, 3 Jul 2004 11:48:55 -0700 (PDT)
In-Reply-To: <opsakrcgqcuvpchu@quark>
References: <13704684.1088815647983.JavaMail.dtcd@mac.com> <opsakrcgqcuvpchu@quark>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-15-1051683415; protocol="application/pkcs7-signature"
Message-Id: <AB02ABEA-CD21-11D8-B513-000A95DC3D90@mac.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: Q: modfied vs issued vs created
Date: Sat, 3 Jul 2004 14:49:09 -0400
To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
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-15-1051683415
Content-Type: text/plain;
	charset=ISO-8859-1;
	format=flowed
Content-Transfer-Encoding: quoted-printable


On 3 Jul 2004, at 2:37 pm, Asbj=F8rn Ulsberg wrote:

> =ABIf an entry has been made available on several distinct occasions,=20=

> this represents the date of the latest re-issue=BB. I think this needs=20=

> to be rephrased. If 'issued' is supposed to exist as an alternative to=20=

> 'created', then 'issued' can _never_ change, whether the entry is=20
> re-issued a thousand times. I think 'created' is probably a better=20
> alternative for 'issued' than the other way around, and thus should=20
> 'issued' be the optional element, not 'created'.

You make a good point here, but go after the wrong solution. If an=20
article is reissued, <issued> no longer represents the creation date.=20
However the first time an article is published, they can be assumed to=20=

be the same, or very similar. The reason <issued> is required and not=20
<created> is that most software will only know the date the user=20
clicked the Publish button, not when the article was created.

> It's a lot more interesting for an aggregator to know when the entry=20=

> was first created than to know when it was first issued.

Why? Most use aggregators to keep up with news. It's a lot more=20
interesting to something has been reissued than when that entry was=20
first created.

> Who would ever be interested in when the entry was _last_ issued,=20
> anyway?

Tim Bray's readers. Tim likes to reuse old articles rather than create=20=

new ones when he has something to post. Why not just use the modified=20
date? Because almost everyone else who modifies old entries isn't=20
trying to reissue them. A lot of people seem to have trouble grasping=20
this difference. Publishers really do need a mechanism to modify an=20
entry without re-issuing it, and to re-issue an entry without modifying=20=

it.

Graham Parks=

--Apple-Mail-15-1051683415
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
9w0BCQUxDxcNMDQwNzAzMTg0OTA5WjAjBgkqhkiG9w0BCQQxFgQUw8MkDZ4Xjxuc3H2o/tK0oCT8
0okweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEA1OWPhBK6I+gVeWXsjtnGT8hB
wCRt6EvhvPhixz+Qs6sudhUrH3TKOJF5YM045XUwA107zZdBanpNu6Z1ExkSF/PbrRMR2CYl2ET4
+twb1XvuC34d1YgpWKKStGPWknCgdIi0M45Bvq+KvULUWLmtaHdSTq+DDDV9wlL4yj1qU3B73exG
KiVvhGS0jRKWWxQB2glc4PYqj2D5r/dtkrxhLtA6/lgcZvqt2v0NbmpNUBU/XBxFtUb9aEuV7NZ1
VvAavHzqkkZyCo1Eq/1iklN4rOy6hDOHdXjQC816k9QtxPfTM4WMqAw1oXHd8Qs/KkpFV1DpfMcu
tP/3Ungz5JkS0AAAAAAAAA==

--Apple-Mail-15-1051683415--



From owner-atom-syntax@mail.imc.org  Sat Jul  3 15:13: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 PAA12617
	for <atompub-archive@lists.ietf.org>; Sat, 3 Jul 2004 15:13: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 i63J3XmM031685;
	Sat, 3 Jul 2004 12:03: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 i63J3Xa8031684;
	Sat, 3 Jul 2004 12:03: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 i63J3W6R031676
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 12:03: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 E3B9E7C122; Sat,  3 Jul 2004 21:59:38 +0200 (CEST)
Date: Sat, 03 Jul 2004 21:06:40 +0200
To: "John Panzer" <jpanzer@aol.net>
Subject: Re: PaceSimpleResourcePosting and PUT
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <opsairy6o1uvpchu@quark> <40E597FF.8020808@aol.net> <opsai5d4uouvpchu@quark> <40E64A34.5060406@aol.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: <opsakspewuuvpchu@quark>
In-Reply-To: <40E64A34.5060406@aol.net>
User-Agent: Opera M2/7.51 (Win32, build 3798)
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, 02 Jul 2004 22:55:00 -0700, John Panzer <jpanzer@aol.net> wrote:

> I don't think anyone assumes that you can implement Atom without at  
> least the equivalent of CGI scripts. :)

That depends on what part of Atom you're talking about. The format, and  
the correct serving of it, should be able to be implemented by Bob which  
is an unprivileged user[1]. The API, however, is impossible to implement  
on a standard Apache or IIS web server. What would be fun, though, is if  
the Atom API was possible to support just by installing existing WebDAV  
services for the operating system of your choice.

> I have a URI like this: http://example.org/resources/mycat.jpg.  When
> I do a GET on this URI, I retrieve the image/jpeg data.  When I do a
> PUT to this URI, I replace the image/jpeg data.  When I DELETE the
> URI, I delete the image/jpeg data.

Yes. And as the current Atom API is defined, you would use POST to create  
assign 'mycat.jpg' an URI and initially create it.

> Can all Atom servers, even ones implemented with CGI scripts, handle  
> this?

Yes. I'm very confident that can be done, but you need some kind of url  
rewrite procedure to have all the HTTP methods routed to an associated CGI  
(or similar) for a seemingly static URI like the one above.

> Some Atom implementations may need to use URIs like
> http://example.org/cgi-bin/resources?name=mycat.jpg, so that their CGI  
> scripts can get control on HEAD, GET, PUT, and DELETE.

That shouldn't be necessary if you can use something like .htaccess on  
Apache, or have nice administrators on IIS with ASP.NET. The problem is  
that if people somehow can't do rewrite, they would most likely want to  
serve the resources for GETs as 'http://example.org/resources/mycat.jpg'  
but for all the other verbs  
'http://example.org/cgi-bin/resources?name=mycat.jpg'.

This splits the resource in half, kind of, because it is accessible from  
two different URI's. And not that each URI is equal; no, you can only use  
one for GET and the other for PUT and DELETE (for POST, you'd use a  
totally separate URI anyway).

> This is actually important to the context of both  
> PaceSimpleResourcePosting and PaceNonEntryResources, because both assume  
> that you can take a single URI and use it for both simple GETs (e.g.,  
> when using an XHTML img[@src]) and for any subsequent PUTs or DELETEs.

Yes.

> If that assumption works for even CGI-limited servers, I think  
> everything would be fine.  If not, then the two Paces above might have  
> some issues.

As the API offers 'service.edit' URI's, I don't think this is a big  
problem. This URI can be something different for PUT than it is for GET.  
It's not very REST-ish or intuitive, but it works for rewrite-disabled  
people and servers.

> Dumb question:  I assume Apache does hand HEAD requests to CGIs?  :^)

Yes, it does.

> It's pretty easy if you have control over the server itself (by which I  
> mean the ability to remap URLs to your own code).  It sounds like this  
> is supportable even for CGI based services too, assuming that web  
> servers will just hand the darn verbs to the scripts.

With rewrite in Apache and on IIS, all HTTP methods are handed off to the  
scripts. On Apache, OPTIONS is however, not handed off. I haven't gotten  
time to test how IIS handles OPTIONS, but as we can't rely on that method  
because of Apache's flaw, anyway, I don't think it matters much how IIS  
handles it.

> Sorry, what I meant to ask was whether PUT should be required to be  
> atomic: When your PUT fails midway through the 1MB cat video upload, is  
> the prior content untouched?

Oh. This would be very implementation specific, I think, but Atom could  
probably offer some indications on what should happen. I would assume most  
scripts receiving a file would write it to memory before overwriting the  
original file, thus leaving the original intact until the whole bulk is  
received from the client.

____
[1] <url: http://www.intertwingly.net/wiki/pie/UnprivilegedUsers>

-- 
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 Jul  3 15:17: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 PAA13275
	for <atompub-archive@lists.ietf.org>; Sat, 3 Jul 2004 15:17: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 i63J7fLl031911;
	Sat, 3 Jul 2004 12:07:41 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i63J7fV0031910;
	Sat, 3 Jul 2004 12:07:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i63J7egu031901
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 12:07:41 -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 617EE7C123; Sat,  3 Jul 2004 22:03:46 +0200 (CEST)
Date: Sat, 03 Jul 2004 21:10:49 +0200
To: danny666@virgilio.it
Subject: Re: Validing parser required?
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <40E57909.4040808@intertwingly.net> <20040702160222.GO5957@tartarus.org> <A6E0CEEBB30A0208C3AD370C@diva.verity.com> <40E67DD4.10600@virgilio.it>
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: <opsakswbiiuvpchu@quark>
In-Reply-To: <40E67DD4.10600@virgilio.it>
User-Agent: Opera M2/7.51 (Win32, build 3798)
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, 03 Jul 2004 11:35:16 +0200, Danny Ayers <danny666@virgilio.it>  
wrote:

> "Validation is not a requirement of an Atom processor.".

But should we, or shuld we not have normative XSD's, RNG's, WSDL's et al?  
If we are, I think we should encourage validation, but I agree that  
requiring it is not feasible.

-- 
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 Jul  3 15:19: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 PAA13589
	for <atompub-archive@lists.ietf.org>; Sat, 3 Jul 2004 15:19: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 i63J949i031967;
	Sat, 3 Jul 2004 12:09: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 i63J94EE031966;
	Sat, 3 Jul 2004 12:09:04 -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 i63J93Iu031957
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 12:09:03 -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 E514D7C122; Sat,  3 Jul 2004 22:05:09 +0200 (CEST)
To: =?iso-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceNoInfoSet
References: <F925141D-CC46-11D8-B7F4-000A95BD86C0@mnot.net> <40E59276.9030609@dehora.net> <27C3E61C-CCAF-11D8-B7F4-000A95BD86C0@mnot.net> <40E693ED.7030402@dehora.net>
Message-ID: <opsaksym1muvpchu@quark>
Date: Sat, 03 Jul 2004 21:12:12 +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: <40E693ED.7030402@dehora.net>
User-Agent: Opera M2/7.51 (Win32, build 3798)
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, 03 Jul 2004 12:09:33 +0100, Bill de hÓra <bill@dehora.net> wrote:

>>  "Atom's data model is described in terms of the XML Information Set  
>> [ref] and serialised as XML 1.0 [ref]."
>
> +1, that's very clear.

I agree. Does this one sentence need its own pace? I think not. But if it  
does, I have no problems with creating 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  Sat Jul  3 15:24: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 PAA14498
	for <atompub-archive@lists.ietf.org>; Sat, 3 Jul 2004 15:24: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 i63JCvSR032220;
	Sat, 3 Jul 2004 12: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 i63JCvw4032219;
	Sat, 3 Jul 2004 12:12:57 -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 i63JCvWG032185
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 12:12:57 -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 i63JCtt10444
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 12:12:55 -0700 (PDT)
Received: from aol.net ([10.169.192.26]) by judge.mcom.com
          (Netscape Messaging Server 4.15) with ESMTP id I0AIPI00.K0X;
          Sat, 3 Jul 2004 12:12:54 -0700 
Message-ID: <40E70539.70504@aol.net>
Date: Sat, 03 Jul 2004 12:12:57 -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: Ryan Tomayko <rtomayko@gmail.com>
CC: Atom-Syntax <atom-syntax@imc.org>,
        =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?=
 <asbjorn@tigerstaden.no>
Subject: Re: PaceSimpleResourcePosting and PUT
References: <opsairy6o1uvpchu@quark> <40E64BA6.5070402@aol.net> <f732822d0407030053186491b6@mail.gmail.com>
In-Reply-To: <f732822d0407030053186491b6@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------040301040105040407070900"
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>


This is a multi-part message in MIME format.
--------------040301040105040407070900
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Ryan Tomayko wrote:

>On Fri, 02 Jul 2004 23:01:10 -0700, John Panzer <jpanzer@aol.net> wrote:
>  
>
>>My answer is:  Because an Atom server implemented through CGI scripts
>>may not be able to support client-specified arbirary URIs.  That is, CGI
>>scripts may not be able to field HTTP requests unless the URIs in the
>>HTTP requests include "/cgi-bin/scriptname" or similar; so, they can't
>>field PUTs to arbitrary URIs.
>>
>>But they _can_ support PUT and DELETE if the server gets to specify the
>>URI for resources, for example
>>http://example.org/cgi-bin/resources.pl?res=mycat.jpg.
>>    
>>
>
>I know of no web serving environment that does not support the
>PATH_INFO variable (or its equivalent for non-CGI based environments).
>
>>From http://hoohoo.ncsa.uiuc.edu/cgi/env.html
>
>  PATH_INFO
>
>  The extra path information, as given by 
>  the client. In other words, scripts can be 
>  accessed by their virtual pathname, followed 
>  by extra information at the end of this path. 
>  The extra information is sent as PATH_INFO. 
>  This information should be decoded by the 
>  server if it comes from a URL before it is 
>  passed to the CGI script."
>
>So, the following should be possible on all systems:
>
>http://example.org/cgi-bin/resources.pl/mycat.jpg
>
>Also, I may be wrong about this but I don't believe using query
>parameters instead of PATH_INFO will make a URI any less URIy. You can
>specify query parameters to a POST or PUT along with a request body
>carrying application/atom+xml. Query parameters are not
>second-class-citizens.
>
>Giving everything a URI does not necessarily mean giving everything a
>URI without query parameters. One publishing system may have
>service.edit URIs like:
>
>http://example.com/mycat.jpg
>
>and another may have service.edit URIs like:
>
>http://example.com/resource.pl?resource=mycat.jpg
>
>PUT and DELETE requests to either of these URIs should operate on the
>logical "mycat.jpg" resource exactly like a GET would. Just because
>the second example uses query parameters doesn't make it any less of a
>URI and doesn't make it less useful to methods other than GET. The
>first example is "prettier" to look at; that's the only difference I
>can establish. Am I missing (possibly a lot of) something here?
>
>Ryan
>  
>
I totally agree with you; I was just using the query parameter version 
to make the point that the server needs to be able to control the format 
of the URI.  This is still the case even if you use PATH_INFO.  That is, 
clients cannot necessarily be allowed to say "put my cat picture at 
http://example.com/mypictures/cat.jpg" because a server may not be able 
to map that URI to a CGI script.  The URI in some servers has to start 
with the path /cgi-bin/. I am imagining here a hosted environment in 
which URIs to CGI scripts have to have this form, and where the person 
running an Atom service can't remap URIs, etc.  Does that make sense?

At least, such is my understanding of the situation (and of one hosting 
provider that I actually use). 

John

--------------040301040105040407070900
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Ryan Tomayko wrote:<br>
<blockquote cite="midf732822d0407030053186491b6@mail.gmail.com"
 type="cite">
  <pre wrap="">On Fri, 02 Jul 2004 23:01:10 -0700, John Panzer <a class="moz-txt-link-rfc2396E" href="mailto:jpanzer@aol.net">&lt;jpanzer@aol.net&gt;</a> wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">My answer is:  Because an Atom server implemented through CGI scripts
may not be able to support client-specified arbirary URIs.  That is, CGI
scripts may not be able to field HTTP requests unless the URIs in the
HTTP requests include "/cgi-bin/scriptname" or similar; so, they can't
field PUTs to arbitrary URIs.

But they _can_ support PUT and DELETE if the server gets to specify the
URI for resources, for example
<a class="moz-txt-link-freetext" href="http://example.org/cgi-bin/resources.pl?res=mycat.jpg">http://example.org/cgi-bin/resources.pl?res=mycat.jpg</a>.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I know of no web serving environment that does not support the
PATH_INFO variable (or its equivalent for non-CGI based environments).

&gt;From <a class="moz-txt-link-freetext" href="http://hoohoo.ncsa.uiuc.edu/cgi/env.html">http://hoohoo.ncsa.uiuc.edu/cgi/env.html</a>

  PATH_INFO

  The extra path information, as given by 
  the client. In other words, scripts can be 
  accessed by their virtual pathname, followed 
  by extra information at the end of this path. 
  The extra information is sent as PATH_INFO. 
  This information should be decoded by the 
  server if it comes from a URL before it is 
  passed to the CGI script."

So, the following should be possible on all systems:

<a class="moz-txt-link-freetext" href="http://example.org/cgi-bin/resources.pl/mycat.jpg">http://example.org/cgi-bin/resources.pl/mycat.jpg</a>

Also, I may be wrong about this but I don't believe using query
parameters instead of PATH_INFO will make a URI any less URIy. You can
specify query parameters to a POST or PUT along with a request body
carrying application/atom+xml. Query parameters are not
second-class-citizens.

Giving everything a URI does not necessarily mean giving everything a
URI without query parameters. One publishing system may have
service.edit URIs like:

<a class="moz-txt-link-freetext" href="http://example.com/mycat.jpg">http://example.com/mycat.jpg</a>

and another may have service.edit URIs like:

<a class="moz-txt-link-freetext" href="http://example.com/resource.pl?resource=mycat.jpg">http://example.com/resource.pl?resource=mycat.jpg</a>

PUT and DELETE requests to either of these URIs should operate on the
logical "mycat.jpg" resource exactly like a GET would. Just because
the second example uses query parameters doesn't make it any less of a
URI and doesn't make it less useful to methods other than GET. The
first example is "prettier" to look at; that's the only difference I
can establish. Am I missing (possibly a lot of) something here?

Ryan
  </pre>
</blockquote>
I totally agree with you; I was just using the query parameter version
to make the point that the server needs to be able to control the
format of the URI.&nbsp; This is still the case even if you use PATH_INFO.&nbsp;
That is, clients cannot necessarily be allowed to say "put my cat
picture at <a class="moz-txt-link-freetext" href="http://example.com/mypictures/cat.jpg">http://example.com/mypictures/cat.jpg</a>" because a server may
not be able to map that URI to a CGI script.&nbsp; The URI in some servers
has to start with the path /cgi-bin/. I am imagining here a hosted
environment in which URIs to CGI scripts have to have this form, and
where the person running an Atom service can't remap URIs, etc.&nbsp; Does
that make sense?<br>
<br>
At least, such is my understanding of the situation (and of one hosting
provider that I actually use).&nbsp; <br>
<br>
John<br>
</body>
</html>

--------------040301040105040407070900--



From owner-atom-syntax@mail.imc.org  Sat Jul  3 15: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 PAA15719
	for <atompub-archive@lists.ietf.org>; Sat, 3 Jul 2004 15:49: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 i63JcM0b034143;
	Sat, 3 Jul 2004 12:38:22 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i63JcMx8034142;
	Sat, 3 Jul 2004 12:38: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 i63JcL4L034131
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 12:38: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 63C4A7C120; Sat,  3 Jul 2004 22:34:27 +0200 (CEST)
Date: Sat, 03 Jul 2004 21:41:36 +0200
To: Graham <dtcd@mac.com>
Subject: Re: Q: modfied vs issued vs created
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <13704684.1088815647983.JavaMail.dtcd@mac.com> <opsakrcgqcuvpchu@quark> <AB02ABEA-CD21-11D8-B513-000A95DC3D90@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: <opsakubmttuvpchu@quark>
In-Reply-To: <AB02ABEA-CD21-11D8-B513-000A95DC3D90@mac.com>
User-Agent: Opera M2/7.51 (Win32, build 3798)
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, 3 Jul 2004 14:49:09 -0400, Graham <dtcd@mac.com> wrote:

> You make a good point here, but go after the wrong solution. If an
> article is reissued, <issued> no longer represents the creation date.

Then we can't say that in the specification. Issued is issued, and never  
'created', and they will never share any semantics, whatsoever. They are  
of the same data type, but that's it.

> However the first time an article is published, they can be assumed to
> be the same, or very similar.

That's really of no interest to anyone. If someone would like to know when  
an article was created, they SHOULD NOT be encouraged to look at the  
'issued' date, if that date is bound to change every other minute.

> The reason <issued> is required and not <created> is that most
> software will only know the date the user clicked the Publish button,
> not when the article was created.

To take an example, Movable Type first creates an article, and then  
publishes it first when the user hits [Save] with the status set to  
'Publish'. I'm not sure how the internal structure of MT is, but there's  
at least no problem with having the first created date saved somewhere.

>> It's a lot more interesting for an aggregator to know when the entry
>> was first created than to know when it was first issued.
>
> Why? Most use aggregators to keep up with news. It's a lot more
> interesting to something has been reissued than when that entry was
> first created.

If it is how you say, that publishers tend to re-publish old entries, of  
course it is interesting to know when the entry was first written. It is  
about context. If you write something about the internet in 1996 and then  
re-issue the same article in 2004, it would actually be nice to have some  
idea of when the article was originally written. If the only date you  
receive is '2004-07-03', the readers will look very skewed on it when they  
read how you explain about great technology like «browsers», «HTML» and  
the likes.

However, if you edit the article, and publish it again, with a time span  
of two weeks, the article should not get a new 'issued' date, but an  
updated 'modified' date.

>> Who would ever be interested in when the entry was _last_ issued,
>> anyway?
>
> Tim Bray's readers. Tim likes to reuse old articles rather than create
> new ones when he has something to post.

Uhm. What is it that he reuses? The ID's of the entries, or the content?

> Why not just use the modified date? Because almost everyone else who
> modifies old entries isn't trying to reissue them.

I have no idea whatsoever you're trying to say here. Would you care to  
elaborate a bit more, please?

> A lot of people seem to have trouble grasping this difference. Publishers
> really do need a mechanism to modify an entry without re-issuing it, and
> to re-issue an entry without modifying it.

I work in one of Norways largest news publishing corporations, and I will  
make a very strong claim that it's a lot more important to be able to  
modify an issued article, and reflect that in the Atom entry (but preserve  
the original 'created' date), than to re-issue a really old article and  
reflect that with an updated 'issued' 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  Sat Jul  3 15:58: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 PAA16216
	for <atompub-archive@lists.ietf.org>; Sat, 3 Jul 2004 15:58: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 i63JcaHJ034157;
	Sat, 3 Jul 2004 12:38: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 i63Jca3Z034156;
	Sat, 3 Jul 2004 12:38: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 i63JcaYb034147
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 12:38:36 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040703193835.6416.qmail@web41212.mail.yahoo.com>
Received: from [24.18.131.127] by web41212.mail.yahoo.com via HTTP; Sat, 03 Jul 2004 12:38:35 PDT
Date: Sat, 3 Jul 2004 12:38:35 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: RE: AtomPubIssuesList
To: David Orchard <dorchard@bea.com>, Sam Ruby <rubys@intertwingly.net>,
        Atom-Syntax Syntax <atom-syntax@imc.org>
In-Reply-To: <32D5845A745BFB429CBDBADA57CD41AF08A31CF2@ussjex01.amer.bea.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


--- David Orchard <dorchard@bea.com> wrote:
> 
> I think I was asked to look into this, and accepted
> the action item.  I spoke with Tim Bray last week,
> and he assured me that this was not a high priority
> item, especially when I mentioned I was looking at
> what Atom would look like in WSDL 2.0 and WSDL 2.0
> has hopefully a strong HTTP binding.  Is this wrong?
> 
> I would have thought that you:
> - would have an "extensibility" action item
> outstanding 
> - would check with the action item owner
> periodically
> - would have an open issue with an issue raiser and
> the assigned action item.
> 
> The only issue I see related is the
> PaceEntryElementNeedsVersionAttribute.

As an aggregator author and someone who's seen first
hand the problems software development teams face when
dealing with extensibility and versioning in XML
formats I see this as a high priority item. 

I've been waiting to finish my article for XML.com on
versioning and extensibility before actually
contributing a Pace so I wouldn't have to repeat my
arguments. If no one plans to write a Pace in the next
week or so then I'll produce one next weekend. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 



From owner-atom-syntax@mail.imc.org  Sat Jul  3 16: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 QAA16724
	for <atompub-archive@lists.ietf.org>; Sat, 3 Jul 2004 16: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 i63Jm2VW034608;
	Sat, 3 Jul 2004 12:48: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 i63Jm2On034607;
	Sat, 3 Jul 2004 12:48: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 i63Jm1sL034599
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 12:48: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 65B277C122; Sat,  3 Jul 2004 22:44:08 +0200 (CEST)
Date: Sat, 03 Jul 2004 21:51:18 +0200
To: "John Panzer" <jpanzer@aol.net>
Subject: Re: PaceSimpleResourcePosting and PUT
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <opsairy6o1uvpchu@quark> <40E64BA6.5070402@aol.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: <opsakursqruvpchu@quark>
In-Reply-To: <40E64BA6.5070402@aol.net>
User-Agent: Opera M2/7.51 (Win32, build 3798)
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, 02 Jul 2004 23:01:10 -0700, John Panzer <jpanzer@aol.net> wrote:

> [...] an Atom server implemented through CGI scripts may not be able
> to support client-specified arbirary URIs.

True. That's why we need a mechanism to negotiate supported HTTP methods.  
Do a HEAD on the URI you'd like to PUT, and if you don't get 'Accept: PUT'  
in return, then don't do PUT on it. Of course, if you do, you'd most  
likely get «405 method not allowed» in return. In that case, you would  
have to use POST to some other URL to let the server handle the URI space.

> That is, CGI scripts may not be able to field HTTP requests unless the
> URIs in the HTTP requests include "/cgi-bin/scriptname" or similar; so,
> they can't field PUTs to arbitrary URIs.

Those servers probably exist, yes. It's stupid, because most of these  
servers are probably Apache with .htaccess possibilities where you can do  
rewrite.

> But they _can_ support PUT and DELETE if the server gets to specify the  
> URI for resources, for example  
> http://example.org/cgi-bin/resources.pl?res=mycat.jpg.

Yes. Atom should probably encourage, but not require, the server to do  
some kind of rewrite. Encouraging rewrite would also help pushing the  
idiom of «Cool URI's don't change»[1] forward, which imho is a Good Thing.

____
[1] <url: http://www.w3.org/Provider/Style/URI.html>

-- 
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 Jul  3 16:11: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 QAA17194
	for <atompub-archive@lists.ietf.org>; Sat, 3 Jul 2004 16:11: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 i63K0Coo035140;
	Sat, 3 Jul 2004 13:00: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 i63K0CjL035139;
	Sat, 3 Jul 2004 13:00: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 i63K0BIx035131
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 13:00: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 822957C119; Sat,  3 Jul 2004 22:56:17 +0200 (CEST)
Date: Sat, 03 Jul 2004 22:03:31 +0200
To: "Mark Nottingham" <mnot@mnot.net>
Subject: Re: PaceXmlBaseEverywhere
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <BA72FC2A-CC47-11D8-B7F4-000A95BD86C0@bea.com> <327469D8-CC71-11D8-BA50-000A95A51C9E@sun.com> <20040702222446.GA16686@homer.w3.org> <CF9D211D-CC84-11D8-B7F4-000A95BD86C0@mnot.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: <opsakvb5t8uvpchu@quark>
In-Reply-To: <CF9D211D-CC84-11D8-B7F4-000A95BD86C0@mnot.net>
User-Agent: Opera M2/7.51 (Win32, build 3798)
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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, 2 Jul 2004 17:06:19 -0700, Mark Nottingham <mnot@mnot.net> wrote:

> If you want your infrastructure to apply XML Base for you, it has to  
> know where to apply it. In a container format like Atom, that doesn't  
> work very well, unless you have good Schema information.

But coming to think of it; how often is really 'base' used? And how often  
is it realisticly to assume it will be used in Atom? Is the base going to  
change for each and every element in the feed? Is there any aggregator in  
existance that could cope with something like this:

   <?xml version="1.0" encoding="utf-8"?>
   <feed version="0.3" xmlns="http://purl.org/atom/ns#"
     xmlns:my="http://example.com/my#namespace"
     xmlns:date="http://date.example.com/date#namespace"
     xml:base="http://example.com/">

     <title>Asbjørn Ulsberg's weblog</title>

     <link rel="alternate" type="text/html"
      xml:base="http://example.org/" href="asbjornu" />

     <modified xml:base="http://date.example.com/
       date:href="modified">2003-12-13T18:30:02Z</modified>

     <author xml:base="http://example.net/" my:href="asbjornu">
       <name>Asbjørn Ulsberg</name>
     </author>

     <entry>
       <title>XML base example</title>
       <id>tag:example.org,2004:6.2397</id>
       <issued>2003-12-13T08:29:29-04:00</issued>
       <modified>2003-12-13T18:30:02Z</modified>

       <content type="application/xhtml+xml" mode="xml"
         xml:base="http://example.org/articles/">
         <div xmlns="http://www.w3.org/1999/xhtml"
           <h1><a href="62397.html">XML base example</a></h1>
         </div>
       </content>
     </entry>
   </feed>

This is probably a bad example, but hopefully it shows how meaningless  
«xml:base everywhere» is. I can understand the need to change the URI base  
for each entry, and maybe for each content element, but for each and every  
element in 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 Jul  3 16:33: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 QAA19481
	for <atompub-archive@lists.ietf.org>; Sat, 3 Jul 2004 16:33: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 i63KJAs6036239;
	Sat, 3 Jul 2004 13:19: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 i63KJAv6036238;
	Sat, 3 Jul 2004 13:19: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 i63KJ9ik036223
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 13: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 7CE117C119; Sat,  3 Jul 2004 23:15:15 +0200 (CEST)
Cc: "Sam Ruby" <rubys@intertwingly.net>
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Withdrawn: PaceXmlValidity
Date: Sat, 03 Jul 2004 22:22: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
Message-ID: <opsakv7voluvpchu@quark>
User-Agent: Opera M2/7.51 (Win32, build 3798)
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 have withdrawn PaceXmlValidity[1] because it is superseded by the much  
more complete PaceShouldBeWellFormed[2].

____
[1] <url: http://www.intertwingly.net/wiki/pie/PaceXmlValidity>
[2] <url: http://www.intertwingly.net/wiki/pie/PaceShouldBeWellFormed>

-- 
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 Jul  3 16: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 QAA20191
	for <atompub-archive@lists.ietf.org>; Sat, 3 Jul 2004 16:39: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 i63KSQZ4037090;
	Sat, 3 Jul 2004 13:28: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 i63KSQVu037089;
	Sat, 3 Jul 2004 13:28: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 i63KSP7p037072
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 13:28: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 89CA27C119; Sat,  3 Jul 2004 23:24:31 +0200 (CEST)
Cc: "Sam Ruby" <rubys@intertwingly.net>
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Withdrawn: PaceContentTypeHandling
Date: Sat, 03 Jul 2004 22:31:51 +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
Message-ID: <opsakwndiyuvpchu@quark>
User-Agent: Opera M2/7.51 (Win32, build 3798)
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 have withdrawn PaceContentTypeHandling[1] because it is superseded by  
the much more complete PaceShouldBeWellFormed[2].

____
[1] <url: http://www.intertwingly.net/wiki/pie/PaceContentTypeHandling>
[2] <url: http://www.intertwingly.net/wiki/pie/PaceShouldBeWellFormed>

-- 
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 Jul  3 16:56:12 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21567
	for <atompub-archive@lists.ietf.org>; Sat, 3 Jul 2004 16:56:12 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i63KfkBE037564;
	Sat, 3 Jul 2004 13:41: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 i63Kfka1037563;
	Sat, 3 Jul 2004 13:41:46 -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 i63KfjtC037557
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 13:41:45 -0700 (PDT)
	(envelope-from dtcd@mac.com)
Received: from webmail06.mac.com (webmail06-en1 [10.13.11.148])
	by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i63KforT018836;
	Sat, 3 Jul 2004 13:41:50 -0700 (PDT)
Received: from webmail06 (localhost [127.0.0.1])
	by webmail06.mac.com (8.12.6/8.12.2) with ESMTP id i63Kfotc013718;
	Sat, 3 Jul 2004 13:41:50 -0700 (PDT)
Message-ID: <14543268.1088887310064.JavaMail.dtcd@mac.com>
Date: Sat, 03 Jul 2004 21:41:50 +0100
From: Graham Parks <dtcd@mac.com>
To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
Subject: Re: Q: modfied vs issued vs created
Cc: atom-syntax@imc.org
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 i63KfjtC037558
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, July 03, 2004, at 08:41PM, Asbjørn Ulsberg <asbjorn@tigerstaden.no> wrote:

>On Sat, 3 Jul 2004 14:49:09 -0400, Graham <dtcd@mac.com> wrote:
>
>> You make a good point here, but go after the wrong solution. If an
>> article is reissued, <issued> no longer represents the creation date.
>
>Then we can't say that in the specification. Issued is issued, and never  
>'created', and they will never share any semantics, whatsoever. They are  
>of the same data type, but that's it.

Fair point.

>That's really of no interest to anyone. If someone would like to know when  
>an article was created, they SHOULD NOT be encouraged to look at the  
>'issued' date, if that date is bound to change every other minute.

Well I think I'm allowinf for that - I'm warning publishers of the assumptions consumers will make if metadata is ommitted. There might be a better way to word it.

>To take an example, Movable Type first creates an article, and then  
>publishes it first when the user hits [Save] with the status set to  
>'Publish'. I'm not sure how the internal structure of MT is, but there's  
>at least no problem with having the first created date saved somewhere.

Yes, but that's MT. The one date (and event) all systems publishing Atom will be able to record is the date that the content was actually issued.

>If it is how you say, that publishers tend to re-publish old entries, of  
>course it is interesting to know when the entry was first written. It is  
>about context. If you write something about the internet in 1996 and then  
>re-issue the same article in 2004, it would actually be nice to have some  
>idea of when the article was originally written. If the only date you  
>receive is '2004-07-03', the readers will look very skewed on it when they  
>read how you explain about great technology like «browsers», «HTML» and  
>the likes.

Well, it's up to the publisher to provide that information in those cirumstances. I don't think it matters which is most interesting, though, it's what publishers have and consumers need.

>However, if you edit the article, and publish it again, with a time span  
>of two weeks, the article should not get a new 'issued' date, but an  
>updated 'modified' date.

Why not? The intention of <issued> in PaceEntryDates is just that (provided the publisher actually wants to reissue the article, and wasn't just correcting a typo).

>Uhm. What is it that he reuses? The ID's of the entries, or the content?

He'd rather add something new to an old article, where most reissue the entry.

>> Why not just use the modified date? Because almost everyone else who
>> modifies old entries isn't trying to reissue them.
>
>I have no idea whatsoever you're trying to say here. Would you care to  
>elaborate a bit more, please?

In Blogger and propably MT and probably most other things, if I go and edit and old article, it *does not* jump back on to the front page. It's been <modified>, but it hasn't been <reissued>.

>I work in one of Norways largest news publishing corporations, and I will  
>make a very strong claim that it's a lot more important to be able to  
>modify an issued article, and reflect that in the Atom entry (but preserve  
>the original 'created' date), than to re-issue a really old article and  
>reflect that with an updated 'issued' date.

You're talking as if PaceEntryDates removes the <created> field. They're all still available. As I said before, issuing is the only event that all systems will have in common, and is therefore the only date that can be mandatory.

Graham Parks



From owner-atom-syntax@mail.imc.org  Sat Jul  3 17: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 RAA21820
	for <atompub-archive@lists.ietf.org>; Sat, 3 Jul 2004 17:04: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 i63Ku4Xt038362;
	Sat, 3 Jul 2004 13:56: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 i63Ku4Pt038361;
	Sat, 3 Jul 2004 13:56:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtp012.mail.yahoo.com (smtp012.mail.yahoo.com [216.136.173.32])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i63Ku4jU038355
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 13:56:04 -0700 (PDT)
	(envelope-from mc@xegesis.org)
Received: from unknown (HELO ?192.168.1.103?) (mcraigchampion@68.40.14.49 with plain)
  by smtp012.mail.yahoo.com with SMTP; 3 Jul 2004 20:56:06 -0000
Mime-Version: 1.0 (Apple Message framework v618)
In-Reply-To: <15A0CA58-CD22-11D8-BA50-000A95A51C9E@sun.com>
References: <F925141D-CC46-11D8-B7F4-000A95BD86C0@mnot.net> <40E59276.9030609@dehora.net> <27C3E61C-CCAF-11D8-B7F4-000A95BD86C0@mnot.net> <58E465B4-CCFD-11D8-BA50-000A95A51C9E@sun.com> <3C16EE15-CD1B-11D8-A3E7-000A95CCC59E@xegesis.org> <15A0CA58-CD22-11D8-BA50-000A95A51C9E@sun.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <6497E842-CD33-11D8-A3E7-000A95CCC59E@xegesis.org>
Content-Transfer-Encoding: 7bit
From: Michael Champion <mc@xegesis.org>
Subject: Re: PaceNoInfoSet
Date: Sat, 3 Jul 2004 16:56:02 -0400
To: Atom Syntax <atom-syntax@imc.org>
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>
Content-Transfer-Encoding: 7bit



On Jul 3, 2004, at 2:52 PM, Tim Bray wrote:

>
>  Whether you want to call that a "logical structure" or a "syntax" 
> doesn't seem that big a deal... but I lean in favor of syntax because 
> interoperation, in particular across a network, takes place at the 
> level of syntax.

OK, no big deal, we're talking about the same thing I guess -- the 
allowed elements and attributes, and where they can appear.

>
> The reason the specification exists is to support programmers in 
> building software which interoperates across the network.  All they 
> can be sure of is that they will get messages which are XML 1.0 
> documents and whose syntax is constrained in a way that's conveniently 
> described using the Infoset.  The logical model they choose to 
> construct inside their software to deal with this is none of our 
> concern, and if it looks totally unlike the XML Infoset, that's fine 
> and we shouldn't give anyone help in claiming that it isn't.  -Tim
>

Well, as far as I'm concerned someone querying an XQuery-enabled DBMS 
for Atom entries is "building software which interoperates across the 
network" and I (albeit with a certain amount of day-job bias) think of 
this as a reasonable use case for Atom.  I don't want to belabor the 
point because there is a close enogh correspondence between XML "bits 
on the wire" and the data model of XPath/XQuery and I can't imagine how 
your proposed language in the Atom spec would get in the way of that in 
the real world.  Still, as a way of aligning Atom with the range of XML 
specs that are in wide use, especially XPath/XSLT/XQuery, I would 
prefer a neutral statement such as Mark proposed rather than an 
explicit statement that Atom is *only* a bits on the wire syntax.



From owner-atom-syntax@mail.imc.org  Sat Jul  3 17:09: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 RAA22093
	for <atompub-archive@lists.ietf.org>; Sat, 3 Jul 2004 17:09: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 i63Ktvn8038349;
	Sat, 3 Jul 2004 13: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 i63KtvLW038348;
	Sat, 3 Jul 2004 13:55:57 -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 i63KtuFb038334
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 13:55:56 -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 i63Ktr53019650
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 15:55:53 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i63KtqER019646;
	Sat, 3 Jul 2004 15:55:52 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceSimpleResourcePosting and PUT
References: <opsairy6o1uvpchu@quark> <40E64BA6.5070402@aol.net>
	<opsakursqruvpchu@quark>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 03 Jul 2004 15:55:52 -0500
In-Reply-To: <opsakursqruvpchu@quark>
Message-ID: <m3u0wostd3.fsf@bitsko.slc.ut.us>
Lines: 29
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 i63KtuFb038341
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 <asbjorn@tigerstaden.no> writes:

> On Fri, 02 Jul 2004 23:01:10 -0700, John Panzer <jpanzer@aol.net> wrote:
> 
> > That is, CGI scripts may not be able to field HTTP requests unless
> > the URIs in the HTTP requests include "/cgi-bin/scriptname" or
> > similar; so, they can't field PUTs to arbitrary URIs.
> 
> Those servers probably exist, yes. It's stupid, because most of
> these servers are probably Apache with .htaccess possibilities where
> you can do rewrite.

There seems to be some confusion here about "any random URL on a host"
and the URL space Atom publishing systems expose -- and it has
*nothing* to do with POST, PUT and DELETE or URL rewriting.

PUT and DELETE work anywhere that POST does.

If you're talking about a random URL on a host and wondering if Atom
allows you to PUT/DELETE there, ask yourself the question, "can I POST
there?"  If not, it's probably not a CGI or a server module, it's a
read-only location served by the web server internally -- so it just
doesn't matter whether it supports PUT, DELETE, *or* POST.

URL rewriting is an orthogonal feature, relevant only from the
perspective of someone who wants to map some URL space on the server
to a CGI or module that supports the Atom protocol.

  -- Ken



From owner-atom-syntax@mail.imc.org  Sat Jul  3 18: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 SAA24452
	for <atompub-archive@lists.ietf.org>; Sat, 3 Jul 2004 18: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 i63LioDF040443;
	Sat, 3 Jul 2004 14:44: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 i63Lioa3040442;
	Sat, 3 Jul 2004 14:44: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.203])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i63Linea040434
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 14:44:50 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id 55so18215rni
        for <atom-syntax@imc.org>; Sat, 03 Jul 2004 14:44:33 -0700 (PDT)
Received: by 10.38.71.6 with SMTP id t6mr230814rna;
        Sat, 03 Jul 2004 14:44:33 -0700 (PDT)
Message-ID: <14be96d304070314444314e110@mail.gmail.com>
Date: Sat, 3 Jul 2004 17:44:33 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Withdrawn: PaceShouldBeWellFormed
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


http://intertwingly.net/wiki/pie/PaceShouldBeWellFormed

After careful consideration and discussion with the author of RFC 3023
and others on this list, I am withdrawing this proposal. It is
inappropriate for Atom to redefine the behavior of a media type that
isn't ours. Apache has fixed their problem (latest version of 1.3 and
2.0 now default to "application/xml" for .xml files), so this mess
will sort itself out in five to ten years. If you can't live with
XML's rules in the meantime, then you shouldn't have chosen XML.

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Sat Jul  3 18: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 SAA25935
	for <atompub-archive@lists.ietf.org>; Sat, 3 Jul 2004 18: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 i63MBs02041296;
	Sat, 3 Jul 2004 15:11: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 i63MBsVo041295;
	Sat, 3 Jul 2004 15:11:54 -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 i63MBrLm041288
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 15:11:53 -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 i63MBr53020547
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 17:11:53 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i63MBqq7020543;
	Sat, 3 Jul 2004 17:11:52 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceSimpleResourcePosting and PUT
References: <opsairy6o1uvpchu@quark> <40E597FF.8020808@aol.net>
	<opsai5d4uouvpchu@quark>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 03 Jul 2004 17:11:52 -0500
In-Reply-To: <opsai5d4uouvpchu@quark>
Message-ID: <m3oemwspuf.fsf@bitsko.slc.ut.us>
Lines: 17
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 i63MBsLm041290
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 <asbjorn@tigerstaden.no> writes:

> On Fri, 02 Jul 2004 10:14:39 -0700, John Panzer <jpanzer@aol.net> wrote:
> > So my first question is, is this supportable by all Atom-enabled
> > servers?
> 
> I haven't read any requirements list for what it takes to be an
> Atom-enabled server, but I would say that one of the requirements
> SHOULD be to accept PUT and DELETE.

Atom API today is MUST support POST/GET/PUT/DELETE and SHOULD support
the SOAP fallback that uses only POST/GET.

The support is not for the benefit of servers but for some client
libraries that do not have solid support for PUT/DELETE.

  -- Ken



From owner-atom-syntax@mail.imc.org  Sat Jul  3 18:28:29 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26058
	for <atompub-archive@lists.ietf.org>; Sat, 3 Jul 2004 18:28:28 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i63MFJoN041411;
	Sat, 3 Jul 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 i63MFJZ6041410;
	Sat, 3 Jul 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 (mproxy.gmail.com [216.239.56.251])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i63MFI8O041404
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 15:15:18 -0700 (PDT)
	(envelope-from rtomayko@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so1093227cwc
        for <atom-syntax@imc.org>; Sat, 03 Jul 2004 15:15:23 -0700 (PDT)
Received: by 10.11.118.71 with SMTP id q71mr209428cwc;
        Sat, 03 Jul 2004 15:15:23 -0700 (PDT)
Message-ID: <f732822d04070315154ffe4dbd@mail.gmail.com>
Date: Sat, 3 Jul 2004 18:15:23 -0400
From: Ryan Tomayko <rtomayko@gmail.com>
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceSimpleResourcePosting and PUT
Cc: John Panzer <jpanzer@aol.net>, "Asbjørn Ulsberg" <asbjorn@tigerstaden.no>
In-Reply-To: <40E70539.70504@aol.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <opsairy6o1uvpchu@quark> <40E64BA6.5070402@aol.net> <f732822d0407030053186491b6@mail.gmail.com> <40E70539.70504@aol.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


Ahh, I see. 

So, you could PUT to the following:

http://example.com/cgi-bin/resource.pl/mypictures/cat.jpg

But having "cgi-bin/resource.pl/" in the URI is annoying and limits
where things can be PUT..

Thanks,
Ryan

----- Original Message -----
From: John Panzer <jpanzer@aol.net>
[snip]
I totally agree with you; I was just using the query parameter version
to make the point that the server needs to be able to control the
format of the URI.  This is still the case even if you use PATH_INFO. 
That is, clients cannot necessarily be allowed to say "put my cat
picture at http://example.com/mypictures/cat.jpg" because a server may
not be able to map that URI to a CGI script.  The URI in some servers
has to start with the path /cgi-bin/. I am imagining here a hosted
environment in which URIs to CGI scripts have to have this form, and
where the person running an Atom service can't remap URIs, etc.  Does
that make sense?

At least, such is my understanding of the situation (and of one hosting
provider that I actually use).  

John



From owner-atom-syntax@mail.imc.org  Sat Jul  3 18:39: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 SAA26404
	for <atompub-archive@lists.ietf.org>; Sat, 3 Jul 2004 18: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 i63MQEUm041765;
	Sat, 3 Jul 2004 15:26:14 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i63MQEPo041764;
	Sat, 3 Jul 2004 15:26:14 -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 i63MQCvH041758
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 15:26:13 -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 i63MQC53020704
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 17:26:12 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i63MQCK9020700;
	Sat, 3 Jul 2004 17:26:12 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceSimpleResourcePosting and PUT
References: <opsairy6o1uvpchu@quark> <40E64BA6.5070402@aol.net>
	<f732822d0407030053186491b6@mail.gmail.com> <40E70539.70504@aol.net>
	<f732822d04070315154ffe4dbd@mail.gmail.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 03 Jul 2004 17:26:12 -0500
In-Reply-To: <f732822d04070315154ffe4dbd@mail.gmail.com>
Message-ID: <m3k6xksp6j.fsf@bitsko.slc.ut.us>
Lines: 6
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: <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've added a PUT/DELETE FAQ to the wiki that I hope summarizes all the
discussion in this thread and previous threads.

    http://intertwingly.net/wiki/pie/PutDeleteFaq

  -- Ken



From owner-atom-syntax@mail.imc.org  Sat Jul  3 20:04: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 UAA29515
	for <atompub-archive@lists.ietf.org>; Sat, 3 Jul 2004 20:04: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 i63NohwX044998;
	Sat, 3 Jul 2004 16:50:43 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i63Nohmj044997;
	Sat, 3 Jul 2004 16:50:43 -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 i63NohTv044990
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 16:50:43 -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 i63Noh403587
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 16:50:43 -0700 (PDT)
Received: from aol.net ([10.169.192.24]) by judge.mcom.com
          (Netscape Messaging Server 4.15) with ESMTP id I0AVKI01.T16;
          Sat, 3 Jul 2004 16:50:42 -0700 
Message-ID: <40E74650.2020100@aol.net>
Date: Sat, 03 Jul 2004 16:50:40 -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: Ken MacLeod <ken@bitsko.slc.ut.us>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceSimpleResourcePosting and PUT
References: <opsairy6o1uvpchu@quark> <40E64BA6.5070402@aol.net>	<f732822d0407030053186491b6@mail.gmail.com> <40E70539.70504@aol.net>	<f732822d04070315154ffe4dbd@mail.gmail.com> <m3k6xksp6j.fsf@bitsko.slc.ut.us>
In-Reply-To: <m3k6xksp6j.fsf@bitsko.slc.ut.us>
Content-Type: multipart/alternative;
 boundary="------------030705030009000009000607"
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>


This is a multi-part message in MIME format.
--------------030705030009000009000607
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Ken MacLeod wrote:

>I've added a PUT/DELETE FAQ to the wiki that I hope summarizes all the
>discussion in this thread and previous threads.
>
>    http://intertwingly.net/wiki/pie/PutDeleteFaq
>
>  -- Ken
>
>  
>
Looks good; one minor nit and a question:

>
>     I have a URL '/image/kitten.jpg', can it support PUT/DELETE?
>
> You can't PUT or DELETE, or POST for that matter, to arbitrary 
> locations on the server. Atom editable resources must be at URL 
> locations where a CGI, server module, or server page can respond to them.
>
Should this read "You can't necessarily PUT or DELETE ... to arbitrary 
locations on the server."? That is, there exist servers which do support 
this and also servers that don't support this (as described further down).

>
>     Can I use the OPTIONS method to an Apache server to see if
>     PUT/DELETE are supported?
>
> Apache does not let a CGI program the OPTIONS method (by default?), so 
> it would require additional configuration privileges to change the 
> list of supported methods returned by OPTIONS.
>
> Apache server modules can respond to OPTIONS methods.
>
> At this time, in Atom, if you are provided an EditURI you take that as 
> an indication that PUT/DELETE are supported on that URI.
>
> "...HTTP/1.1 does not require that OPTIONS responses be truthful." -- 
> Roy Fielding <http://archive.apache.org/gnats/378>
>
 From my reading of the RFCs, clients can also use HEAD (and for that 
matter, GET) and look at the Allow: response header the server returns.  
If no header exists, the default allowed methods are HEAD and GET.   If 
the header does exist, it should give the same information it would have 
given for OPTIONS.  So I'm assuming that clients can use HEAD as a 
workaround; is this a valid assumption?  Am I reading the standards 
correctly?

(OK, one other nit:  If you have a NonEntryResource, I don't think you 
don't have an EditURI for it, as defined in the Atom spec.  So I assume 
that the above applies only to Entry resources.)

-John

--------------030705030009000009000607
Content-Type: multipart/related;
 boundary="------------060307050104080200090609"


--------------060307050104080200090609
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Ken MacLeod wrote:<br>
<blockquote cite="midm3k6xksp6j.fsf@bitsko.slc.ut.us" type="cite">
  <pre wrap="">I've added a PUT/DELETE FAQ to the wiki that I hope summarizes all the
discussion in this thread and previous threads.

    <a class="moz-txt-link-freetext" href="http://intertwingly.net/wiki/pie/PutDeleteFaq">http://intertwingly.net/wiki/pie/PutDeleteFaq</a>

  -- Ken

  </pre>
</blockquote>
Looks good; one minor nit and a question:<br>
<blockquote type="cite">
  <h2 id="head-0ed444797dccfe05712279c902abfefbb5bb61af">I have a URL
'/image/kitten.jpg', can it support PUT/DELETE?</h2>
  <p>
You can't PUT or DELETE, or POST for that matter, to arbitrary
locations on the server. Atom editable resources must be at URL
locations where a CGI, server module, or server page can respond to
them. </p>
</blockquote>
Should this read "You can't necessarily PUT or DELETE ... to arbitrary
locations on the server."? That is, there exist servers which do
support this and also servers that don't support this (as described
further down).<br>
<blockquote type="cite">
  <h2 id="head-7d6b15cf9a0d15702fccd0dfa87be4d2bb79d1c3">Can I use the
OPTIONS method to an Apache server to see if PUT/DELETE are supported?</h2>
  <p>
Apache does not let a CGI program the OPTIONS method (by default?), so
it would require additional configuration privileges to change the list
of supported methods returned by OPTIONS. </p>
  <p>
Apache server modules can respond to OPTIONS methods. </p>
  <p>
At this time, in Atom, if you are provided an EditURI you take that as
an indication that PUT/DELETE are supported on that URI. </p>
  <p>
"...HTTP/1.1 does not require that OPTIONS responses be truthful." -- <a
 class="external" href="http://archive.apache.org/gnats/378"><img
 src="cid:part1.03050909.07030607@aol.net" alt="[WWW]" height="11"
 width="11">Roy Fielding</a> </p>
</blockquote>
From my reading of the RFCs, clients can also use HEAD (and for that
matter, GET) and look at the Allow: response header the server
returns.&nbsp; If no header exists, the default allowed methods are HEAD and
GET.&nbsp;&nbsp; If the header does exist, it should give the same information it
would have given for OPTIONS.&nbsp; So I'm assuming that clients can use
HEAD as a workaround; is this a valid assumption?&nbsp; Am I reading the
standards correctly?<br>
<br>
(OK, one other nit:&nbsp; If you have a NonEntryResource, I don't think you
don't have an EditURI for it, as defined in the Atom spec.&nbsp; So I assume
that the above applies only to Entry resources.)<br>
<br>
-John<br>
</body>
</html>

--------------060307050104080200090609
Content-Type: image/png;
 name="moin-www.png"
Content-ID: <part1.03050909.07030607@aol.net>
Content-Disposition: inline;
 filename="moin-www.png"
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAAAsAAAALAgMAAADUwp+1AAAACVBMVEUA/wC/v78AAP+0MGAC
AAAAAnRSTlP/AOW3MEoAAAABYktHRAJmC3xkAAAALUlEQVR42mMIZQgBwikMEUxLGLIUVjBk
aS1gyGKA4CigWFjXFIbQVSEMoaEhAPFLC8/vqdQnAAAAAElFTkSuQmCC
--------------060307050104080200090609--

--------------030705030009000009000607--



From owner-atom-syntax@mail.imc.org  Sat Jul  3 20:44: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 UAA01228
	for <atompub-archive@lists.ietf.org>; Sat, 3 Jul 2004 20:43: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 i640Tbeu047627;
	Sat, 3 Jul 2004 17: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 i640Tbn7047626;
	Sat, 3 Jul 2004 17:29:37 -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 i640Talj047620
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 17:29:36 -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 i640Ta404658
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 17:29:36 -0700 (PDT)
Received: from aol.net ([10.169.192.24]) by judge.mcom.com
          (Netscape Messaging Server 4.15) with ESMTP id I0AXDB00.Y0X;
          Sat, 3 Jul 2004 17:29:35 -0700 
Message-ID: <40E74F6F.2060507@aol.net>
Date: Sat, 03 Jul 2004 17:29:35 -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: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceSimpleResourcePosting and PUT
References: <opsairy6o1uvpchu@quark> <40E597FF.8020808@aol.net> <opsai5d4uouvpchu@quark> <40E64A34.5060406@aol.net> <opsakspewuuvpchu@quark>
In-Reply-To: <opsakspewuuvpchu@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 Fri, 02 Jul 2004 22:55:00 -0700, John Panzer <jpanzer@aol.net> wrote:
>
>> I don't think anyone assumes that you can implement Atom without at  
>> least the equivalent of CGI scripts. :)
>
>
> That depends on what part of Atom you're talking about. The format, 
> and  the correct serving of it, should be able to be implemented by 
> Bob which  is an unprivileged user[1]. The API, however, is impossible 
> to implement  on a standard Apache or IIS web server.

Why?  (If it's already a nongoal to implement the API using 
non-priviledged scripts, great.  I hadn't heard that.)

> What would be fun, though, is if  the Atom API was possible to support 
> just by installing existing WebDAV  services for the operating system 
> of your choice.
>
>> I have a URI like this: http://example.org/resources/mycat.jpg.  When
>> I do a GET on this URI, I retrieve the image/jpeg data.  When I do a
>> PUT to this URI, I replace the image/jpeg data.  When I DELETE the
>> URI, I delete the image/jpeg data.
>
>
> Yes. And as the current Atom API is defined, you would use POST to 
> create  assign 'mycat.jpg' an URI and initially create it.
>
Ah, but the context of this discussion is about non-entry resources.  
Which have a special twist that make them slightly different from 
entries -- see below.  (But yes, I agree regarding the POST mechanism -- 
for example, see PaceSimpleResourcePosting).
...

>
>> Some Atom implementations may need to use URIs like
>> http://example.org/cgi-bin/resources?name=mycat.jpg, so that their 
>> CGI  scripts can get control on HEAD, GET, PUT, and DELETE.
>
>
> That shouldn't be necessary if you can use something like .htaccess 
> on  Apache, or have nice administrators on IIS with ASP.NET. The 
> problem is  that if people somehow can't do rewrite, they would most 
> likely want to  serve the resources for GETs as 
> 'http://example.org/resources/mycat.jpg'  but for all the other verbs  
> 'http://example.org/cgi-bin/resources?name=mycat.jpg'.
>
> This splits the resource in half, kind of, because it is accessible 
> from  two different URI's. And not that each URI is equal; no, you can 
> only use  one for GET and the other for PUT and DELETE (for POST, 
> you'd use a  totally separate URI anyway).

Ah, this is the crux of the matter.  The impetus for this discussion is 
non entry resources (PaceNonEntryResources/PaceSimpleResourcePosting).  
I think that non entry resources in these proposals _require_ that a 
single URI be used for all possible methods after creation (GET, PUT, 
DELETE, say).  Here's why:

One of the main use cases is to be able to post an Atom entry which, as 
its XHTML content, has the following fragment:

<img src="http://example.com/myblog/resources/cat1.jpg" align="right"/>A 
picture of Fluffy!<br/>

Note that nowhere else in the universe is there a reference to 
http://example.com/myblog/resources/cat1.jpg, at least when it's first 
uploaded.  (And for cat pictures, let's face it, do we really want more 
references?)  Well, a client could of course keep track of it locally, 
but let's say it doesn't. 

Suppose I want to update the picture of Fluffy with a better version 
(fixed redeye) a day later.  How do I do this?  Well, first I need to 
retrieve the entry with my Atom client; this gives me the XHTML in a 
WSYWIG editor.  Then I presumably drag and drop the fixed picture on top 
of the old one, and the client notes that I've updated the content.  
Then I save the entry.  My client _may_ be smart enough to do a PUT of 
the new content to http://example.com/myblog/resources/cat1.jpg instead 
of a POST to create yet another picture.  Since it only has the GETtable 
URI for the resource at hand, the simplest thing is for that URI to 
support PUT as well.  If it doesn't, how do we get a URI that _does_ 
support PUT?  Specify yet another introspection API?

The current Atom introspection mechanisms for entries do not work for 
this case.  To start with, you can have any number of non-entry 
resources associated with an entry:

<p><img src="http://example.com/myblog/resources/cat1.jpg" 
align="right"/>A picture of Fluffy!</p>
<p><img src="http://example.com/myblog/resources/cat2.jpg" 
align="right"/>A picture of Buffy!</p>
...

But you only have one service.edit URI associated with an entry. So 
there's a cardinality problem at the very least. :)

This all assumes that we want to be able to create clients that attempt 
to deal with compound documents intelligently (not that Atom should 
require such clients, but I think it should _allow_ them; we certainly 
plan to work on such clients, and we want to use Atom wherever 
possible).  That is, I don't think that users should be forced to manage 
the URIs of their cat pictures manually.  I think that intelligent 
clients can help with the management a lot, given just standard linking 
constructs such as <img src>.

>
>> This is actually important to the context of both  
>> PaceSimpleResourcePosting and PaceNonEntryResources, because both 
>> assume  that you can take a single URI and use it for both simple 
>> GETs (e.g.,  when using an XHTML img[@src]) and for any subsequent 
>> PUTs or DELETEs.
>
>
> Yes.
>
>> If that assumption works for even CGI-limited servers, I think  
>> everything would be fine.  If not, then the two Paces above might 
>> have  some issues.
>
>
> As the API offers 'service.edit' URI's, I don't think this is a big  
> problem. This URI can be something different for PUT than it is for 
> GET.  It's not very REST-ish or intuitive, but it works for 
> rewrite-disabled  people and servers.

Note that we're not talking about entries in this context, we're talking 
about non-entry resources and there is no service.edit URI that points 
at any of them (at least under 
PaceNonEntryResources/PaceSimpleResourcePosting). 

-John



From owner-atom-syntax@mail.imc.org  Sat Jul  3 21:09: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 VAA02100
	for <atompub-archive@lists.ietf.org>; Sat, 3 Jul 2004 21:09:42 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i640ttRD048665;
	Sat, 3 Jul 2004 17:55: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 i640ttpn048664;
	Sat, 3 Jul 2004 17:55:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from xanthus.host4u.net (xanthus.host4u.net [216.71.64.130])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i640tsaA048656
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 17:55:54 -0700 (PDT)
	(envelope-from paul@paulbaranowski.org)
Received: from [127.0.0.1] (static-80-97.dsl.cuic.ca [216.126.80.97] (may be forged))
	by xanthus.host4u.net (8.11.6/8.11.6) with ESMTP id i640tsM21158
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 19:55:54 -0500
Message-ID: <40E75594.30206@paulbaranowski.org>
Date: Sat, 03 Jul 2004 20:55:48 -0400
From: Paul Baranowski <paul@paulbaranowski.org>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: atom-syntax@imc.org
Subject: Atom 0.3 Spec Confusion - atom:link & atom:id
X-Enigmail-Version: 0.84.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
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


Sorry if this isnt the correct mailing list, please tell me where to 
direct my questions if I am in the wrong place...

You've probably heard this already, but here are some things I found 
confusing about the Atom 0.3 spec:

atom:feed --> atom:link - specifies that "atom:feed elements MUST 
contain at least one atom:link element with a rel attribute value of 
"alternate".".  This is confusing because the word "alternate" can be 
used to convey different things here.  What is the context for this 
word?  Does "alternate" mean "the link specified is the location of this 
feed"?  Or does alternate mean "an alternative location where you can 
get this feed if the other link given is currently not available" 
(assuming there was another "link" element specified, without the 
"alternate" attribute).  Or does it mean something else entirely?

atom:feed --> atom:entry --> atom:id - Does not specify whether it is 
required or not!  (Is it?)

Thanks for your time, I look forward to your thoughts on this...

- Paul Baranowski
paul@paulbaranowski.org






From owner-atom-syntax@mail.imc.org  Sat Jul  3 23:26: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 XAA06771
	for <atompub-archive@lists.ietf.org>; Sat, 3 Jul 2004 23:26: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 i6438k5H054568;
	Sat, 3 Jul 2004 20:08: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 i6438kU1054567;
	Sat, 3 Jul 2004 20:08: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 i6438hAw054541
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 20:08:45 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 4 Jul 2004 13:13:06 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sun, 04 Jul 2004 13:08:14 +1000
Subject: Re: Atom 0.3 Spec Confusion - atom:link & atom:id
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD0DB1BE.1D269%eric.scheid@ironclad.net.au>
In-Reply-To: <40E75594.30206@paulbaranowski.org>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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 4/7/04 10:55 AM, "Paul Baranowski" <paul@paulbaranowski.org> wrote:

> atom:feed --> atom:link - specifies that "atom:feed elements MUST
> contain at least one atom:link element with a rel attribute value of
> "alternate".".  This is confusing because the word "alternate" can be
> used to convey different things here.  What is the context for this
> word?  

IIRC, I think it is meant to be the flip version of the auto-discovery
alternate link found at the web page for the feed. That is, the feed is the
alternate to the web page, and the web page is the alternate of the feed.

Thus:

    http://example.com/blog.html
        'alternate' --> feed.atom

    http://example.com/feed.atom
        'alternate' --> blog.html

This is a little bit confusing, since (IIRC) the auto-discovery spec talks
of using 'alternate' to find the feed, and what we have here "looks" like an
auto-discovery link, but isn't (?)

> Does "alternate" mean "the link specified is the location of this
> feed"?  

 From memory, link/[@rel="service.feed"] would specify that. It would be nice
to have that required in the feed (for one-click subscriptions mechanisms).

I note in passing that some blogspot templates use 'service.feed' instead of
'alternate', which defeats NNW's auto-discovery mechanism :-(

> Or does alternate mean "an alternative location where you can
> get this feed if the other link given is currently not available"

probably not.



From owner-atom-syntax@mail.imc.org  Sun Jul  4 00:42: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 AAA09844
	for <atompub-archive@lists.ietf.org>; Sun, 4 Jul 2004 00:42: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 i644NoKk059773;
	Sat, 3 Jul 2004 21:23: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 i644NoZJ059772;
	Sat, 3 Jul 2004 21:23: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 (mproxy.gmail.com [216.239.56.240])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i644Nocd059761
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 21:23:50 -0700 (PDT)
	(envelope-from rtomayko@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so1330854cwc
        for <atom-syntax@imc.org>; Sat, 03 Jul 2004 21:23:52 -0700 (PDT)
Received: by 10.11.118.71 with SMTP id q71mr227554cwc;
        Sat, 03 Jul 2004 21:23:52 -0700 (PDT)
Message-ID: <f732822d04070321234e100d1@mail.gmail.com>
Date: Sun, 4 Jul 2004 00:23:52 -0400
From: Ryan Tomayko <rtomayko@gmail.com>
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceXmlBaseEverywhere
Cc: Mark Nottingham <mnot@mnot.net>,
        "Asbjørn Ulsberg" <asbjorn@tigerstaden.no>
In-Reply-To: <opsakvb5t8uvpchu@quark>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
References: <BA72FC2A-CC47-11D8-B7F4-000A95BD86C0@bea.com> <327469D8-CC71-11D8-BA50-000A95A51C9E@sun.com> <20040702222446.GA16686@homer.w3.org> <CF9D211D-CC84-11D8-B7F4-000A95BD86C0@mnot.net> <opsakvb5t8uvpchu@quark>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i644Nocd059764
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, 03 Jul 2004 22:03:31 +0200, Asbjørn Ulsberg
<asbjorn@tigerstaden.no> wrote:
> But coming to think of it; how often is really 'base' used? And how often
> is it realisticly to assume it will be used in Atom? Is the base going to
> change for each and every element in the feed? Is there any aggregator in
> existance that could cope with something like this:

I think so. I've always thought about xml:base much like I think about
xml namespaces. Would you consider specifying where in an atom
document namespaces can be defined?

In fact, I was under the impression that "supporting xml:base" meant
supporting it everywhere in a document. I didn't know it was legal to
support it only on certain elements. Running over the recommendation
[1] quickly doesn't seem to confirm or reject this point of view. Does
anyone know for sure whether it is legal to use xml:base only on
specific elements?

Also, I must be misunderstanding how "infrastructure to apply XML Base
for you" is perceived to work. Processors that support xml:base
natively (libxml2 for example) make obtaining the base URI for a given
element trivial and, to my knowledge, assume xml:base everywhere. But
all these processors do is keep track of the base URI, they do not
actually change any data in the document. It makes the base URI for
any element available so that it may be retrieved by the application.
I get the feeling we're expecting some infrastructure to automatically
"absolutize" URIs for us. I'm not sure I've ever seen a tool capable
of that because it would require a schema or some other augmentation
to specify which items in a document are URIs. Processors make the
base URI available given an element, it's the role of the code
resolving the URI to use this information when retrieving URIs.

I would also like to note that I've implemented xml:base generically
on top of SAX, Pull, and DOM based parsers without much trouble. The
only time I've had real problems with xml:base is within XSLT and
there only because there is no standard way of resolving URIs relative
to a base URI.

Ryan

[1] http://www.w3.org/TR/xmlbase/



From owner-atom-syntax@mail.imc.org  Sun Jul  4 01:08: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 BAA10449
	for <atompub-archive@lists.ietf.org>; Sun, 4 Jul 2004 01:08: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 i644sv0R060774;
	Sat, 3 Jul 2004 21:54: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 i644svKF060773;
	Sat, 3 Jul 2004 21:54:57 -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 (mproxy.gmail.com [216.239.56.243])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i644svaq060767
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 21:54:57 -0700 (PDT)
	(envelope-from rtomayko@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so1353101cwc
        for <atom-syntax@imc.org>; Sat, 03 Jul 2004 21:55:04 -0700 (PDT)
Received: by 10.11.116.72 with SMTP id o72mr233621cwc;
        Sat, 03 Jul 2004 21:55:03 -0700 (PDT)
Message-ID: <f732822d040703215577bcddb3@mail.gmail.com>
Date: Sun, 4 Jul 2004 00:55:03 -0400
From: Ryan Tomayko <rtomayko@gmail.com>
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceSimpleResourcePosting and PUT
Cc: Ken MacLeod <ken@bitsko.slc.ut.us>
In-Reply-To: <m3k6xksp6j.fsf@bitsko.slc.ut.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <opsairy6o1uvpchu@quark> <40E64BA6.5070402@aol.net>
	<f732822d0407030053186491b6@mail.gmail.com> <40E70539.70504@aol.net>
	<f732822d04070315154ffe4dbd@mail.gmail.com> <m3k6xksp6j.fsf@bitsko.slc.ut.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 03 Jul 2004 17:26:12 -0500, Ken MacLeod <ken@bitsko.slc.ut.us> wrote:
> 
> I've added a PUT/DELETE FAQ to the wiki that I hope summarizes all the
> discussion in this thread and previous threads.
> 
>     http://intertwingly.net/wiki/pie/PutDeleteFaq

Nice. This should clear up a lot of misundestanding on this topic.

I've added a bit about where the "PUT/DELETE needs WebDAV"
misconception may have come from. Feel free to refactor however you
see fit.

Ryan



From owner-atom-syntax@mail.imc.org  Sun Jul  4 02: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 CAA26021
	for <atompub-archive@lists.ietf.org>; Sun, 4 Jul 2004 02: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 i6466Xco089852;
	Sat, 3 Jul 2004 23:06: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 i6466Xeo089851;
	Sat, 3 Jul 2004 23:06:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6466WIs089802
	for <atom-syntax@imc.org>; Sat, 3 Jul 2004 23:06:32 -0700 (PDT)
	(envelope-from sjenson@google.com)
Received: from eta.corp.google.com (gpsi1.corp.google.com [10.3.0.251])
	by 216-239-45-4.google.com (8.12.11/8.12.9) with ESMTP id i6466Rsp004213
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 3 Jul 2004 23:06:27 -0700
Received: from sjenson by eta.corp.google.com with local (Exim 4.14 #4)
	id 1Bh08x-0002ly-IA by authid <sjenson>; Sat, 03 Jul 2004 23:06:27 -0700
Date: Sat, 3 Jul 2004 23:06:27 -0700
From: steve jenson <stevej@google.com>
To: eric.scheid@ironclad.net.au
Cc: atom-syntax@imc.org
Subject: RE: Atom 0.3 Spec Confusion - atom:link & atom:id
Message-ID: <20040704060620.GA10097@google.com>
Reply-To: stevej@google.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i
X-Sender: stevej@google.com
X-Subliminal: you are getting very sleepy
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>



> > Does "alternate" mean "the link specified is the location of this
> > feed"?
>
> From memory, link/[@rel="service.feed"] would specify that. It would be nice
> to have that required in the feed (for one-click subscriptions mechanisms).

service.feed means that if you query it as a Atom API FeedURI resource
(i.e. with a GET and with your credentials) you'll get back a feed of entries
so you can navigate to the entry you want to edit (and query that entry's
service.edit rel or EditURI). It's not the feed that we subscribe to in our
aggregators (so I expect this to become "this isn't 'subscribable' so don't
call it <feed>, part deux")

http://bitworking.org/projects/atom/draft-gregorio-09.html#FeedURI

> I note in passing that some blogspot templates use 'service.feed' instead of
> 'alternate', which defeats NNW's auto-discovery mechanism :-(

Yes, this has broken somehow. I'll get a fix in for it this week. All Blogger
blogs created since January should have service.feed, service.post, and
alternate links.


Thank you for the note,
-steve



From owner-atom-syntax@mail.imc.org  Sun Jul  4 05:01: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 FAA01661
	for <atompub-archive@lists.ietf.org>; Sun, 4 Jul 2004 05:01: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 i648j6Kk044346;
	Sun, 4 Jul 2004 01:45:06 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i648j6gX044345;
	Sun, 4 Jul 2004 01:45: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 (imap.gmx.net [213.165.64.20])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i648j4hV044270
	for <atom-syntax@imc.org>; Sun, 4 Jul 2004 01:45:05 -0700 (PDT)
	(envelope-from julian.reschke@gmx.de)
Received: (qmail 25606 invoked by uid 65534); 4 Jul 2004 08:44:54 -0000
Received: from pD9535E0F.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.94.15)
  by mail.gmx.net (mp015) with SMTP; 04 Jul 2004 10:44:54 +0200
X-Authenticated: #1915285
Message-ID: <40E7C381.5020109@gmx.de>
Date: Sun, 04 Jul 2004 10:44:49 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: John Panzer <jpanzer@aol.net>
CC: Ken MacLeod <ken@bitsko.slc.ut.us>, Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceSimpleResourcePosting and PUT
References: <opsairy6o1uvpchu@quark> <40E64BA6.5070402@aol.net>	<f732822d0407030053186491b6@mail.gmail.com> <40E70539.70504@aol.net>	<f732822d04070315154ffe4dbd@mail.gmail.com> <m3k6xksp6j.fsf@bitsko.slc.ut.us> <40E74650.2020100@aol.net>
In-Reply-To: <40E74650.2020100@aol.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


John Panzer wrote:

>  >From my reading of the RFCs, clients can also use HEAD (and for that 
> matter, GET) and look at the Allow: response header the server returns.  
> If no header exists, the default allowed methods are HEAD and GET.   If 
> the header does exist, it should give the same information it would have 
> given for OPTIONS.  So I'm assuming that clients can use HEAD as a 
> workaround; is this a valid assumption?  Am I reading the standards 
> correctly?

Well, only if you do it as workaround, that is: try OPTIONS first then 
do HEAD as a last resort. We can't require all servers to return 
"Allow:" headers upon HEAD just because their support for OPTIONS is 
broken. BTW: note that with a complex server supporting WebDAV ACL and 
DeltaV, computing the set of allowed methods may be quite complex and 
certainly isn't something you want to do for each single HEAD request.

Anyway, the simplest way to discover support for PUT is to do the PUT 
request and to look at the HTTP response code. If it's 405, the PUT 
method is not supported for that resource (and a compliant server *then* 
will send an "Allow:" header with the names of supported methods).

 > ...

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From owner-atom-syntax@mail.imc.org  Sun Jul  4 05:21:48 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02645
	for <atompub-archive@lists.ietf.org>; Sun, 4 Jul 2004 05:21:48 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6494Zgi051008;
	Sun, 4 Jul 2004 02:04: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 i6494Zlq051007;
	Sun, 4 Jul 2004 02:04:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (pop.gmx.de [213.165.64.20])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6494Xqu050965
	for <atom-syntax@imc.org>; Sun, 4 Jul 2004 02:04:34 -0700 (PDT)
	(envelope-from julian.reschke@gmx.de)
Received: (qmail 15065 invoked by uid 65534); 4 Jul 2004 09:04:28 -0000
Received: from pD9535E0F.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.94.15)
  by mail.gmx.net (mp025) with SMTP; 04 Jul 2004 11:04:28 +0200
X-Authenticated: #1915285
Message-ID: <40E7C816.1040404@gmx.de>
Date: Sun, 04 Jul 2004 11:04:22 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Atom-Syntax <atom-syntax@imc.org>
CC: John Panzer <jpanzer@aol.net>, Ken MacLeod <ken@bitsko.slc.ut.us>
Subject: Re: PaceSimpleResourcePosting and PUT
References: <opsairy6o1uvpchu@quark> <40E64BA6.5070402@aol.net>	<f732822d0407030053186491b6@mail.gmail.com> <40E70539.70504@aol.net>	<f732822d04070315154ffe4dbd@mail.gmail.com> <m3k6xksp6j.fsf@bitsko.slc.ut.us> <40E74650.2020100@aol.net> <40E7C381.5020109@gmx.de>
In-Reply-To: <40E7C381.5020109@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:

 > ...
> Well, only if you do it as workaround, that is: try OPTIONS first then 
> do HEAD as a last resort. We can't require all servers to return 
> "Allow:" headers upon HEAD just because their support for OPTIONS is 
> broken. BTW: note that with a complex server supporting WebDAV ACL and 
> ...

This should have read: "...just because support for OPTIONS in other 
servers is broken...".

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From owner-atom-syntax@mail.imc.org  Sun Jul  4 05:48: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 FAA03501
	for <atompub-archive@lists.ietf.org>; Sun, 4 Jul 2004 05:48: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 i649VjGp060593;
	Sun, 4 Jul 2004 02:31: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 i649VjA6060592;
	Sun, 4 Jul 2004 02:31:45 -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 [212.123.84.93])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i649ViPJ060552
	for <atom-syntax@imc.org>; Sun, 4 Jul 2004 02:31:44 -0700 (PDT)
	(envelope-from danny666@virgilio.it)
Received: from virgilio.it (62.11.126.233) by mail-relay-3.tiscali.it (7.1.021.3)
        id 40D9B1FB00384807; Sun, 4 Jul 2004 11:32:39 +0200
Message-ID: <40E7CE08.7050006@virgilio.it>
Date: Sun, 04 Jul 2004 11:29:44 +0200
From: Danny Ayers <danny666@virgilio.it>
Reply-To: danny666@virgilio.it
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Baranowski <paul@paulbaranowski.org>
CC: atom-syntax@imc.org, mnot@mnot.net
Subject: Re: Atom 0.3 Spec Confusion - atom:link & atom:id
References: <40E75594.30206@paulbaranowski.org>
In-Reply-To: <40E75594.30206@paulbaranowski.org>
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


Paul Baranowski wrote:

> Sorry if this isnt the correct mailing list, please tell me where to 
> direct my questions if I am in the wrong place...


Definitely the right place.

> atom:feed --> atom:entry --> atom:id - Does not specify whether it is 
> required or not!  (Is it?)


I believe it is required, as a "MUST", the next spec draft will be 
clearer ;-)

On the other hand, I think the use of "alternate" is not good at all - I 
believe the responses you've had have been accurate, but it is a very 
confusing term.

Cheers,
Danny.

-- 

Raw
http://dannyayers.com



From owner-atom-syntax@mail.imc.org  Sun Jul  4 05:49: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 FAA03537
	for <atompub-archive@lists.ietf.org>; Sun, 4 Jul 2004 05:49: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 i649P0BY058201;
	Sun, 4 Jul 2004 02:25: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 i649P0OY058200;
	Sun, 4 Jul 2004 02:25:00 -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 [212.123.84.93])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i649OxKN058161
	for <atom-syntax@imc.org>; Sun, 4 Jul 2004 02:24:59 -0700 (PDT)
	(envelope-from danny666@virgilio.it)
Received: from virgilio.it (62.11.126.233) by mail-relay-3.tiscali.it (7.1.021.3)
        id 40D9B1FB00384496; Sun, 4 Jul 2004 11:24:59 +0200
Message-ID: <40E7CC3C.4040801@virgilio.it>
Date: Sun, 04 Jul 2004 11:22:04 +0200
From: Danny Ayers <danny666@virgilio.it>
Reply-To: danny666@virgilio.it
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mark Pilgrim <pilgrim@gmail.com>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Withdrawn: PaceShouldBeWellFormed
References: <14be96d304070314444314e110@mail.gmail.com>
In-Reply-To: <14be96d304070314444314e110@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


Mark Pilgrim wrote:

>http://intertwingly.net/wiki/pie/PaceShouldBeWellFormed
>
>After careful consideration and discussion with the author of RFC 3023
>and others on this list, I am withdrawing this proposal. It is
>inappropriate for Atom to redefine the behavior of a media type that
>isn't ours. Apache has fixed their problem (latest version of 1.3 and
>2.0 now default to "application/xml" for .xml files), so this mess
>will sort itself out in five to ten years. If you can't live with
>XML's rules in the meantime, then you shouldn't have chosen XML.
>  
>

Correct me if I'm wrong, but the only parts of this Pace which might 
conflict with RFC 3023 are sections 6.1:4:2 and 6.1:5.
I suggest this Pace stays on the table, with those parts elided. Baby, 
bathwater and all that.

Cheers,
Danny.

-- 

Raw
http://dannyayers.com



From owner-atom-syntax@mail.imc.org  Sun Jul  4 08:03:38 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08209
	for <atompub-archive@lists.ietf.org>; Sun, 4 Jul 2004 08:03:37 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i64BSWRG079864;
	Sun, 4 Jul 2004 04: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 i64BSWLQ079863;
	Sun, 4 Jul 2004 04:28: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 ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i64BSOOK079829
	for <atom-syntax@imc.org>; Sun, 4 Jul 2004 04:28: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 5737F7C120; Sun,  4 Jul 2004 14:24:17 +0200 (CEST)
Date: Sun, 04 Jul 2004 13:31:44 +0200
To: danny666@virgilio.it
Subject: Re: Atom 0.3 Spec Confusion - atom:link & atom:id
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <40E75594.30206@paulbaranowski.org> <40E7CE08.7050006@virgilio.it>
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: <opsal2a6uouvpchu@quark>
In-Reply-To: <40E7CE08.7050006@virgilio.it>
User-Agent: Opera M2/7.51 (Win32, build 3798)
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, 04 Jul 2004 11:29:44 +0200, Danny Ayers <danny666@virgilio.it>  
wrote:

>> atom:feed --> atom:entry --> atom:id - Does not specify whether it is  
>> required or not!  (Is it?)
>
> I believe it is required, as a "MUST", the next spec draft will be  
> clearer ;-)

I've created a pace to clearify it:

<url: http://www.intertwingly.net/wiki/pie/PaceEntryIdRequired>

> On the other hand, I think the use of "alternate" is not good at all - I  
> believe the responses you've had have been accurate, but it is a very  
> confusing term.

I agree.

-- 
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 Jul  4 08: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 IAA10030
	for <atompub-archive@lists.ietf.org>; Sun, 4 Jul 2004 08: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 i64CMiiC083986;
	Sun, 4 Jul 2004 05:22:44 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i64CMins083983;
	Sun, 4 Jul 2004 05:22: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 i64CMhWt083972
	for <atom-syntax@imc.org>; Sun, 4 Jul 2004 05: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 1DCB57C120; Sun,  4 Jul 2004 15:18:41 +0200 (CEST)
Date: Sun, 04 Jul 2004 14:26:21 +0200
To: "Ryan Tomayko" <rtomayko@gmail.com>
Subject: Re: PaceXmlBaseEverywhere
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <BA72FC2A-CC47-11D8-B7F4-000A95BD86C0@bea.com> <327469D8-CC71-11D8-BA50-000A95A51C9E@sun.com> <20040702222446.GA16686@homer.w3.org> <CF9D211D-CC84-11D8-B7F4-000A95BD86C0@mnot.net> <opsakvb5t8uvpchu@quark> <f732822d04070321234e100d1@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: <opsal4t7hnuvpchu@quark>
In-Reply-To: <f732822d04070321234e100d1@mail.gmail.com>
User-Agent: Opera M2/7.51 (Win32, build 3798)
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, 4 Jul 2004 00:23:52 -0400, Ryan Tomayko <rtomayko@gmail.com> wrote:

> I think so. I've always thought about xml:base much like I think about
> xml namespaces. Would you consider specifying where in an atom
> document namespaces can be defined?

No, of course not.

> In fact, I was under the impression that "supporting xml:base" meant
> supporting it everywhere in a document. I didn't know it was legal to
> support it only on certain elements.

Afaik (I'm no XSD champion) you need to explicitly specify on what  
elements you are to allow xml:lang, xml:base and so on in XSD. That's some  
part of the problem. So not being explicit in the specification about this  
means that we can't be explicit in XSD schemas either, which again means  
xml:base or xml:lang can't be used «everywhere».

If xml:lang and xml:base is to be used «everywhere», then this needs to go  
into the specification. I think «everywhere» is a bit too much, and think  
Content Constructs and maybe a couple of other elements are more than  
enough. But no matter what elements these attributes are allowed on, it  
needs to be stated explicitly. And the XSD needs to implement this just as  
explicitly (I presume the same goes for RNG).

> Running over the recommendation[1] quickly doesn't seem to confirm
> or reject this point of view. Does anyone know for sure whether it is
> legal to use xml:base only on specific elements?

Not including validation and XSD into the equation; yes, xml:base is  
allowed everywhere. The XML specification and its friends are independent  
of the schema languages, after all. But when you begin to talk about  
validation, you need to be more explicit.
>
> Also, I must be misunderstanding how "infrastructure to apply XML Base
> for you" is perceived to work. Processors that support xml:base
> natively (libxml2 for example) make obtaining the base URI for a given
> element trivial and, to my knowledge, assume xml:base everywhere.

Ok, cool. I have really no idea what libraries support xml:base natively.  
Could Dare tell us if System.Xml and MSXML supports xml:base natively, as  
libxml2?

> But all these processors do is keep track of the base URI, they do not
> actually change any data in the document. It makes the base URI for any
> element available so that it may be retrieved by the application.

How is the URI base retrieved? Does each node of a DOM document, or the  
context of a SAX based parser have a .base property or similar that at any  
given time contains the base of the element in scope?

> I get the feeling we're expecting some infrastructure to automatically
> "absolutize" URIs for us.

Well, that's the hard part of this, imho. Just have a look at how  
amazingly difficult this is in HTML:

<url: http://diveintomark.org/archives/2004/01/02/relative-uris>

I'm not saying it's equally hard in Atom, but it's sure hard enough. I  
think we will see a lot of xml:base-bugs in Atom implementations.

> I'm not sure I've ever seen a tool capable of that because it would
> require a schema or some other augmentation to specify which items
> in a document are URIs.

Atom will hopefully have a normative schema, but I've raised the question  
about having 'href' in no namespace at all, while having 'xml:base' in the  
XML namespace. Maybe 'xlink:href' would be more appropriate.

> Processors make the base URI available given an element, it's the role
> of the code resolving the URI to use this information when retrieving
> URIs.

Yes, I agree, but it's resolving the URI that's difficult.

> I would also like to note that I've implemented xml:base generically
> on top of SAX, Pull, and DOM based parsers without much trouble.

Maybe you could write something up on the Wiki or somewhere else on how it  
should be done? A step by step explanation of what to consider each time  
you meet a new xml:base attribute? That would have been really nice. The  
Atom specification can never have too many attached tutorials or examples.

-- 
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 Jul  4 09:05: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 JAA10958
	for <atompub-archive@lists.ietf.org>; Sun, 4 Jul 2004 09:05: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 i64CfAv8085263;
	Sun, 4 Jul 2004 05:41: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 i64CfAAX085262;
	Sun, 4 Jul 2004 05:41: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 i64Cf5ib085247
	for <atom-syntax@imc.org>; Sun, 4 Jul 2004 05:41: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 7605C7C120; Sun,  4 Jul 2004 15:37:02 +0200 (CEST)
Date: Sun, 04 Jul 2004 14:44:47 +0200
To: danny666@virgilio.it
Subject: Re: Withdrawn: PaceShouldBeWellFormed
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <14be96d304070314444314e110@mail.gmail.com> <40E7CC3C.4040801@virgilio.it>
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: <opsal5oxx5uvpchu@quark>
In-Reply-To: <40E7CC3C.4040801@virgilio.it>
User-Agent: Opera M2/7.51 (Win32, build 3798)
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, 04 Jul 2004 11:22:04 +0200, Danny Ayers <danny666@virgilio.it>  
wrote:

> I suggest this Pace stays on the table

I agree. I think we need it, seeing that IIS 6 (on Windows Server 2003)  
still serves '.xml' as 'text/xml'. I don't have much faith in seeing  
'.xml' files served as 'application/xml' on that server any time soon,  
either. An much less '.atom' files served as 'application/atom+xml'.

-- 
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 Jul  4 09:59:52 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14045
	for <atompub-archive@lists.ietf.org>; Sun, 4 Jul 2004 09:59: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 i64DXwA9095127;
	Sun, 4 Jul 2004 06:33: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 i64DXwOQ095126;
	Sun, 4 Jul 2004 06:33: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.193])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i64DXvWK095119
	for <atom-syntax@imc.org>; Sun, 4 Jul 2004 06:33:58 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d19so35956rnf
        for <atom-syntax@imc.org>; Sun, 04 Jul 2004 06:33:47 -0700 (PDT)
Received: by 10.38.81.59 with SMTP id e59mr120217rnb;
        Sun, 04 Jul 2004 06:33:46 -0700 (PDT)
Message-ID: <14be96d304070406333aa407e0@mail.gmail.com>
Date: Sun, 4 Jul 2004 09:33:46 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: "Asbjørn Ulsberg" <asbjorn@tigerstaden.no>
Subject: Re: PaceXmlBaseEverywhere
Cc: Ryan Tomayko <rtomayko@gmail.com>, Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <opsal4t7hnuvpchu@quark>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
References: <BA72FC2A-CC47-11D8-B7F4-000A95BD86C0@bea.com> <327469D8-CC71-11D8-BA50-000A95A51C9E@sun.com> <20040702222446.GA16686@homer.w3.org> <CF9D211D-CC84-11D8-B7F4-000A95BD86C0@mnot.net> <opsakvb5t8uvpchu@quark> <f732822d04070321234e100d1@mail.gmail.com> <opsal4t7hnuvpchu@quark>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i64DXwWK095121
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, 04 Jul 2004 14:26:21 +0200, Asbjørn Ulsberg
<asbjorn@tigerstaden.no> wrote:
> Well, that's the hard part of this, imho. Just have a look at how
> amazingly difficult this is in HTML:
> 
> <url: http://diveintomark.org/archives/2004/01/02/relative-uris>
> 
> I'm not saying it's equally hard in Atom, but it's sure hard enough. I
> think we will see a lot of xml:base-bugs in Atom implementations.

A bug is a test case we haven't written yet.

http://intertwingly.net/wiki/pie/ConformanceTests
http://diveintomark.org/tests/client/base/

Meanwhile, my own Universal Feed Parser passes all of these test cases:

http://feedparser.org/tests/wellformed/base/

Note that some of UFP's cases test conditions that are unsupported by
spec text, and indeed test formats which do not mention XML:Base at
all.  I do not wish to discuss what to do with such non-Atom specs,
but merely to point out that comprehensive test suites are possible.

> Maybe you could write something up on the Wiki or somewhere else on how it
> should be done? A step by step explanation of what to consider each time
> you meet a new xml:base attribute? That would have been really nice. The
> Atom specification can never have too many attached tutorials or examples.

The XML:Base specification is short and surprisingly easy to read, if
you like that sort of thing.

http://www.w3.org/TR/xmlbase/

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Sun Jul  4 10:06: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 KAA14479
	for <atompub-archive@lists.ietf.org>; Sun, 4 Jul 2004 10:06: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 i64Dn2Fe098046;
	Sun, 4 Jul 2004 06:49:02 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i64Dn2wU098045;
	Sun, 4 Jul 2004 06:49: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 i64Dn0rq098003
	for <atom-syntax@imc.org>; Sun, 4 Jul 2004 06:49: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 1DE037C120; Sun,  4 Jul 2004 16:44:58 +0200 (CEST)
To: "Mark Pilgrim" <pilgrim@gmail.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceXmlBaseEverywhere
References: <BA72FC2A-CC47-11D8-B7F4-000A95BD86C0@bea.com> <327469D8-CC71-11D8-BA50-000A95A51C9E@sun.com> <20040702222446.GA16686@homer.w3.org> <CF9D211D-CC84-11D8-B7F4-000A95BD86C0@mnot.net> <opsakvb5t8uvpchu@quark> <f732822d04070321234e100d1@mail.gmail.com> <opsal4t7hnuvpchu@quark> <14be96d304070406333aa407e0@mail.gmail.com>
Message-ID: <opsal8sxzvuvpchu@quark>
Date: Sun, 04 Jul 2004 15:51:59 +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: <14be96d304070406333aa407e0@mail.gmail.com>
User-Agent: Opera M2/7.51 (Win32, build 3798)
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, 4 Jul 2004 09:33:46 -0400, Mark Pilgrim <pilgrim@gmail.com> wrote:

> A bug is a test case we haven't written yet.

True.

> Meanwhile, my own Universal Feed Parser passes all of these test cases:
>
> http://feedparser.org/tests/wellformed/base/

Goodie. I guess this is no big concern, then. Great! :-)

> The XML:Base specification is short and surprisingly easy to read, if
> you like that sort of thing.

Yes, it is not a hard read, fortunately.

-- 
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 Jul  4 11: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 LAA20473
	for <atompub-archive@lists.ietf.org>; Sun, 4 Jul 2004 11: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 i64FTZuA019183;
	Sun, 4 Jul 2004 08: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 i64FTZJZ019182;
	Sun, 4 Jul 2004 08:29:35 -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 i64FTYXp019169
	for <atom-syntax@imc.org>; Sun, 4 Jul 2004 08:29:34 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.8] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id 1F5B3727D; Sun,  4 Jul 2004 08:29:37 -0700 (PDT)
In-Reply-To: <opsakvb5t8uvpchu@quark>
References: <BA72FC2A-CC47-11D8-B7F4-000A95BD86C0@bea.com> <327469D8-CC71-11D8-BA50-000A95A51C9E@sun.com> <20040702222446.GA16686@homer.w3.org> <CF9D211D-CC84-11D8-B7F4-000A95BD86C0@mnot.net> <opsakvb5t8uvpchu@quark>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <F4869DAD-CDCE-11D8-B7F4-000A95BD86C0@mnot.net>
Cc: Atom-Syntax <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: Re: PaceXmlBaseEverywhere
Date: Sun, 4 Jul 2004 08:29:35 -0700
To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
X-Mailer: Apple Mail (2.618)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i64FTYXp019170
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


Well, that's true of any general mechanism; it can be abused if people 
put their minds to it.

In terms of code, I think the most obtrustive impact of "XML Base 
everywhere" is that, because it can inherit from above but not be 
processed in a generic way, implementations will be required to pass 
XML base context along to extension handlers, and those handlers will 
have to know how to deal with it and compute their own internal base 
URI.

This could be as simple as passing it the parse handler, which will 
contain the context itself, but that depends on the feed parser's 
architecture.


On Jul 3, 2004, at 1:03 PM, Asbjørn Ulsberg wrote:

> On Fri, 2 Jul 2004 17:06:19 -0700, Mark Nottingham <mnot@mnot.net> 
> wrote:
>
>> If you want your infrastructure to apply XML Base for you, it has to 
>> know where to apply it. In a container format like Atom, that doesn't 
>> work very well, unless you have good Schema information.
>
> But coming to think of it; how often is really 'base' used? And how 
> often is it realisticly to assume it will be used in Atom? Is the base 
> going to change for each and every element in the feed? Is there any 
> aggregator in existance that could cope with something like this:
>
>   <?xml version="1.0" encoding="utf-8"?>
>   <feed version="0.3" xmlns="http://purl.org/atom/ns#"
>     xmlns:my="http://example.com/my#namespace"
>     xmlns:date="http://date.example.com/date#namespace"
>     xml:base="http://example.com/">
>
>     <title>Asbjørn Ulsberg's weblog</title>
>
>     <link rel="alternate" type="text/html"
>      xml:base="http://example.org/" href="asbjornu" />
>
>     <modified xml:base="http://date.example.com/
>       date:href="modified">2003-12-13T18:30:02Z</modified>
>
>     <author xml:base="http://example.net/" my:href="asbjornu">
>       <name>Asbjørn Ulsberg</name>
>     </author>
>
>     <entry>
>       <title>XML base example</title>
>       <id>tag:example.org,2004:6.2397</id>
>       <issued>2003-12-13T08:29:29-04:00</issued>
>       <modified>2003-12-13T18:30:02Z</modified>
>
>       <content type="application/xhtml+xml" mode="xml"
>         xml:base="http://example.org/articles/">
>         <div xmlns="http://www.w3.org/1999/xhtml"
>           <h1><a href="62397.html">XML base example</a></h1>
>         </div>
>       </content>
>     </entry>
>   </feed>
>
> This is probably a bad example, but hopefully it shows how meaningless 
> «xml:base everywhere» is. I can understand the need to change the URI 
> base for each entry, and maybe for each content element, but for each 
> and every element in the feed?

--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org  Sun Jul  4 12: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 MAA21447
	for <atompub-archive@lists.ietf.org>; Sun, 4 Jul 2004 12:29: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 i64GBjgJ027676;
	Sun, 4 Jul 2004 09:11:45 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i64GBjh8027675;
	Sun, 4 Jul 2004 09:11:45 -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 i64GBjsf027661
	for <atom-syntax@imc.org>; Sun, 4 Jul 2004 09:11:45 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.8] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id 3601D727D; Sun,  4 Jul 2004 09:11:48 -0700 (PDT)
In-Reply-To: <6497E842-CD33-11D8-A3E7-000A95CCC59E@xegesis.org>
References: <F925141D-CC46-11D8-B7F4-000A95BD86C0@mnot.net> <40E59276.9030609@dehora.net> <27C3E61C-CCAF-11D8-B7F4-000A95BD86C0@mnot.net> <58E465B4-CCFD-11D8-BA50-000A95A51C9E@sun.com> <3C16EE15-CD1B-11D8-A3E7-000A95CCC59E@xegesis.org> <15A0CA58-CD22-11D8-BA50-000A95A51C9E@sun.com> <6497E842-CD33-11D8-A3E7-000A95CCC59E@xegesis.org>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <D91F78DA-CDD4-11D8-B7F4-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: Atom Syntax <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: Re: PaceNoInfoSet
Date: Sun, 4 Jul 2004 09:11:46 -0700
To: Michael Champion <mc@xegesis.org>, Tim Bray <tbray@textuality.com>
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>
Content-Transfer-Encoding: 7bit



On Jul 3, 2004, at 1:56 PM, Michael Champion wrote:
> On Jul 3, 2004, at 2:52 PM, Tim Bray wrote:
>
>> Whether you want to call that a "logical structure" or a "syntax" 
>> doesn't seem that big a deal... but I lean in favor of syntax because 
>> interoperation, in particular across a network, takes place at the 
>> level of syntax.
>
> OK, no big deal, we're talking about the same thing I guess -- the 
> allowed elements and attributes, and where they can appear.

I think this is a big deal, actually; "logical structure" and "syntax" 
imply two very different things. The former implies a data model, the 
latter implies a sequence of bytes. They're two very different ideas of 
what "Atom" is.

>> The reason the specification exists is to support programmers in 
>> building software which interoperates across the network.  All they 
>> can be sure of is that they will get messages which are XML 1.0 
>> documents and whose syntax is constrained in a way that's 
>> conveniently described using the Infoset.  The logical model they 
>> choose to construct inside their software to deal with this is none 
>> of our concern, and if it looks totally unlike the XML Infoset, 
>> that's fine and we shouldn't give anyone help in claiming that it 
>> isn't.  -Tim

Exactly. We only need one model to describe Atom with (and the Infoset 
will do just fine); we don't need to either explicitly allow or 
disallow other models; it's implicit that people can use other models 
within their own implementations.

It's also possible that people in the future might want to come up with 
a different serialisation of the model we describe Atom with;  however, 
they shouldn't call the result "Atom" without some kind of 
clarification (e.g., a different media type).

What we need to be really, really crisp about here is whether "Atom" 
refers to the data model that we describe in the spec, or the sequence 
of bits when we serialise that on the wire. If we go with the former, 
people will be able to call anything that conforms to that model 
"Atom," no matter how it's serialised. If we go with the latter, people 
will only be able to call a very particular serialisation of the data 
model "Atom".

In other words, we can bind the name "Atom" with the concepts people 
have in their head -- feeds, entries and so forth -- or with can bind 
it to the characters on the wire -- "<feed>", "<entry>" and so forth 
(Namespaces make this more complex in reality, but you get the idea). 
It's Infoset-level vs. MIME entity-level.

On balance, I can go with either of these approaches, as long as we 
make a clear distinction. I don't want people to be having this 
disagreement after we have an RFC.

I personally lean towards the former, because my general experience has 
been that extensibility is useful in specifications; it improves their 
chances of being relevant in the long term. If a truly better 
serialisation of the Infoset comes out (whether it's XML 1.5, 3.0 or 
binary XML 1.0) and gets serious traction, it would be a shame if we 
had to call Atom something different to take advantage of it 
(obviously, it'd need a new media type, for interop). Granted, I'm not 
at all convinced that it's possible to offer enough value to get that 
traction.

The latter approach cuts off alternate serialisations at the knees; you 
couldn't even refer to them in prose as "Atom", it would have to be 
something like "Atom/XML1.1". I'm not against this, but wonder if it's 
really necessary; the market will build its own profile of what "Atom" 
means, no matter what the underlying technology is.

In any case, we need close on this; can we get a reading from folks on 
whether they want Atom to mean:
   a) An abstract data model
   b) A particular arrangement of bits

As stated, I'm OK with either.

Cheers,

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Sun Jul  4 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 NAA22932
	for <atompub-archive@lists.ietf.org>; Sun, 4 Jul 2004 13:14: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 i64GlCHD034503;
	Sun, 4 Jul 2004 09: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 i64GlC6g034502;
	Sun, 4 Jul 2004 09:47:12 -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 i64GlALK034480
	for <atom-syntax@imc.org>; Sun, 4 Jul 2004 09:47: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 i64Gl853010407
	for <atom-syntax@imc.org>; Sun, 4 Jul 2004 11:47:08 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i64Gl8wL010403;
	Sun, 4 Jul 2004 11:47:08 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceSimpleResourcePosting and PUT
References: <opsairy6o1uvpchu@quark> <40E597FF.8020808@aol.net>
	<opsai5d4uouvpchu@quark> <40E64A34.5060406@aol.net>
	<opsakspewuuvpchu@quark> <40E74F6F.2060507@aol.net>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 04 Jul 2004 11:47:07 -0500
In-Reply-To: <40E74F6F.2060507@aol.net>
Message-ID: <m3fz87sos4.fsf@bitsko.slc.ut.us>
Lines: 81
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 i64GlBLK034497
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


jpanzer@aol.net (John Panzer) writes:

> Asbjørn Ulsberg wrote:

> > That shouldn't be necessary if you can use something like
> > .htaccess on Apache, or have nice administrators on IIS with
> > ASP.NET. The problem is that if people somehow can't do rewrite,
> > they would most likely want to serve the resources for GETs as
> > 'http://example.org/resources/mycat.jpg' but for all the other
> > verbs 'http://example.org/cgi-bin/resources?name=mycat.jpg'.
> >
> > This splits the resource in half, kind of, because it is
> > accessible from two different URI's. And not that each URI is
> > equal; no, you can only use one for GET and the other for PUT and
> > DELETE (for POST, you'd use a totally separate URI anyway).
> 
> Ah, this is the crux of the matter.  The impetus for this discussion
> is non entry resources
> (PaceNonEntryResources/PaceSimpleResourcePosting).  I think that non
> entry resources in these proposals _require_ that a single URI be
> used for all possible methods after creation (GET, PUT, DELETE,
> say).  Here's why:

Note: it is perfectly acceptable for a publishing system to publish
static, GET-only, instances of a resource in a different URL location,
possibly even on a different host.  We don't have a name or label for
this kind of URI location, WebDAV calls it an "output resource", so
OutputURI sounds good.

The editable resource at the EditURI would support GET/PUT/DELETE (and
whether it is also a PostURI for posting new sub-resources is a
separate concern).  It's also possible that the EditURI might be
restricted to authenticated users.

Atom does not currently have a method for informing a client what the
OutputURI is for resources in general.  Entries can have a
link/@rel=alternate for the browsable OutputURI.

At this time, the publishing system must document the relationship
between the AtomAPI locations (EditURI) and where the resources are
published (OutputURI) so that the user can edit entries appropriately.

> > As the API offers 'service.edit' URI's, I don't think this is a
> > big problem. This URI can be something different for PUT than it
> > is for GET.  It's not very REST-ish or intuitive, but it works for
> > rewrite-disabled people and servers.
> 
> Note that we're not talking about entries in this context, we're
> talking about non-entry resources and there is no service.edit URI
> that points at any of them (at least under
> PaceNonEntryResources/PaceSimpleResourcePosting). -John

Notifying editing clients of non-entry resource locations was a
feature of PaceResource, on the principle that <resource> elements
would be in dynamic and index feeds but not displayed as entries in
newsreader clients.

We have to decide carefully in this support because there's a mature
and straightforward solution for this available in WebDAV, PROPFIND,
for indexing collections of resources.

A trimmed-to-relevant portion of the output from

  curl -X PROPFIND -H "Depth: 1" http://test.webdav.org/dav/atom/

<dav:response xmlns:dav="DAV:">
  <dav:href>/dav/atom/kitty.jpg</dav:href>
  <dav:propstat>
    <dav:prop>
      <dav:resourcetype/>
      <dav:getcontenttype>image/jpeg</dav:getcontenttype>
      <dav:creationdate>2004-07-04T16:30:36Z</dav:creationdate>
      <dav:getcontentlength>43397</dav:getcontentlength>
      <dav:getlastmodified>Sun, 04 Jul 2004 16:30:36 GMT</dav:getlastmodified>
      <dav:getetag>"43d4-a985-f0ac8300"</dav:getetag>
    </dav:prop>
    <dav:status>HTTP/1.1 200 OK</dav:status>
  </dav:propstat>
</dav:response>

  -- Ken



From owner-atom-syntax@mail.imc.org  Sun Jul  4 13:19: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 NAA23161
	for <atompub-archive@lists.ietf.org>; Sun, 4 Jul 2004 13:19: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 i64Gq90i035619;
	Sun, 4 Jul 2004 09:52: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 i64Gq9gO035616;
	Sun, 4 Jul 2004 09:52: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 i64Gq8U8035604
	for <atom-syntax@imc.org>; Sun, 4 Jul 2004 09:52:08 -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 i64Go953025651
	for <atom-syntax@imc.org>; Sun, 4 Jul 2004 10:50:10 -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 <0I0C00GTN6UYWW@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sun, 04 Jul 2004 10:52:10 -0600 (MDT)
Received: from [172.20.101.179] ([66.243.155.130])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0C003A86UXL2@mail.sun.net> for atom-syntax@imc.org; Sun,
 04 Jul 2004 10:52:10 -0600 (MDT)
Date: Sun, 04 Jul 2004 09:52:36 -0700
From: Tim Bray <tbray@textuality.com>
Subject: Re: PaceNoInfoSet
In-reply-to: <D91F78DA-CDD4-11D8-B7F4-000A95BD86C0@mnot.net>
To: Mark Nottingham <mnot@mnot.net>
Cc: Atom Syntax <atom-syntax@imc.org>, Michael Champion <mc@xegesis.org>
Message-id: <8D29C042-CDDA-11D8-B898-000A95A51C9E@textuality.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: <F925141D-CC46-11D8-B7F4-000A95BD86C0@mnot.net>
 <40E59276.9030609@dehora.net> <27C3E61C-CCAF-11D8-B7F4-000A95BD86C0@mnot.net>
 <58E465B4-CCFD-11D8-BA50-000A95A51C9E@sun.com>
 <3C16EE15-CD1B-11D8-A3E7-000A95CCC59E@xegesis.org>
 <15A0CA58-CD22-11D8-BA50-000A95A51C9E@sun.com>
 <6497E842-CD33-11D8-A3E7-000A95CCC59E@xegesis.org>
 <D91F78DA-CDD4-11D8-B7F4-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


> In any case, we need close on this; can we get a reading from folks on 
> whether they want Atom to mean:
>   a) An abstract data model
>   b) A particular arrangement of bits

(b), because experience has taught us that interoperation on the basis 
of syntax is do-able (not easy, do-able), while interaction on the 
basis of data model is insanely difficult in the general case in 
heterogeneous networked applications.  I think we have to be all about 
interoperability first, last, and always. -Tim



From owner-atom-syntax@mail.imc.org  Sun Jul  4 13:25:31 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23509
	for <atompub-archive@lists.ietf.org>; Sun, 4 Jul 2004 13:25:30 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i64HDhxN039622;
	Sun, 4 Jul 2004 10:13:43 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i64HDgmf039621;
	Sun, 4 Jul 2004 10:13:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.mnot.net (adsl-67-119-69-242.dsl.sntc01.pacbell.net [67.119.69.242])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i64HDfgA039601
	for <atom-syntax@imc.org>; Sun, 4 Jul 2004 10:13:41 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.8] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id BDDB8727D; Sun,  4 Jul 2004 10:13:44 -0700 (PDT)
In-Reply-To: <8D29C042-CDDA-11D8-B898-000A95A51C9E@textuality.com>
References: <F925141D-CC46-11D8-B7F4-000A95BD86C0@mnot.net> <40E59276.9030609@dehora.net> <27C3E61C-CCAF-11D8-B7F4-000A95BD86C0@mnot.net> <58E465B4-CCFD-11D8-BA50-000A95A51C9E@sun.com> <3C16EE15-CD1B-11D8-A3E7-000A95CCC59E@xegesis.org> <15A0CA58-CD22-11D8-BA50-000A95A51C9E@sun.com> <6497E842-CD33-11D8-A3E7-000A95CCC59E@xegesis.org> <D91F78DA-CDD4-11D8-B7F4-000A95BD86C0@mnot.net> <8D29C042-CDDA-11D8-B898-000A95A51C9E@textuality.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <8051ED41-CDDD-11D8-B7F4-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: Atom Syntax <atom-syntax@imc.org>, Michael Champion <mc@xegesis.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: Re: PaceNoInfoSet
Date: Sun, 4 Jul 2004 10:13:43 -0700
To: Tim Bray <tbray@textuality.com>
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>
Content-Transfer-Encoding: 7bit



On Jul 4, 2004, at 9:52 AM, Tim Bray wrote:

>> In any case, we need close on this; can we get a reading from folks 
>> on whether they want Atom to mean:
>>   a) An abstract data model
>>   b) A particular arrangement of bits
>
> (b), because experience has taught us that interoperation on the basis 
> of syntax is do-able (not easy, do-able), while interaction on the 
> basis of data model is insanely difficult in the general case in 
> heterogeneous networked applications.  I think we have to be all about 
> interoperability first, last, and always. -Tim

Of course we have to think about interoperability, but that isn't the 
question at hand; Atom will be specified in terms of the same 
constructs -- i.e., we'll interoperate based upon the Infoset -- no 
matter what the outcome of this decision.

What does "interoperation on the basis of syntax" mean? No matter how 
we specify Atom, it will involve an abstraction, even if that is a 
sequence of characters (which would be massively inefficient; I 
personally don't want to start writing "a '<' character followed by 
either...").

The question at hand is what abstraction "Atom" refers to. If we 
constrain it to a particular serialisation of the Infoset, that's fine, 
but I don't think that the statement "Atom is XML 1.0" buys much in 
terms of interoperability; MIME has enough flexibility to accommodate 
different serialisations of an abstraction in an interoperable fashion.

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Sun Jul  4 13:48: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 NAA24109
	for <atompub-archive@lists.ietf.org>; Sun, 4 Jul 2004 13:48: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 i64HZAuV043870;
	Sun, 4 Jul 2004 10:35: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 i64HZA76043869;
	Sun, 4 Jul 2004 10:35:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtp105.mail.sc5.yahoo.com (smtp105.mail.sc5.yahoo.com [66.163.169.225])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i64HZApc043854
	for <atom-syntax@imc.org>; Sun, 4 Jul 2004 10:35:10 -0700 (PDT)
	(envelope-from mc@xegesis.org)
Received: from unknown (HELO ?192.168.1.103?) (mcraigchampion@68.40.14.49 with plain)
  by smtp105.mail.sc5.yahoo.com with SMTP; 4 Jul 2004 17:35:13 -0000
Mime-Version: 1.0 (Apple Message framework v618)
In-Reply-To: <8D29C042-CDDA-11D8-B898-000A95A51C9E@textuality.com>
References: <F925141D-CC46-11D8-B7F4-000A95BD86C0@mnot.net> <40E59276.9030609@dehora.net> <27C3E61C-CCAF-11D8-B7F4-000A95BD86C0@mnot.net> <58E465B4-CCFD-11D8-BA50-000A95A51C9E@sun.com> <3C16EE15-CD1B-11D8-A3E7-000A95CCC59E@xegesis.org> <15A0CA58-CD22-11D8-BA50-000A95A51C9E@sun.com> <6497E842-CD33-11D8-A3E7-000A95CCC59E@xegesis.org> <D91F78DA-CDD4-11D8-B7F4-000A95BD86C0@mnot.net> <8D29C042-CDDA-11D8-B898-000A95A51C9E@textuality.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <7F165F8B-CDE0-11D8-A3E7-000A95CCC59E@xegesis.org>
Content-Transfer-Encoding: 7bit
From: Michael Champion <mc@xegesis.org>
Subject: Re: PaceNoInfoSet
Date: Sun, 4 Jul 2004 13:35:09 -0400
To: Atom Syntax <atom-syntax@imc.org>
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>
Content-Transfer-Encoding: 7bit



On Jul 4, 2004, at 12:52 PM, Tim Bray wrote:
>

>  I think we have to be all about interoperability first, last, and 
> always. -Tim
>
>
Absolutely, that's the whole reason for Atom's existence.  I agree with 
Mark that Atom should be unambiguous on which definition it uses, and 
don't think that it is worth a long digression over which is chosen, 
but
  I just don't accept the premise that interoperability can only be 
guaranteed at the "arrangement of bits on the wire" level.  That's 
certainly not the experience of the DBMS world where interoperability 
(to the extent that it is possible at all due to business issues such 
as who supports which definitions of SQL) is indeed at the level of the 
SQL language and ODBC/JDBC/ADO/JDO/etc. APIs.  The reasonably decent 
interoperability of the numerous variants of HTML and RSS could be 
interpreted either way ("the glass is half empty" because 
interoperability is partial and tedious for developers, or "the glass 
is half full" because most end users don't have to care). Likewise, 
this mailing list seems to have spent the bulk of its bandwidth 
discussing in excruciating detail the myriad ways in which the XML and 
internet standards do not really and truly define the arrangement of 
bits on the wire in a way that real people can use with confidence 
today.

Given the likelihood that Atom will have to coexist with specs such as 
SOAP and XQuery as well as with syntax-level specs such as XML  it is 
at least arguable that basing the definition on an abstract data model 
will be both easier for this group to actually complete and more useful 
for code developers.  Likewise, XML itself  is evolving -- XML 1.1 
certainly threw a monkey wrench into SOAP 1.2; I don't have an opinion 
whether that would have been more or less damaging had SOAP been based 
on bits on the wire rather than the Infoset, but it seems worth 
analyzing here.  Other changes, such as the possibility of a de facto 
standard (or two, or three) performance-optimized  XML serialization 
need to have their impacts on Atom analyzed.  Can you really just say 
"don't do that" and expect the world to agree?  Maybe, but if you 
define Atom at the information model level then the question just 
doesn't come up.

Again, I don't have a really strong opinion that defining Atom as an 
abstract data model is the best approach, but I do think that some 
further discussion is necessary -- it's not nearly as cut and dried as 
Tim's statement  that "experience teaches us" that interoperation at 
the syntax level is more easily achieveable implies, IMHO.  At a 
minimum, I suggest that you satisfy yourselves that the syntax-level 
definition solves more problems than it creates under a plausible set 
of use cases, including:
- XQuery access of Atom syndicated in a DBMS
- Atom transported within a SOAP envelope
- A possible future with one or more "efficient" serializations of the 
Infoset being widely supported.



From owner-atom-syntax@mail.imc.org  Sun Jul  4 14: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 OAA25499
	for <atompub-archive@lists.ietf.org>; Sun, 4 Jul 2004 14: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 i64HtUx0047802;
	Sun, 4 Jul 2004 10:55: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 i64HtU6R047801;
	Sun, 4 Jul 2004 10:55: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.47])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i64HtUV3047795
	for <atom-syntax@imc.org>; Sun, 4 Jul 2004 10:55: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 i64HtXVN018916
	for <atom-syntax@imc.org>; Sun, 4 Jul 2004 10:55:33 -0700 (PDT)
Received: from [12.40.111.47] (wireless-12-40-111-47.bryantpark.org [12.40.111.47] (may be forged))
	(authenticated bits=0)
	by mac.com (Xserve/smtpin01/MantshX 4.0) with ESMTP id i64HtDTv022012
	for <atom-syntax@imc.org>; Sun, 4 Jul 2004 10:55:24 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v618)
In-Reply-To: <8051ED41-CDDD-11D8-B7F4-000A95BD86C0@mnot.net>
References: <F925141D-CC46-11D8-B7F4-000A95BD86C0@mnot.net> <40E59276.9030609@dehora.net> <27C3E61C-CCAF-11D8-B7F4-000A95BD86C0@mnot.net> <58E465B4-CCFD-11D8-BA50-000A95A51C9E@sun.com> <3C16EE15-CD1B-11D8-A3E7-000A95CCC59E@xegesis.org> <15A0CA58-CD22-11D8-BA50-000A95A51C9E@sun.com> <6497E842-CD33-11D8-A3E7-000A95CCC59E@xegesis.org> <D91F78DA-CDD4-11D8-B7F4-000A95BD86C0@mnot.net> <8D29C042-CDDA-11D8-B898-000A95A51C9E@textuality.com> <8051ED41-CDDD-11D8-B7F4-000A95BD86C0@mnot.net>
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-22--1012623297; protocol="application/pkcs7-signature"
Message-Id: <545395D8-CDE3-11D8-B513-000A95DC3D90@mac.com>
From: Graham <dtcd@mac.com>
Subject: Re: PaceNoInfoSet
Date: Sun, 4 Jul 2004 13:55:26 -0400
To: Atom Syntax <atom-syntax@imc.org>
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-22--1012623297
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 4 Jul 2004, at 1:13 pm, Mark Nottingham wrote:

> The question at hand is what abstraction "Atom" refers to. If we 
> constrain it to a particular serialisation of the Infoset, that's 
> fine, but I don't think that the statement "Atom is XML 1.0" buys much 
> in terms of interoperability; MIME has enough flexibility to 
> accommodate different serialisations of an abstraction in an 
> interoperable fashion.

Yes, but software doesn't. My experience is that people trying to be 
clever by do it by jamming a crowbar in any gap in the spec they spot. 
If the spec allows for alternate serializations, no matter what 
language you use to discourage them, some idiot somewhere is going 
shove an ASN.1 or soemthing feed online and then complain that all (or 
certain) "Atom-compatible" aggregators are broken. They might even 
persuade a couple of developers to support it, which means we'll all 
have to. I think the spec needs to be completely locked down on this 
aspect if we're to retain control of what happens out in the wild.

Graham 
--Apple-Mail-22--1012623297
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
9w0BCQUxDxcNMDQwNzA0MTc1NTI2WjAjBgkqhkiG9w0BCQQxFgQUmgkhJQ2T/1IVWY2eiq4YvxxJ
CEsweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAARdz6M8a0HY1k9vwA8h/xTvU
ng1kkhIf7gHrT4uQ4oR5h8Sc90ynkSSs6uDZWzKdKbNdsdA+bnwT/tI/skr14yHMPyokCFmEBZ1P
vkUqBNpRcqU8Eo8IEl9bGd9ynJ9EwUhZP+WuCSV5Ts2b6EP1rqhXafrAFIJ4U3B7OyXdHtrGyhWn
pyh8jdxZUqy/9DzbOc1y6R4/gHjM8Fn6/OyaQl9b6thwhSQWpmJi0xzoa2NGkm8AucQxDuKnTSbu
a4EUMyltZ6ipGWQTSdzWW1235ai8y7bm4OeFxWqosMQmlo9iOeSjWlmNzC05KJTUiR3BKhfWtvhO
k3Ofw7em5Ad9YgAAAAAAAA==

--Apple-Mail-22--1012623297--



From owner-atom-syntax@mail.imc.org  Sun Jul  4 16:34:33 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00596
	for <atompub-archive@lists.ietf.org>; Sun, 4 Jul 2004 16:34: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 i64KHDVw075729;
	Sun, 4 Jul 2004 13:17:13 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i64KHD4g075728;
	Sun, 4 Jul 2004 13:17:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.245])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i64KHCdm075713
	for <atom-syntax@imc.org>; Sun, 4 Jul 2004 13:17:12 -0700 (PDT)
	(envelope-from rtomayko@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so2064703cwc
        for <atom-syntax@imc.org>; Sun, 04 Jul 2004 13:16:55 -0700 (PDT)
Received: by 10.11.116.64 with SMTP id o64mr265427cwc;
        Sun, 04 Jul 2004 13:16:55 -0700 (PDT)
Message-ID: <f732822d04070413166ae231ff@mail.gmail.com>
Date: Sun, 4 Jul 2004 16:16:55 -0400
From: Ryan Tomayko <rtomayko@gmail.com>
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceXmlBaseEverywhere
Cc: "Asbjørn Ulsberg" <asbjorn@tigerstaden.no>
In-Reply-To: <opsal4t7hnuvpchu@quark>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
References: <BA72FC2A-CC47-11D8-B7F4-000A95BD86C0@bea.com> <327469D8-CC71-11D8-BA50-000A95A51C9E@sun.com> <20040702222446.GA16686@homer.w3.org> <CF9D211D-CC84-11D8-B7F4-000A95BD86C0@mnot.net> <opsakvb5t8uvpchu@quark> <f732822d04070321234e100d1@mail.gmail.com> <opsal4t7hnuvpchu@quark>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i64KHCdm075722
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, 04 Jul 2004 14:26:21 +0200, Asbjørn Ulsberg
<asbjorn@tigerstaden.no> wrote:
> On Sun, 4 Jul 2004 00:23:52 -0400, Ryan Tomayko <rtomayko@gmail.com> wrote:
> > But all these processors do is keep track of the base URI, they do not
> > actually change any data in the document. It makes the base URI for any
> > element available so that it may be retrieved by the application.
> 
> How is the URI base retrieved? Does each node of a DOM document, or the
> context of a SAX based parser have a .base property or similar that at any
> given time contains the base of the element in scope?

Yep, that's pretty much it. The libxml2 C interface has an
xmlNodeGetBase function [1] that takes a pointer to a Document and
Node and gives you back the base URI. The Python for libxml2 bindings
have a wrapper for this as well [2].

Probably the best place to look at how DOM and DOMlike APIs do, or
will, implement this is the the recently completed DOM Level 3
Recommendation [3], which adds support for XML Base to standard DOM
implementations:

  This version enhances DOM Level 2 Core by completing the 
  mapping between DOM and the XML Information Set [XML 
  Information Set], including the support for XML Base [XML Base], 
  ...

Especially Section 1.3.4 "Base URIs" [4], which confirms your guess of
a ".base property":

  The DOM Level 3 adds support for the [base URI] property defined 
  in [XML Information Set] by providing a new attribute on the Node 
  interface that exposes this information. However, unlike the 
  Node.namespaceURI attribute, the Node.baseURI attribute is not a 
  static piece of information that every node carries. Instead, it is a value 
  that is dynamically computed according to [XML Base]. 

To my earlier point, I don't think there's any way to tell DOM Level 3
parsers to only process xml:base for certain elements. Perhaps Mike
Champion can tell us a little about how xml:base was approached the
way it was.

> Maybe you could write something up on the Wiki or somewhere else on how it
> should be done? A step by step explanation of what to consider each time
> you meet a new xml:base attribute?

The XML Base Recommendation does a great job of explaining the rules.
As for implementation details, here's a quick overview of how I
attacked base processing for different processing models:

Tree based APIs (like DOM) are probably the easiest to implement this
for. Obtaining the base uri for any node consists of walking the
ancestor-or-self sequence looking for xml:base attributes. If the API
supports XPath, this is usually a simple matter of evaluating the
following expression: ancestor-or-self::*/@xml:base and running
through the nodeset in reverse.

If you're using SAX, I suggest creating an XMLFilter that maintains a
stack of base URIs. The filter looks for xml:base attributes during
startElement and pushes their value onto the stack. When the
corresponding endElement method is called, the URI is popped off the
stack. If you then start from the bottom of the stack and move up, you
can obtain an absolute base uri for the current event at any time
during the parse.

Implementing on top of Pull Based APIs is similar to implementing on
top of SAX.

Ryan

[1] http://xmlsoft.org/html/libxml-tree.html#xmlNodeGetBase
[2] http://pyxmlsec.labs.libre-entreprise.org/docs/html/libxml2.xmlNode-class.html#getBase
[3] http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/
[4] http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#baseURIs-Considerations



From owner-atom-syntax@mail.imc.org  Sun Jul  4 17:14: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 RAA01787
	for <atompub-archive@lists.ietf.org>; Sun, 4 Jul 2004 17:14: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 i64Kw5OL084717;
	Sun, 4 Jul 2004 13:58: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 i64Kw5tR084716;
	Sun, 4 Jul 2004 13:58:05 -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 i64Kvncu084648
	for <atom-syntax@imc.org>; Sun, 4 Jul 2004 13:58:01 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.8] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id 1E35E7288; Sun,  4 Jul 2004 13:57:34 -0700 (PDT)
In-Reply-To: <545395D8-CDE3-11D8-B513-000A95DC3D90@mac.com>
References: <F925141D-CC46-11D8-B7F4-000A95BD86C0@mnot.net> <40E59276.9030609@dehora.net> <27C3E61C-CCAF-11D8-B7F4-000A95BD86C0@mnot.net> <58E465B4-CCFD-11D8-BA50-000A95A51C9E@sun.com> <3C16EE15-CD1B-11D8-A3E7-000A95CCC59E@xegesis.org> <15A0CA58-CD22-11D8-BA50-000A95A51C9E@sun.com> <6497E842-CD33-11D8-A3E7-000A95CCC59E@xegesis.org> <D91F78DA-CDD4-11D8-B7F4-000A95BD86C0@mnot.net> <8D29C042-CDDA-11D8-B898-000A95A51C9E@textuality.com> <8051ED41-CDDD-11D8-B7F4-000A95BD86C0@mnot.net> <545395D8-CDE3-11D8-B513-000A95DC3D90@mac.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <C47699F6-CDFC-11D8-B7F4-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: Atom Syntax <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: Re: PaceNoInfoSet -- building block vs. profile
Date: Sun, 4 Jul 2004 13:57:31 -0700
To: Graham <dtcd@mac.com>
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>
Content-Transfer-Encoding: 7bit


OK. Are we going to take the same approach to extensibility of Atom 
itself? For example, are we going to disallow Atom feeds from being 
extended in such a way that current-generation aggregators can't fully 
understand them, or perhaps don't interoperate with them well?

This is perhaps the other facet of the question -- is "Atom" a strict 
profile of what we're doing (e.g. MUST have a title, MUST NOT have...) 
or is it just a generic container that different applications can 
extend?

In other words, is "Atom" a building block that can be used for a 
variety of tasks, or is a purpose-specific profile that requires 
certain things and has more limited extensibility?

Cheers,

P.S. I'm not pushing back on your answer, Graham -- I think you make an 
excellent point. IME, most efforts go through a crisis of identity, 
where some level of navel-gazing of the "what does 'is' mean?" sort is 
done. Doing so gets everybody on the same page, and is generally 
productive, as long as it doesn't turn into a rat-hole. It's good that 
we're at that stage so early in the process; getting around to it in 
the latter stages can be disastrous...



On Jul 4, 2004, at 10:55 AM, Graham wrote:

> On 4 Jul 2004, at 1:13 pm, Mark Nottingham wrote:
>
>> The question at hand is what abstraction "Atom" refers to. If we 
>> constrain it to a particular serialisation of the Infoset, that's 
>> fine, but I don't think that the statement "Atom is XML 1.0" buys 
>> much in terms of interoperability; MIME has enough flexibility to 
>> accommodate different serialisations of an abstraction in an 
>> interoperable fashion.
>
> Yes, but software doesn't. My experience is that people trying to be 
> clever by do it by jamming a crowbar in any gap in the spec they spot. 
> If the spec allows for alternate serializations, no matter what 
> language you use to discourage them, some idiot somewhere is going 
> shove an ASN.1 or soemthing feed online and then complain that all (or 
> certain) "Atom-compatible" aggregators are broken. They might even 
> persuade a couple of developers to support it, which means we'll all 
> have to. I think the spec needs to be completely locked down on this 
> aspect if we're to retain control of what happens out in the wild.
>
> Graham

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Sun Jul  4 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 RAA02364
	for <atompub-archive@lists.ietf.org>; Sun, 4 Jul 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 i64LFTH1087861;
	Sun, 4 Jul 2004 14:15:29 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i64LFTAt087860;
	Sun, 4 Jul 2004 14:15:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail4.edisontel.com (mail4.edisontel.com [62.94.0.37])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i64LFSQD087845
	for <atom-syntax@imc.org>; Sun, 4 Jul 2004 14:15:29 -0700 (PDT)
	(envelope-from danny666@virgilio.it)
Received: from virgilio.it (62.94.192.200) by mail4.edisontel.com (7.0.024)
        id 3FB4847C008E4682; Sun, 4 Jul 2004 23:14:51 +0200
Message-ID: <40E872DE.3080004@virgilio.it>
Date: Sun, 04 Jul 2004 23:13:02 +0200
From: Danny Ayers <danny666@virgilio.it>
Reply-To: danny666@virgilio.it
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tim Bray <tbray@textuality.com>
CC: Mark Nottingham <mnot@mnot.net>, Atom Syntax <atom-syntax@imc.org>,
        Michael Champion <mc@xegesis.org>
Subject: Re: PaceNoInfoSet
References: <F925141D-CC46-11D8-B7F4-000A95BD86C0@mnot.net> <40E59276.9030609@dehora.net> <27C3E61C-CCAF-11D8-B7F4-000A95BD86C0@mnot.net> <58E465B4-CCFD-11D8-BA50-000A95A51C9E@sun.com> <3C16EE15-CD1B-11D8-A3E7-000A95CCC59E@xegesis.org> <15A0CA58-CD22-11D8-BA50-000A95A51C9E@sun.com> <6497E842-CD33-11D8-A3E7-000A95CCC59E@xegesis.org> <D91F78DA-CDD4-11D8-B7F4-000A95BD86C0@mnot.net> <8D29C042-CDDA-11D8-B898-000A95A51C9E@textuality.com>
In-Reply-To: <8D29C042-CDDA-11D8-B898-000A95A51C9E@textuality.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:

>
>> In any case, we need close on this; can we get a reading from folks 
>> on whether they want Atom to mean:
>>   a) An abstract data model
>>   b) A particular arrangement of bits
>

This is a misleading contrast.  Neither model without syntax or syntax 
without model offer interop.

> (b), because experience has taught us that interoperation on the basis 
> of syntax is do-able (not easy, do-able), while interaction on the 
> basis of data model is insanely difficult in the general case in 
> heterogeneous networked applications.  I think we have to be all about 
> interoperability first, last, and always. -Tim


Interoperation in what sense? Without anything shared beyond syntax, 
there can be no communication. Bits over the wire are still bits, 
nothing more.

On the other hand, we aren't looking for interaction on the basis of a 
data model *in the general case*, just within the scope of the 
syndication model. This is not insanely difficult, just fairly hard.

Fact is, we need model (however informal) and at least one syntax for 
interop. I'd push the proportions more towards (a formal) model, but 
that's just my personal preference.

Cheers,
Danny.


-- 

Raw
http://dannyayers.com



From owner-atom-syntax@mail.imc.org  Sun Jul  4 17:31: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 RAA02382
	for <atompub-archive@lists.ietf.org>; Sun, 4 Jul 2004 17:31: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 i64LA4Mj086780;
	Sun, 4 Jul 2004 14:10: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 i64LA40O086779;
	Sun, 4 Jul 2004 14:10:04 -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 i64LA3F3086745
	for <atom-syntax@imc.org>; Sun, 4 Jul 2004 14:10:03 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040704211001.29826.qmail@web41210.mail.yahoo.com>
Received: from [131.107.3.85] by web41210.mail.yahoo.com via HTTP; Sun, 04 Jul 2004 14:10:01 PDT
Date: Sun, 4 Jul 2004 14:10:01 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: PaceXmlBaseEverywhere
To: "Asbjørn_Ulsberg" <asbjorn@tigerstaden.no>,
        Ryan Tomayko <rtomayko@gmail.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <opsal4t7hnuvpchu@quark>
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>


--- Asbjørn_Ulsberg <asbjorn@tigerstaden.no> wrote:
> 
> On Sun, 4 Jul 2004 00:23:52 -0400, Ryan Tomayko
> <rtomayko@gmail.com> wrote:
> 
> > In fact, I was under the impression that
> "supporting xml:base" meant
> > supporting it everywhere in a document. I didn't
> know it was legal to
> > support it only on certain elements.
> 
> Afaik (I'm no XSD champion) you need to explicitly
> specify on what  
> elements you are to allow xml:lang, xml:base and so
> on in XSD. That's some  
> part of the problem. So not being explicit in the
> specification about this  
> means that we can't be explicit in XSD schemas
> either, which again means  
> xml:base or xml:lang can't be used «everywhere».

There's nothing stopping one from specifying that
every element can have xml:base and xml:lang in the
schema. 

 
> Ok, cool. I have really no idea what libraries
> support xml:base natively.  
> Could Dare tell us if System.Xml and MSXML supports
> xml:base natively, as  
> libxml2?

Nope. The xml:base spec was produced after the last
major coding work was done on either System.Xml or
MSXML in their most recent major releases. Since There
hasn't really been much [if any] demand for xml:base
support in our APIs which is unsurprising since the
primary users of xml:base in the wild (XHTML &
XInclude) aren't getting that much usage from the
average XML developer.  

The next version of System.Xml will not have xml:base
support but will fix the bug where the XSD validator
complains about xml:base attributes being undefined.
This means that currently if you try to validate an
XML document that uses xml:base using the
System.Xml.XmlValidatingReader class you will get
validation errors using current versions of the .NET
Framework. 

I don't think MSXML has any plans to add xml:base
support in a future version but will double check with
the PM responsible for it when she gets back from
vacation. 

> Atom will hopefully have a normative schema, but
> I've raised the question  
> about having 'href' in no namespace at all, while
> having 'xml:base' in the  
> XML namespace. Maybe 'xlink:href' would be more
> appropriate.

I don't see why this is a problem. Most XML formats do
not have attributes in a namespace unless they are
global attributes which can appear elements from
different namespaces.  



=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


	
		
__________________________________
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 Jul  4 17:54: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 RAA03260
	for <atompub-archive@lists.ietf.org>; Sun, 4 Jul 2004 17:54: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 i64Lb5BU092312;
	Sun, 4 Jul 2004 14:37: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 i64Lb5bn092311;
	Sun, 4 Jul 2004 14:37: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.47])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i64Lb5fh092296
	for <atom-syntax@imc.org>; Sun, 4 Jul 2004 14:37:05 -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 i64Lb7VN028177;
	Sun, 4 Jul 2004 14:37:07 -0700 (PDT)
Received: from [12.40.111.47] (wireless-12-40-111-47.bryantpark.org [12.40.111.47] (may be forged))
	(authenticated bits=0)
	by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id i64Lb5ta022644;
	Sun, 4 Jul 2004 14:37:06 -0700 (PDT)
In-Reply-To: <C47699F6-CDFC-11D8-B7F4-000A95BD86C0@mnot.net>
References: <F925141D-CC46-11D8-B7F4-000A95BD86C0@mnot.net> <40E59276.9030609@dehora.net> <27C3E61C-CCAF-11D8-B7F4-000A95BD86C0@mnot.net> <58E465B4-CCFD-11D8-BA50-000A95A51C9E@sun.com> <3C16EE15-CD1B-11D8-A3E7-000A95CCC59E@xegesis.org> <15A0CA58-CD22-11D8-BA50-000A95A51C9E@sun.com> <6497E842-CD33-11D8-A3E7-000A95CCC59E@xegesis.org> <D91F78DA-CDD4-11D8-B7F4-000A95BD86C0@mnot.net> <8D29C042-CDDA-11D8-B898-000A95A51C9E@textuality.com> <8051ED41-CDDD-11D8-B7F4-000A95BD86C0@mnot.net> <545395D8-CDE3-11D8-B513-000A95DC3D90@mac.com> <C47699F6-CDFC-11D8-B7F4-000A95BD86C0@mnot.net>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-23--999308042; protocol="application/pkcs7-signature"
Message-Id: <54D6241E-CE02-11D8-B513-000A95DC3D90@mac.com>
Cc: Atom Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: PaceNoInfoSet -- building block vs. profile
Date: Sun, 4 Jul 2004 17:37:21 -0400
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-23--999308042
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 4 Jul 2004, at 4:57 pm, Mark Nottingham wrote:

> OK. Are we going to take the same approach to extensibility of Atom 
> itself? For example, are we going to disallow Atom feeds from being 
> extended in such a way that current-generation aggregators can't fully 
> understand them, or perhaps don't interoperate with them well?

I think this was what I was getting at with my comments about <content 
src="">. The best approach to extensibility to me would be 
multi-faceted-ness - ie Different kinds of applications would have 
there own part of Atom, and can be targeted specifically and 
separately. Overloading of specific elements means they change meaning 
in different contexts, and a non-target-audience app has problems, 
which threatens manageability and transparency of the format.

Back to the topic, I think the best approach, if we're going to allow 
alternate serializations to be called Atom, is to have all endpoints 
able to provide and consume XML 1.0, and there to be a standard way to 
get to it.

Graham Parks
--Apple-Mail-23--999308042
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
9w0BCQUxDxcNMDQwNzA0MjEzNzIxWjAjBgkqhkiG9w0BCQQxFgQU4/WKoAwTwu9NkVcXHY4Lz3fe
5uEweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAm6KsGPoX9afqSkgrM2/FJiXP
veaNCPe8Nw2yj9vvBStflD9Myus7KOPC4cZjGah9PTjlCaBtnQvoBO/2r/TBRCFSVYnIkcdp3x0B
+Ioem6wodktqxBfFUcTRqtTfVDeL1Idqk8JA16i5e3OJhXL0osa9lqSj/kfYH/2OGl9bUCXIftAY
oTQ2MuVuiRck1Em6sl6AVnuWh3mMkcSopPOUMBCEDsiAwSKBEkplo1mMyBCQaQz487Ga+DQhU/Yk
YwnRxnbEBdM+hC7R4zAd1sybdcuOvwKO0c78idQ9NMzU3fMZifmYKCJtJSKEvjKYUKiL8oVkE/Mv
8i/RdYRzR5yV7wAAAAAAAA==

--Apple-Mail-23--999308042--



From owner-atom-syntax@mail.imc.org  Sun Jul  4 17: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 RAA03339
	for <atompub-archive@lists.ietf.org>; Sun, 4 Jul 2004 17:55: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 i64La3jv092092;
	Sun, 4 Jul 2004 14: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 i64La3xI092091;
	Sun, 4 Jul 2004 14:36:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i64La2HG092065
	for <atom-syntax@imc.org>; Sun, 4 Jul 2004 14:36:03 -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 5E0607C120; Mon,  5 Jul 2004 00:31:54 +0200 (CEST)
Date: Sun, 04 Jul 2004 23:39:39 +0200
To: "Dare Obasanjo" <kpako@yahoo.com>
Subject: Re: PaceXmlBaseEverywhere
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <20040704211001.29826.qmail@web41210.mail.yahoo.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: <opsamugdemuvpchu@quark>
In-Reply-To: <20040704211001.29826.qmail@web41210.mail.yahoo.com>
User-Agent: Opera M2/7.51 (Win32, build 3798)
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, 4 Jul 2004 14:10:01 -0700 (PDT), Dare Obasanjo <kpako@yahoo.com>  
wrote:

> There's nothing stopping one from specifying that every element
> can have xml:base and xml:lang in the schema.

No, but you have to explicitly allow it, no? If you don't assert that an  
element can contain a 'xml:base' attribute in the schema, can it contain  
the attribute nonetheless?

>> Could Dare tell us if System.Xml and MSXML supports xml:base
>> natively, as libxml2?
>
> Nope. The xml:base spec was produced after the last major
> coding work was done on either System.Xml or MSXML in their
> most recent major releases.

Ok.

> Since There hasn't really been much [if any] demand for xml:base
> support in our APIs which is unsurprising since the primary
> users of xml:base in the wild (XHTML & XInclude) aren't getting
> that much usage from the average XML developer.

True. That might change now that Atom and other vocabularies utilize  
'xml:base', though.

> The next version of System.Xml will not have xml:base support but
> will fix the bug where the XSD validator complains about xml:base
> attributes being undefined.

What is this bug, really? Is it so that an XSD should not really need to  
explicitly state where 'xml:base' (or 'xml:*' really) is allowed, but now  
you have to in order to make the XSD work with System.Xml?

> This means that currently if you try to validate an XML document
> that uses xml:base using the System.Xml.XmlValidatingReader class
> you will get validation errors using current versions of the .NET
> Framework.

Right.

> I don't think MSXML has any plans to add xml:base support in a
> future version but will double check with the PM responsible for it
> when she gets back from vacation.

Cool. Support for xml:base (and xml:lang, for that matter) in the XML  
libraries would help Atom development a great deal.

>> I've raised the question about having 'href' in no namespace at all,
>> while having 'xml:base' in the XML namespace. Maybe 'xlink:href'
>> would be more appropriate.
>
> I don't see why this is a problem. Most XML formats do not have
> attributes in a namespace unless they are global attributes which
> can appear elements from different namespaces.

Yes, well, I guess there isn't much of a problem. I just think it's  
inconsistent that @href belongs to Atom, while the attribute controlling  
@href's behaviour in respect to relative URI's is in the XML namespace. No  
biggie.

-- 
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 Jul  4 18: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 SAA04788
	for <atompub-archive@lists.ietf.org>; Sun, 4 Jul 2004 18: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 i64Lmsbv094549;
	Sun, 4 Jul 2004 14:48:54 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i64LmsJC094548;
	Sun, 4 Jul 2004 14:48:54 -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 i64Lmh3F094461
	for <atom-syntax@imc.org>; Sun, 4 Jul 2004 14:48:48 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.8] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id A8DDD727D; Sun,  4 Jul 2004 14:48:34 -0700 (PDT)
In-Reply-To: <54D6241E-CE02-11D8-B513-000A95DC3D90@mac.com>
References: <F925141D-CC46-11D8-B7F4-000A95BD86C0@mnot.net> <40E59276.9030609@dehora.net> <27C3E61C-CCAF-11D8-B7F4-000A95BD86C0@mnot.net> <58E465B4-CCFD-11D8-BA50-000A95A51C9E@sun.com> <3C16EE15-CD1B-11D8-A3E7-000A95CCC59E@xegesis.org> <15A0CA58-CD22-11D8-BA50-000A95A51C9E@sun.com> <6497E842-CD33-11D8-A3E7-000A95CCC59E@xegesis.org> <D91F78DA-CDD4-11D8-B7F4-000A95BD86C0@mnot.net> <8D29C042-CDDA-11D8-B898-000A95A51C9E@textuality.com> <8051ED41-CDDD-11D8-B7F4-000A95BD86C0@mnot.net> <545395D8-CDE3-11D8-B513-000A95DC3D90@mac.com> <C47699F6-CDFC-11D8-B7F4-000A95BD86C0@mnot.net> <54D6241E-CE02-11D8-B513-000A95DC3D90@mac.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <E4B6A294-CE03-11D8-8B38-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: Atom Syntax <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: Re: PaceNoInfoSet -- building block vs. profile
Date: Sun, 4 Jul 2004 14:48:32 -0700
To: Graham <dtcd@mac.com>
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>
Content-Transfer-Encoding: 7bit


Interesting. If I read you correctly, this would mean that we'd say 
that Atom-the-format would be a data model that allows multiple 
serialisations, but only defines one, XML 1.0. Meanwhile 
Atom-the-protocol would require support for the defined XML 1.0 
serialisation, but would allow negotiation of other format 
serialisations when they're supported.

Correct? If so, +1 from me to the approach. It does mean we need to be 
careful about defining conformance of endpoints in the protocol, but I 
think that's a good thing.


On Jul 4, 2004, at 2:37 PM, Graham wrote:

> Back to the topic, I think the best approach, if we're going to allow 
> alternate serializations to be called Atom, is to have all endpoints 
> able to provide and consume XML 1.0, and there to be a standard way to 
> get to it.

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Sun Jul  4 18: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 SAA05758
	for <atompub-archive@lists.ietf.org>; Sun, 4 Jul 2004 18: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 i64M2O0K097076;
	Sun, 4 Jul 2004 15: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 i64M2O28097075;
	Sun, 4 Jul 2004 15:02:24 -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 i64M2Os1097067
	for <atom-syntax@imc.org>; Sun, 4 Jul 2004 15:02:24 -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 i64Lv3uo006515;
	Sun, 4 Jul 2004 17:57: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 BGX41629 (AUTH bob@wyman.us);
	Sun, 4 Jul 2004 18:02:25 -0400 (EDT)
Message-Id: <200407042202.BGX41629@ms8.netsolmail.com>
Reply-To: <bob@wyman.us>
From: "Bob Wyman" <bob@wyman.us>
To: "'Mark Nottingham'" <mnot@mnot.net>, "'Michael Champion'" <mc@xegesis.org>,
        "'Tim Bray'" <tbray@textuality.com>
Cc: "'Atom Syntax'" <atom-syntax@imc.org>
Subject: RE: PaceNoInfoSet
Date: Sun, 4 Jul 2004 18:00:30 -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: <D91F78DA-CDD4-11D8-B7F4-000A95BD86C0@mnot.net>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Thread-Index: AcRh5ijp8LAtyx6EQyeKRLV1K0VMHQAKivIg
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:
> It's also possible that people in the future might want to come
> up with a different serialisation of the model we describe Atom
> with;  however, they shouldn't call the result "Atom" without some
> kind of clarification (e.g., a different media type).
	How different must the media type be in order to be "acceptable" to
the Atom community?
	As is well known from previous discussions of this topic, I would
very much like to be able to use an alternative serialization in a number of
high volume applications for Atom. One very good looking alternative to XML
would be the "Fast Infoset"[1] that Sun is sponsoring through the ITU/ISO
standardization process. Fast Infoset is explicitly designed to encode the
XML Infoset in a compact and efficiently parsed format while ensuring that
one can build interfaces via SAX or even a version of GENX whose behavior is
largely indistinguishable from implementations that are written over
text-based XML. Once Fast Infoset is finished with its rounds through the
standardization process, I'd like to have
	application/atom+fastinfoset
as an alternative to:
	application/atom+xml

	This is a distinct media type but still contains the string
"atom"... Would that be acceptable?

		bob wyman

[1] http://java.sun.com/developer/technicalArticles/xml/fastinfoset/




From owner-atom-syntax@mail.imc.org  Sun Jul  4 19:39: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 TAA08042
	for <atompub-archive@lists.ietf.org>; Sun, 4 Jul 2004 19: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 i64NCt8P010116;
	Sun, 4 Jul 2004 16:12: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 i64NCtbi010113;
	Sun, 4 Jul 2004 16:12: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 i64NCsNJ010106
	for <atom-syntax@imc.org>; Sun, 4 Jul 2004 16:12:54 -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 i64NCqvw005996;
	Sun, 4 Jul 2004 19:12: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 BGX51071 (AUTH bob@wyman.us);
	Sun, 4 Jul 2004 19:12:58 -0400 (EDT)
Message-Id: <200407042312.BGX51071@ms8.netsolmail.com>
Reply-To: <bob@wyman.us>
From: "Bob Wyman" <bob@wyman.us>
To: "'Antone Roundy'" <antone@geckotribe.com>, <atom-syntax@imc.org>
Subject: RE: PaceEntryOrigin
Date: Sun, 4 Jul 2004 19:11:03 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0049_01C461FA.A6BC8EF0"
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <E61C0AED-C9D4-11D8-A64A-003065EA6144@geckotribe.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Thread-Index: AcRd5KLk5BmAZONPQ8+wPktDiiEsLAEMqtbg
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>


This is a multi-part message in MIME format.

------=_NextPart_000_0049_01C461FA.A6BC8EF0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Re: PaceEntryOrigin

 

      1) Clearly, I'm missing something very important in the way people are
thinking about Atom... I simply don't understand why everyone seems to
insist on overloading the link element whenever possible. It seems to me
that link, if used at all, would provide an interesting way to accommodate a
number of add-on extensions. However, if we know up-front that there is some
data that we want to have in a "standard" Atom feed or entry, why in the
world use link? Why not just provide an element which is custom designed for
the specific data? What does link give us that we can't get from a specific
element?

      Clearly, I think PaceEntryOrigin should *not* use link, but rather
have a specific element, like the "source-feed" element that we discussed at
the Atom community meeting and that PubSub.com has been supporting in its
Atom-over-Jabber feeds.

      2) As I have stated before, I think that when building a composite
feed, we need to communicate more than simply the URI of the origin feed.
Minimally, we should be able to pass along the title of the feed in addition
to the URI. It may also be necessary to pass along the copyright and/or
rights statements for the feed from which an entry was extracted. And, it
might even be reasonable to pass along information about the modified time
of the source feed. I think I could create reasonable arguments for needing
to pass *any* or *all* of the source feed's metadata.

      However, the current draft of PaceEntryOrigin only provides explicit
support for the URI (even though title is mentioned in the notes.) In any
case, since PaceEntryOrigin is relies on link, if accepted, we wouldn't be
able to include any data that couldn't be encoded in an attribute. If this
is the case, then let's just remove all the elements from feed and replace
them with attributes... If attributes are ok for PaceEntryOrigin, then they
must be ok for the feed itself...

      3. Let me provide an example of an application for PaceEntryOrigin: As
has been mentioned before, we at PubSub.com provide Atom feeds over the
Jabber/XMPP IM protocol. We've recently released via SourceForge,[1] a quick
little .NET application that allows you to receive notifications of updates
to RSS/Atom files in a window on your Windows desktop.[1] Notifications are
sent to the client application using Atom over Jabber and each notification
displayed contains: The date the entry was issued, the Title and URI of the
entry and the Title and URI of the feed the entry was taken from. An entry
in the display looks something like what you see below:

 


 <http://www.newsgator.com/news/archive.aspx?post=40> NewsGator
Technologies, Developer of Leading RSS Tools and Services, Closes Series A
Funding 

 


 <http://www.newsgator.com/> NewsGator News and Updates

 


Wed, 23 Jun 2004 06:15:00 GMT 

 

      Of course, people who write their own applications can get the full
content of the entry sent to them; however, we find that the minimal useful
content concerning an entry consists of the five elements that we display in
our application. I would very much like to be able to use "standard Atom" to
encode these notifications - but as PaceEntryOrigin is currently written, I
would have to continue to do something "proprietary" or non-standard in
order to pass the title of the origin or source feed. (I.e. I would have to
continue to use the ps:source-feed element that we've been using to-date.)
This is not a good thing. Also, I think it is not hard to imagine that some
people will claim that it is desirable to allow users to display additional
information such as feed copyright or rights, feed modification times, feed
descriptions, feed authors, etc. in this sort of display. But, if
PaceEntryOrigin doesn't provide for all that data to be attached to an
entry, I'm once again stuck doing non-standard stuff. 

 

      I strongly argue that PaceEntryOrigin should be based on a distinct
element (atom:origin would be fine), not an overloading of <link/> and that
it should be possible for the atom:origin element to carry any and all
feed-level meta-data. I am opposed to PaceEntryOrigin in its current form.

 

            bob wyman

 

[1] http://sourceforge.net/projects/pubsubxmpp/

 

 


------=_NextPart_000_0049_01C461FA.A6BC8EF0
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Verdana;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 77.95pt 1.0in 77.95pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Re: PaceEntryOrigin<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1) Clearly, I'm missing something =
very important
in the way people are thinking about Atom... I simply don't understand =
why
everyone seems to insist on overloading the link element whenever =
possible. It
seems to me that link, if used at all, would provide an interesting way =
to accommodate
a number of add-on extensions. However, if we know up-front that there =
is some
data that we want to have in a &quot;standard&quot; Atom feed or entry, =
why in
the world use link? Why not just provide an element which is custom =
designed
for the specific data? What does link give us that we can't get from a =
specific
element?<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Clearly, I think PaceEntryOrigin =
should
*not* use link, but rather have a specific element, like the
&quot;source-feed&quot; element that we discussed at the Atom community =
meeting
and that PubSub.com has been supporting in its Atom-over-Jabber =
feeds.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2) As I have stated before, I =
think that
when building a composite feed, we need to communicate more than simply =
the URI
of the origin feed. Minimally, we should be able to pass along the title =
of the
feed in addition to the URI. It may also be necessary to pass along the
copyright and/or rights statements for the feed from which an entry was
extracted. And, it might even be reasonable to pass along information =
about the
modified time of the source feed. I think I could create reasonable =
arguments
for needing to pass *any* or *all* of the source feed's =
metadata.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; However, the current draft of
PaceEntryOrigin only provides explicit support for the URI (even though =
title
is mentioned in the notes.) In any case, since PaceEntryOrigin is relies =
on
link, if accepted, we wouldn't be able to include any data that couldn't =
be encoded
in an attribute. If this is the case, then let's just remove all the =
elements
from feed and replace them with attributes... If attributes are ok for
PaceEntryOrigin, then they must be ok for the feed =
itself...<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3. Let me provide an example of =
an
application for PaceEntryOrigin: As has been mentioned before, we at =
PubSub.com
provide Atom feeds over the Jabber/XMPP IM protocol. We&#8217;ve =
recently released
via SourceForge,[1] a quick little .NET application that allows you to =
receive
notifications of updates to RSS/Atom files in a window on your Windows =
desktop.[1]
Notifications are sent to the client application using Atom over Jabber =
and
each notification displayed contains: The date the entry was issued, the =
Title
and URI of the entry and the Title and URI of the feed the entry was =
taken from.
An entry in the display looks something like what you see =
below:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;<o:p></o:p></span></font></p>

<table class=3DMsoNormalTable border=3D0 cellpadding=3D0 width=3D"100%"
 bgcolor=3D"#E5ECF9" style=3D'width:100.0%;background:#E5ECF9'>
 <tr>
  <td style=3D'padding:.75pt .75pt .75pt .75pt'>
  <p class=3DMsoNormal><font size=3D1 face=3DArial><span =
style=3D'font-size:9.0pt;
  font-family:Arial'><a
  href=3D"http://www.newsgator.com/news/archive.aspx?post=3D40" =
target=3D"_blank"><font
  face=3DVerdana><span style=3D'font-family:Verdana'>NewsGator =
Technologies,
  Developer of Leading RSS Tools and Services, Closes Series A =
Funding</span></font></a>
  <o:p></o:p></span></font></p>
  </td>
  <td style=3D'padding:.75pt .75pt .75pt .75pt'>
  <p class=3DMsoNormal><font size=3D1 face=3DArial><span =
style=3D'font-size:9.0pt;
  font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>
  </td>
 </tr>
 <tr>
  <td style=3D'padding:.75pt .75pt .75pt .75pt'>
  <p class=3DMsoNormal><font size=3D1 face=3DArial><span =
style=3D'font-size:9.0pt;
  font-family:Arial'><a href=3D"http://www.newsgator.com/" =
target=3D"_blank"><font
  size=3D1><span style=3D'font-size:8.0pt'>NewsGator News and =
Updates</span></font></a><o:p></o:p></span></font></p>
  </td>
  <td style=3D'padding:.75pt .75pt .75pt .75pt'>
  <p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span
  style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></p>
  </td>
 </tr>
 <tr>
  <td style=3D'padding:.75pt .75pt .75pt .75pt'>
  <p class=3DMsoNormal><font size=3D1 color=3Dlightseagreen =
face=3DArial><span
  style=3D'font-size:8.0pt;font-family:Arial;color:lightseagreen'>Wed, =
23 Jun
  2004 06:15:00 GMT <o:p></o:p></span></font></p>
  </td>
  <td style=3D'padding:.75pt .75pt .75pt .75pt'>
  <p class=3DMsoNormal><font size=3D1 face=3DArial><span =
style=3D'font-size:9.0pt;
  font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>
  </td>
 </tr>
</table>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Of course, people who write their =
own
applications can get the full content of the entry sent to them; =
however, we
find that the minimal useful content concerning an entry consists of the =
five
elements that we display in our application. I would very much like to =
be able
to use &#8220;standard Atom&#8221; to encode these notifications &#8211; =
but as
PaceEntryOrigin is currently written, I would have to continue to do =
something &#8220;proprietary&#8221;
or non-standard in order to pass the title of the origin or source feed. =
(I.e. I
would have to continue to use the ps:source-feed element that =
we&#8217;ve been
using to-date.) This is not a good thing. Also, I think it is not hard =
to
imagine that some people will claim that it is desirable to allow users =
to
display additional information such as feed copyright or rights, feed =
modification
times, feed descriptions, feed authors, etc. in this sort of display. =
But, if
PaceEntryOrigin doesn&#8217;t provide for all that data to be attached =
to an
entry, I&#8217;m once again stuck doing non-standard stuff. =
<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I strongly argue that =
PaceEntryOrigin
should be based on a distinct element (atom:origin would be fine), not =
an
overloading of &lt;link/&gt; and that it should be possible for the =
atom:origin
element to carry any and all feed-level meta-data. I am opposed to
PaceEntryOrigin in its current form.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; bob wyman<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>[1] <a =
href=3D"http://sourceforge.net/projects/pubsubxmpp/">http://sourceforge.n=
et/projects/pubsubxmpp/</a><o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0049_01C461FA.A6BC8EF0--



From owner-atom-syntax@mail.imc.org  Sun Jul  4 20:24: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 UAA10164
	for <atompub-archive@lists.ietf.org>; Sun, 4 Jul 2004 20:24: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 i6504QJg020587;
	Sun, 4 Jul 2004 17:04: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 i6504Qmx020586;
	Sun, 4 Jul 2004 17:04:26 -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 i6504PSE020559
	for <atom-syntax@imc.org>; Sun, 4 Jul 2004 17:04:25 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040705000426.60550.qmail@web41206.mail.yahoo.com>
Received: from [67.160.85.98] by web41206.mail.yahoo.com via HTTP; Sun, 04 Jul 2004 17:04:26 PDT
Date: Sun, 4 Jul 2004 17:04:26 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: PaceXmlBaseEverywhere
To: "Asbjørn_Ulsberg" <asbjorn@tigerstaden.no>
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <opsamugdemuvpchu@quark>
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>


--- Asbjørn_Ulsberg <asbjorn@tigerstaden.no> wrote:
> 
> > There's nothing stopping one from specifying that
> every element
> > can have xml:base and xml:lang in the schema.
> 
> No, but you have to explicitly allow it, no? If you
> don't assert that an  
> element can contain a 'xml:base' attribute in the
> schema, can it contain  
> the attribute nonetheless?

This should lead to an error during validation because
no xml:base attribute is defined for the element in
the schema. 
 

> Yes, well, I guess there isn't much of a problem. I
> just think it's  
> inconsistent that @href belongs to Atom, while the
> attribute controlling  
> @href's behaviour in respect to relative URI's is in
> the XML namespace. No  
> biggie.

Then you are raising a fundamental problem with XML as
a whole since this is how xml:base, xml:space and
xml:lang all work. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 



From owner-atom-syntax@mail.imc.org  Sun Jul  4 20: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 UAA10185
	for <atompub-archive@lists.ietf.org>; Sun, 4 Jul 2004 20:24: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 i64NlGhl017336;
	Sun, 4 Jul 2004 16:47: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 i64NlG2b017335;
	Sun, 4 Jul 2004 16:47: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 i64NlG2Y017319
	for <atom-syntax@imc.org>; Sun, 4 Jul 2004 16:47:16 -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 1BhGhV-00018I-FJ; Sun, 04 Jul 2004 23:47:13 +0000
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Sun, 04 Jul 2004 19:47:18 -0400
Subject: Re: PaceEntryOrigin
From: Robert Sayre <mint@franklinmint.fm>
To: Bob Wyman <bob@wyman.us>, "'Antone Roundy'" <antone@geckotribe.com>,
        Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD0E0F46.11F06%mint@franklinmint.fm>
In-Reply-To: <200407042312.BGX51071@ms8.netsolmail.com>
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: <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 7/4/04 7:11 PM, "Bob Wyman" <bob@wyman.us> wrote:

> Re: PaceEntryOrigin
> 
> 
> 
>     1) Clearly, I'm missing something very important in the way people are
> thinking about Atom... I simply don't understand why everyone seems to insist
> on overloading the link element whenever possible.

I'll troll again:
http://www.imc.org/atom-syntax/mail-archive/msg06039.html

Who is in favor of using the link element at all?

Robert Sayre



From owner-atom-syntax@mail.imc.org  Sun Jul  4 21:12: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 VAA12007
	for <atompub-archive@lists.ietf.org>; Sun, 4 Jul 2004 21:12: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 i650tCM8030511;
	Sun, 4 Jul 2004 17:55: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 i650tCIX030510;
	Sun, 4 Jul 2004 17:55:12 -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 i650tBxk030494
	for <atom-syntax@imc.org>; Sun, 4 Jul 2004 17:55:11 -0700 (PDT)
	(envelope-from jfc@datajournal.dj)
Received: from f01v-22-210.d0.club-internet.fr ([212.195.247.210] helo=jfc2.datajournal.dj)
	by montage.altserver.com with esmtp (Exim 4.34)
	id 1BhHlF-0002UH-Lx; Sun, 04 Jul 2004 17:55:10 -0700
Message-Id: <6.1.1.1.2.20040705012822.04c3ceb0@mail.datajournal.dj>
X-Sender: jfc+datajournal.dj@mail.datajournal.dj
X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1
Date: Mon, 05 Jul 2004 01:32:17 +0200
To: <bob@wyman.us>, "'Mark Nottingham'" <mnot@mnot.net>,
        "'Michael Champion'" <mc@xegesis.org>,
        "'Tim Bray'" <tbray@textuality.com>
From: DJWS <jfc@datajournal.dj>
Subject: RE: PaceNoInfoSet
Cc: "'Atom Syntax'" <atom-syntax@imc.org>
In-Reply-To: <200407042202.BGX41629@ms8.netsolmail.com>
References: <D91F78DA-CDD4-11D8-B7F4-000A95BD86C0@mnot.net>
 <200407042202.BGX41629@ms8.netsolmail.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 - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - datajournal.dj
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 00:00 05/07/04, Bob Wyman wrote:
>Fast Infoset is explicitly designed to encode the XML Infoset in a compact 
>and efficiently parsed format while ensuring that one can build interfaces 
>via SAX or even a version of GENX whose behavior is largely 
>indistinguishable from implementations that are written over text-based 
>XML. Once Fast Infoset is finished with its rounds through the 
>standardization process, I'd like to have application/atom+fastinfoset as 
>an alternative to: application/atom+xml

Could it be not supported in using ASN.1. I understand that Fast Infoset is 
only a Java version of ASN.1 support ? Are there no "C" existing tools 
which could be used with ATOM now ? (My main initial interest in ATOM is 
that support).
Thank you.
Jefsey Morfin

>This is a distinct media type but still contains the string "atom"... 
>Would that be acceptable?
>                 bob wyman
>
>[1] http://java.sun.com/developer/technicalArticles/xml/fastinfoset/



From owner-atom-syntax@mail.imc.org  Sun Jul  4 21:34: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 VAA12599
	for <atompub-archive@lists.ietf.org>; Sun, 4 Jul 2004 21:34: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 i651G8Hl034369;
	Sun, 4 Jul 2004 18:16: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 i651G89b034368;
	Sun, 4 Jul 2004 18:16:08 -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 i651G75W034352
	for <atom-syntax@imc.org>; Sun, 4 Jul 2004 18:16:07 -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 i651Kah8012459;
	Sun, 4 Jul 2004 21:20: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 BGX69310 (AUTH bob@wyman.us);
	Sun, 4 Jul 2004 21:16:10 -0400 (EDT)
Message-Id: <200407050116.BGX69310@ms8.netsolmail.com>
Reply-To: <bob@wyman.us>
From: "Bob Wyman" <bob@wyman.us>
To: "'Mark Nottingham'" <mnot@mnot.net>, "'Graham'" <dtcd@mac.com>
Cc: "'Atom Syntax'" <atom-syntax@imc.org>
Subject: RE: PaceNoInfoSet -- building block vs. profile
Date: Sun, 4 Jul 2004 21:14:15 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <E4B6A294-CE03-11D8-8B38-000A95BD86C0@mnot.net>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Thread-Index: AcRiFchyYSZO1d/+TLu8rTSbGFUj2gAFxfqw
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:
> If I read you correctly, this would mean that we'd say 
> that Atom-the-format would be a data model that allows multiple
> serialisations, but only defines one, XML 1.0. Meanwhile 
> Atom-the-protocol would require support for the defined XML 1.0 
> serialisation, but would allow negotiation of other format 
> serialisations when they're supported.
	+1 (It would be *excellent* if this were the case!)

		bob wyman
 



From owner-atom-syntax@mail.imc.org  Sun Jul  4 21:46:08 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12906
	for <atompub-archive@lists.ietf.org>; Sun, 4 Jul 2004 21:46:08 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i651U5Nb036751;
	Sun, 4 Jul 2004 18:30: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 i651U59O036750;
	Sun, 4 Jul 2004 18:30:05 -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 i651U4IO036744
	for <atom-syntax@imc.org>; Sun, 4 Jul 2004 18:30:04 -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 i651Oluo000513;
	Sun, 4 Jul 2004 21:24: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 BGX71510 (AUTH bob@wyman.us);
	Sun, 4 Jul 2004 21:30:08 -0400 (EDT)
Message-Id: <200407050130.BGX71510@ms8.netsolmail.com>
Reply-To: <bob@wyman.us>
From: "Bob Wyman" <bob@wyman.us>
To: "'DJWS'" <jfc@datajournal.dj>, <bob@wyman.us>,
        "'Mark Nottingham'" <mnot@mnot.net>,
        "'Michael Champion'" <mc@xegesis.org>,
        "'Tim Bray'" <tbray@textuality.com>
Cc: "'Atom Syntax'" <atom-syntax@imc.org>
Subject: RE: PaceNoInfoSet
Date: Sun, 4 Jul 2004 21:28: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: <6.1.1.1.2.20040705012822.04c3ceb0@mail.datajournal.dj>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Thread-Index: AcRiKtcXj2txPw3RQbym+vKs+A0b4gAAuLxg
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


DJWS wrote:
> I understand that Fast Infoset is only a Java version of ASN.1 support ?

	There is absolutely no relationship between Java and Fast Infoset. 

	Fast Infoset is defined using an ASN.1 schema and uses ASN.1 PER as
an encoding format. Thus, any code that can deal with PER can read and write
Fast Infoset. However, I'm confident that most users of Fast Infoset won't
know or even care that an ASN.1 defined binary encoding is being used. This
is because Fast Infoset involves only one very simple, fixed schema for the
infoset and only uses a small portion of the full power of PER. Thus, my
expectation is that it will be very easy to produce open-source modules that
work with Fast Infoset. The situation will be the same as exists today with
libaries that read and write X.500 certificates (which are encoded using
binary ASN.1). There are many code libraries that encode and decode X.500
certificates with great ease and facility but are not capable of dealing
with any other binary data.
	I expect that since Sun is a strong supporter of Fast Infoset, they
will probably lead in developing Java-based tools to work with it. However,
this is not because of any linkage between Fast Infoset and Java, rather, it
is just because Sun is a strong supporter of both Java and Fast Infoset.
We'll have to wait for the Fast Infoset standard to get finished and in the
field before we know what the actual support will look like. I think,
however, that you should assume that good C support will be available.

		bob wyman




From owner-atom-syntax@mail.imc.org  Sun Jul  4 22:19: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 WAA14118
	for <atompub-archive@lists.ietf.org>; Sun, 4 Jul 2004 22:19: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 i6524I0u043546;
	Sun, 4 Jul 2004 19:04: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 i6524I0J043545;
	Sun, 4 Jul 2004 19:04:18 -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 i6524HWl043522
	for <atom-syntax@imc.org>; Sun, 4 Jul 2004 19:04:17 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040705020419.93177.qmail@web41205.mail.yahoo.com>
Received: from [67.160.85.98] by web41205.mail.yahoo.com via HTTP; Sun, 04 Jul 2004 19:04:18 PDT
Date: Sun, 4 Jul 2004 19:04:18 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: RE: PaceNoInfoSet
To: bob@wyman.us, "'DJWS'" <jfc@datajournal.dj>,
        "'Mark Nottingham'" <mnot@mnot.net>,
        "'Michael Champion'" <mc@xegesis.org>,
        "'Tim Bray'" <tbray@textuality.com>
Cc: "'Atom Syntax'" <atom-syntax@imc.org>
In-Reply-To: <200407050130.BGX71510@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: <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:
> 
> We'll have to wait for the Fast Infoset standard to
> get finished and in the
> field before we know what the actual support will
> look like. 

Which standards body has Fast Infoset been submitted
to? 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail 



From owner-atom-syntax@mail.imc.org  Sun Jul  4 23:06: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 XAA15859
	for <atompub-archive@lists.ietf.org>; Sun, 4 Jul 2004 23:06: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 i652mUYU051450;
	Sun, 4 Jul 2004 19:48: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 i652mU06051449;
	Sun, 4 Jul 2004 19:48: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 i652mSaT051361
	for <atom-syntax@imc.org>; Sun, 4 Jul 2004 19:48:29 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Mon, 5 Jul 2004 12:52:50 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Mon, 05 Jul 2004 12:39:52 +1000
Subject: Re: PaceEntryOrigin
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD0EFC98.1D4F2%eric.scheid@ironclad.net.au>
In-Reply-To: <BD0E0F46.11F06%mint@franklinmint.fm>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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 5/7/04 9:47 AM, "Robert Sayre" <mint@franklinmint.fm> wrote:

> Who is in favor of using the link element at all?

here is some psuedo-code for handling the <link> element...

    getEntryElements(theEntryNode)
    for each <link>
        injectLink(href,title,type, rel)
    end. 

on the other hand, the psuedo-code to handle all manner of different element
names (including namespaced extensions) would be quite a bit longer, and
also pretty much incapable of handling link types which are unknown at the
time of writing the code.

e.



From owner-atom-syntax@mail.imc.org  Mon Jul  5 00:24:05 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20508
	for <atompub-archive@lists.ietf.org>; Mon, 5 Jul 2004 00:24: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 i653vh3U066938;
	Sun, 4 Jul 2004 20:57: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 i653vhlx066937;
	Sun, 4 Jul 2004 20:57:43 -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 i653vN0C066840
	for <atom-syntax@imc.org>; Sun, 4 Jul 2004 20:57:42 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.8] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id 0C3E77288; Sun,  4 Jul 2004 20:57:17 -0700 (PDT)
In-Reply-To: <20040705020419.93177.qmail@web41205.mail.yahoo.com>
References: <20040705020419.93177.qmail@web41205.mail.yahoo.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <66E731F3-CE37-11D8-8B38-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: "'Tim Bray'" <tbray@textuality.com>, "'DJWS'" <jfc@datajournal.dj>,
        "'Michael Champion'" <mc@xegesis.org>,
        "'Atom Syntax'" <atom-syntax@imc.org>, bob@wyman.us
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: PaceNoInfoSet
Date: Sun, 4 Jul 2004 20:57:15 -0700
To: Dare Obasanjo <kpako@yahoo.com>
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>
Content-Transfer-Encoding: 7bit


Fast Infoset is being standardised by a joint committee of ISO -- the 
mother of all standards organisations -- and ITU.
   http://www.itu.int/ITU-T/asn1/workprogram.html

This doesn't mean that it will be successful, adopted by the market, or 
the right thing to do technically, but you certainly can't say that it 
isn't a "real standard"; arguably, it's more real than XML, HTTP and 
all the rest, as ISO is a de jure standards organisation, unlike the 
W3C and IETF, which are both "mere" consortia.

That also doesn't mean that it's what most people would call an "open" 
process, hence the paucity of information available online.


On Jul 4, 2004, at 7:04 PM, Dare Obasanjo wrote:

>
> Which standards body has Fast Infoset been submitted
> to?

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Mon Jul  5 04:47: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 EAA14973
	for <atompub-archive@lists.ietf.org>; Mon, 5 Jul 2004 04:47: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 i658TLTg074620;
	Mon, 5 Jul 2004 01: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 i658TLwi074618;
	Mon, 5 Jul 2004 01:29:21 -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 i658TLqs074585
	for <atom-syntax@imc.org>; Mon, 5 Jul 2004 01:29:21 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040705082911.62130.qmail@web41207.mail.yahoo.com>
Received: from [67.160.85.98] by web41207.mail.yahoo.com via HTTP; Mon, 05 Jul 2004 01:29:11 PDT
Date: Mon, 5 Jul 2004 01:29:11 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: PaceEntryOrigin
To: Eric Scheid <eric.scheid@ironclad.net.au>,
        Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <BD0EFC98.1D4F2%eric.scheid@ironclad.net.au>
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>


--- Eric Scheid <eric.scheid@ironclad.net.au> wrote:
>
> > Who is in favor of using the link element at all?
> 
> here is some psuedo-code for handling the <link>
> element...
> 
>     getEntryElements(theEntryNode)
>     for each <link>
>         injectLink(href,title,type, rel)
>     end. 
> 
> on the other hand, the psuedo-code to handle all
> manner of different element
> names (including namespaced extensions) would be
> quite a bit longer, and
> also pretty much incapable of handling link types
> which are unknown at the
> time of writing the code.

I find this argument very suspect. Your argument
assumes that all <link> elements are similar enough
that they can be treated in some default identical
manner by Atom consumers. As an aggregator author,
lets assume I decide to render all links that are part
as hyperlinks that the user can click on. Let's see
whether this default logic works for the proposed link
types thus far. Taking a look at 
http://intertwingly.net/wiki/pie/LinkTagMeaning I
count about 14 or 15 values for the rel attribute. If
I implemented the same behavior for all 14 types of
links in RSS Bandit [render a clickable link], at
least half of these could be considered incorrect ways
to support these features (e.g. service.edit,
service.post, comments, transform.input,
transform.output, icon, etc). Making all these things
links is misleading since it implies that they can be
treated consistently when in truth they cannot. 

The entire concept of extensibility through <link>
elements is built on a faulty premise and is an
example chasing of a false goal[0]. 

Also, the focus on link based extensions ignores the
fact that lots of extensions to entries won't be links
if history from RSS is any guide[1, 2,3]. 

[0]
http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=fbe8824b-79e5-459d-98b0-b7153d0eda0e
[1]
http://blogs.law.harvard.edu/tech/directory/5/specifications/rss20ModulesNamespaces
[2] http://web.resource.org/rss/1.0/modules/dc/
[3] http://web.resource.org/rss/1.0/modules/dcterms/

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail 



From owner-atom-syntax@mail.imc.org  Mon Jul  5 05:41: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 FAA16735
	for <atompub-archive@lists.ietf.org>; Mon, 5 Jul 2004 05:41: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 i659QxvJ094792;
	Mon, 5 Jul 2004 02:26: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 i659Qxd7094791;
	Mon, 5 Jul 2004 02:26:59 -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 i659QwUP094746
	for <atom-syntax@imc.org>; Mon, 5 Jul 2004 02:26:59 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 93739 messnum 9205663 invoked from network[62.77.172.85/62-77-172-85.customer.eircom.net]); 5 Jul 2004 09:26:53 -0000
Received: from 62-77-172-85.customer.eircom.net (HELO ?200.200.200.38?) (62.77.172.85)
  by mail10.svc.cra.dublin.eircom.net (qp 93739) with SMTP; 5 Jul 2004 09:26:53 -0000
Message-ID: <40E91EDC.20404@dehora.net>
Date: Mon, 05 Jul 2004 10:26:52 +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: PaceEntryOrigin
References: <200407042312.BGX51071@ms8.netsolmail.com>
In-Reply-To: <200407042312.BGX51071@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: <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:

>       1) Clearly, I'm missing something very important in the way people 
> are thinking about Atom... I simply don't understand why everyone seems 
> to insist on overloading the link element whenever possible. 

Not "everyone". If you look through the archives you will see a 
number of people have questioned the way link is used.


>       Clearly, I think PaceEntryOrigin should *not* use link, but rather 
> have a specific element, like the "source-feed" element that we 
> discussed at the Atom community meeting and that PubSub.com has been 
> supporting in its Atom-over-Jabber feeds.

The Pace's mainline wording has such an element. The link option I 
provided, because it seemed to me, inevitable, that it would arise 
in discussion.


>       2) As I have stated before, I think that when building a composite 
> feed, we need to communicate more than simply the URI of the origin 
> feed. Minimally, we should be able to pass along the title of the feed 
> in addition to the URI. It may also be necessary to pass along the 
> copyright and/or rights statements for the feed from which an entry was 
> extracted. And, it might even be reasonable to pass along information 
> about the modified time of the source feed. I think I could create 
> reasonable arguments for needing to pass *any* or *all* of the source 
> feed's metadata.
 >
 > [...]
>       I strongly argue that PaceEntryOrigin should be based on a 
> distinct element (atom:origin would be fine), not an overloading of 
> <link/> and that it should be possible for the atom:origin element to 
> carry any and all feed-level meta-data. I am opposed to PaceEntryOrigin 
> in its current form.

Will you propose atom:origin have child elements? Otherwise if you 
want these things, then you should create arguments for them - feel 
free to update the wiki page with such an option.

cheers
Bill




From owner-atom-syntax@mail.imc.org  Mon Jul  5 05: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 FAA16974
	for <atompub-archive@lists.ietf.org>; Mon, 5 Jul 2004 05:46: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 i659VAPM096358;
	Mon, 5 Jul 2004 02: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 i659VA2C096357;
	Mon, 5 Jul 2004 02:31:10 -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 i659V9lP096317
	for <atom-syntax@imc.org>; Mon, 5 Jul 2004 02:31:10 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 45700 messnum 2832007 invoked from network[62.77.172.85/62-77-172-85.customer.eircom.net]); 5 Jul 2004 09:31:04 -0000
Received: from 62-77-172-85.customer.eircom.net (HELO ?200.200.200.38?) (62.77.172.85)
  by mail07.svc.cra.dublin.eircom.net (qp 45700) with SMTP; 5 Jul 2004 09:31:04 -0000
Message-ID: <40E91FD7.8050604@dehora.net>
Date: Mon, 05 Jul 2004 10:31:03 +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: PaceEntryOrigin
References: <BD0EFC98.1D4F2%eric.scheid@ironclad.net.au>
In-Reply-To: <BD0EFC98.1D4F2%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:


> here is some psuedo-code for handling the <link> element...
> 
>     getEntryElements(theEntryNode)
>     for each <link>
>         injectLink(href,title,type, rel)
>     end. 
> 
> on the other hand, the psuedo-code to handle all manner of different element
> names (including namespaced extensions) would be quite a bit longer, and
> also pretty much incapable of handling link types which are unknown at the
> time of writing the code.

I don't buy that argument. The way link is currently to supply 
control codes, you will have a switch somewhere.  In your case it 
will be inside injectLink(). So, above, how will I handle the rel I 
haven't seen before?

cheers
Bill



From owner-atom-syntax@mail.imc.org  Mon Jul  5 07:24: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 HAA21097
	for <atompub-archive@lists.ietf.org>; Mon, 5 Jul 2004 07:24: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 i65B6jZa015668;
	Mon, 5 Jul 2004 04:06: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 i65B6jEo015667;
	Mon, 5 Jul 2004 04:06:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i65B6gIn015615
	for <atom-syntax@imc.org>; Mon, 5 Jul 2004 04:06:44 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Mon, 5 Jul 2004 21:11:15 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Mon, 05 Jul 2004 20:16:10 +1000
Subject: Re: PaceEntryOrigin
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD0F678A.1D5AE%eric.scheid@ironclad.net.au>
In-Reply-To: <40E91FD7.8050604@dehora.net>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i65B6jIn015662
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 5/7/04 7:31 PM, "Bill de hÓra" <bill@dehora.net> wrote:

> I don't buy that argument. The way link is currently to supply
> control codes, you will have a switch somewhere.  In your case it
> will be inside injectLink(). So, above, how will I handle the rel I
> haven't seen before?

do you mean a switch like

    if @rel is in {known & linkable} then
        write <a> link

or do you mean a switch like

    if @rel is not in {known & unlinkable} then
        write <a> link

e.




From owner-atom-syntax@mail.imc.org  Mon Jul  5 07:28: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 HAA21320
	for <atompub-archive@lists.ietf.org>; Mon, 5 Jul 2004 07:28: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 i65B6jFe015661;
	Mon, 5 Jul 2004 04:06: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 i65B6jHF015660;
	Mon, 5 Jul 2004 04:06:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i65B6g9v015598
	for <atom-syntax@imc.org>; Mon, 5 Jul 2004 04:06:44 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Mon, 5 Jul 2004 21:11:02 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Mon, 05 Jul 2004 21:06:08 +1000
Subject: Re: PaceEntryOrigin
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD0F7340.1D5C1%eric.scheid@ironclad.net.au>
In-Reply-To: <20040705082911.62130.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: <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 5/7/04 6:29 PM, "Dare Obasanjo" <kpako@yahoo.com> wrote:

> I find this argument very suspect. Your argument
> assumes that all <link> elements are similar enough
> that they can be treated in some default identical
> manner by Atom consumers.

Well, there *is* a pace suggesting that non-clickable <link>s like
'service.edit' be done in some other element.

> As an aggregator author,
> lets assume I decide to render all links that are part
> as hyperlinks that the user can click on.

Why handicap yourself? As an aggregator *user* I already do more than simply
"click" on hyperlinks. One example: in my pubsub feeds I sometimes drag the
blog URL to NNW's subscription panel, which usually causes NNW to subscribe
to the feed for that blog. No side trip to a browser necessary.

(it fails where the auto-discovery links at the site are not 100%, but if
pubsub had the feed URI in the entry

> Let's see whether this default logic works for the proposed link types thus
> far. Taking a look at http://intertwingly.net/wiki/pie/LinkTagMeaning I count
> about 14 or 15 values for the rel attribute.

Whoa there nellie! Some of those @rel values are for feed level links only.
I count 11 which are usable at the entry level (and six which are feed level
... are there some which you are not counting?)

> If I implemented the same behavior for all 14 types of links in RSS Bandit
> [render a clickable link], at least half of these could be considered
> incorrect ways to support these features (e.g. service.edit, service.post,
> comments, transform.input, transform.output, icon, etc). Making all these
> things links is misleading since it implies that they can be treated
> consistently when in truth they cannot.

Considering only the rel values relevant to entries, there are then just 2
link types which are not directly usable: service.post and service.post ...
which as noted above may not even end up being in <link> elements.

> Also, the focus on link based extensions ignores the fact that lots of
> extensions to entries won't be links if history from RSS is any guide[1, 2,3].

I don't know anyone who is suggesting that (eg) <dc:subject> should be
written as <link>, or that the utility of <link> excludes the possibility of
<dc:subject>

e.



From owner-atom-syntax@mail.imc.org  Mon Jul  5 08: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 IAA22609
	for <atompub-archive@lists.ietf.org>; Mon, 5 Jul 2004 08:08: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 i65BsuFc018684;
	Mon, 5 Jul 2004 04: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 i65Bsuwb018683;
	Mon, 5 Jul 2004 04:54:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i65Bst8C018669
	for <atom-syntax@imc.org>; Mon, 5 Jul 2004 04:54:55 -0700 (PDT)
	(envelope-from gstein@google.com)
Received: from buu.corp.google.com (gpsi1.corp.google.com [10.3.0.251])
	by 216-239-45-4.google.com (8.12.11/8.12.9) with ESMTP id i65Bsn1c009060
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 5 Jul 2004 04:54:49 -0700
Received: from gstein by buu.corp.google.com with local (Exim 4.14 #4)
	id 1BhS3d-0007QS-Br by authid <gstein>; Mon, 05 Jul 2004 04:54:49 -0700
Date: Mon, 5 Jul 2004 04:54:49 -0700
From: Greg Stein <gstein@google.com>
To: Ezra Cooper <ezra@sixapart.com>
Cc: atom-syntax@imc.org
Subject: Re: PaceSecurityServices & Digest auth
Message-ID: <20040705115449.GA27740@google.com>
References: <37DF50E8-CB00-11D8-8081-000A95CFF6CC@sixapart.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <37DF50E8-CB00-11D8-8081-000A95CFF6CC@sixapart.com>
User-Agent: Mutt/1.4.1i
X-URL: http://www.lyra.org/greg/
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


On Wed, Jun 30, 2004 at 06:44:40PM -0700, Ezra Cooper wrote:
>...
> I see three issues to be addressed with Digest:
> 
>   (1) Some web-servers remove the WWW-Authenticate header before 
> passing it to a CGI program.

This is on purpose. Very, very much so.

The mechanism for passing information from the web server to the CGI
program is via the environment. The particular scenario that you're trying
to solve is "my ISP let's me write a CGI, and I can't enable authn within
the web server itself [so I must do authn in the CGI script]".

Now carry this forward a couple steps. In some environments, suExec is
being used so the script runs as the user who wrote the thing. But in some
environments, the CGI runs as the same user as the httpd process. Or, in
other words, *all* CGI scripts run that way.

Now you've got a bunch of CGI scripts all running as the same uid, and
you've got some authn information sitting in the environment of some. Now
some cracker comes along and simply dumps out /proc/*/environ from his own
CGI. Sure, many can't be read, but some *can*. And now he has your
password.

Apache does not pass the Authorization header to CGIs because it is a
security hole. A big one. You can enable it if you want, but you're going
to have to pass -DSECURITY_HOLD_PASS_AUTHORIZATION to the Apache build.
That symbol isn't a joke. It really is a hole if that goes into the env.

>   (2) We need an equivalent method for use within a SOAP message.
>   (3) The default HTTP Digest auth algorithm is based on MD5, and 
> requires the server to be able to form an MD5 hash based on the triple 
> (username, realm, password). If you don't store either the cleartext 
> password or that specific hash, you're out of luck.

"or that specific hash" seems to solve the problem just fine. What's the
issue here?

> To address (1), I propose this addition to the end of section K,kk. in 
> PaceSecurityServices:
> 
> ========
> An Atom client MAY authenticate itself to an Atom server by sending an 
> X-Atom-Authenticate HTTP header, in the same form as for the 
> WWW-Authenticate header [RFC2617]. If an Atom client sends a 
> WWW-Authenticate header, it SHOULD have the same value as the 
> X-Atom-Authenticate header.
> ========

This simply introduces a security hole, which is not something we should
be advocating or encouraging. I'll -1 this right now. And if I'm feeling
particularly evil, I'll go update the httpd server to filter this header,
too (big <wink>!)

>...
> As to (2), I suggest that we simply tunnel the header fields of HTTP 
> Digest Auth within XML elements (the same way we've done with WSSE). 
> Using WSSE UsernameToken is attractive, except for requiring the server 
> to store the password in the clear. I'll be interested what others 
> think about this.

Why not just use WSSE? Above, you take issue with storing cleartext digest
passwords. Can't you just use WSSE and demand that the hashed-form of that
authn mechanism be used?

> To address the third issue, I'd like to propose some alternative 
> "algorithms" (in the sense of RFC 2617) for Digest auth. In particular

The server should just store the hashed forms. I don't see a big problem
here.

I can't see that introducing alternate algorithms will fix it, either.
Digest authn has a basic structural weakness (to exposure of the
server-side cleartext passwords or hashes) because of how (and what)
information is traded between server and client. You aren't going to get
around that unless you move to something more akin to SSL (and hashing
arbitrary values, rather than just coughing up a particular hash result).


IMO, use SSL. Failing that, use Digest. Failing that, use WSSE with a
hashed secret (no plaintext!). I don't know that Yet Another
Authentication Mechanism needs to be defined.

Cheers,
-g



From owner-atom-syntax@mail.imc.org  Mon Jul  5 10:53: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 KAA01778
	for <atompub-archive@lists.ietf.org>; Mon, 5 Jul 2004 10:53:34 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i65ES8bV030636;
	Mon, 5 Jul 2004 07:28: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 i65ES89a030635;
	Mon, 5 Jul 2004 07:28:08 -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 i65ES7JK030623
	for <atom-syntax@imc.org>; Mon, 5 Jul 2004 07:28:07 -0700 (PDT)
	(envelope-from antone@geckotribe.com)
Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134])
          by comcast.net (rwcrmhc13) with SMTP
          id <20040705142802015003m34ve>; Mon, 5 Jul 2004 14:28:03 +0000
Date: Mon, 5 Jul 2004 08:28:01 -0600
Subject: Re: PaceEntryOrigin
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: <BD0EFC98.1D4F2%eric.scheid@ironclad.net.au>
Message-Id: <850388B3-CE8F-11D8-A656-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 Sunday, July 4, 2004, at 08:39  PM, Eric Scheid wrote:
>> Who is in favor of using the link element at all?
>
> here is some psuedo-code for handling the <link> element...
>
>     getEntryElements(theEntryNode)
>     for each <link>
>         injectLink(href,title,type, rel)
>     end.
>
> on the other hand, the psuedo-code to handle all manner of different 
> element
> names (including namespaced extensions) would be quite a bit longer, 
> and
> also pretty much incapable of handling link types which are unknown at 
> the
> time of writing the code.
>
+1.  I'm in favor of <link>, but also in favor of limiting its scope as 
noted in PaceLinkPurpose.  Sure, people try to overload it with too 
many uses, but I'm not convinced that throwing it out altogether is the 
way to go.  It could be argued that link[@rel='start'], 
link[@rel='next'], and link[@rel='prev'] could all go into a <navigate> 
element or something--that provides nice grouping.  But on the other 
hand, those things clearly ARE links whether they end up being <link>s 
or not.  Turning those three into <start>, <next> and <prev> on the 
other hand, would result, I think, in far too many different elements 
that all do almost exactly the same things--it creates clutter. 
<navigate> would be a less extreme example of the same thing.



From owner-atom-syntax@mail.imc.org  Mon Jul  5 11:01: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 LAA02149
	for <atompub-archive@lists.ietf.org>; Mon, 5 Jul 2004 11:01: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 i65EfwvD032240;
	Mon, 5 Jul 2004 07:41:58 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i65Efw0T032239;
	Mon, 5 Jul 2004 07:41:58 -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 i65EfvFo032224
	for <atom-syntax@imc.org>; Mon, 5 Jul 2004 07:41: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 (rwcrmhc11) with SMTP
          id <2004070514415501300jdp1fe>; Mon, 5 Jul 2004 14:41:55 +0000
Date: Mon, 5 Jul 2004 08:41:53 -0600
Subject: Re: PaceEntryOrigin
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: <BD0F7340.1D5C1%eric.scheid@ironclad.net.au>
Message-Id: <75153354-CE91-11D8-A656-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 Monday, July 5, 2004, at 05:06  AM, Eric Scheid wrote:
>> I find this argument very suspect. Your argument
>> assumes that all <link> elements are similar enough
>> that they can be treated in some default identical
>> manner by Atom consumers.
>
> Well, there *is* a pace suggesting that non-clickable <link>s like
> 'service.edit' be done in some other element.
>
In addition to PaceLinkPurpose, there's a specific proposal for 
service.*: PaceServiceElement.  PaceLinkPurpose would require new 
solutions for transform.input, transform.output, and icon as well, 
reducing the list in LinkTagMeaning from 16 to 10 distinct values.  
Assuming that in a feed reader, clicking a link to a feed (or entry in 
Atom format) works better than it does in the average web browser, the 
rest would not be unreasonable to render as a clickable link.

http://www.intertwingly.net/wiki/pie/PaceLinkPurpose
http://www.intertwingly.net/wiki/pie/PaceServiceElement
http://www.intertwingly.net/wiki/pie/LinkTagMeaning



From owner-atom-syntax@mail.imc.org  Mon Jul  5 12:07: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 MAA04798
	for <atompub-archive@lists.ietf.org>; Mon, 5 Jul 2004 12:07: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 i65FdoHe037171;
	Mon, 5 Jul 2004 08:39: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 i65Fdo5Z037170;
	Mon, 5 Jul 2004 08:39:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i65Fdn2a037162
	for <atom-syntax@imc.org>; Mon, 5 Jul 2004 08:39:49 -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 1BhVZH-0000Wy-Br; Mon, 05 Jul 2004 15:39:43 +0000
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Mon, 05 Jul 2004 11:39:49 -0400
Subject: Re: PaceEntryOrigin
From: Robert Sayre <mint@franklinmint.fm>
To: Dare Obasanjo <kpako@yahoo.com>, Eric Scheid <eric.scheid@ironclad.net.au>,
        Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD0EEE85.11F23%mint@franklinmint.fm>
In-Reply-To: <20040705082911.62130.qmail@web41207.mail.yahoo.com>
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: <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 7/5/04 4:29 AM, "Dare Obasanjo" <kpako@yahoo.com> wrote:

> 
> --- Eric Scheid <eric.scheid@ironclad.net.au> wrote:
>> 
>>> Who is in favor of using the link element at all?
>> 
>> here is some psuedo-code for handling the <link>
>> element...
>> 
>>     getEntryElements(theEntryNode)
>>     for each <link>
>>         injectLink(href,title,type, rel)
>>     end. 
>> 
>> on the other hand, the psuedo-code to handle all
>> manner of different element
>> names (including namespaced extensions) would be
>> quite a bit longer, and
>> also pretty much incapable of handling link types
>> which are unknown at the
>> time of writing the code.
> 
> I find this argument very suspect.

As do I. The other mechanisms that have been proposed (xlink, rdf/xml, etc)
are all capable of handling unknown link types.

> 
> The entire concept of extensibility through <link>
> elements is built on a faulty premise and is an
> example chasing of a false goal[0].
> 
> Also, the focus on link based extensions ignores the
> fact that lots of extensions to entries won't be links
> if history from RSS is any guide[1, 2,3].
>

Faulty premise indeed. html:link is broken and underspecified [4]. Browser
authors appear to deal with it as legacy baggage. No one uses the damn thing
in HTML and we've glommed onto it like it's the best thing ever! I agree
with Bob Wyman. I don't get it.

Robert Sayre


> [0]
> http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=fbe8824b-79e5-459d-98b0-
> b7153d0eda0e
> [1]
> http://blogs.law.harvard.edu/tech/directory/5/specifications/rss20ModulesNames
> paces
> [2] http://web.resource.org/rss/1.0/modules/dc/
> [3] http://web.resource.org/rss/1.0/modules/dcterms/
> 

[4] http://www.hixie.ch/specs/html/link/



From owner-atom-syntax@mail.imc.org  Mon Jul  5 12:32: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 MAA05757
	for <atompub-archive@lists.ietf.org>; Mon, 5 Jul 2004 12:32: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 i65GAnFR039449;
	Mon, 5 Jul 2004 09:10:49 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i65GAnaS039448;
	Mon, 5 Jul 2004 09:10: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 i65GAiXK039409
	for <atom-syntax@imc.org>; Mon, 5 Jul 2004 09:10:46 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 6 Jul 2004 02:14:48 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Tue, 06 Jul 2004 02:09:49 +1000
Subject: Re: PaceEntryOrigin
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD0FBA6D.1D67F%eric.scheid@ironclad.net.au>
In-Reply-To: <BD0EEE85.11F23%mint@franklinmint.fm>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


On 6/7/04 1:39 AM, "Robert Sayre" <mint@franklinmint.fm> wrote:

> As do I. The other mechanisms that have been proposed (xlink, rdf/xml, etc)
> are all capable of handling unknown link types.

You do realise that xlink has much more complicated semantics of linking,
right? For example, it has an attribute 'type' which could have values of
"simple", "extended", "locator", "arc", "resource", "title", or "none". Then
there are the other attributes like 'actuate'.

Do we really want to require atom applications to handle such a complicated
thing?

e.



From owner-atom-syntax@mail.imc.org  Mon Jul  5 12:50: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 MAA06526
	for <atompub-archive@lists.ietf.org>; Mon, 5 Jul 2004 12:50: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 i65GcWGT041303;
	Mon, 5 Jul 2004 09: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 i65GcW37041302;
	Mon, 5 Jul 2004 09:38:32 -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 i65GcWtC041295
	for <atom-syntax@imc.org>; Mon, 5 Jul 2004 09:38:32 -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 i65GcQvu026011;
	Mon, 5 Jul 2004 12:38:26 -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 BGZ37853 (AUTH bob@wyman.us);
	Mon, 5 Jul 2004 12:38:32 -0400 (EDT)
Message-Id: <200407051638.BGZ37853@ms8.netsolmail.com>
Reply-To: <bob@wyman.us>
From: "Bob Wyman" <bob@wyman.us>
To: "'Dare Obasanjo'" <kpako@yahoo.com>
Cc: "'Atom Syntax'" <atom-syntax@imc.org>
Subject: RE: PaceNoInfoSet
Date: Mon, 5 Jul 2004 12:36:38 -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: <20040705020419.93177.qmail@web41205.mail.yahoo.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Thread-Index: AcRiNH7l+bnPzf1mSVqdNqLsZE3jZwAdrPvQ
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:
>Which standards body has Fast Infoset been submitted to? 
	Fast Infoset[1] is the joint work of ISO/IEC-JTC1/SC6 [2] and
ITU-T/SG17[3,4]. Fast WebServices (aka: X.695)[5] is also a joint ISO/ITU
project.

		bob wyman

[1] http://java.sun.com/developer/technicalArticles/xml/fastinfoset/
[2] http://www.jtc1.org/: SC6 is the current home of X.400, X.500 and ASN.1
[3] http://www.itu.int/ITU-T/studygroups/com17/index.asp
[4] http://www.itu.int/ITU-T/asn1/
[5] http://java.sun.com/developer/technicalArticles/WebServices/fastWS/








From owner-atom-syntax@mail.imc.org  Mon Jul  5 13:04: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 NAA07034
	for <atompub-archive@lists.ietf.org>; Mon, 5 Jul 2004 13:04: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 i65GoOhs041887;
	Mon, 5 Jul 2004 09:50: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 i65GoOig041886;
	Mon, 5 Jul 2004 09:50:24 -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 i65GoNeK041873
	for <atom-syntax@imc.org>; Mon, 5 Jul 2004 09:50:23 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040705165017.69175.qmail@web41201.mail.yahoo.com>
Received: from [67.160.85.98] by web41201.mail.yahoo.com via HTTP; Mon, 05 Jul 2004 09:50:17 PDT
Date: Mon, 5 Jul 2004 09:50:17 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: PaceEntryOrigin
To: Eric Scheid <eric.scheid@ironclad.net.au>,
        Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <BD0FBA6D.1D67F%eric.scheid@ironclad.net.au>
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>


--- Eric Scheid <eric.scheid@ironclad.net.au> wrote:
> 
> On 6/7/04 1:39 AM, "Robert Sayre"
> <mint@franklinmint.fm> wrote:
> 
> > As do I. The other mechanisms that have been
> proposed (xlink, rdf/xml, etc)
> > are all capable of handling unknown link types.
> 
> You do realise that xlink has much more complicated
> semantics of linking,
> right? For example, it has an attribute 'type' which
> could have values of
> "simple", "extended", "locator", "arc", "resource",
> "title", or "none". Then
> there are the other attributes like 'actuate'.
> 
> Do we really want to require atom applications to
> handle such a complicated
> thing?

As link is currently being used in Atom it is quite
USELESS for aggregator authors to use it to do
anything meaningful with unknown links. At list with
XLink it allows finer grained semantics about the link
to be passed around besides title and URI. 

The simplicity you claim currently exists is due to
link being horribly underspecified not from some
elegant simplicity. 

Personally I think th etime has come to scale bank
this overuse of link and muddy semantics it
introduces. Atom is supposed to be a tightly specified
spec that helps aggregator authors. The current usage
of the link elements makes a mockery of that claim. 



=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
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 Jul  5 13: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 NAA08103
	for <atompub-archive@lists.ietf.org>; Mon, 5 Jul 2004 13:34: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 i65HJfnL043536;
	Mon, 5 Jul 2004 10:19: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 i65HJf1U043535;
	Mon, 5 Jul 2004 10:19: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 i65HJd8i043529
	for <atom-syntax@imc.org>; Mon, 5 Jul 2004 10:19:40 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 6 Jul 2004 03:24:34 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Tue, 06 Jul 2004 03:19:40 +1000
Subject: Re: PaceEntryOrigin
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Dare Obasanjo <kpako@yahoo.com>, Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD0FCACC.1D6E1%eric.scheid@ironclad.net.au>
In-Reply-To: <20040705165017.69175.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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


On 6/7/04 2:50 AM, "Dare Obasanjo" <kpako@yahoo.com> wrote:

> The simplicity you claim currently exists is due to link being horribly
> underspecified not from some elegant simplicity.
> 

Please identify in what ways <link> is underspecified. Perhaps all that is
needed is, um, specification text to be written.

So ... what parts of the 0.3 spec is ambiguous/contradictory/silent w.r.t.
<link>? In what ways can <link> be interpreted in more than one way that
will lead to confusion or interoperability problems?

e.



From owner-atom-syntax@mail.imc.org  Mon Jul  5 13:38: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 NAA08269
	for <atompub-archive@lists.ietf.org>; Mon, 5 Jul 2004 13:38: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 i65HEXGD043356;
	Mon, 5 Jul 2004 10: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 i65HEXi8043355;
	Mon, 5 Jul 2004 10:14:33 -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 i65HEX0T043349
	for <atom-syntax@imc.org>; Mon, 5 Jul 2004 10:14:33 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040705171426.80998.qmail@web41214.mail.yahoo.com>
Received: from [67.160.85.98] by web41214.mail.yahoo.com via HTTP; Mon, 05 Jul 2004 10:14:26 PDT
Date: Mon, 5 Jul 2004 10:14:26 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: PaceEntryOrigin
To: Eric Scheid <eric.scheid@ironclad.net.au>,
        Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <BD0F7340.1D5C1%eric.scheid@ironclad.net.au>
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>


--- Eric Scheid <eric.scheid@ironclad.net.au> wrote:
>
> Well, there *is* a pace suggesting that
> non-clickable <link>s like
> 'service.edit' be done in some other element.

That's a start. I'd also like to see some tightening
of the text around links providing guidelines for waht
should or should not be a link. It seems there are
currently a lot of Paces around link which makes it
hard to figure out which way forward to me. 
 
> > As an aggregator author,
> > lets assume I decide to render all links that are
> part
> > as hyperlinks that the user can click on.
> 
> Why handicap yourself? As an aggregator *user* I
> already do more than simply
> "click" on hyperlinks. One example: in my pubsub
> feeds I sometimes drag the
> blog URL to NNW's subscription panel, which usually
> causes NNW to subscribe
> to the feed for that blog. No side trip to a browser
> necessary.

The point of my example is that as currently
specified, the semantics of the various links is
inconsistent so aggregator authors can't just write
some generic foreach loop and process all links
identically. 

I'm also not sure what your example with NNW has to do
with anything. RSS Bandit has the same functionality
and I see it as orthogonal with dealing with how one
processes links in a generic manner. 

> 
> Considering only the rel values relevant to entries,
> there are then just 2
> link types which are not directly usable:
> service.post and service.post ...
> which as noted above may not even end up being in
> <link> elements.


I'd also count comments as not being directly usable
if clicked on directly.  However you do point out that
feed level links are quite problematic since the
majority of the links with inconsistent semantics as
links are feed level links.  



=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
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 Jul  5 14:03:22 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09129
	for <atompub-archive@lists.ietf.org>; Mon, 5 Jul 2004 14:03: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 i65HlU9W046305;
	Mon, 5 Jul 2004 10:47: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 i65HlUj7046304;
	Mon, 5 Jul 2004 10:47: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 i65HlRWx046297
	for <atom-syntax@imc.org>; Mon, 5 Jul 2004 10:47:29 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 6 Jul 2004 03:52:20 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Tue, 06 Jul 2004 03:47:26 +1000
Subject: Re: PaceEntryOrigin
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD0FD14E.1D6ED%eric.scheid@ironclad.net.au>
In-Reply-To: <20040705171426.80998.qmail@web41214.mail.yahoo.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


On 6/7/04 3:14 AM, "Dare Obasanjo" <kpako@yahoo.com> wrote:

> The point of my example is that as currently specified, the semantics of the
> various links is inconsistent so aggregator authors can't just write some
> generic foreach loop and process all links identically.

if PaceLinkPurpose is accepted, then the semantics are quite clear: the
<link> element provides a usable link between the entry and some other
resource, described by the @rel attribute. I'm not real happy about
"clickable" as usable can include drag/drop instead.

> I'm also not sure what your example with NNW has to do with anything. RSS
> Bandit has the same functionality and I see it as orthogonal with dealing with
> how one processes links in a generic manner.

it was a counter to your assumption:

    >> As an aggregator author, lets assume I decide to render
    >> all links that are part [of the entry] as hyperlinks that
    >> the user can click on.

I'm saying there are different things that can be done, apart from just
"clicking".

If we assume that links only exist to "click", and by that I assume result
in the linked resource being loaded into a browser window somewhere, then it
wouldn't make any sense to click on links which lead to atom feeds since no
one wants to read xml gobbledegook. However, if we assume that more things
can be done than simply "click", then a link to xml resources could be very
handy.

>> Considering only the rel values relevant to entries, there are then just 2
>> link types which are not directly usable: service.post and service.edit ...
>> which as noted above may not even end up being in <link> elements.
> 
> I'd also count comments as not being directly usable if clicked on directly.

Why would "An Atom Feed for all comments on just this entry" not be useful
if "clicked" on directly (where "clicked" includes "dragged to subscriptions
panel in lieu of one-click subscription mechanisms")?

> However you do point out that feed level links are quite problematic since the
> majority of the links with inconsistent semantics as links are feed level
> links.  

Yes, it appears there are two classes of semantics: there are URIs which can
be GETted to retrieve an interesting resource, which has a relationship with
the current entry as specified in @rel; and secondly there are URIs which
don't return anything useful in response to a GET, but instead require some
other process (such as POST, or retrieving a stylesheet resource and
applying that to the entry).

PaceLinkPurpose proposes that <link> be limited to just the first semantic.

e.



From owner-atom-syntax@mail.imc.org  Mon Jul  5 14:19:18 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09619
	for <atompub-archive@lists.ietf.org>; Mon, 5 Jul 2004 14:19: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 i65I2UkI046982;
	Mon, 5 Jul 2004 11: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 i65I2U16046981;
	Mon, 5 Jul 2004 11:02:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web41508.mail.yahoo.com (web41508.mail.yahoo.com [66.218.93.91])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i65I2TQw046972
	for <atom-syntax@imc.org>; Mon, 5 Jul 2004 11:02:29 -0700 (PDT)
	(envelope-from randymorin@yahoo.com)
Message-ID: <20040705180228.47319.qmail@web41508.mail.yahoo.com>
Received: from [66.46.139.106] by web41508.mail.yahoo.com via HTTP; Mon, 05 Jul 2004 11:02:28 PDT
Date: Mon, 5 Jul 2004 11:02:28 -0700 (PDT)
From: Randy Charles Morin <randymorin@yahoo.com>
Reply-To: randy@kbcafe.com
Subject: PaceAutoDisco Redo
To: Atomlist <atom-syntax@imc.org>
Cc: Mark Pilgrim <pilgrim@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-843283170-1089050548=:45186"
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>


--0-843283170-1089050548=:45186
Content-Type: text/plain; charset=us-ascii

How is this for the PaceAutoDisco?
Thanks,
 
Randy
http://www.kbcafe.com
 

		
---------------------------------
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
--0-843283170-1089050548=:45186
Content-Type: text/html; charset=us-ascii

<DIV>How is this for the <A href="http://www.intertwingly.net/wiki/pie/PaceAutoDisco?action=highlight&amp;value=CategoryProposals">PaceAutoDisco</A>?</DIV>
<DIV>Thanks,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Randy</DIV>
<DIV><A href="http://www.kbcafe.com">http://www.kbcafe.com</A></DIV>
<DIV>&nbsp;</DIV><p>
		<hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/mail_us/taglines/100/*http://promotions.yahoo.com/new_mail/static/efficiency.html">New and Improved Yahoo! Mail</a> - 100MB free storage!
--0-843283170-1089050548=:45186--



From owner-atom-syntax@mail.imc.org  Mon Jul  5 14: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 OAA10131
	for <atompub-archive@lists.ietf.org>; Mon, 5 Jul 2004 14:32: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 i65IBKpL047682;
	Mon, 5 Jul 2004 11:11: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 i65IBKFK047681;
	Mon, 5 Jul 2004 11:11:20 -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 i65IBKV8047675
	for <atom-syntax@imc.org>; Mon, 5 Jul 2004 11:11:20 -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 i65IBO2G003271
	for <atom-syntax@imc.org>; Mon, 5 Jul 2004 11:11:24 -0700 (PDT)
Received: from [12.40.111.47] (wireless-12-40-111-47.bryantpark.org [12.40.111.47] (may be forged))
	(authenticated bits=0)
	by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id i65I9fT9011123
	for <atom-syntax@imc.org>; Mon, 5 Jul 2004 11:09:48 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v618)
In-Reply-To: <20040705171426.80998.qmail@web41214.mail.yahoo.com>
References: <20040705171426.80998.qmail@web41214.mail.yahoo.com>
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1--925356761; protocol="application/pkcs7-signature"
Message-Id: <833C1795-CEAE-11D8-9CA1-000A95DC3D90@mac.com>
From: Graham <dtcd@mac.com>
Subject: Re: PaceEntryOrigin
Date: Mon, 5 Jul 2004 14:09:52 -0400
To: Atom Syntax <atom-syntax@imc.org>
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--925356761
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

I'd like to join Dare and everyone else in saying the link tag as it 
stands is absolutely horrible (I'm being polite today). The public are 
already abusing it by putting unlisted values in @rel. Atom members are 
already abusing it by introducing features through new rels that would 
never get through if they required a new element. The worst thing is 
that it's stolen from HTML, so every time someone suggests a 
modification that makes it more useful, but incompatible with HTML, 
they get shouted down for confusing the ViewSourceClan. Plus it has the 
body - the URI - in an attribute, unlike every other element we have. 
And where's the extension mechanism?

The only sane thing to do is forget it ever existed and work out 
*appropriate* mechanisms for the functionality it orphans.

Graham
--Apple-Mail-1--925356761
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
9w0BCQUxDxcNMDQwNzA1MTgwOTUzWjAjBgkqhkiG9w0BCQQxFgQU7SwmW3lK6cPscYx5C2Y09tTy
0bcweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAjKz7C66t1+VUFh1yM1+q/F7J
xhuoIEnS15hdyJ0Qu9ow4rKfw8uwzIxM3jaBSrSi89rCQCSWwjqC2of3einitGiRtgtWqprS4biG
bI8miEGf1O7SnOdo2X2MLY+7kwXGSrJcLgeIH/JmsqgWMZxJVrqnxBtUTmqJIGnKQM4Gor15JA3r
VFplXVco/2pq/N/vYTRZmutW6lNmQSijdHdK/GqLI8+lhKxQ7AaTf1dLyFk1pxyrucnkmDmLU6a3
V2am7YmFXd8dJ47NGGYoXO7eiNFM8mYzHC9vA10pBCGvSzXv8BcxM2tQIosdjDScJ7pl5Pq85ITd
xF5O8i0hHHkJGwAAAAAAAA==

--Apple-Mail-1--925356761--



From owner-atom-syntax@mail.imc.org  Mon Jul  5 14: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 OAA10173
	for <atompub-archive@lists.ietf.org>; Mon, 5 Jul 2004 14:32:23 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i65ICQxO047789;
	Mon, 5 Jul 2004 11: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 i65ICQOb047788;
	Mon, 5 Jul 2004 11:12:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web41506.mail.yahoo.com (web41506.mail.yahoo.com [66.218.93.89])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i65ICQnu047779
	for <atom-syntax@imc.org>; Mon, 5 Jul 2004 11:12:26 -0700 (PDT)
	(envelope-from randymorin@yahoo.com)
Message-ID: <20040705181224.36635.qmail@web41506.mail.yahoo.com>
Received: from [66.46.139.106] by web41506.mail.yahoo.com via HTTP; Mon, 05 Jul 2004 11:12:24 PDT
Date: Mon, 5 Jul 2004 11:12:24 -0700 (PDT)
From: Randy Charles Morin <randymorin@yahoo.com>
Reply-To: randy@kbcafe.com
Subject: PaceInterop Withdrawn
To: Atomlist <atom-syntax@imc.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-405983221-1089051144=:35478"
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>


--0-405983221-1089051144=:35478
Content-Type: text/plain; charset=us-ascii

I have marked it withdrawn. If someone else has the time to finish PaceInterop, then please take the reigns.
Thanks,
 
Randy
http://www.kbcafe.com
 

		
---------------------------------
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
--0-405983221-1089051144=:35478
Content-Type: text/html; charset=us-ascii

<DIV>I have marked it withdrawn. If&nbsp;someone else has the time to finish <A href="http://www.intertwingly.net/wiki/pie/PaceInterop"><STRONG class=highlight>PaceInterop</STRONG></A>, then please take the reigns.</DIV>
<DIV>Thanks,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Randy</DIV>
<DIV><A href="http://www.kbcafe.com">http://www.kbcafe.com</A></DIV>
<DIV>&nbsp;</DIV><p>
		<hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/mail_us/taglines/100/*http://promotions.yahoo.com/new_mail/static/efficiency.html">New and Improved Yahoo! Mail</a> - 100MB free storage!
--0-405983221-1089051144=:35478--



From owner-atom-syntax@mail.imc.org  Mon Jul  5 15:18: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 PAA13420
	for <atompub-archive@lists.ietf.org>; Mon, 5 Jul 2004 15:18: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 i65J2uvg052697;
	Mon, 5 Jul 2004 12:02: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 i65J2uuF052696;
	Mon, 5 Jul 2004 12:02:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web41507.mail.yahoo.com (web41507.mail.yahoo.com [66.218.93.90])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i65J2tia052679
	for <atom-syntax@imc.org>; Mon, 5 Jul 2004 12:02:55 -0700 (PDT)
	(envelope-from randymorin@yahoo.com)
Message-ID: <20040705190253.46800.qmail@web41507.mail.yahoo.com>
Received: from [66.46.139.106] by web41507.mail.yahoo.com via HTTP; Mon, 05 Jul 2004 12:02:53 PDT
Date: Mon, 5 Jul 2004 12:02:53 -0700 (PDT)
From: Randy Charles Morin <randymorin@yahoo.com>
Reply-To: randy@kbcafe.com
Subject: Re: Validing parser required? 
To: Sam Ruby <rubys@intertwingly.net>, Atomlist <atom-syntax@imc.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1679722799-1089054173=:44525"
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>


--0-1679722799-1089054173=:44525
Content-Type: text/plain; charset=us-ascii

>However, if someone is interested in crafting more surgical 
>language which only addresses the issue of validation and does 
>not prevent, for example, inline DTDs, I will gladly defer to 
>them. Otherwise, I will write up a Pace to include something 
>like the sentence above into the Atom specifications and such a 
>Pace will eventually get scheduled and disposed of.

FYI. That was part of PaceInterop, which I abandoned. 
 
Randy
http://www.kbcafe.com
 

		
---------------------------------
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
--0-1679722799-1089054173=:44525
Content-Type: text/html; charset=us-ascii

<DIV><FONT face="Courier New">&gt;However, if someone is interested in crafting more surgical </FONT></DIV>
<DIV><FONT face="Courier New">&gt;language which only addresses the issue of validation and does </FONT></DIV>
<DIV><FONT face="Courier New">&gt;not prevent, for example, inline DTDs, I will gladly defer to </FONT></DIV>
<DIV><FONT face="Courier New">&gt;them. Otherwise, I will write up a Pace to include something </FONT></DIV>
<DIV><FONT face="Courier New">&gt;like the sentence above into the Atom specifications and such a </FONT></DIV>
<DIV><FONT face="Courier New">&gt;Pace will eventually get scheduled and disposed of.</FONT><BR></DIV>
<DIV>FYI. That was part of <A href="http://www.intertwingly.net/wiki/pie/PaceInterop">PaceInterop</A>, which I abandoned. </DIV>
<DIV>&nbsp;</DIV>
<DIV>Randy</DIV>
<DIV><A href="http://www.kbcafe.com">http://www.kbcafe.com</A></DIV>
<DIV>&nbsp;</DIV><p>
		<hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/mail_us/taglines/50x/*http://promotions.yahoo.com/new_mail/static/efficiency.html">Yahoo! Mail</a> - 50x more storage than other providers!
--0-1679722799-1089054173=:44525--



From owner-atom-syntax@mail.imc.org  Mon Jul  5 17:38: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 RAA18296
	for <atompub-archive@lists.ietf.org>; Mon, 5 Jul 2004 17:38: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 i65LL0v2061948;
	Mon, 5 Jul 2004 14:21:00 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i65LL0Ge061946;
	Mon, 5 Jul 2004 14:21: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 i65LL0Sl061917
	for <atom-syntax@imc.org>; Mon, 5 Jul 2004 14:21:00 -0700 (PDT)
	(envelope-from antone@geckotribe.com)
Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134])
          by comcast.net (sccrmhc13) with SMTP
          id <2004070521205901600o48fie>; Mon, 5 Jul 2004 21:20:59 +0000
Date: Mon, 5 Jul 2004 15:20:54 -0600
Subject: Re: PaceEntryOrigin
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: <BD0FD14E.1D6ED%eric.scheid@ironclad.net.au>
Message-Id: <32CE4C2C-CEC9-11D8-9691-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 Monday, July 5, 2004, at 11:47  AM, Eric Scheid wrote:
> On 6/7/04 3:14 AM, "Dare Obasanjo" <kpako@yahoo.com> wrote:
>
>> The point of my example is that as currently specified, the semantics 
>> of the
>> various links is inconsistent so aggregator authors can't just write 
>> some
>> generic foreach loop and process all links identically.
>
> if PaceLinkPurpose is accepted, then the semantics are quite clear: the
> <link> element provides a usable link between the entry and some other
> resource, described by the @rel attribute. I'm not real happy about
> "clickable" as usable can include drag/drop instead.
>
The way feed readers usually work today, clicking a link does tend to 
imply that the target of the link is going to open in a web browser 
window, but I expect that to change, and in fact, the winds of change 
are blowing already.  (If no such change were coming, then I'd agree 
that "clickable" would be the wrong word to express the idea.)  The 
"winds of change" are things like people implementing "feed://", which 
opens a feed in a browser--non standard, yes, but the fact that people 
are doing it shows that there is a demand for some way of getting feeds 
to open in a feed reader automatically.

Following a link to a feed shouldn't always result in subscribing to 
the feed.  For example, following link[@rel="start"], link[@rel="next"] 
and link[@rel="prev"] are ways to see more of the current feed--they 
shouldn't result in an additional subscription.  Also, just as clicking 
a link to a webpage does not automatically bookmark the page, there's 
no reason why clicking a link to a feed should automatically subscribe 
you to it. It should load the feed in your feed reader, and then you 
should be able to subscribe to it if it looks interesting enough.  (How 
many times have you subscribed to a feed to see if it looked like you 
wanted to subscribe to it, only to unsubscribe immediately?  I've done 
it many times).

So there's my defense of the word "clickable" in this context.  It 
certainly doesn't preclude dragging and dropping, but as I imagine the 
results of a click, it covers what I think <link> should be used for.



From owner-atom-syntax@mail.imc.org  Mon Jul  5 17:55:26 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18775
	for <atompub-archive@lists.ietf.org>; Mon, 5 Jul 2004 17:55:25 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i65LXtro062599;
	Mon, 5 Jul 2004 14:33: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 i65LXtN3062598;
	Mon, 5 Jul 2004 14:33:55 -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 i65LXtgg062592
	for <atom-syntax@imc.org>; Mon, 5 Jul 2004 14:33:55 -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 i65LXqt23594
	for <atom-syntax@imc.org>; Mon, 5 Jul 2004 14:33:52 -0700 (PDT)
Received: from aol.net ([10.169.192.35]) by judge.mcom.com
          (Netscape Messaging Server 4.15) with ESMTP id I0EEKF00.619;
          Mon, 5 Jul 2004 14:33:51 -0700 
Message-ID: <40E9C93D.2040203@aol.net>
Date: Mon, 05 Jul 2004 14:33:49 -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: Ken MacLeod <ken@bitsko.slc.ut.us>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceSimpleResourcePosting and PUT
References: <opsairy6o1uvpchu@quark> <40E597FF.8020808@aol.net>	<opsai5d4uouvpchu@quark> <40E64A34.5060406@aol.net>	<opsakspewuuvpchu@quark> <40E74F6F.2060507@aol.net> <m3fz87sos4.fsf@bitsko.slc.ut.us>
In-Reply-To: <m3fz87sos4.fsf@bitsko.slc.ut.us>
Content-Type: multipart/alternative;
 boundary="------------060202040301080203060503"
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>


This is a multi-part message in MIME format.
--------------060202040301080203060503
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

First, let me note that these issues only arise when discussing 
PUT/DELETE with non-entry resources.  (That's why I hesitated to add 
PUT/DELETE into the core proposal earlier.)

Ken MacLeod wrote:

>jpanzer@aol.net (John Panzer) writes:
>  
>
>>Asbjørn Ulsberg wrote:
>>    
>>
>>>That shouldn't be necessary if you can use something like
>>>.htaccess on Apache, or have nice administrators on IIS with
>>>ASP.NET. The problem is that if people somehow can't do rewrite,
>>>they would most likely want to serve the resources for GETs as
>>>'http://example.org/resources/mycat.jpg' but for all the other
>>>verbs 'http://example.org/cgi-bin/resources?name=mycat.jpg'.
>>>
>>>This splits the resource in half, kind of, because it is
>>>accessible from two different URI's. And not that each URI is
>>>equal; no, you can only use one for GET and the other for PUT and
>>>DELETE (for POST, you'd use a totally separate URI anyway).
>>>      
>>>
>>Ah, this is the crux of the matter.  The impetus for this discussion
>>is non entry resources
>>(PaceNonEntryResources/PaceSimpleResourcePosting).  I think that non
>>entry resources in these proposals _require_ that a single URI be
>>used for all possible methods after creation (GET, PUT, DELETE,
>>say).  Here's why:
>>    
>>
>
>Note: it is perfectly acceptable for a publishing system to publish
>static, GET-only, instances of a resource in a different URL location,
>possibly even on a different host.  We don't have a name or label for
>this kind of URI location, WebDAV calls it an "output resource", so
>OutputURI sounds good.
>  
>
I see what you're saying, but I at first glance I think this introduces 
a lot of complexity that needs to be justified.  Why do we need it? 

o PaceSimpleResourcePosting already supports resource URIs on arbitrary 
hosts.
o PaceSimpleResourcePosting doesn't require support for PUT and DELETE, 
so in that sense the resource URI could be an "OutputURI".
o However, PaceSimpleResourcePosting says that servers SHOULD support 
PUT and DELETE on the resource URI itself; that is, the recommended 
approach for doing editing is to use one URI (e.g., 
http://example.org/res/kitty1.jpg) , not many.  We believe this is 
compatible with straightforward WebDAV as well.

#3 is where PaceSimpleResourcePosting currently differs.  I see two 
issues with using mutiple resource URIs:

(1) Many URIs are more complicated than one URI; are there non-edge 
cases where servers or clients need there to be more than one URI?
(2) There doesn't seem to be a way proposed to discover the non-entry 
resources associated with an entry, under the multi-URI approach.

#2 might be confusing, so let me repeat my earlier use case which 
motiviates the one-URI approach:

> One of the main use cases is to be able to post an Atom entry which, 
> as its XHTML content, has the following fragment:
>
> <img src="http://example.com/myblog/resources/cat1.jpg" 
> align="right"/>A picture of Fluffy!<br/>
>
> Note that nowhere else in the universe is there a reference to 
> http://example.com/myblog/resources/cat1.jpg, at least when it's first 
> uploaded.  (And for cat pictures, let's face it, do we really want 
> more references?)  Well, a client could of course keep track of it 
> locally, but let's say it doesn't.
> Suppose I want to update the picture of Fluffy with a better version 
> (fixed redeye) a day later.  How do I do this?  Well, first I need to 
> retrieve the entry with my Atom client; this gives me the XHTML in a 
> WSYWIG editor.  Then I presumably drag and drop the fixed picture on 
> top of the old one, and the client notes that I've updated the 
> content.  Then I save the entry.  My client _may_ be smart enough to 
> do a PUT of the new content to 
> http://example.com/myblog/resources/cat1.jpg instead of a POST to 
> create yet another picture.  Since it only has the GETtable URI for 
> the resource at hand, the simplest thing is for that URI to support 
> PUT as well.  If it doesn't, how do we get a URI that _does_ support 
> PUT?  Specify yet another introspection API? 

Ken, could you document how you would address the problem above in the 
multi-URI approach, so we could compare the two approaches?  That is, 
given that http://example.com/myblog/resources/cat1.jpg is just the 
"OutputURI", how would I find the "EditURI" and update the cat picture?  
Or if there are multiple approaches, perhaps you could list them.

>The editable resource at the EditURI would support GET/PUT/DELETE (and
>whether it is also a PostURI for posting new sub-resources is a
>separate concern).  It's also possible that the EditURI might be
>restricted to authenticated users.
>
>Atom does not currently have a method for informing a client what the
>OutputURI is for resources in general.  Entries can have a
>link/@rel=alternate for the browsable OutputURI.
>
>  
>
I'm a little puzzled by this.  See the cat picture use case above.  I 
think we'd both agree that http://example.com/myblog/resources/cat1.jpg 
IS the 'OutputURI'.  Where we appear to differ is in whether 
http://example.com/myblog/resources/cat1.jpg is also the 'EditURI'.  
PaceSimpleResourcePosting calls for OutputURI=EditURI.

>At this time, the publishing system must document the relationship
>between the AtomAPI locations (EditURI) and where the resources are
>published (OutputURI) so that the user can edit entries appropriately.
>
>  
>
Ken, do you envision there being publishing-system-specific ways to 
relate the OutputURI and the EditURI, which clients would need to keep 
track of?  Or are you implying that this is a gap in the Atom spec that 
should be filled?  (My proposal: PaceSimpleResourcePosting calls for 
OutputURI=EditURI :).)

>>>As the API offers 'service.edit' URI's, I don't think this is a
>>>big problem. This URI can be something different for PUT than it
>>>is for GET.  It's not very REST-ish or intuitive, but it works for
>>>rewrite-disabled people and servers.
>>>      
>>>
>>Note that we're not talking about entries in this context, we're
>>talking about non-entry resources and there is no service.edit URI
>>that points at any of them (at least under
>>PaceNonEntryResources/PaceSimpleResourcePosting). -John
>>    
>>
>
>Notifying editing clients of non-entry resource locations was a
>feature of PaceResource, on the principle that <resource> elements
>would be in dynamic and index feeds but not displayed as entries in
>newsreader clients.
>
>  
>
PaceResource (http://www.intertwingly.net/wiki/pie/PaceResource) 
proposes adding atom:resource elements to the feed.  It doesn't seem to 
have any way to relate the resources to the entries they are logically 
associated with, which PaceSimpleResourcePosting does.  That is, it 
still doesn't address the issue of how, given a specific atom:entry, I 
find the EditURIs for the resources associated with it?

Having a collection of all resources associated with a blog seems like 
the 20% case to me, while being able to go from an entry to its 
associated resources seems like the 80% case. 

I agree with you, Ken, that it would probably be better to let an 
existing standard -- like WebDAV -- deal with the 20% case where users 
actually _do_ want to manually manage a collection of random resources 
associated with their blog:

>We have to decide carefully in this support because there's a mature
>and straightforward solution for this available in WebDAV, PROPFIND,
>for indexing collections of resources.
>
>A trimmed-to-relevant portion of the output from
>
>  curl -X PROPFIND -H "Depth: 1" http://test.webdav.org/dav/atom/
>
><dav:response xmlns:dav="DAV:">
>  <dav:href>/dav/atom/kitty.jpg</dav:href>
>  <dav:propstat>
>    <dav:prop>
>      <dav:resourcetype/>
>      <dav:getcontenttype>image/jpeg</dav:getcontenttype>
>      <dav:creationdate>2004-07-04T16:30:36Z</dav:creationdate>
>      <dav:getcontentlength>43397</dav:getcontentlength>
>      <dav:getlastmodified>Sun, 04 Jul 2004 16:30:36 GMT</dav:getlastmodified>
>      <dav:getetag>"43d4-a985-f0ac8300"</dav:getetag>
>    </dav:prop>
>    <dav:status>HTTP/1.1 200 OK</dav:status>
>  </dav:propstat>
></dav:response>
>
>  -- Ken
>
>  
>
Yep.  My proposal is, if you want a collection of resources like this, 
use WebDAV and PROPFIND, not Atom.

-John

--------------060202040301080203060503
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
First, let me note that these issues only arise when discussing
PUT/DELETE with non-entry resources.&nbsp; (That's why I hesitated to add
PUT/DELETE into the core proposal earlier.)<br>
<br>
Ken MacLeod wrote:<br>
<blockquote cite="midm3fz87sos4.fsf@bitsko.slc.ut.us" type="cite">
  <pre wrap=""><a class="moz-txt-link-abbreviated" href="mailto:jpanzer@aol.net">jpanzer@aol.net</a> (John Panzer) writes:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Asbj&oslash;rn Ulsberg wrote:
    </pre>
  </blockquote>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">That shouldn't be necessary if you can use something like
.htaccess on Apache, or have nice administrators on IIS with
ASP.NET. The problem is that if people somehow can't do rewrite,
they would most likely want to serve the resources for GETs as
'<a class="moz-txt-link-freetext" href="http://example.org/resources/mycat.jpg">http://example.org/resources/mycat.jpg</a>' but for all the other
verbs '<a class="moz-txt-link-freetext" href="http://example.org/cgi-bin/resources?name=mycat.jpg">http://example.org/cgi-bin/resources?name=mycat.jpg</a>'.

This splits the resource in half, kind of, because it is
accessible from two different URI's. And not that each URI is
equal; no, you can only use one for GET and the other for PUT and
DELETE (for POST, you'd use a totally separate URI anyway).
      </pre>
    </blockquote>
    <pre wrap="">Ah, this is the crux of the matter.  The impetus for this discussion
is non entry resources
(PaceNonEntryResources/PaceSimpleResourcePosting).  I think that non
entry resources in these proposals _require_ that a single URI be
used for all possible methods after creation (GET, PUT, DELETE,
say).  Here's why:
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Note: it is perfectly acceptable for a publishing system to publish
static, GET-only, instances of a resource in a different URL location,
possibly even on a different host.  We don't have a name or label for
this kind of URI location, WebDAV calls it an "output resource", so
OutputURI sounds good.
  </pre>
</blockquote>
I see what you're saying, but I at first glance I think this introduces
a lot of complexity that needs to be justified.&nbsp; Why do we need it?&nbsp; <br>
<br>
o PaceSimpleResourcePosting already supports resource URIs on arbitrary
hosts.<br>
o PaceSimpleResourcePosting doesn't require support for PUT and DELETE,
so in that sense the resource URI could be an "OutputURI".<br>
o However, PaceSimpleResourcePosting says that servers SHOULD support
PUT and DELETE on the resource URI itself; that is, the recommended
approach for doing editing is to use one URI (e.g.,
<a class="moz-txt-link-freetext" href="http://example.org/res/kitty1.jpg">http://example.org/res/kitty1.jpg</a>) , not many.&nbsp; We believe this is
compatible with straightforward WebDAV as well.<br>
<br>
#3 is where PaceSimpleResourcePosting currently differs.&nbsp; I see two
issues with using mutiple resource URIs:<br>
<br>
(1) Many URIs are more complicated than one URI; are there non-edge
cases where servers or clients need there to be more than one URI?<br>
(2) There doesn't seem to be a way proposed to discover the non-entry
resources associated with an entry, under the multi-URI approach.<br>
<br>
#2 might be confusing, so let me repeat my earlier use case which
motiviates the one-URI approach:<br>
<br>
<blockquote type="cite">One of the main use cases is to be able to post
an Atom entry which, as its XHTML content, has the following fragment:
  <br>
  <br>
&lt;img src=<a class="moz-txt-link-rfc2396E"
 href="http://example.com/myblog/resources/cat1.jpg">"http://example.com/myblog/resources/cat1.jpg"</a>
align="right"/&gt;A picture of Fluffy!&lt;br/&gt;
  <br>
  <br>
Note that nowhere else in the universe is there a reference to <a
 class="moz-txt-link-freetext"
 href="http://example.com/myblog/resources/cat1.jpg">http://example.com/myblog/resources/cat1.jpg</a>,
at least when it's first uploaded.&nbsp; (And for cat pictures, let's face
it, do we really want more references?)&nbsp; Well, a client could of course
keep track of it locally, but let's say it doesn't. <br>
Suppose I want to update the picture of Fluffy with a better version
(fixed redeye) a day later.&nbsp; How do I do this?&nbsp; Well, first I need to
retrieve the entry with my Atom client; this gives me the XHTML in a
WSYWIG editor.&nbsp; Then I presumably drag and drop the fixed picture on
top of the old one, and the client notes that I've updated the
content.&nbsp; Then I save the entry.&nbsp; My client <span
 class="moz-txt-underscore"><span class="moz-txt-tag">_</span>may<span
 class="moz-txt-tag">_</span></span> be smart enough to do a PUT of the
new content to <a class="moz-txt-link-freetext"
 href="http://example.com/myblog/resources/cat1.jpg">http://example.com/myblog/resources/cat1.jpg</a>
instead of a POST to create yet another picture.&nbsp; Since it only has the
GETtable URI for the resource at hand, the simplest thing is for that
URI to support PUT as well.&nbsp; If it doesn't, how do we get a URI that <span
 class="moz-txt-underscore"><span class="moz-txt-tag">_</span>does<span
 class="moz-txt-tag">_</span></span> support PUT?&nbsp; Specify yet another
introspection API?
</blockquote>
Ken, could you document how you would address the problem above in the
multi-URI approach, so we could compare the two approaches?&nbsp; That is,
given that <a class="moz-txt-link-freetext"
 href="http://example.com/myblog/resources/cat1.jpg">http://example.com/myblog/resources/cat1.jpg</a>
is just the "OutputURI", how would I find the "EditURI" and update the
cat picture?&nbsp; Or if there are multiple approaches, perhaps you could
list them.<br>
<br>
<blockquote cite="midm3fz87sos4.fsf@bitsko.slc.ut.us" type="cite">
  <pre wrap="">
The editable resource at the EditURI would support GET/PUT/DELETE (and
whether it is also a PostURI for posting new sub-resources is a
separate concern).  It's also possible that the EditURI might be
restricted to authenticated users.

Atom does not currently have a method for informing a client what the
OutputURI is for resources in general.  Entries can have a
link/@rel=alternate for the browsable OutputURI.

  </pre>
</blockquote>
I'm a little puzzled by this.&nbsp; See the cat picture use case above.&nbsp; I
think we'd both agree that <a class="moz-txt-link-freetext"
 href="http://example.com/myblog/resources/cat1.jpg">http://example.com/myblog/resources/cat1.jpg</a>
IS the 'OutputURI'.&nbsp; Where we appear to differ is in whether <a
 class="moz-txt-link-freetext"
 href="http://example.com/myblog/resources/cat1.jpg">http://example.com/myblog/resources/cat1.jpg</a>
is also the 'EditURI'.&nbsp; PaceSimpleResourcePosting calls for
OutputURI=EditURI.<br>
<blockquote cite="midm3fz87sos4.fsf@bitsko.slc.ut.us" type="cite">
  <pre wrap="">At this time, the publishing system must document the relationship
between the AtomAPI locations (EditURI) and where the resources are
published (OutputURI) so that the user can edit entries appropriately.

  </pre>
</blockquote>
Ken, do you envision there being publishing-system-specific ways to
relate the OutputURI and the EditURI, which clients would need to keep
track of?&nbsp; Or are you implying that this is a gap in the Atom spec that
should be filled?&nbsp; (My proposal: PaceSimpleResourcePosting calls for
OutputURI=EditURI :).)<br>
<br>
<blockquote cite="midm3fz87sos4.fsf@bitsko.slc.ut.us" type="cite">
  <pre wrap=""></pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">As the API offers 'service.edit' URI's, I don't think this is a
big problem. This URI can be something different for PUT than it
is for GET.  It's not very REST-ish or intuitive, but it works for
rewrite-disabled people and servers.
      </pre>
    </blockquote>
    <pre wrap="">Note that we're not talking about entries in this context, we're
talking about non-entry resources and there is no service.edit URI
that points at any of them (at least under
PaceNonEntryResources/PaceSimpleResourcePosting). -John
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Notifying editing clients of non-entry resource locations was a
feature of PaceResource, on the principle that &lt;resource&gt; elements
would be in dynamic and index feeds but not displayed as entries in
newsreader clients.

  </pre>
</blockquote>
PaceResource (<a class="moz-txt-link-freetext" href="http://www.intertwingly.net/wiki/pie/PaceResource">http://www.intertwingly.net/wiki/pie/PaceResource</a>)
proposes adding atom:resource elements to the feed.&nbsp; It doesn't seem to
have any way to relate the resources to the entries they are logically
associated with, which PaceSimpleResourcePosting does.&nbsp; That is, it
still doesn't address the issue of how, given a specific atom:entry, I
find the EditURIs for the resources associated with it?<br>
<br>
Having a collection of all resources associated with a blog seems like
the 20% case to me, while being able to go from an entry to its
associated resources seems like the 80% case.&nbsp; <br>
<br>
I agree with you, Ken, that it would probably be better to let an
existing standard -- like WebDAV -- deal with the 20% case where users
actually _do_ want to manually manage a collection of random resources
associated with their blog:<br>
<blockquote cite="midm3fz87sos4.fsf@bitsko.slc.ut.us" type="cite">
  <pre wrap="">We have to decide carefully in this support because there's a mature
and straightforward solution for this available in WebDAV, PROPFIND,
for indexing collections of resources.

A trimmed-to-relevant portion of the output from

  curl -X PROPFIND -H "Depth: 1" <a class="moz-txt-link-freetext" href="http://test.webdav.org/dav/atom/">http://test.webdav.org/dav/atom/</a>

&lt;dav:response xmlns:dav="DAV:"&gt;
  &lt;dav:href&gt;/dav/atom/kitty.jpg&lt;/dav:href&gt;
  &lt;dav:propstat&gt;
    &lt;dav:prop&gt;
      &lt;dav:resourcetype/&gt;
      &lt;dav:getcontenttype&gt;image/jpeg&lt;/dav:getcontenttype&gt;
      &lt;dav:creationdate&gt;2004-07-04T16:30:36Z&lt;/dav:creationdate&gt;
      &lt;dav:getcontentlength&gt;43397&lt;/dav:getcontentlength&gt;
      &lt;dav:getlastmodified&gt;Sun, 04 Jul 2004 16:30:36 GMT&lt;/dav:getlastmodified&gt;
      &lt;dav:getetag&gt;"43d4-a985-f0ac8300"&lt;/dav:getetag&gt;
    &lt;/dav:prop&gt;
    &lt;dav:status&gt;HTTP/1.1 200 OK&lt;/dav:status&gt;
  &lt;/dav:propstat&gt;
&lt;/dav:response&gt;

  -- Ken

  </pre>
</blockquote>
Yep.&nbsp; My proposal is, if you want a collection of resources like this,
use WebDAV and PROPFIND, not Atom.<br>
<br>
-John<br>
</body>
</html>

--------------060202040301080203060503--



From owner-atom-syntax@mail.imc.org  Mon Jul  5 17:58: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 RAA18861
	for <atompub-archive@lists.ietf.org>; Mon, 5 Jul 2004 17:58: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 i65LYJ7r062613;
	Mon, 5 Jul 2004 14:34: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 i65LYJJS062612;
	Mon, 5 Jul 2004 14:34:19 -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 i65LYIOs062605
	for <atom-syntax@imc.org>; Mon, 5 Jul 2004 14:34:18 -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 <2004070521341801400jeb56e>; Mon, 5 Jul 2004 21:34:18 +0000
Date: Mon, 5 Jul 2004 15:34:13 -0600
Subject: Re: PaceEntryOrigin
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: <833C1795-CEAE-11D8-9CA1-000A95DC3D90@mac.com>
Message-Id: <0F3A98F9-CECB-11D8-9691-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 Monday, July 5, 2004, at 12:09  PM, Graham wrote:
> I'd like to join Dare and everyone else in saying the link tag as it 
> stands is absolutely horrible (I'm being polite today). The public are 
> already abusing it by putting unlisted values in @rel. Atom members 
> are already abusing it by introducing features through new rels that 
> would never get through if they required a new element. The worst 
> thing is that it's stolen from HTML, so every time someone suggests a 
> modification that makes it more useful, but incompatible with HTML, 
> they get shouted down for confusing the ViewSourceClan. Plus it has 
> the body - the URI - in an attribute, unlike every other element we 
> have. And where's the extension mechanism?
>
> The only sane thing to do is forget it ever existed and work out 
> *appropriate* mechanisms for the functionality it orphans.
>
The ViewSourceClan has not shouted PaceLinkPurpose down.  Unless I'm 
misperceiving, the comments that have been addressed to it have been 
almost universally positive (so far!)

I don't think we can throw a feature out on the basis of it's having 
been abused while in development.  But if that's what you really want 
to do, how about writing proposals to replace each of the @rel values.  
And please don't lump them all together into one--given that all 
existing and proposed links are not similar enough that you're 
comfortable having them all handled by one element, I think they're 
different enough that we need to be able to consider them in logical 
groups rather than all at once.  If all the alternative proposals get 
accepted, then link will be gone without having to decide to drop it.  
I've written PaceServiceElement to take care of the ones that I'm most 
interested in having changed.  There are 4 more values in the current 
spec, or 13 more in LinkTagMeaning.



From owner-atom-syntax@mail.imc.org  Mon Jul  5 18:58: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 SAA22124
	for <atompub-archive@lists.ietf.org>; Mon, 5 Jul 2004 18:58: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 i65Mc0d1067723;
	Mon, 5 Jul 2004 15:38: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 i65Mc05Q067722;
	Mon, 5 Jul 2004 15:38:00 -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 i65Mc0IX067714
	for <atom-syntax@imc.org>; Mon, 5 Jul 2004 15:38:00 -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 i65Mc34Q003168;
	Mon, 5 Jul 2004 15:38:03 -0700
Received: from ussjex01.amer.bea.com ([172.16.120.50]) by ussjfe01.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 5 Jul 2004 15:38:02 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: PaceEntryOrigin
Date: Mon, 5 Jul 2004 15:38:02 -0700
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF08AFC78D@ussjex01.amer.bea.com>
Thread-Topic: PaceEntryOrigin
Thread-Index: AcRisISl5ntvOHRvRf+FeV4sJzZTNQALv0nw
From: "David Orchard" <dorchard@bea.com>
To: "Dare Obasanjo" <kpako@yahoo.com>,
        "Eric Scheid" <eric.scheid@ironclad.net.au>,
        "Atom Syntax" <atom-syntax@imc.org>
X-OriginalArrivalTime: 05 Jul 2004 22:38:02.0785 (UTC) FILETIME=[BB4DC910:01C462E0]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i65Mc0IX067716
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


Here here.  A big +1.

I personally would really like to see strongly typed links, optionally based upon XLink.  Then the writing of entries etc. can be made easier because it can mandate a type of link using Schema constructs, ie <element ref="EditLink" minOccurs="1"> or some such.  I don't care much whether XLink is used, but I'd really like to have strongly typed links where the type is known using Schema constructs rather than something re-invented (like rel).  

The whole approach of "bottom-typing" where the type of the thing is known by the contents of the leaf nodes leaves a strongly-typed guy like me with the whillies.  For the record, I also recall Tim Bray voting for "use Xlink" at a TAG meeting in http://www.w3.org/2002/09/24-tag-summary#xlinkScope-23 :-)

Cheers,
Dave

> -----Original Message-----
> From: owner-atom-syntax@mail.imc.org
> [mailto:owner-atom-syntax@mail.imc.org]On Behalf Of Dare Obasanjo
> Sent: Monday, July 05, 2004 9:50 AM
> To: Eric Scheid; Atom Syntax
> Subject: Re: PaceEntryOrigin
> 
> 
> 
> --- Eric Scheid <eric.scheid@ironclad.net.au> wrote:
> > 
> > On 6/7/04 1:39 AM, "Robert Sayre"
> > <mint@franklinmint.fm> wrote:
> > 
> > > As do I. The other mechanisms that have been
> > proposed (xlink, rdf/xml, etc)
> > > are all capable of handling unknown link types.
> > 
> > You do realise that xlink has much more complicated
> > semantics of linking,
> > right? For example, it has an attribute 'type' which
> > could have values of
> > "simple", "extended", "locator", "arc", "resource",
> > "title", or "none". Then
> > there are the other attributes like 'actuate'.
> > 
> > Do we really want to require atom applications to
> > handle such a complicated
> > thing?
> 
> As link is currently being used in Atom it is quite
> USELESS for aggregator authors to use it to do
> anything meaningful with unknown links. At list with
> XLink it allows finer grained semantics about the link
> to be passed around besides title and URI. 
> 
> The simplicity you claim currently exists is due to
> link being horribly underspecified not from some
> elegant simplicity. 
> 
> Personally I think th etime has come to scale bank
> this overuse of link and muddy semantics it
> introduces. Atom is supposed to be a tightly specified
> spec that helps aggregator authors. The current usage
> of the link elements makes a mockery of that claim. 
> 
> 
> 
> =====
> THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
> My dungeon will have its own qualified medical staff complete 
> with bodyguards. That way if a prisoner becomes sick and his 
> cellmate tells the guard it's an emergency, the guard will 
> fetch a trauma team instead of opening up the cell for a look.
> 
> 
> 		
> __________________________________
> 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 Jul  5 19:01:49 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22250
	for <atompub-archive@lists.ietf.org>; Mon, 5 Jul 2004 19:01:49 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i65MdsCB067815;
	Mon, 5 Jul 2004 15:39: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 i65Mdsaf067814;
	Mon, 5 Jul 2004 15:39:54 -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 i65MdrEd067808
	for <atom-syntax@imc.org>; Mon, 5 Jul 2004 15:39:53 -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 i65Mdx4Q003218
	for <atom-syntax@imc.org>; Mon, 5 Jul 2004 15:39:59 -0700
Received: from ussjex01.amer.bea.com ([172.16.120.50]) by ussjfe01.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 5 Jul 2004 15:39:58 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: Atom API in WSDL 2.0
Date: Mon, 5 Jul 2004 15:39:58 -0700
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF08AFC78E@ussjex01.amer.bea.com>
Thread-Topic: Atom API in WSDL 2.0
Thread-Index: AcRi4T20FYBW8LmuSPOJM/0W3Sxtqw==
From: "David Orchard" <dorchard@bea.com>
To: "Atom Syntax" <atom-syntax@imc.org>
X-OriginalArrivalTime: 05 Jul 2004 22:39:58.0722 (UTC) FILETIME=[00685E20:01C462E1]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i65MdrEd067809
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've published my take at the Atom API in WSDL 2.0 at http://www.pacificspirit.com/blog/2004/07/05/atom_03_wsdl_20

I've got a # of questions in there.  Can I consider them posted to the list, or should I post them 1 by 1?

Dave



From owner-atom-syntax@mail.imc.org  Mon Jul  5 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 TAA22520
	for <atompub-archive@lists.ietf.org>; Mon, 5 Jul 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 i65MwkOF069887;
	Mon, 5 Jul 2004 15:58: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 i65Mwk7A069886;
	Mon, 5 Jul 2004 15:58:46 -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 i65Mwkh5069880
	for <atom-syntax@imc.org>; Mon, 5 Jul 2004 15:58:46 -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 CA7784F2EA;
	Mon,  5 Jul 2004 18:58:49 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040705085150.05c59710@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Mon, 05 Jul 2004 08:54:07 +0900
To: Asbj=?ISO-2022-JP?B?GyRCj1MbKEI=?=n Ulsberg <asbjorn@tigerstaden.no>,
        "Eric Scheid" <eric.scheid@ironclad.net.au>
From: Martin Duerst <duerst@w3.org>
Subject: Re: PacePutIpAddrInEntry
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <opsag51ir2uvpchu@quark>
References: <BD09CAB6.1C80A%eric.scheid@ironclad.net.au>
 <BD09CAB6.1C80A%eric.scheid@ironclad.net.au>
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: <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


At 22:04 04/07/01 +0200, Asbj$BS(Bn Ulsberg wrote:

>On Thu, 01 Jul 2004 14:05:42 +1000, Eric Scheid
><eric.scheid@ironclad.net.au> wrote:
>
>>>Speaking of... Is there a common designation for IP addresses and DNS
>>>names we could use instead of 'ipaddr' or 'ip-address'?
>>
>>ModWiki uses <host>
>
>+1 on <host>, then. It might be a bit ambiguous, or at least somewhat hard
>to understand, but what it's for will be written in the spec., so it's no
>big issue. <host> is at least better than both <ipaddr> and <ip-address>,
>imho.

Please check RFC 2396 and RFC 2396bis. The URI spec has exactly
the same problem, and has solved some things already that
you might want to include (futureproofing for IP versions,...).
The name is only a syntax production, so it probably has not
received as much thought as an XML element, or was choosen
to distinguish from other syntax productions.

Regards,   Martin.



From owner-atom-syntax@mail.imc.org  Mon Jul  5 19: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 TAA22541
	for <atompub-archive@lists.ietf.org>; Mon, 5 Jul 2004 19: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 i65MwbOV069877;
	Mon, 5 Jul 2004 15: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 i65MwbeG069876;
	Mon, 5 Jul 2004 15:58:37 -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 i65MwaRn069870
	for <atom-syntax@imc.org>; Mon, 5 Jul 2004 15:58:36 -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 011F44F2EA;
	Mon,  5 Jul 2004 18:58:39 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040705083522.05c5db20@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Mon, 05 Jul 2004 08:37:00 +0900
To: Mark Nottingham <mnot@mnot.net>,
        Bill de =?ISO-2022-JP?B?aBskQiViGyhCcmE=?= <bill@dehora.net>
From: Martin Duerst <duerst@w3.org>
Subject: Re: PaceNoInfoSet
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <27C3E61C-CCAF-11D8-B7F4-000A95BD86C0@mnot.net>
References: <40E59276.9030609@dehora.net>
 <F925141D-CC46-11D8-B7F4-000A95BD86C0@mnot.net>
 <40E59276.9030609@dehora.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: <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 22:09 04/07/02 -0700, Mark Nottingham wrote:

>How about:
>
>"Atom's data model is described in terms of the XML Information Set [ref] 
>and serialised as XML 1.0 [ref]."

As long as this does not imply using the terms in the XML Information Set
spec (Element Information Item, Attribute Information Item,...), I'm fine
with this. Using these terms would make the spec longer and more tedious
to read at no real benefit.

Regards,   Martin.



>--
>Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Mon Jul  5 19:16: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 TAA22739
	for <atompub-archive@lists.ietf.org>; Mon, 5 Jul 2004 19:16: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 i65Mxkwq069995;
	Mon, 5 Jul 2004 15:59:46 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i65MxkFW069994;
	Mon, 5 Jul 2004 15:59:46 -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 i65MxjIQ069986
	for <atom-syntax@imc.org>; Mon, 5 Jul 2004 15:59: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 i65Mxh407267
	for <atom-syntax@imc.org>; Mon, 5 Jul 2004 15:59:43 -0700 (PDT)
Received: from aol.net ([10.169.192.35]) by judge.mcom.com
          (Netscape Messaging Server 4.15) with ESMTP id I0EIJD02.Z19;
          Mon, 5 Jul 2004 15:59:37 -0700 
Message-ID: <40E9DD5A.9070601@aol.net>
Date: Mon, 05 Jul 2004 15:59:38 -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: Julian Reschke <julian.reschke@gmx.de>
CC: Ken MacLeod <ken@bitsko.slc.ut.us>, Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceSimpleResourcePosting and PUT
References: <opsairy6o1uvpchu@quark> <40E64BA6.5070402@aol.net>	<f732822d0407030053186491b6@mail.gmail.com> <40E70539.70504@aol.net>	<f732822d04070315154ffe4dbd@mail.gmail.com> <m3k6xksp6j.fsf@bitsko.slc.ut.us> <40E74650.2020100@aol.net> <40E7C381.5020109@gmx.de>
In-Reply-To: <40E7C381.5020109@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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:

>
> John Panzer wrote:
>
>>  >From my reading of the RFCs, clients can also use HEAD (and for 
>> that matter, GET) and look at the Allow: response header the server 
>> returns.  If no header exists, the default allowed methods are HEAD 
>> and GET.   If the header does exist, it should give the same 
>> information it would have given for OPTIONS.  So I'm assuming that 
>> clients can use HEAD as a workaround; is this a valid assumption?  Am 
>> I reading the standards correctly?
>
>
> Well, only if you do it as workaround, that is: try OPTIONS first then 
> do HEAD as a last resort. We can't require all servers to return 
> "Allow:" headers upon HEAD just because their support for OPTIONS is 
> broken. BTW: note that with a complex server supporting WebDAV ACL and 
> DeltaV, computing the set of allowed methods may be quite complex and 
> certainly isn't something you want to do for each single HEAD request.
>
> Anyway, the simplest way to discover support for PUT is to do the PUT 
> request and to look at the HTTP response code. If it's 405, the PUT 
> method is not supported for that resource (and a compliant server 
> *then* will send an "Allow:" header with the names of supported methods).
>
Hmm.  What exactly does Apache return for OPTIONS?  Does it return a 200 
success code?  Quick experiment with 1.3.26, virtual host environment:

-------
$ telnet johnpanzer.com 80
Trying 64.71.137.114...
Connected to johnpanzer.com.
Escape character is '^]'.
OPTIONS /cgi-bin/hello.cgi HTTP/1.1
Host: johnpanzer.com

HTTP/1.1 200 OK
Date: Mon, 05 Jul 2004 22:14:54 GMT
Server: Apache/1.3.26 (Unix) AuthMySQL/2.20 PHP/4.1.2 mod_gzip/1.3.19.1a 
mod_ssl/2.8.9 OpenSSL/0.9.6g
Content-Length: 0
Allow: GET, HEAD, POST, OPTIONS, TRACE
-------
So, assuming that if Apache intercepts OPTIONS it will return 200 OK and 
say that it doesn't support PUT and DELETE by default...

...how can I tell whether OPTIONS is broken?  Should a client check for 
PUT and DELETE in OPTIONS, and then if they're not there, do a HEAD and 
see if _that_ lists them?

-------
telnet johnpanzer.com 80
Trying 64.71.137.114...
Connected to walnut.he.net (64.71.137.114).
Escape character is '^]'.
HEAD /cgi-bin/hello.cgi HTTP/1.1
Host: johnpanzer.com

HTTP/1.1 200 OK
Date: Mon, 05 Jul 2004 22:17:59 GMT
Server: Apache/1.3.26 (Unix) AuthMySQL/2.20 PHP/4.1.2 mod_gzip/1.3.19.1a 
mod_ssl/2.8.9 OpenSSL/0.9.6g
Content-Type: text/html
-------
 
The script actually gets called for HEAD, so it could put in something 
like Allow: GET, HEAD, POST, OPTIONS, TRACE, PUT, DELETE.  In this case, 
the script isn't written nicely and doesn't put in Allow: at all. 

Here's my question:  If you have a server where OPTIONS returns a valid 
Allow: header for your script (but disallows PUT and DELETE), _and_ for 
efficiency reasons does not return an Allow: header for HEAD... how do 
you distinguish this from a 'broken' server that looks like the one 
above?  I can't see any way.  So a client is going to have to ignore the 
result of OPTIONS completely and just try the method, as Julian 
suggested.  Which is a shame, because clients can't then be smart about 
what options they present to the user.

Alternatively, we could just say a server SHOULD support OPTIONS/Allow: 
; clients SHOULD trust the results; if OPTIONS says PUT is disallowed, 
clients have a workaround: POST a new copy of the resource (getting a 
new URL) and move the link(s) in question.  Which they should have the 
freedom to do anyway.  (Of course clients can also do an attempt-to-PUT 
first and only create a new resource if it returns a 405.)

Here's what this might look like as an edit to PaceSimpleResourcePosting:

> To support capability discovery, servers SHOULD support the 
> [http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.2 OPTIONS] 
> method on the resource URI and return the list of other allowed 
> methods in the 
> [http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.7 
> Allow:] header.  Further, PUT or DELETE MUST each return an 
> appropriate HTTP status if not implemented -- e.g., 405. (Not all CGI 
> based servers can provide a valid Allow: header from OPTIONS. If PUT 
> and DELETE are in Allow:, user agents SHOULD assume they are in fact 
> available for the URI.  If not, user agents MAY assume they are not 
> available.  User agents MAY alternatively attempt PUT or DELETE to the 
> URI and check the result status.)  (Note that a workaround for lack of 
> PUT support is to create a new resource via ResourcePostURI and update 
> the relevant link to point to the new resource.)
>
> Atom servers MAY optionally also support some profile of WebDAV for 
> these resources.  The above capability discovery and usage is upwardly 
> compatible with WebDAV, so clients MAY elect to support either or both.



-John




From owner-atom-syntax@mail.imc.org  Mon Jul  5 19:24:37 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22999
	for <atompub-archive@lists.ietf.org>; Mon, 5 Jul 2004 19:24:36 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i65N6cYo070526;
	Mon, 5 Jul 2004 16:06: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 i65N6cAA070525;
	Mon, 5 Jul 2004 16:06:38 -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 i65N6cSx070519
	for <atom-syntax@imc.org>; Mon, 5 Jul 2004 16:06:38 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.10] (unknown [63.96.165.85])
	by mail.mnot.net (Postfix) with ESMTP
	id 6A002727D; Mon,  5 Jul 2004 16:06:43 -0700 (PDT)
In-Reply-To: <4.2.0.58.J.20040705083522.05c5db20@localhost>
References: <40E59276.9030609@dehora.net> <F925141D-CC46-11D8-B7F4-000A95BD86C0@mnot.net> <40E59276.9030609@dehora.net> <4.2.0.58.J.20040705083522.05c5db20@localhost>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <FA57C169-CED7-11D8-8B38-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: Atom Syntax <atom-syntax@imc.org>,
        =?UTF-8?Q?Bill_de_h=E3=83=A2ra?= <bill@dehora.net>
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: PaceNoInfoSet
Date: Mon, 5 Jul 2004 16:06:42 -0700
To: Martin Duerst <duerst@w3.org>
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>
Content-Transfer-Encoding: 7bit


That's the plan; the Notational Conventions state:

                 Atom is specified using the XML Infoset, but uses a 
shorthand
                 for common terms; the phrase "Information Item" is not 
used
                 when naming XML constructs.

Cheers,


On Jul 4, 2004, at 4:37 PM, Martin Duerst wrote:

> At 22:09 04/07/02 -0700, Mark Nottingham wrote:
>
>> How about:
>>
>> "Atom's data model is described in terms of the XML Information Set 
>> [ref] and serialised as XML 1.0 [ref]."
>
> As long as this does not imply using the terms in the XML Information 
> Set
> spec (Element Information Item, Attribute Information Item,...), I'm 
> fine
> with this. Using these terms would make the spec longer and more 
> tedious
> to read at no real benefit.
>
> Regards,   Martin.
>
>
>
>> --
>> Mark Nottingham     http://www.mnot.net/
>>

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Tue Jul  6 03:51: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 DAA27103
	for <atompub-archive@lists.ietf.org>; Tue, 6 Jul 2004 03: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 i667UfQj056195;
	Tue, 6 Jul 2004 00: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 i667UfhW056194;
	Tue, 6 Jul 2004 00:30: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.net [213.165.64.20])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i667UdgN056125
	for <atom-syntax@imc.org>; Tue, 6 Jul 2004 00:30:40 -0700 (PDT)
	(envelope-from julian.reschke@gmx.de)
Received: (qmail 17140 invoked by uid 65534); 6 Jul 2004 07:30:29 -0000
Received: from pD9FF098B.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.9.139)
  by mail.gmx.net (mp023) with SMTP; 06 Jul 2004 09:30:29 +0200
X-Authenticated: #1915285
Message-ID: <40EA5512.2050909@gmx.de>
Date: Tue, 06 Jul 2004 09:30:26 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: John Panzer <jpanzer@aol.net>
CC: Ken MacLeod <ken@bitsko.slc.ut.us>, Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceSimpleResourcePosting and PUT
References: <opsairy6o1uvpchu@quark> <40E64BA6.5070402@aol.net>	<f732822d0407030053186491b6@mail.gmail.com> <40E70539.70504@aol.net>	<f732822d04070315154ffe4dbd@mail.gmail.com> <m3k6xksp6j.fsf@bitsko.slc.ut.us> <40E74650.2020100@aol.net> <40E7C381.5020109@gmx.de> <40E9DD5A.9070601@aol.net>
In-Reply-To: <40E9DD5A.9070601@aol.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


John Panzer wrote:
> Hmm.  What exactly does Apache return for OPTIONS?  Does it return a 200 
> success code?  Quick experiment with 1.3.26, virtual host environment:
> 
> -------
> $ telnet johnpanzer.com 80
> Trying 64.71.137.114...
> Connected to johnpanzer.com.
> Escape character is '^]'.
> OPTIONS /cgi-bin/hello.cgi HTTP/1.1
> Host: johnpanzer.com
> 
> HTTP/1.1 200 OK
> Date: Mon, 05 Jul 2004 22:14:54 GMT
> Server: Apache/1.3.26 (Unix) AuthMySQL/2.20 PHP/4.1.2 mod_gzip/1.3.19.1a 
> mod_ssl/2.8.9 OpenSSL/0.9.6g
> Content-Length: 0
> Allow: GET, HEAD, POST, OPTIONS, TRACE
> -------
> So, assuming that if Apache intercepts OPTIONS it will return 200 OK and 
> say that it doesn't support PUT and DELETE by default...
> 
> ...how can I tell whether OPTIONS is broken?  Should a client check for 
> PUT and DELETE in OPTIONS, and then if they're not there, do a HEAD and 
> see if _that_ lists them?

That's a good question. For plain WebDAV this isn't a problem, because 
it requires the server to *also* return the "DAV:" response header in 
the response (<http://greenbytes.de/tech/webdav/rfc2518.html#HEADER_DAV>).

> -------
> telnet johnpanzer.com 80
> Trying 64.71.137.114...
> Connected to walnut.he.net (64.71.137.114).
> Escape character is '^]'.
> HEAD /cgi-bin/hello.cgi HTTP/1.1
> Host: johnpanzer.com
> 
> HTTP/1.1 200 OK
> Date: Mon, 05 Jul 2004 22:17:59 GMT
> Server: Apache/1.3.26 (Unix) AuthMySQL/2.20 PHP/4.1.2 mod_gzip/1.3.19.1a 
> mod_ssl/2.8.9 OpenSSL/0.9.6g
> Content-Type: text/html
> -------
> 
> The script actually gets called for HEAD, so it could put in something 
> like Allow: GET, HEAD, POST, OPTIONS, TRACE, PUT, DELETE.  In this case, 
> the script isn't written nicely and doesn't put in Allow: at all.
> Here's my question:  If you have a server where OPTIONS returns a valid 
> Allow: header for your script (but disallows PUT and DELETE), _and_ for 
> efficiency reasons does not return an Allow: header for HEAD... how do 
> you distinguish this from a 'broken' server that looks like the one 
> above?  I can't see any way.  So a client is going to have to ignore the 
> result of OPTIONS completely and just try the method, as Julian 
> suggested.  Which is a shame, because clients can't then be smart about 
> what options they present to the user.

I think that's correct.

> Alternatively, we could just say a server SHOULD support OPTIONS/Allow: 
> ; clients SHOULD trust the results; if OPTIONS says PUT is disallowed, 
> clients have a workaround: POST a new copy of the resource (getting a 
> new URL) and move the link(s) in question.  Which they should have the 
> freedom to do anyway.  (Of course clients can also do an attempt-to-PUT 
> first and only create a new resource if it returns a 405.)

This probably will work.

> Here's what this might look like as an edit to PaceSimpleResourcePosting:
> 
>> To support capability discovery, servers SHOULD support the 
>> [http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.2 OPTIONS] 
>> method on the resource URI and return the list of other allowed 
>> methods in the 
>> [http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.7 
>> Allow:] header.  Further, PUT or DELETE MUST each return an 
>> appropriate HTTP status if not implemented -- e.g., 405. (Not all CGI 
>> based servers can provide a valid Allow: header from OPTIONS. If PUT 
>> and DELETE are in Allow:, user agents SHOULD assume they are in fact 
>> available for the URI.  If not, user agents MAY assume they are not 
>> available.  User agents MAY alternatively attempt PUT or DELETE to the 
>> URI and check the result status.)  (Note that a workaround for lack of 
>> PUT support is to create a new resource via ResourcePostURI and update 
>> the relevant link to point to the new resource.)
>>
>> Atom servers MAY optionally also support some profile of WebDAV for 
>> these resources.  The above capability discovery and usage is upwardly 
>> compatible with WebDAV, so clients MAY elect to support either or both.

Julian
-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From owner-atom-syntax@mail.imc.org  Tue Jul  6 08: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 IAA09406
	for <atompub-archive@lists.ietf.org>; Tue, 6 Jul 2004 08:23: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 i66BxMc0027617;
	Tue, 6 Jul 2004 04:59: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 i66BxM44027616;
	Tue, 6 Jul 2004 04:59: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 (mproxy.gmail.com [216.239.56.248])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i66BxM6B027607
	for <atom-syntax@imc.org>; Tue, 6 Jul 2004 04:59:22 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so4159257cwc
        for <atom-syntax@imc.org>; Tue, 06 Jul 2004 04:59:16 -0700 (PDT)
Received: by 10.11.116.8 with SMTP id o8mr70582cwc;
        Tue, 06 Jul 2004 04:59:16 -0700 (PDT)
Message-ID: <3f1451f5040706045969f0c2d1@mail.gmail.com>
Date: Tue, 6 Jul 2004 07:59:16 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Greg Stein <gstein@google.com>
Subject: Re: PaceSecurityServices & Digest auth
Cc: Ezra Cooper <ezra@sixapart.com>, atom-syntax@imc.org
In-Reply-To: <20040705115449.GA27740@google.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <37DF50E8-CB00-11D8-8081-000A95CFF6CC@sixapart.com> <20040705115449.GA27740@google.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 Mon, 5 Jul 2004 04:54:49 -0700, Greg Stein <gstein@google.com> wrote:
> 
> On Wed, Jun 30, 2004 at 06:44:40PM -0700, Ezra Cooper wrote:
> >...
> > I see three issues to be addressed with Digest:
> >
> >   (1) Some web-servers remove the WWW-Authenticate header before
> > passing it to a CGI program.
> 
> This is on purpose. Very, very much so.
> 
> The mechanism for passing information from the web server to the CGI
> program is via the environment. The particular scenario that you're trying
> to solve is "my ISP let's me write a CGI, and I can't enable authn within
> the web server itself [so I must do authn in the CGI script]".
> 
> Now carry this forward a couple steps. In some environments, suExec is
> being used so the script runs as the user who wrote the thing. But in some
> environments, the CGI runs as the same user as the httpd process. Or, in
> other words, *all* CGI scripts run that way.
> 
> Now you've got a bunch of CGI scripts all running as the same uid, and
> you've got some authn information sitting in the environment of some. Now
> some cracker comes along and simply dumps out /proc/*/environ from his own
> CGI. Sure, many can't be read, but some *can*. And now he has your
> password.
 
Not true in the case of Digest. In the case of Basic where the 
password is passed in plain text this is a problem but there 
is no reason at all for Apache to strip the headers for Digest. 

 
> > To address (1), I propose this addition to the end of section K,kk. in
> > PaceSecurityServices:
> >
> > ========
> > An Atom client MAY authenticate itself to an Atom server by sending an
> > X-Atom-Authenticate HTTP header, in the same form as for the
> > WWW-Authenticate header [RFC2617]. If an Atom client sends a
> > WWW-Authenticate header, it SHOULD have the same value as the
> > X-Atom-Authenticate header.
> > ========
> 
> This simply introduces a security hole, which is not something we should
> be advocating or encouraging. I'll -1 this right now. And if I'm feeling
> particularly evil, I'll go update the httpd server to filter this header,
> too (big <wink>!)

Apache needlessly strips the headers when Digest authentication
is used thus locking out CGIs from handling the authentication
themselves. If Apache didn't have that behaviour than the creation
of  this variant of Digest wouldn't have been necessary.

Please understand that *you* are the damage we are trying to route around.

   Thanks,
   -joe



From owner-atom-syntax@mail.imc.org  Tue Jul  6 08:32: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 IAA10071
	for <atompub-archive@lists.ietf.org>; Tue, 6 Jul 2004 08:32: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 i66CBhQN028941;
	Tue, 6 Jul 2004 05: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 i66CBhBZ028940;
	Tue, 6 Jul 2004 05:11: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 (mproxy.gmail.com [216.239.56.241])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i66CBhk6028934
	for <atom-syntax@imc.org>; Tue, 6 Jul 2004 05:11:43 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id w29so3003951cwb
        for <atom-syntax@imc.org>; Tue, 06 Jul 2004 05:11:45 -0700 (PDT)
Received: by 10.11.99.49 with SMTP id w49mr401013cwb;
        Tue, 06 Jul 2004 05:11:45 -0700 (PDT)
Message-ID: <3f1451f504070605116418a38c@mail.gmail.com>
Date: Tue, 6 Jul 2004 08:11:45 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Eric Scheid <eric.scheid@ironclad.net.au>
Subject: Re: PaceEntryOrigin
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <BD0FBA6D.1D67F%eric.scheid@ironclad.net.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <BD0FBA6D.1D67F%eric.scheid@ironclad.net.au>
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, 06 Jul 2004 02:09:49 +1000, Eric Scheid
<eric.scheid@ironclad.net.au> wrote:
> 
> On 6/7/04 1:39 AM, "Robert Sayre" <mint@franklinmint.fm> wrote:
> 
> > As do I. The other mechanisms that have been proposed (xlink, rdf/xml, etc)
> > are all capable of handling unknown link types.
> 
> You do realise that xlink has much more complicated semantics of linking,
> right? For example, it has an attribute 'type' which could have values of
> "simple", "extended", "locator", "arc", "resource", "title", or "none". Then
> there are the other attributes like 'actuate'.
> 
> Do we really want to require atom applications to handle such a complicated
> thing?

Also any consideration of XLink would have to take into 
acccount the fact that the xlink:type attribute is a *mandatory*
attribute that MUST be present on every element
that uses xlink, even if it is just simple linking,
i.e. xlink:type="simple".

All the more reason to consider SkunkLink.

    Thanks,
    -joe



From owner-atom-syntax@mail.imc.org  Tue Jul  6 08:33: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 IAA10344
	for <atompub-archive@lists.ietf.org>; Tue, 6 Jul 2004 08: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 i66CFUwg029302;
	Tue, 6 Jul 2004 05:15: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 i66CFUIY029301;
	Tue, 6 Jul 2004 05:15: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 i66CFTp8029293
	for <atom-syntax@imc.org>; Tue, 6 Jul 2004 05:15:30 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net ([66.57.27.65])
	(authenticated bits=0)
	by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i66CFtxr021123;
	Tue, 6 Jul 2004 08:15:55 -0400
Message-ID: <40EA97DB.6010600@intertwingly.net>
Date: Tue, 06 Jul 2004 08:15:23 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <tbray@textuality.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceNoInfoSet
References: <F925141D-CC46-11D8-B7F4-000A95BD86C0@mnot.net> <40E59276.9030609@dehora.net> <27C3E61C-CCAF-11D8-B7F4-000A95BD86C0@mnot.net> <58E465B4-CCFD-11D8-BA50-000A95A51C9E@sun.com> <3C16EE15-CD1B-11D8-A3E7-000A95CCC59E@xegesis.org> <15A0CA58-CD22-11D8-BA50-000A95A51C9E@sun.com> <6497E842-CD33-11D8-A3E7-000A95CCC59E@xegesis.org> <D91F78DA-CDD4-11D8-B7F4-000A95BD86C0@mnot.net> <8D29C042-CDDA-11D8-B898-000A95A51C9E@textuality.com>
In-Reply-To: <8D29C042-CDDA-11D8-B898-000A95A51C9E@textuality.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:

>> In any case, we need close on this; can we get a reading from folks on 
>> whether they want Atom to mean:
>>   a) An abstract data model
>>   b) A particular arrangement of bits
> 
> (b), because experience has taught us that interoperation on the basis 
> of syntax is do-able (not easy, do-able), while interaction on the basis 
> of data model is insanely difficult in the general case in heterogeneous 
> networked applications.  I think we have to be all about 
> interoperability first, last, and always. -Tim

I don't quite see it as that black and white.

In particular, I see the following arrangements of bits as being 
indistinguishable:

    '>', '&gt;', '&#62;', and '&#x3e', '&#x3E'

There are a number of other questions which infosets answer.  For 
example, on elements which permit a number of attributes, are the order 
of attributes significant?  Is the amount of whitespace separating such 
attributes significant?

- Sam Ruby




From owner-atom-syntax@mail.imc.org  Tue Jul  6 08:33: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 IAA10366
	for <atompub-archive@lists.ietf.org>; Tue, 6 Jul 2004 08:33: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 i66CCs9r028993;
	Tue, 6 Jul 2004 05:12: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 i66CCsYq028992;
	Tue, 6 Jul 2004 05:12: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 (mproxy.gmail.com [216.239.56.247])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i66CCsXp028986
	for <atom-syntax@imc.org>; Tue, 6 Jul 2004 05:12:54 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so4171793cwc
        for <atom-syntax@imc.org>; Tue, 06 Jul 2004 05:12:51 -0700 (PDT)
Received: by 10.11.116.64 with SMTP id o64mr401995cwc;
        Tue, 06 Jul 2004 05:12:51 -0700 (PDT)
Message-ID: <3f1451f50407060512572a23e3@mail.gmail.com>
Date: Tue, 6 Jul 2004 08:12:51 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: David Orchard <dorchard@bea.com>
Subject: Re: Atom API in WSDL 2.0
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <32D5845A745BFB429CBDBADA57CD41AF08AFC78E@ussjex01.amer.bea.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <32D5845A745BFB429CBDBADA57CD41AF08AFC78E@ussjex01.amer.bea.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 Mon, 5 Jul 2004 15:39:58 -0700, David Orchard <dorchard@bea.com> wrote:
> 
> I've published my take at the Atom API in WSDL 2.0 at http://www.pacificspirit.com/blog/2004/07/05/atom_03_wsdl_20
> 
> I've got a # of questions in there.  Can I consider them posted to the list, or should I post them 1 by 1?

Please post them to the list 1 by 1.

    Thanks,
    -joe



From owner-atom-syntax@mail.imc.org  Tue Jul  6 09: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 JAA12841
	for <atompub-archive@lists.ietf.org>; Tue, 6 Jul 2004 09:21:40 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i66D19cO033612;
	Tue, 6 Jul 2004 06:01: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 i66D19Zf033611;
	Tue, 6 Jul 2004 06:01:09 -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 i66D18Ab033603
	for <atom-syntax@imc.org>; Tue, 6 Jul 2004 06:01:09 -0700 (PDT)
	(envelope-from djpowell@djpowell.net)
Received: (qmail 91651 invoked from network); 6 Jul 2004 13:01:10 -0000
Received: from localhost.34sp.com (HELO localhost) (127.0.0.1)
  by localhost.34sp.com with SMTP; 6 Jul 2004 13:01:10 -0000
Received: from 194.203.191.188 ([194.203.191.188]) 
	by webmail.djpowell.net (IMP) with HTTP 
	for <davep@djpowell.net@localhost>; Tue,  6 Jul 2004 14:01:10 +0100
Message-ID: <1089118870.40eaa2964b912@webmail.djpowell.net>
Date: Tue,  6 Jul 2004 14:01:10 +0100
From: David Powell <djpowell@djpowell.net>
To: atom-syntax@imc.org
Subject: Avoiding duplicate entries / Idempotent posting
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: <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


Hi,

I’ve recently been looking at the Atom API spec, and admittedly haven't spent
much time trawling the list archives yet, so apologies if this has been
discussed:

Does the Atom API provide a way to idempotently POST an entry?  In the case of
some protocol-level errors it is not possible to tell if the entry has been
posted, so the client can't know whether or not to retry the request and risk
posting a duplicate entry. 

Eg:

try {
  POST entry
  if (status==2xx) then OK
  if (status==4xx) then REPORT_ERROR
  if (status==5xx) then RETRY_REQUEST
  ...
} catch IOException {
  // what now? 
}


One way of avoiding this problem (a) is to POST a dummy entry (or a zero-length
POST?) to the PostURI.  This dummy entry would be marked as hidden and wouldn't
show on the feed or the site, but then its EditURI could be used by the client
to PUT the entry to when it is ready to upload it.  The POST would essentially
just be used to reserve a URI, and as PUTing to an EditURI is idempotent, the
client can just repeat the PUT if there is an error.


Another possibility (b) would be to continue to use POST, but to add a
"message-id" field containing a GUID to the entry (in the body or in HTTP?),
and to allow the server to ignore duplicate message-ids.


Either of these techniques could be deployed without affecting existing clients
that do not require idempotent posting.

These techniques would both require extensions to Atom, do people have any other
techniques for avoiding duplicate entries?  I think that it is important to get
this right, especially for Atom clients on mobile devices where connectivity
might be less than ideal.

-- 
Dave



From owner-atom-syntax@mail.imc.org  Tue Jul  6 10:03: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 KAA15802
	for <atompub-archive@lists.ietf.org>; Tue, 6 Jul 2004 10:03: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 i66Dd5ba037072;
	Tue, 6 Jul 2004 06:39: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 i66Dd54Y037071;
	Tue, 6 Jul 2004 06:39: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 (mproxy.gmail.com [216.239.56.243])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i66Dd3nd037053
	for <atom-syntax@imc.org>; Tue, 6 Jul 2004 06:39:05 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so4244062cwc
        for <atom-syntax@imc.org>; Tue, 06 Jul 2004 06:39:00 -0700 (PDT)
Received: by 10.11.118.68 with SMTP id q68mr424538cwc;
        Tue, 06 Jul 2004 06:39:00 -0700 (PDT)
Message-ID: <3f1451f50407060639164fbe53@mail.gmail.com>
Date: Tue, 6 Jul 2004 09:39:00 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: David Powell <djpowell@djpowell.net>
Subject: Re: Avoiding duplicate entries / Idempotent posting
Cc: atom-syntax@imc.org
In-Reply-To: <1089118870.40eaa2964b912@webmail.djpowell.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <1089118870.40eaa2964b912@webmail.djpowell.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,  6 Jul 2004 14:01:10 +0100, David Powell <djpowell@djpowell.net> wrote:
> 
> Hi,
> 
> I've recently been looking at the Atom API spec, and admittedly haven't spent
> much time trawling the list archives yet, so apologies if this has been
> discussed:
> 
> Does the Atom API provide a way to idempotently POST an entry?  In the case of
> some protocol-level errors it is not possible to tell if the entry has been
> posted, so the client can't know whether or not to retry the request and risk
> posting a duplicate entry.

Only a HTTP response of 201 indicates that an
entry has been created. More verbage should be added
to the spec to make that clearer.

    Thanks,
    -joe



From owner-atom-syntax@mail.imc.org  Tue Jul  6 11:04: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 LAA21888
	for <atompub-archive@lists.ietf.org>; Tue, 6 Jul 2004 11:04: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 i66EdkeI042246;
	Tue, 6 Jul 2004 07:39: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 i66Edk8g042245;
	Tue, 6 Jul 2004 07:39: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 i66EdjYb042239
	for <atom-syntax@imc.org>; Tue, 6 Jul 2004 07:39:45 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.10] (unknown [63.96.165.85])
	by mail.mnot.net (Postfix) with ESMTP
	id 1F582727D; Tue,  6 Jul 2004 07:39:48 -0700 (PDT)
In-Reply-To: <3f1451f50407060639164fbe53@mail.gmail.com>
References: <1089118870.40eaa2964b912@webmail.djpowell.net> <3f1451f50407060639164fbe53@mail.gmail.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <53ED40FE-CF5A-11D8-8B38-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: atom-syntax@imc.org, David Powell <djpowell@djpowell.net>
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: Avoiding duplicate entries / Idempotent posting
Date: Tue, 6 Jul 2004 07:39:46 -0700
To: Joe Gregorio <joe.gregorio@gmail.com>
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>
Content-Transfer-Encoding: 7bit


That doesn't guarantee that a post won't be duplicated; for example, if 
the connection drops before the response is received by the client, the 
server will have created the resource, but the client will believe it 
hasn't.

For something more reliable, see:
   http://www.mnot.net/blog/2003/09/13/click_submit_only_once


On Jul 6, 2004, at 6:39 AM, Joe Gregorio wrote:

>
> On Tue,  6 Jul 2004 14:01:10 +0100, David Powell 
> <djpowell@djpowell.net> wrote:
>>
>> Hi,
>>
>> I've recently been looking at the Atom API spec, and admittedly 
>> haven't spent
>> much time trawling the list archives yet, so apologies if this has 
>> been
>> discussed:
>>
>> Does the Atom API provide a way to idempotently POST an entry?  In 
>> the case of
>> some protocol-level errors it is not possible to tell if the entry 
>> has been
>> posted, so the client can't know whether or not to retry the request 
>> and risk
>> posting a duplicate entry.
>
> Only a HTTP response of 201 indicates that an
> entry has been created. More verbage should be added
> to the spec to make that clearer.
>
>     Thanks,
>     -joe
>

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Tue Jul  6 11:11: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 LAA22150
	for <atompub-archive@lists.ietf.org>; Tue, 6 Jul 2004 11: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 i66Elgnn043964;
	Tue, 6 Jul 2004 07:47: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 i66Elgcv043963;
	Tue, 6 Jul 2004 07:47: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-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 i66ElfaP043949;
	Tue, 6 Jul 2004 07:47:41 -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 i66Eliil019179;
	Tue, 6 Jul 2004 08:47:44 -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 <0I0F00M0LQFJF5@edgemail1.Central.Sun.COM>; Tue,
 06 Jul 2004 08:47:44 -0600 (MDT)
Received: from [192.168.1.100] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0F003TPQFJL5@mail.sun.net>; Tue,
 06 Jul 2004 08:47:43 -0600 (MDT)
Date: Tue, 06 Jul 2004 07:47:41 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceSecurityServices & Digest auth
In-reply-to: <3f1451f5040706045969f0c2d1@mail.gmail.com>
To: Atom Syntax <atom-syntax@imc.org>, Paul Hoffman <phoffman@imc.org>
Message-id: <6E8A9E95-CF5B-11D8-9E41-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: <37DF50E8-CB00-11D8-8081-000A95CFF6CC@sixapart.com>
 <20040705115449.GA27740@google.com> <3f1451f5040706045969f0c2d1@mail.gmail.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 Jul 6, 2004, at 4:59 AM, Joe Gregorio wrote:

... a bunch of reasonable arguments about Apache headers, then...

> Please understand that *you* are the damage we are trying to route 
> around.

Joe, *please* don't do this.  You can't be an editor and a leader of 
the community and a flamer at the same time.  I think an apology to 
Greg would be in order.

- Tim Bray, Director of Web Technologies, Sun Microsystems
   +1-877-305-0889 http://www.tbray.org/ongoing/
   AIM: MarkupPedant



From owner-atom-syntax@mail.imc.org  Tue Jul  6 11:14: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 LAA22315
	for <atompub-archive@lists.ietf.org>; Tue, 6 Jul 2004 11:14: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 i66EvYKd045068;
	Tue, 6 Jul 2004 07:57:34 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i66EvY2g045067;
	Tue, 6 Jul 2004 07:57:34 -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 i66EvWZj045058
	for <atom-syntax@imc.org>; Tue, 6 Jul 2004 07:57:33 -0700 (PDT)
	(envelope-from djpowell@djpowell.net)
Received: (qmail 6013 invoked from network); 6 Jul 2004 14:57:35 -0000
Received: from localhost.34sp.com (HELO localhost) (127.0.0.1)
  by localhost.34sp.com with SMTP; 6 Jul 2004 14:57:35 -0000
Received: from 194.203.191.188 ([194.203.191.188]) 
	by webmail.djpowell.net (IMP) with HTTP 
	for <davep@djpowell.net@localhost>; Tue,  6 Jul 2004 15:57:35 +0100
Message-ID: <1089125855.40eabddf30bdd@webmail.djpowell.net>
Date: Tue,  6 Jul 2004 15:57:35 +0100
From: David Powell <djpowell@djpowell.net>
To: Joe Gregorio <joe.gregorio@gmail.com>
Cc: atom-syntax@imc.org
Subject: Re: Avoiding duplicate entries / Idempotent posting
References: <1089118870.40eaa2964b912@webmail.djpowell.net> <3f1451f50407060639164fbe53@mail.gmail.com>
In-Reply-To: <3f1451f50407060639164fbe53@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: <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 Joe Gregorio <joe.gregorio@gmail.com>:

> 
> On Tue,  6 Jul 2004 14:01:10 +0100, David Powell <djpowell@djpowell.net>
> wrote:
> > 
> > Hi,
> > 
> > I've recently been looking at the Atom API spec, and admittedly haven't
> spent
> > much time trawling the list archives yet, so apologies if this has been
> > discussed:
> > 
> > Does the Atom API provide a way to idempotently POST an entry?  In the case
> of
> > some protocol-level errors it is not possible to tell if the entry has
> been
> > posted, so the client can't know whether or not to retry the request and
> risk
> > posting a duplicate entry.
> 
> Only a HTTP response of 201 indicates that an
> entry has been created. More verbage should be added
> to the spec to make that clearer.
> 
>     Thanks,
>     -joe
> 

Thanks, but perhaps I wasn't clear:

I understand that 201 means that the entry was created, and 4xx/5xx means that
the entry was not created, but I was talking about the case where no status
code reaches the client at all.

The sort of situation where the client has sent the request, but not received a
response, so doesn't know whether the server has failed to process the request,
or processed the request but failed to return the status.

This could be caused by network problems causing a connection to be dropped,
proxies failing, or anything where the client's HTTP library decides to throw
an exception rather than returning the response for whatever reason.

Another example would be if the user was connected via a proxy, and the proxy
returned a 502/503/504 response.  The client wouldn't know whether the POST had
been successfully processed or not.

I have implemented HTTP applications before where these sort of errors have
occurred and it isn't nice to have no deterministic way of knowing what to do
next.


As you might have guessed this request comes from one of those early
interactions with the Internet that has left me scarred – we've all encountered
the following horror story:

  You click on a button on a web page marked "Send" or "Buy" only to spend
  the next 5 minutes staring at a spinning IE logo whilst the realisation
  that you have been jilted sinks in.  Usually these pages have stern red
  text below them that warns you to only click the button once.

Things don't have to be this way.
 
-- 
Dave





From owner-atom-syntax@mail.imc.org  Tue Jul  6 11:46: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 LAA24720
	for <atompub-archive@lists.ietf.org>; Tue, 6 Jul 2004 11:46: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 i66FF2VL046974;
	Tue, 6 Jul 2004 08:15: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 i66FF2G6046973;
	Tue, 6 Jul 2004 08:15: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 (mproxy.gmail.com [216.239.56.253])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i66FF2eF046967
	for <atom-syntax@imc.org>; Tue, 6 Jul 2004 08:15:02 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id w29so3121082cwb
        for <atom-syntax@imc.org>; Tue, 06 Jul 2004 08:15:05 -0700 (PDT)
Received: by 10.11.99.49 with SMTP id w49mr420748cwb;
        Tue, 06 Jul 2004 08:15:05 -0700 (PDT)
Message-ID: <3f1451f50407060815645d59e8@mail.gmail.com>
Date: Tue, 6 Jul 2004 11:15:05 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Greg Stein <gstein@google.com>
Subject: Re: PaceSecurityServices & Digest auth
Cc: Ezra Cooper <ezra@sixapart.com>, atom-syntax@imc.org
In-Reply-To: <3f1451f5040706045969f0c2d1@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <37DF50E8-CB00-11D8-8081-000A95CFF6CC@sixapart.com> <20040705115449.GA27740@google.com> <3f1451f5040706045969f0c2d1@mail.gmail.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, 6 Jul 2004 07:59:16 -0400, Joe Gregorio <joe.gregorio@gmail.com> wrote:
> Please understand that *you* are the damage we are trying to route around.

It has been pointed out to me off-list that this 
was unduly harsh. Please accepy my apologies.

    -joe



From owner-atom-syntax@mail.imc.org  Tue Jul  6 12:01:14 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26501
	for <atompub-archive@lists.ietf.org>; Tue, 6 Jul 2004 12: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 i66FXOio050295;
	Tue, 6 Jul 2004 08:33: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 i66FXO4R050294;
	Tue, 6 Jul 2004 08:33: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 (mproxy.gmail.com [216.239.56.240])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i66FXOMU050288
	for <atom-syntax@imc.org>; Tue, 6 Jul 2004 08:33:24 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so4341098cwc
        for <atom-syntax@imc.org>; Tue, 06 Jul 2004 08:33:27 -0700 (PDT)
Received: by 10.11.116.8 with SMTP id o8mr93965cwc;
        Tue, 06 Jul 2004 08:33:26 -0700 (PDT)
Message-ID: <3f1451f5040706083331333d4a@mail.gmail.com>
Date: Tue, 6 Jul 2004 11:33:26 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: David Powell <djpowell@djpowell.net>
Subject: Re: Avoiding duplicate entries / Idempotent posting
Cc: atom-syntax@imc.org
In-Reply-To: <1089125855.40eabddf30bdd@webmail.djpowell.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <1089118870.40eaa2964b912@webmail.djpowell.net> <3f1451f50407060639164fbe53@mail.gmail.com> <1089125855.40eabddf30bdd@webmail.djpowell.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,  6 Jul 2004 15:57:35 +0100, David Powell <djpowell@djpowell.net> wrote:
> Thanks, but perhaps I wasn't clear:
> 
....
> 
> Things don't have to be this way.

Now I get it, and Mark has pointed out one such solution:

http://www.mnot.net/blog/2003/09/13/click_submit_only_once

The other possibility is to do a GET on the PostURI
to retrieve a partially filled in atom 'entry' which 
you stuff your content into before submitting
it back to PostURI to create an Entry. A nonce value
in a namespaced element could be added to such
a 'template' to avoid multiple submissions of the same
entry.

The idea of a 'template' entry retrieved from PostURI 
came up previously during a discussion of querying
server capabilities:

http://intertwingly.net/wiki/pie/AtomApiContentNegotiation

   -joe



From owner-atom-syntax@mail.imc.org  Tue Jul  6 14:01: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 OAA07531
	for <atompub-archive@lists.ietf.org>; Tue, 6 Jul 2004 14:01:23 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i66HOkOi060775;
	Tue, 6 Jul 2004 10:24: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 i66HOkHZ060774;
	Tue, 6 Jul 2004 10:24: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 i66HOjEl060766
	for <atom-syntax@imc.org>; Tue, 6 Jul 2004 10:24:45 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i66HMl53001039
	for <atom-syntax@imc.org>; Tue, 6 Jul 2004 11:22:47 -0600 (MDT)
Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0I0F00M2NXPCF5@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Tue, 06 Jul 2004 11:24:48 -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 <0I0F003SQXPBL5@mail.sun.net> for atom-syntax@imc.org; Tue,
 06 Jul 2004 11:24:48 -0600 (MDT)
Date: Tue, 06 Jul 2004 10:24:45 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Work Queue rotation #2
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <5FC8FF2B-CF71-11D8-9E41-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: <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


Per the current state of our issues list 
(http://www.intertwingly.net/wiki/pie/AtomPubIssuesList) we're supposed 
to be striving for consensus on PaceIntrospection and PaceEntryOrigin.

The discussion has been fairly light in volume and rather poorly 
focused, but on behalf Paul and myself, here's our best take on where 
we are:

1. PaceEntryOrigin.  There appears to be rough consensus that this 
back-pointer is a good idea.  Discussion of its exact syntax has been 
sucked into the PaceLinkConstruct rat-hole.  So, let's go ahead and 
wire it into the next set of drafts consistent with the way they are 
(which I take it means another <link rel=""> value) and, if we decide 
to change course on the way we do links, we'll change it then along 
with all the other links.

2. PaceIntrospection.  We don't detect consensus of any kind, rough or 
smooth, which means that there's nothing we can ask the editors to do.  
I'm not sure whether it's a problem with the way the Pace is written, 
or the focus of the discussion, or what, but let's declare temporary 
defeat on this one.  I think most of us think that having a documented 
introspection discover/introspection mechanism is an important piece of 
the puzzle, it's just that we haven't got a proposal written down yet 
that we can build consensus around.  Everyone please feel free to 
revise/recast/re-propose something in this area and we'll try again 
later.

So, Sam will now turn the crank and bring forward another small set of 
issues for us to try to knock off the list.   We need to work on at 
least one issue that affects the protocol, not just the data-format, 
drafts.  Also, given that we'd like to get a set of drafts done in time 
for the August IETF, it would be nice to select a few things that we 
have a chance of knocking off in the next week or two.

  -Tim



From owner-atom-syntax@mail.imc.org  Tue Jul  6 14:08: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 OAA08086
	for <atompub-archive@lists.ietf.org>; Tue, 6 Jul 2004 14:08: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 i66HfRNT062173;
	Tue, 6 Jul 2004 10:41: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 i66HfRAC062172;
	Tue, 6 Jul 2004 10:41:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rongo.sixapart.com (dsl081-057-015.sfo1.dsl.speakeasy.net [64.81.57.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i66HfRKs062161
	for <atom-syntax@imc.org>; Tue, 6 Jul 2004 10:41:27 -0700 (PDT)
	(envelope-from ezra@sixapart.com)
Received: from [192.168.100.250] (Aphrodite.sm.sixapart.com [192.168.100.250])
	by rongo.sixapart.com (Postfix) with ESMTP
	id CF76247BFD; Tue,  6 Jul 2004 09:38:35 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <B61CD3A8-CF73-11D8-A0A3-000A95CFF6CC@sixapart.com>
Content-Transfer-Encoding: 7bit
Cc: atom-syntax@imc.org
From: Ezra Cooper <ezra@sixapart.com>
Subject: Re: PaceSecurityServices & alternate algorithms
Date: Tue, 6 Jul 2004 10:41:29 -0700
To: Greg Stein <gstein@google.com>
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>
Content-Transfer-Encoding: 7bit


On Jul 5, 2004, at 4:54 AM, Greg Stein wrote:

> Why not just use WSSE? Above, you take issue with storing cleartext 
> digest
> passwords. Can't you just use WSSE and demand that the hashed-form of 
> that
> authn mechanism be used?

This sentence isn't totally clear to me, but I think it says either 
"demand that the user remember the hashed form of her familiar 
password" or "demand that the server use a certain algorithm to compute 
the stored version of the password."  But WSSE doesn't specify any 
particular hash algorithm, or provide an extensibility mechanism to 
pick one out at auth time, the way Digest does.

I want the user to be able to use her familiar password, and not the 
hashed version, of course.

Paul Hoffman wrote:

> The WSSE-like authentication mechanism as described earlier requires 
> that passwords be stored in the clear. It could be modified to allow 
> storage of a hashed form, I think. (I'm not sure here: we would need 
> to do some design and pass it by some applied crypto experts.)

This is essentially what I'm looking for, but it seems easier to use 
Digest than to modify WSSE.

Under Digest, the client can accept the familiar password from the 
user, and create the hashed form (according to a known algorithm named 
by the server), then prove to the server that it knows the hashed form.

This does have the weakness that if someone gets the hashed password 
off the server (which we assume a cracker can do, in a generic hosting 
environment), then he can authenticate himself to the server, because 
the hashed form is what would be used as the input to the Digest 
algorithm. The only advantage, then, is that the scope of the damage is 
limited, when we assume that the user has used that same password for 
other services. (Since the salt/realm would be different on other 
services, the hashed password would not be usable there).

Greg Stein wrote:

> I can't see that introducing alternate algorithms will fix it, either.
> Digest authn has a basic structural weakness (to exposure of the
> server-side cleartext passwords or hashes) because of how (and what)
> information is traded between server and client.

Agreed. Still, I see it as valuable to keep cleartext passwords off the 
wire and out of the server's storage, and Digest allows us to do that.

>>   (3) The default HTTP Digest auth algorithm is based on MD5, and
>> requires the server to be able to form an MD5 hash based on the triple
>> (username, realm, password). If you don't store either the cleartext
>> password or that specific hash, you're out of luck.
>
> "or that specific hash" seems to solve the problem just fine. What's 
> the
> issue here?
> [...]
> I can't see that introducing alternate algorithms will fix it, either.

The only reason to introduce alternate algorithms is to avoid a 
dependency on MD5. That might be valuable, because MD5 is (slightly) 
encumbered. I'm not hell-bent on this, but there may be some advantages 
to using SHA1 instead.

I'll defer to the community on whether MD5 should be required for all 
Atom tools (at least those that are not using SSL), or whether SHA1 
would be preferable.

> You aren't going to get around that unless you move to something more 
> akin to SSL

SSL solves all of the security problems, but it's not going to be 
feasible for many, many people who install downloadable software on a 
generic hosting account. I think this is a significant class of users 
that the community has chosen to keep in mind (correct me if I'm 
wrong).

I think SSL should be a 'standard option' for Atom auth since it does 
give more security and for those servers where it's possible, it's easy 
to set up.

Ezra



From owner-atom-syntax@mail.imc.org  Tue Jul  6 14:19: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 OAA09445
	for <atompub-archive@lists.ietf.org>; Tue, 6 Jul 2004 14: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 i66Hcnev061993;
	Tue, 6 Jul 2004 10:38: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 i66HcnmK061992;
	Tue, 6 Jul 2004 10:38:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rongo.sixapart.com (dsl081-057-015.sfo1.dsl.speakeasy.net [64.81.57.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i66HcmNe061977
	for <atom-syntax@imc.org>; Tue, 6 Jul 2004 10:38:48 -0700 (PDT)
	(envelope-from ezra@sixapart.com)
Received: from [192.168.100.250] (Aphrodite.sm.sixapart.com [192.168.100.250])
	by rongo.sixapart.com (Postfix) with ESMTP
	id D183E47F87; Tue,  6 Jul 2004 09:35:56 -0700 (PDT)
In-Reply-To: <20040705115449.GA27740@google.com>
References: <37DF50E8-CB00-11D8-8081-000A95CFF6CC@sixapart.com> <20040705115449.GA27740@google.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <174BA4DA-CF11-11D8-8EDC-000A95CFF6CC@sixapart.com>
Content-Transfer-Encoding: 7bit
Cc: atom-syntax@imc.org
From: Ezra Cooper <ezra@sixapart.com>
Subject: Re: PaceSecurityServices & alternate HTTP header
Date: Mon, 5 Jul 2004 22:55:31 -0700
To: Greg Stein <gstein@google.com>
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>
Content-Transfer-Encoding: 7bit


On Jul 5, 2004, at 4:54 AM, Greg Stein wrote:

> Now you've got a bunch of CGI scripts all running as the same uid, and
> you've got some authn information sitting in the environment of some. 
> Now
> some cracker comes along and simply dumps out /proc/*/environ from his 
> own
> CGI. Sure, many can't be read, but some *can*. And now he has your
> password.

I see how that's a risk for Basic auth, but not for Digest. That's why 
we hash the nonce in there, so that the exact header value is only 
useful once. Sure, I guess there's a race condition if this cracker can 
make use of the token before the original process has a chance to 
cancel the nonce; but it seems like it would be tricky to arrange.

I would expect clients to be conscientious and not to pass re-usable 
authentication information in this alternate HTTP header. Maybe the 
proposed spec text should be explicit about that:

===============
An Atom client MAY authenticate itself to an Atom server by sending an 
X-Atom-Authorization HTTP header, in the same form as for the 
Authorization header [RFC2617]. If an Atom client sends an 
Authorization header, it SHOULD have the same value as the 
X-Atom-Authorization header. An Atom client MUST NOT use the 
X-Atom-Authorization header to send the user's password or any token 
that could be replayed by an eavesdropper to authenticate itself to the 
server.
===============

Is that OK? Any other holes?

Thanks,
Ezra



From owner-atom-syntax@mail.imc.org  Tue Jul  6 14:33:33 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10342
	for <atompub-archive@lists.ietf.org>; Tue, 6 Jul 2004 14:33: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 i66I9aNE065036;
	Tue, 6 Jul 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 i66I9avq065035;
	Tue, 6 Jul 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 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 i66I9ZVl065026
	for <atom-syntax@imc.org>; Tue, 6 Jul 2004 11:09:35 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 29864 messnum 5119550 invoked from network[62.77.172.85/62-77-172-85.customer.eircom.net]); 6 Jul 2004 18:09:33 -0000
Received: from 62-77-172-85.customer.eircom.net (HELO ?200.200.200.38?) (62.77.172.85)
  by mail13.svc.cra.dublin.eircom.net (qp 29864) with SMTP; 6 Jul 2004 18:09:33 -0000
Message-ID: <40EAEADB.6000603@dehora.net>
Date: Tue, 06 Jul 2004 19:09:31 +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: Tim Bray <Tim.Bray@Sun.COM>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Work Queue rotation #2
References: <5FC8FF2B-CF71-11D8-9E41-000A95A51C9E@sun.com>
In-Reply-To: <5FC8FF2B-CF71-11D8-9E41-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:

> 1. PaceEntryOrigin.  [...]

> (which I 
> take it means another <link rel=""> value) and, if we decide to change 
> course on the way we do links, we'll change it then along with all the 
> other links.

FTR: <link> was added as option. I'm not seeing consensus on that 
option and personally don't think it should be used over a full 
element *this* round, but I'm happy the editors have enough 
information to make a call one way or another.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Tue Jul  6 14: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 OAA11512
	for <atompub-archive@lists.ietf.org>; Tue, 6 Jul 2004 14: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 i66ITWD6066898;
	Tue, 6 Jul 2004 11:29: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 i66ITWcp066897;
	Tue, 6 Jul 2004 11:29:32 -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 i66ITV4k066891
	for <atom-syntax@imc.org>; Tue, 6 Jul 2004 11:29:31 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.10] (unknown [63.96.165.85])
	by mail.mnot.net (Postfix) with ESMTP id 21980727D
	for <atom-syntax@imc.org>; Tue,  6 Jul 2004 11:29:35 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <6E2C04D7-CF7A-11D8-88EB-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: Temporary namespaces and version IDs for format draft
Date: Tue, 6 Jul 2004 11:29:34 -0700
To: Atom Syntax <atom-syntax@imc.org>
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>
Content-Transfer-Encoding: 7bit


This is just a note to say that I've submitted the -00 draft of the 
Atom format for publication as an Internet-Draft. It should appear in 
the Internet-Drafts directly shortly.

The draft incorporates all of the changes listed as 'Accepted' in [1].

To clarify the status of the draft, some text has been added to the 
editorial note:

> The Atom format is a work-in-progress, and this draft is both 
> incomplete and likely to change rapidly. As a result, THE FORMAT 
> DESCRIBED BY THIS DRAFT SHOULD NOT BE DEPLOYED, either in production 
> systems or in any non-experimental fashion on the Internet.

Additionally, the version identifier and namespace URI have both been 
changed to clearly identify experimental uses of this draft; the 
version ID is "draft-ietf-atompub-format-00: do not deploy" and the 
namespace URI is 
"http://purl.org/atom/ns#draft-ietf-atompub-format-00".

Please discuss; if it's a problem, we can change it in -01.

Regards,


1. http://www.intertwingly.net/wiki/pie/AtomPubIssuesList

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Tue Jul  6 14:56: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 OAA12317
	for <atompub-archive@lists.ietf.org>; Tue, 6 Jul 2004 14:56: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 i66IgoNk067683;
	Tue, 6 Jul 2004 11:42: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 i66IgoXX067682;
	Tue, 6 Jul 2004 11:42: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.195])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i66IgnRq067676
	for <atom-syntax@imc.org>; Tue, 6 Jul 2004 11:42:50 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d15so51792rng
        for <atom-syntax@imc.org>; Tue, 06 Jul 2004 11:42:50 -0700 (PDT)
Received: by 10.38.71.14 with SMTP id t14mr24312rna;
        Tue, 06 Jul 2004 11:42:50 -0700 (PDT)
Message-ID: <14be96d30407061142441f70ee@mail.gmail.com>
Date: Tue, 6 Jul 2004 14:42:50 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Atom Syntax <atom-syntax@imc.org>
Subject: PaceMustBeWellFormed
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 i66IgoRq067677
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


http://intertwingly.net/wiki/pie/PaceMustBeWellFormed

== Abstract ==

[MarkPilgrim] Clarify the rules for determining well-formedness of an
Atom feed served over HTTP, covering issues of character encoding and
MIME types.  Also, client requirements for handling non-well-formed
feeds.

== Status ==

Open

== Rationale ==

RFC 3023 defines rules for determining the character encoding of a
feed (or any other XML document served over HTTP).  The default
configuration for most web servers is to serve ".xml" files as
"text/xml" with no charset parameter.  According to RFC 3023, all of
these feeds MUST be parsed as "us-ascii".  This leaves
UnprivilegedUsers without a way to publish Atom feeds in any other
encoding except us-ascii.  Furthermore, the Atom-enabled applications
that the UnprivilegedUsers are running may not even have enough
privileges to determine that they are, in fact, unprivileged in this
way.

Therefore, this proposal recommends that all Atom-enabled publishers
"assume the worst" and only emit ASCII-compatible XML.

== Proposal ==

Insert as section 6:

6. Client processing requirements

Atom feeds served over HTTP MUST be well-formed XML 1.0, as defined in
Section 2.1 of the XML specification
<http://www.w3.org/TR/REC-xml/#sec-well-formed>.  Furthermore, the
concept of XML well-formedness relies on first determining the
character encoding of the XML document.  RFC 3023 defines how to
determine the character encoding of XML documents served over HTTP.

6.1 Determining the character encoding of an Atom feed

The rules for determining the character encoding of an Atom feed are
the same as determining the character encoding of any XML document
served over HTTP.  The rules are wholely defined by RFC 3023, but they
are summarized here because there has been widespread confusion over
how RFC 3023 should be interpreted:

 1. When serving an Atom feed, it is RECOMMENDED that publishers
include the charset parameter along with the media type in the
Content-type HTTP header.  If the charset parameter is present,
clients MUST parse the Atom feed in that charset, ignoring any charset
declared in the encoding attribute of the XML declaration.
 1. Publishers SHOULD serve all Atom feeds with the media type
"application/atom+xml" (registered in Section 8 of this document). 
Clients MUST treat "application/atom+xml" as "application/xml" and
determine the character encoding as per RFC 3023 or its successor.
 1. If a publisher wishes to serve an Atom feed over HTTP, but for
some reason they are unable to use the "application/atom+xml" media
type, the publisher SHOULD use "application/xml", and clients MUST
determine the character encoding as per RFC 3023 or its successor.
 1. If a publisher is unable to serve their Atom feed with a
Content-Type of "application/atom+xml" or "application/xml", they MAY
use "text/xml".  According to RFC 3023, XML documents served as
"text/xml" with no charset parameter have a character encoding of
"us-ascii".
  1. When serving an Atom feed as "text/xml", publishers MUST escape
all non-US-ASCII characters as
[http://www.w3.org/TR/REC-xml/#sec-references character references]. 
For example, '&#xf8;' for the character 'ø'.
  1. When retrieving an Atom feed served with a Content-type of
"text/xml", clients MUST parse it with a "us-ascii" encoding.  If such
a feed contains non-US-ASCII characters, and clients MUST reject it as
non-well-formed.
 1. Publishers MUST NOT serve Atom feeds with a media type other than
"application/atom+xml" (registered in this Section 8 of document) or
one of the XML media types defined in RFC 3023 or its successor.  In
particular, "text/plain" is never an appropriate media type for an
Atom feed.  When retrieving an Atom feed served with a non-XML media
type, clients MUST reject it as non-well-formed.

6.2 Handling well-formedness errors

After determining the character encoding by the rules in section 6.1
of this document, clients MUST use a conforming XML parser to parse an
Atom feed.  In particular, clients MUST stop processing at the first
well-formedness error, although they MAY display any information they
have parsed before the first well-formedness error.

Here is a non-comprehensive list of things clients have been known to
do after encountering a well-formedness error, which this document
specifically prohibits:

 * Clients MUST NOT reparse the feed in any other character encoding.
 * Clients MUST NOT "tidy" the feed to attempt to fix mismatched start
and end tags.
 * Clients MUST NOT guess at the meaning of undefined entities,
including entities defined in the HTML specification.

== Impacts ==

This proposal has significant impact for both publishers and clients. 
Publishers must be aware of their web server configuration and ensure
that Atom feeds are served with the appropriate media type, or, if
that is not possible, that all non-US-ASCII characters are properly
escaped.  Clients must ensure that they properly implement RFC 3023,
which few tools currently support.

-----

CategoryProposals

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Tue Jul  6 15:10: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 PAA14048
	for <atompub-archive@lists.ietf.org>; Tue, 6 Jul 2004 15:10: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 i66IsqnE069096;
	Tue, 6 Jul 2004 11:54: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 i66IsqYm069095;
	Tue, 6 Jul 2004 11:54:52 -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 i66Isq9L069086
	for <atom-syntax@imc.org>; Tue, 6 Jul 2004 11:54: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 (rwcrmhc12) with SMTP
          id <2004070618545001400ji0n3e>; Tue, 6 Jul 2004 18:54:50 +0000
Date: Tue, 6 Jul 2004 12:54:49 -0600
Subject: PaceEntryOrigin
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: <40EAEADB.6000603@dehora.net>
Message-Id: <F4C9F9CD-CF7D-11D8-A6A2-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 i66Isq9L069090
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 Tuesday, July 6, 2004, at 12:09  PM, Bill de hÓra wrote:
>> 1. PaceEntryOrigin.  [...]
>
>> (which I take it means another <link rel=""> value) and, if we decide 
>> to change course on the way we do links, we'll change it then along 
>> with all the other links.
>
> FTR: <link> was added as option. I'm not seeing consensus on that 
> option and personally don't think it should be used over a full 
> element *this* round, but I'm happy the editors have enough 
> information to make a call one way or another.
I'd recommend putting this in <link> for now, since that's consistent 
with how we are currently pointing to everything outside of the feed 
(...unless I'm forgetting something).  I'm not suggesting this as a way 
to build inertia for keeping it there (though that's where I expect to 
end up preferring it), but because we're going to need to discuss the 
general topic of pulling things out of <link> and putting them into 
their own elements anyway, so why not start of from one consistent 
model, and then discuss other possible consistent models.

Ultimately, wherever it goes now, unless we dump <link> entirely, where 
to put this URI is going to have to be discussed again. So it doesn't 
matter THAT much.



From subs-reminder@imc.org  Tue Jul  6 17: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 RAA22903
	for <atompub-archive@lists.ietf.org>; Tue, 6 Jul 2004 17:04:50 -0400 (EDT)
From: subs-reminder@imc.org
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i66L4jkk079411
	for <atompub-archive@lists.ietf.org>; Tue, 6 Jul 2004 14:04:45 -0700 (PDT)
	(envelope-from subs-reminder@imc.org)
Received: (from root@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i66L4jwM079410;
	Tue, 6 Jul 2004 14:04:45 -0700 (PDT)
Date: Tue, 6 Jul 2004 14:04:45 -0700 (PDT)
Message-Id: <200407062104.i66L4jwM079410@above.proper.com>
To: atompub-archive@ietf.org
Subject: [[029555711]] Subscription to atom-syntax for atompub-archive@lists.ietf.org

Greetings. This message is a periodic reminder that
     atompub-archive@lists.ietf.org
is subscribed to the
     atom-syntax
mailing list.

*** SEE BELOW: PLEASE DO NOT RESPOND TO THIS MESSAGE. ***

There are two purposes for this message:
- If this message is bounced by your mail server, I can remove you from
  the mailing list and reduce waste of bandwidth and resources. (If you
  are reading this message, it clearly didn't get bounced!)
- Some people stay subscribed to mailing lists even though they do not
  want to because they do not know how to unsubscribe. 

If you want to stay subscribed to the atom-syntax mailing list,
you do not need to do anything. Feel free to delete this message.

On the other hand, if you want to unsubscribe from this list, simply go
to the following link:
     <http://www.imc.org/Unsubs/029555711>

If for some reason you cannot go to that web site, you can also
unsubscribe by email; however, doing so is not as likely to get you
unsubscribed as the web site is. To unsubscribe using email, you can
respond to this message and I will unsubscribe you by hand in the next
few days. Again, this is not assured to work because your mail system
may make it impossible for me to determine who you are or what you want
to unsubscribe to.

Alternatively, you can send a plain-text message to:
     atom-syntax-request@imc.org
with the single word
     unsubscribe
in the body of the message. This last method assumes that the "From:"
address in your mail is "atompub-archive@lists.ietf.org". Again, using the
web site above is more likely to work than this method (due to limitations
in Majordomo, the mailing list software we currently use).

If you have any questions, feel free to contact me.

--Paul Hoffman, list administrator


From owner-atom-syntax@mail.imc.org  Wed Jul  7 04:39: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 EAA04033
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 04:39: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 i678QpJv056822;
	Wed, 7 Jul 2004 01:26: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 i678QpoG056821;
	Wed, 7 Jul 2004 01:26:51 -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 [212.123.84.93])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i678QorD056775
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 01:26:50 -0700 (PDT)
	(envelope-from danny666@virgilio.it)
Received: from virgilio.it (62.11.120.112) by mail-relay-3.tiscali.it (7.1.021.3)
        id 40EB95600000DC07; Wed, 7 Jul 2004 10:25:43 +0200
Message-ID: <40EBB312.6030108@virgilio.it>
Date: Wed, 07 Jul 2004 10:23:46 +0200
From: Danny Ayers <danny666@virgilio.it>
Reply-To: danny666@virgilio.it
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mark Pilgrim <pilgrim@gmail.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceMustBeWellFormed
References: <14be96d30407061142441f70ee@mail.gmail.com>
In-Reply-To: <14be96d30407061142441f70ee@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


Generally looks very good, thanks, though I'm a little puzzled by the 
following line:

Mark Pilgrim wrote:

>Therefore, this proposal recommends that all Atom-enabled publishers
>"assume the worst" and only emit ASCII-compatible XML.
>  
>

I don't understand what the "worst" is here. Consumers, even those 
running server-side, should be able to deal with non-ASCII XML, I don't 
see why the publisher should have to 'dumb down' if they have the 
capability for producing unescaped Unicode as "application/atom+xml". 
The worst is that *some* publishers lack privileges, I don't see why 
that should impact all publishers.

Cheers,
Danny.


-- 

Raw
http://dannyayers.com



From owner-atom-syntax@mail.imc.org  Wed Jul  7 05:28: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 FAA06092
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 05: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 i679G4kB076603;
	Wed, 7 Jul 2004 02: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 i679G4Dl076602;
	Wed, 7 Jul 2004 02:16:04 -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 [212.123.84.93])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i679G33c076562
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 02:16:03 -0700 (PDT)
	(envelope-from danny666@virgilio.it)
Received: from virgilio.it (62.11.120.112) by mail-relay-3.tiscali.it (7.1.021.3)
        id 40EB956000011F09; Wed, 7 Jul 2004 11:15:57 +0200
Message-ID: <40EBBED8.3090803@virgilio.it>
Date: Wed, 07 Jul 2004 11:14:00 +0200
From: Danny Ayers <danny666@virgilio.it>
Reply-To: danny666@virgilio.it
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
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: Work Queue rotation #2
References: <5FC8FF2B-CF71-11D8-9E41-000A95A51C9E@sun.com>
In-Reply-To: <5FC8FF2B-CF71-11D8-9E41-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


Thanks Tim, your take on each seems altogether reasonable.

I wonder if it might be worth adding a "try it" option to the list of 
possible actions - the next release of the spec will presumably have 
versioning protection, so ideas for which there is no obvious consensus 
could be inserted with a caveat that they were exploratory. If features 
appear to work ok in practice (and people actually use them) then 
there's a good case for them staying in. If there is little (positive) 
feedback, the feature gets dropped.

Cheers,
Danny.

Tim Bray wrote:

>
> Per the current state of our issues list 
> (http://www.intertwingly.net/wiki/pie/AtomPubIssuesList) we're 
> supposed to be striving for consensus on PaceIntrospection and 
> PaceEntryOrigin.
>
> The discussion has been fairly light in volume and rather poorly 
> focused, but on behalf Paul and myself, here's our best take on where 
> we are:
>
> 1. PaceEntryOrigin.  There appears to be rough consensus that this 
> back-pointer is a good idea.  Discussion of its exact syntax has been 
> sucked into the PaceLinkConstruct rat-hole.  So, let's go ahead and 
> wire it into the next set of drafts consistent with the way they are 
> (which I take it means another <link rel=""> value) and, if we decide 
> to change course on the way we do links, we'll change it then along 
> with all the other links.
>
> 2. PaceIntrospection.  We don't detect consensus of any kind, rough or 
> smooth, which means that there's nothing we can ask the editors to 
> do.  I'm not sure whether it's a problem with the way the Pace is 
> written, or the focus of the discussion, or what, but let's declare 
> temporary defeat on this one.  I think most of us think that having a 
> documented introspection discover/introspection mechanism is an 
> important piece of the puzzle, it's just that we haven't got a 
> proposal written down yet that we can build consensus around.  
> Everyone please feel free to revise/recast/re-propose something in 
> this area and we'll try again later.
>
> So, Sam will now turn the crank and bring forward another small set of 
> issues for us to try to knock off the list.   We need to work on at 
> least one issue that affects the protocol, not just the data-format, 
> drafts.  Also, given that we'd like to get a set of drafts done in 
> time for the August IETF, it would be nice to select a few things that 
> we have a chance of knocking off in the next week or two.
>
>  -Tim
>
>


-- 

Raw
http://dannyayers.com



From owner-atom-syntax@mail.imc.org  Wed Jul  7 08:26:13 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14795
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 08:26: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 i67CDIx9013915;
	Wed, 7 Jul 2004 05:13:18 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i67CDILx013914;
	Wed, 7 Jul 2004 05:13:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.207])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i67CDC0T013867
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 05:13:12 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d5so107739rng
        for <atom-syntax@imc.org>; Wed, 07 Jul 2004 05:12:57 -0700 (PDT)
Received: by 10.38.3.58 with SMTP id 58mr88806rnc;
        Wed, 07 Jul 2004 05:12:55 -0700 (PDT)
Message-ID: <14be96d304070705127c361613@mail.gmail.com>
Date: Wed, 7 Jul 2004 08:12:55 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: danny666@virgilio.it
Subject: Re: PaceMustBeWellFormed
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <40EBB312.6030108@virgilio.it>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <14be96d30407061142441f70ee@mail.gmail.com> <40EBB312.6030108@virgilio.it>
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 Wed, 07 Jul 2004 10:23:46 +0200, Danny Ayers <danny666@virgilio.it> wrote:
> Generally looks very good, thanks, though I'm a little puzzled by the
> following line:
> 
> Mark Pilgrim wrote:
> 
> >Therefore, this proposal recommends that all Atom-enabled publishers
> >"assume the worst" and only emit ASCII-compatible XML.

I think I explained this better in the "Impacts" section.  Some
publishing programs (such as Movable Type) don't always know *and
can't even discover* whether the feeds they generate will be served as
"text/xml" or "application/xml"-equivalent.  Such programs MUST
generate ASCII-compatible output, otherwise they risk running afoul of
RFC 3023.

This is Martin's worst nightmare [1], that specs would start
recommending ASCII-compatible encoding and eventually everyone would
do that without knowing why.  And he's right, it's the old "cat tied
up during meditation practice" problem [2].  But I don't see any
alternative.  Programs like Movable Type are

(a) our early adopters
(b) publishing static files that are later served by the underlying web server
(c) able to run in extremely unprivileged environments where the end
user is unable to override the default server configuration
(d) generally run on default Apache installs where "text/xml" is still
the default (yes, I know this was changed late last year)

These people *can use Atom*, and they *will use Atom*, and Movable
Type *already supports Atom*.  This proposal spells out the steps they
MUST take to ensure that they are always doing it correctly, even in
unprivileged environments.

Atom is XML, generally served over HTTP.  That is ruled by the
well-formedness provisions and draconian error handling of the XML
specification, and RFC 3023.  I don't make the rules, and (apparently)
I can't change them either.  Failing that, the best I can do is
provide guidance so people can live within the rules.

[1] http://www.imc.org/atom-syntax/mail-archive/msg05928.html
[2] http://www.rider.edu/~suler/zenstory/ritualcat.html

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Wed Jul  7 09:49: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 JAA19525
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 09: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 i67DWrbQ023172;
	Wed, 7 Jul 2004 06: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 i67DWr9p023171;
	Wed, 7 Jul 2004 06:32:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail-relay-1.tiscali.it (mail-relay-1.tiscali.it [212.123.84.91])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i67DWq3x023164
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 06:32:53 -0700 (PDT)
	(envelope-from danny666@virgilio.it)
Received: from virgilio.it (62.11.122.83) by mail-relay-1.tiscali.it (7.1.021.3)
        id 40E574C2001F1AA1; Wed, 7 Jul 2004 15:32:45 +0200
Message-ID: <40EBFB08.9050207@virgilio.it>
Date: Wed, 07 Jul 2004 15:30:48 +0200
From: Danny Ayers <danny666@virgilio.it>
Reply-To: danny666@virgilio.it
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mark Pilgrim <pilgrim@gmail.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceMustBeWellFormed
References: <14be96d30407061142441f70ee@mail.gmail.com> <40EBB312.6030108@virgilio.it> <14be96d304070705127c361613@mail.gmail.com>
In-Reply-To: <14be96d304070705127c361613@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


Mark Pilgrim wrote:

>On Wed, 07 Jul 2004 10:23:46 +0200, Danny Ayers <danny666@virgilio.it> wrote:
>  
>
>>Generally looks very good, thanks, though I'm a little puzzled by the
>>following line:
>>
>>Mark Pilgrim wrote:
>>
>>    
>>
>>>Therefore, this proposal recommends that all Atom-enabled publishers
>>>"assume the worst" and only emit ASCII-compatible XML.
>>>      
>>>
>
>I think I explained this better in the "Impacts" section.  Some
>publishing programs (such as Movable Type) don't always know *and
>can't even discover* whether the feeds they generate will be served as
>"text/xml" or "application/xml"-equivalent.  Such programs MUST
>generate ASCII-compatible output, otherwise they risk running afoul of
>RFC 3023.
>  
>

Right, thanks, I see what you mean now. Still seems a little 
uncomfortable, likely to make some publishers choose the lowest common 
denominator when they don't have to. But is there any significant cost 
in that? Offhand I can't think of any, but this is such a morass.

I wonder if it could be worded in such a way as to encourage 
ASCII-compatible output as the default, but not the *only* possible 
output, and maybe changing the "publishers" in the sentence to 
"developers"?

btw, thanks for the tip [2], I am now on the path to greater 
enlightenment [3]...

Cheers,
Danny.

>[1] http://www.imc.org/atom-syntax/mail-archive/msg05928.html
>[2] http://www.rider.edu/~suler/zenstory/ritualcat.html
>  
>

[3] http://dannyayers.com/2004/07/frumpy-tied.jpg



-- 

Raw
http://dannyayers.com



From owner-atom-syntax@mail.imc.org  Wed Jul  7 09: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 JAA19853
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 09:53: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 i67DeXGR023680;
	Wed, 7 Jul 2004 06:40: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 i67DeXhP023679;
	Wed, 7 Jul 2004 06:40:33 -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 i67DeXrQ023667
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 06:40: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 (rwcrmhc12) with SMTP
          id <2004070713403001400jinf7e>; Wed, 7 Jul 2004 13:40:30 +0000
Date: Wed, 7 Jul 2004 07:40:29 -0600
Subject: Re: PaceMustBeWellFormed
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: <40EBB312.6030108@virgilio.it>
Message-Id: <35B985F6-D01B-11D8-871D-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


I'd suggest the following clarifications:

> Therefore, this proposal recommends that all Atom-enabled publishers
> "assume the worst" and only emit ASCII-compatible XML.

Therefore, this proposal recommends that all UnpriviledgedUsers "assume 
the worst" and only emit ASCII-compatible XML.

> 4. If a publisher is unable to serve their Atom feed with a 
> Content-Type of "application/atom+xml" or "application/xml", they MAY 
> use "text/xml". According to RFC 3023, XML documents served as 
> "text/xml" with no charset parameter have a character encoding of 
> "us-ascii".

4. If a publisher is unable to serve their Atom feed with a 
Content-Type of "application/atom+xml" or "application/xml", they MAY 
use "text/xml". The published SHOULD specify a charset parameter to 
indicate the character encoding used by the feed.

5. If the publisher uses "text/xml" and is unable to specify the 
charset parameter, then according to RFC 3023, the a character encoding 
is "us-ascii".

=====

It's unlikely that anyone who can't control the Content-Type won't be 
able to specify the charset parameter, so #4 may never be done, but it 
does improve clarity, and it does specify an acceptable, if 
unpreferred, Content-Type.



From owner-atom-syntax@mail.imc.org  Wed Jul  7 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 KAA20810
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 10: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 i67Dqvla024635;
	Wed, 7 Jul 2004 06:52:57 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i67DqvRk024634;
	Wed, 7 Jul 2004 06:52:57 -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 i67Dqteh024627
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 06:52:56 -0700 (PDT)
	(envelope-from Janne.Jalkanen@nokia.com)
Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120])
	by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i67DqTN10133;
	Wed, 7 Jul 2004 16:52:29 +0300 (EET DST)
X-Scanned: Wed, 7 Jul 2004 16:52:27 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost)
	by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i67DqRsb013014;
	Wed, 7 Jul 2004 16:52:27 +0300
Received: from mgw-int1.ntc.nokia.com (172.21.143.96)
	by esdks001.ntc.nokia.com 001HQtXt; Wed, 07 Jul 2004 16:52:26 EEST
Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77])
	by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i67DqPH17211;
	Wed, 7 Jul 2004 16:52:25 +0300 (EET DST)
Received: from nokia.com ([172.21.60.114]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Wed, 7 Jul 2004 16:52:22 +0300
Message-ID: <40EC0014.3060306@nokia.com>
Date: Wed, 07 Jul 2004 16:52:20 +0300
From: Janne Jalkanen <Janne.Jalkanen@nokia.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040122
X-Accept-Language: fi, en-us, en
MIME-Version: 1.0
To: ext Julian Reschke <julian.reschke@gmx.de>
CC: John Panzer <jpanzer@aol.net>,
        =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?=
 <asbjorn@tigerstaden.no>,
        Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceSimpleResourcePosting and PUT
References: <opsairy6o1uvpchu@quark> <40E597FF.8020808@aol.net> <opsai5d4uouvpchu@quark> <40E64A34.5060406@aol.net> <40E64FC9.4070800@gmx.de>
In-Reply-To: <40E64FC9.4070800@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 07 Jul 2004 13:52:22.0249 (UTC) FILETIME=[A0816D90:01C46429]
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 think RFC2616 is silent about that topic, so it seems to be a 
> qualify-of-implementation issue. In real life, some servers that map 
> directly to filesystem I/O *will* fail to do this properly.

Temp files are standard in upload implementations.  Anyone who writes 
such bad code that a broken upload can break an existing good file 
should be shot.

Just my 2c.

/Janne



From owner-atom-syntax@mail.imc.org  Wed Jul  7 11:14: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 LAA25272
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 11:14: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 i67F1b1Q030938;
	Wed, 7 Jul 2004 08:01:37 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i67F1bd9030937;
	Wed, 7 Jul 2004 08:01: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 ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i67F1amJ030911
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 08:01: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 E2FC57C0F3; Wed,  7 Jul 2004 18:00:36 +0200 (CEST)
To: "Joe Gregorio" <joe.gregorio@gmail.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceEntryOrigin
References: <BD0FBA6D.1D67F%eric.scheid@ironclad.net.au> <3f1451f504070605116418a38c@mail.gmail.com>
Message-ID: <opsarv6ocguvpchu@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: Wed, 07 Jul 2004 17:05:02 +0200
In-Reply-To: <3f1451f504070605116418a38c@mail.gmail.com>
User-Agent: Opera M2/7.51 (Win32, build 3798)
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 Tue, 6 Jul 2004 08:11:45 -0400, Joe Gregorio <joe.gregorio@gmail.com>  
wrote:

> All the more reason to consider SkunkLink.

+1. I'm all in favour of SkunkLink. Seems like a neat specification, and  
won't have too much impact on how Atom looks today.

-- 
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 Jul  7 12:52: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 MAA00526
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 12:52: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 i67GbLpw038435;
	Wed, 7 Jul 2004 09:37: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 i67GbLSf038434;
	Wed, 7 Jul 2004 09:37: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 i67GbKgf038417
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 09:37: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 8A3977C11E; Wed,  7 Jul 2004 19:36:25 +0200 (CEST)
To: "Antone Roundy" <antone@geckotribe.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceEntryOrigin
References: <F4C9F9CD-CF7D-11D8-A6A2-003065EA6144@geckotribe.com>
Message-ID: <opsar0m0xauvpchu@quark>
Date: Wed, 07 Jul 2004 18:41:14 +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: <F4C9F9CD-CF7D-11D8-A6A2-003065EA6144@geckotribe.com>
User-Agent: Opera M2/7.51 (Win32, build 3798)
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 Tue, 6 Jul 2004 12:54:49 -0600, Antone Roundy <antone@geckotribe.com>  
wrote:

> I'd recommend putting this in <link> for now, since that's consistent  
> with how we are currently pointing to everything outside of the feed  
> (...unless I'm forgetting something).

I agree. Let's just keep the link construct discussion out for now.  
Whenever we reach any consensus on how link constructs should look like,  
all current <link>s will adopt 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 Jul  7 13:17: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 NAA01993
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 13:17: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 i67H2S5I040254;
	Wed, 7 Jul 2004 10:02: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 i67H2SUX040253;
	Wed, 7 Jul 2004 10:02: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 i67H2Rkr040245
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 10:02: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 409C87C129; Wed,  7 Jul 2004 20:01:33 +0200 (CEST)
Date: Wed, 07 Jul 2004 19:05:20 +0200
To: "Tim Bray" <Tim.Bray@sun.com>
Subject: Re: Work Queue rotation #2
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <5FC8FF2B-CF71-11D8-9E41-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: <opsar1q6xauvpchu@quark>
In-Reply-To: <5FC8FF2B-CF71-11D8-9E41-000A95A51C9E@sun.com>
User-Agent: Opera M2/7.51 (Win32, build 3798)
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 Tue, 06 Jul 2004 10:24:45 -0700, Tim Bray <Tim.Bray@Sun.COM> wrote:

> 1. PaceEntryOrigin. [...] So, let's go ahead and wire it into the
> next set of drafts consistent with the way they are (which I take it
> means another <link rel=""> value) and, if we decide to change
> course on the way we do links, we'll change it then along with all the  
> other links.

Sounds good.

> 2. PaceIntrospection. [...] let's declare temporary defeat on this one.

I agree. We need more, or better, proposals for this one. Mr. MacLeod and  
myself are doing some research into whether WebDAV might be used return  
DAV properties as a «site map» that allows for introspection for both the  
API side of things, but also for other, maybe not Atom-related, stuff.

-- 
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 Jul  7 13:54: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 NAA04266
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 13:54: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 i67HeBt7043484;
	Wed, 7 Jul 2004 10:40: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 i67HeBG5043483;
	Wed, 7 Jul 2004 10:40:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.196])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i67HeAgj043470
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 10:40:10 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d19so87338rnf
        for <atom-syntax@imc.org>; Wed, 07 Jul 2004 10:39:42 -0700 (PDT)
Received: by 10.38.71.14 with SMTP id t14mr87301rna;
        Wed, 07 Jul 2004 10:39:35 -0700 (PDT)
Message-ID: <14be96d3040707103826ba6c34@mail.gmail.com>
Date: Wed, 7 Jul 2004 13:38:50 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Atom Syntax <atom-syntax@imc.org>
Subject: IRIs, URIs, and RFC 2396bis
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


The Atom 0.3 draft [1] states that "Link constructs MUST have a href
attribute, whose value MUST be a URI [RFC2396]" [2].  Should this be
changed to "whose value MUST be a URI, as defined by RFC2396 or its
successor," so that Atom can benefit from RFC2396bis? [3]

Alternatively, we could state "whose value MUST be an IRI" [4].  After
reading all three specs (RFC 2396, RFC 2396bis, and the IRI draft), I
am not entirely sure what their relationship is.  RFC 2396bis appears
to obsolete RFC 2396, and IRIs appear to "have a dependency on RFC
2396bis" [5].  Currently Atom mandates RFC 2396 only.  I do not see
any discussion of this on the Atom wiki [6], and only one passing
mention of it in the list archives. [7]

Could someone with more experience shed some light on this situation?

[1] http://www.mnot.net/drafts/draft-nottingham-atom-format-02.html
[2] http://www.ietf.org/rfc/rfc2396.txt
[3] http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html
[4] http://www.w3.org/International/iri-edit/draft-duerst-iri.html
[5] http://lists.w3.org/Archives/Public/public-webarch-comments/2004Feb/0001.html
[6] http://intertwingly.net/wiki/pie/UniversalResourceIdentifier
[7] http://www.imc.org/atom-syntax/mail-archive/msg02941.html

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Wed Jul  7 13:55: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 NAA04311
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 13: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 i67HeBmC043482;
	Wed, 7 Jul 2004 10:40: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 i67HeBP8043481;
	Wed, 7 Jul 2004 10:40:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.195])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i67HeAPg043467
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 10:40:10 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d5so143378rng
        for <atom-syntax@imc.org>; Wed, 07 Jul 2004 10:39:59 -0700 (PDT)
Received: by 10.38.71.14 with SMTP id t14mr87420rna;
        Wed, 07 Jul 2004 10:39:50 -0700 (PDT)
Message-ID: <14be96d3040707103826ba6c34@mail.gmail.com>
Date: Wed, 7 Jul 2004 13:38:50 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Atom Syntax <atom-syntax@imc.org>
Subject: IRIs, URIs, and RFC 2396bis
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


The Atom 0.3 draft [1] states that "Link constructs MUST have a href
attribute, whose value MUST be a URI [RFC2396]" [2].  Should this be
changed to "whose value MUST be a URI, as defined by RFC2396 or its
successor," so that Atom can benefit from RFC2396bis? [3]

Alternatively, we could state "whose value MUST be an IRI" [4].  After
reading all three specs (RFC 2396, RFC 2396bis, and the IRI draft), I
am not entirely sure what their relationship is.  RFC 2396bis appears
to obsolete RFC 2396, and IRIs appear to "have a dependency on RFC
2396bis" [5].  Currently Atom mandates RFC 2396 only.  I do not see
any discussion of this on the Atom wiki [6], and only one passing
mention of it in the list archives. [7]

Could someone with more experience shed some light on this situation?

[1] http://www.mnot.net/drafts/draft-nottingham-atom-format-02.html
[2] http://www.ietf.org/rfc/rfc2396.txt
[3] http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html
[4] http://www.w3.org/International/iri-edit/draft-duerst-iri.html
[5] http://lists.w3.org/Archives/Public/public-webarch-comments/2004Feb/0001.html
[6] http://intertwingly.net/wiki/pie/UniversalResourceIdentifier
[7] http://www.imc.org/atom-syntax/mail-archive/msg02941.html

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Wed Jul  7 14:31:59 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06376
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 14:31:59 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i67IGA7k046841;
	Wed, 7 Jul 2004 11: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 i67IGA0F046838;
	Wed, 7 Jul 2004 11:16:10 -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 i67IG5Lq046815;
	Wed, 7 Jul 2004 11:16:08 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p061104a6bd11ee2b5b17@[10.20.30.249]>
In-Reply-To: <14be96d3040707103826ba6c34@mail.gmail.com>
References: <14be96d3040707103826ba6c34@mail.gmail.com>
Date: Wed, 7 Jul 2004 11:16:20 -0700
To: Mark Pilgrim <pilgrim@gmail.com>, Atom Syntax <atom-syntax@imc.org>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: IRIs, URIs, and RFC 2396bis
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:38 PM -0400 7/7/04, Mark Pilgrim wrote:
>The Atom 0.3 draft [1] states that "Link constructs MUST have a href
>attribute, whose value MUST be a URI [RFC2396]" [2].  Should this be
>changed to "whose value MUST be a URI, as defined by RFC2396 or its
>successor," so that Atom can benefit from RFC2396bis? [3]

Maybe.

>Alternatively, we could state "whose value MUST be an IRI" [4].

No. The IRI spec is not yet an RFC, and it is not at all clear when 
it will be. There is lots of contention about what it means and how 
it should be implemented. Basing our work on IRIs is very, very risky 
for no perceptible value.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Wed Jul  7 14:40: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 OAA06930
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 14:40: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 i67IUbjI048184;
	Wed, 7 Jul 2004 11:30: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 i67IUb6Q048183;
	Wed, 7 Jul 2004 11:30: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.205])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i67IUakM048176
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 11:30:36 -0700 (PDT)
	(envelope-from kevinmarks@gmail.com)
Received: by mproxy.gmail.com with SMTP id d19so91446rnf
        for <atom-syntax@imc.org>; Wed, 07 Jul 2004 11:30:07 -0700 (PDT)
Received: by 10.38.181.19 with SMTP id d19mr133079rnf;
        Wed, 07 Jul 2004 11:30:07 -0700 (PDT)
Message-ID: <73766b16040707113051a74e40@mail.gmail.com>
Date: Wed, 7 Jul 2004 11:30:07 -0700
From: Kevin Marks <kevinmarks@gmail.com>
To: Atom Syntax <atom-syntax@imc.org>
Subject: PaceEntryOrigin, composite feeds and inheritance
In-Reply-To: <5FC8FF2B-CF71-11D8-9E41-000A95A51C9E@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <5FC8FF2B-CF71-11D8-9E41-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 Tue, 06 Jul 2004 10:24:45 -0700, Tim Bray <tim.bray@sun.com> wrote:
> 
> Per the current state of our issues list
> (http://www.intertwingly.net/wiki/pie/AtomPubIssuesList) we're supposed
> to be striving for consensus on PaceIntrospection and PaceEntryOrigin.
> 
> The discussion has been fairly light in volume and rather poorly
> focused, but on behalf Paul and myself, here's our best take on where
> we are:
> 
> 1. PaceEntryOrigin.  There appears to be rough consensus that this
> back-pointer is a good idea.  Discussion of its exact syntax has been
> sucked into the PaceLinkConstruct rat-hole.  So, let's go ahead and
> wire it into the next set of drafts consistent with the way they are
> (which I take it means another <link rel=""> value) and, if we decide
> to change course on the way we do links, we'll change it then along
> with all the other links.

The goal of this element is to make the sources of a composite  feed
clearer. However, just a source URl is nto really sufficient for this,
as the other semantic elements of a feed can be affected too.

There is an alternative here, which was discussed briefly at the end
of the atom community meeting and mentioned here before. This is to
expand and clarify the feed/entry inheritance model such that an entry
can declare the feed-level elements for its original feed.

PaceItemCopyright declares this for the copyright element. The current
0.3 draft just has a note saying [[explain inheritence]] under
atom:author etc.

feed explicitly defines:
title, link, author, contributor,tagline,id, generator, copyright,
info, modified  (and entry)
entry defines:
title, link, author, contributor, id, modified, issued, created,
summary, content

There is a general notion of inheritance of attributes, which is made
explicit for copyright, author and contributor. However this is
problematic for the ones with the same names in feed and entry, but
semantic differences:
title, link, id
and the feed level ones not present in entry:
tagline, generator, copyright (fixed by PaceItemCopyright)

PaceEntryOrigin is a workaround for the semantic collision on link,
but the problem remains with title.

So, how about giving these different names, so that the inheritance
model can remain and be simplified:

Replace feed-level title,link and id with feedtitle, feedlink and feedid.

That way the entry can explicitly over-ride the feedtitle, feedlink
and feedid when it is a composite feed, in the same way as they do
with author, contributor, copyright etc.
Clients then have the explicit semantic information they need to
decide how to display such things.

Otherwise, we're going t keep coming up with these exception cases to
work around this.

I realise that proposing renaming the top-level elements this way is
disruptive, but better to disrupt now than later. If the wise heads
here can see a better way of expressing this semantic distinction
clearly, speak up.



From owner-atom-syntax@mail.imc.org  Wed Jul  7 14:55:46 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07723
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 14:55:46 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i67IiTpm049288;
	Wed, 7 Jul 2004 11:44:29 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i67IiT4V049287;
	Wed, 7 Jul 2004 11:44:29 -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 i67IiTTA049280
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 11:44: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 LAA01177
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 11:44:25 -0700 (PDT)
Received: from mx-rr.verity.com (mx-rr.verity.com [10.3.100.59])
	by mx-rr.verity.com (8.9.3/8.9.3) with SMTP id LAA11095
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 11:44:25 -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); Wed, 07 Jul 2004 11:44:24 -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 <0I0H00B2XW1YWD@shazam.verity.com> for atom-syntax@imc.org; Wed,
 07 Jul 2004 11:44:24 -0700 (PDT)
Date: Wed, 07 Jul 2004 11:44:23 -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: IRIs, URIs, and RFC 2396bis
In-reply-to: <14be96d3040707103826ba6c34@mail.gmail.com>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: 
 <375309C571C0D3FC1C85F345@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
MIME-version: 1.0
X-Mailer: Mulberry/3.1.5 (Mac OS X)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <14be96d3040707103826ba6c34@mail.gmail.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 Wednesday, July 7, 2004 1:38 PM -0400 Mark Pilgrim <pilgrim@gmail.com> wrote:
>
> After reading all three specs (RFC 2396, RFC 2396bis, and the IRI draft),
> I am not entirely sure what their relationship is.

Same here. The IRI spec is especially confusing.

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Wed Jul  7 14:59:31 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07814
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 14:59: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 i67IlMkl049592;
	Wed, 7 Jul 2004 11: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 i67IlMOP049591;
	Wed, 7 Jul 2004 11:47: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 i67IlMoS049584
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 11:47: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 i67IlPil012025
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 12:47:25 -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 <0I0H00M71W71DU@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Wed, 07 Jul 2004 12:47:25 -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 <0I0H00C6IW70E1@mail.sun.net> for atom-syntax@imc.org; Wed,
 07 Jul 2004 12:47:25 -0600 (MDT)
Date: Wed, 07 Jul 2004 11:47:21 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: IRIs, URIs, and RFC 2396bis
In-reply-to: <14be96d3040707103826ba6c34@mail.gmail.com>
To: Mark Pilgrim <pilgrim@gmail.com>
Cc: Atom Syntax <atom-syntax@imc.org>
Message-id: <14670C09-D046-11D8-B2D0-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: <14be96d3040707103826ba6c34@mail.gmail.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 Jul 7, 2004, at 10:38 AM, Mark Pilgrim wrote:

> The Atom 0.3 draft [1] states that "Link constructs MUST have a href
> attribute, whose value MUST be a URI [RFC2396]" [2].  Should this be
> changed to "whose value MUST be a URI, as defined by RFC2396 or its
> successor," so that Atom can benefit from RFC2396bis? [3]

+1. 2396bis is very nearly finished, not controversial as far as I 
know, and immensely better than "2396 Classic".

> Alternatively, we could state "whose value MUST be an IRI" [4].

Less cooked, more controversial, I'd be nervous about this.

>   After
> reading all three specs (RFC 2396, RFC 2396bis, and the IRI draft), I
> am not entirely sure what their relationship is.

You are *not* the only one.

- Tim Bray, Director of Web Technologies, Sun Microsystems
   +1-877-305-0889 http://www.tbray.org/ongoing/
   AIM: MarkupPedant



From owner-atom-syntax@mail.imc.org  Wed Jul  7 15:24: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 PAA11263
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 15:24: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 i67JEhFD052252;
	Wed, 7 Jul 2004 12: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 i67JEhou052251;
	Wed, 7 Jul 2004 12:14:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web41503.mail.yahoo.com (web41503.mail.yahoo.com [66.218.93.86])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i67JEgEG052236
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 12:14:42 -0700 (PDT)
	(envelope-from randymorin@yahoo.com)
Message-ID: <20040707191441.88360.qmail@web41503.mail.yahoo.com>
Received: from [66.46.139.106] by web41503.mail.yahoo.com via HTTP; Wed, 07 Jul 2004 12:14:41 PDT
Date: Wed, 7 Jul 2004 12:14:41 -0700 (PDT)
From: Randy Charles Morin <randymorin@yahoo.com>
Reply-To: randy@kbcafe.com
Subject: Re: Atom API in WSDL 2.0 
To: dorchard@bea.com, Atomlist <atom-syntax@imc.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-323245546-1089227681=:88121"
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>


--0-323245546-1089227681=:88121
Content-Type: text/plain; charset=us-ascii

>Please post them to the list 1 by 1.

That's a lot of posts. How about posting all the questions once. Oops, here ya go :)
 
Randy
http://www.kbcafe.com
 

WSDL 1.1 comments/questions:
- Shouldn't there be a WSDL 1.1 HTTP binding?
- I think the WSDL 1.1 action fields are wrong. The soap action should be the atom ns defined operations, not HTTP operations. Chris Ferris also suggested this. I've done what Chris suggested.
- Is the mime ns decl necessary?
- Why are the responses in "wrapped mode"? I removed the wrapper on the response.

WSDL 1.1 and WSDL 2.0 comments/questions:

- Why isn't the doc/lit style used? This has used the "wrapped" doc/lit. I'd prefer either straight up doc/lit, or even rpc/literal, rather than re-inventing rpc and calling it doc/literal. 

- If wrapped is kept, and the responses are correctly unwrapped, then the wrappers can be updated. I've done so.

- Will SOAP 1.2 be supported?

- Does a service have to support both HTTP Transfer and SOAP/HTTP for the Post and EditURIs? The WSDL to describe that a given dynamic URI supports both bindings is hard to write. It seems harder to write server software as an HTTP POST could be one of: Atom:POST, SOAP:envelope (with one of POST/PUT/DELETE/GET), atom:PUT, atom:DELETE, depending upon whether http, soap, http wrapped are used.

- No mention of any binary data, can't remember if there was talk of adding binary data for images..

- There's no SOAP Faults content

- Is the "wrapped" HTTP supported? Where the POST could contain a DELETE or PUT?

WSDL 2.0 comments/questions:

- in WSDL 2.0, optional elements are allowed, so you could have the security element. I have left it in as I understand the reason for removing it from wsdl 1.1 was that headers can't be optional in wsdl 1.1

- There must be 2 interfaces: the SOAP and the HTTP interface because the interface has to know whether to put the "procedure" as the child or not. A classic leaky abstraction. I also observe the inability to separate soap from http in the abstract layer. 

- There must be 3 http bindings and 3 http endpoints because there are 3 different HTTP uris - POST, ENTRY, and FEED. hmmm.

- The Atom WSDL 1.1 did not provide an HTTP binding, so any comparison of bindings of WSDL is misleading.

- In summary, there are 2 interfaces, 4 bindings, 2 services and 4 endpoints. This doesn't seem very simple from an HTTP perspective. The SOAP binding does look markedly simpler, especially if the ws-security is removed.
 


		
---------------------------------
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
--0-323245546-1089227681=:88121
Content-Type: text/html; charset=us-ascii

<DIV>
<DIV>&gt;Please post them to the list 1 by 1.<BR><BR>That's a lot of posts. How about posting all the questions once. Oops, here ya go :)</DIV>
<DIV>&nbsp;</DIV>
<DIV>Randy</DIV>
<DIV><A href="http://www.kbcafe.com/">http://www.kbcafe.com</A></DIV>
<DIV>&nbsp;</DIV>
<P><B>WSDL 1.1 comments/questions:</B><BR>- Shouldn't there be a WSDL 1.1 HTTP binding?<BR>- I think the WSDL 1.1 action fields are wrong. The soap action should be the atom ns defined operations, not HTTP operations. Chris Ferris also suggested this. I've done what Chris suggested.<BR>- Is the mime ns decl necessary?<BR>- Why are the responses in "wrapped mode"? I removed the wrapper on the response.</P>
<P><B>WSDL 1.1 and WSDL 2.0 comments/questions:</B></P>
<P>- Why isn't the doc/lit style used? This has used the "wrapped" doc/lit. I'd prefer either straight up doc/lit, or even rpc/literal, rather than re-inventing rpc and calling it doc/literal. </P>
<P>- If wrapped is kept, and the responses are correctly unwrapped, then the wrappers can be updated. I've done so.</P>
<P>- Will SOAP 1.2 be supported?</P>
<P>- Does a service have to support both HTTP Transfer and SOAP/HTTP for the Post and EditURIs? The WSDL to describe that a given dynamic URI supports both bindings is hard to write. It seems harder to write server software as an HTTP POST could be one of: Atom:POST, SOAP:envelope (with one of POST/PUT/DELETE/GET), atom:PUT, atom:DELETE, depending upon whether http, soap, http wrapped are used.</P>
<P>- No mention of any binary data, can't remember if there was talk of adding binary data for images..</P>
<P>- There's no SOAP Faults content</P>
<P>- Is the "wrapped" HTTP supported? Where the POST could contain a DELETE or PUT?</P>
<P><B>WSDL 2.0 comments/questions:</B></P>
<P>- in WSDL 2.0, optional elements are allowed, so you could have the security element. I have left it in as I understand the reason for removing it from wsdl 1.1 was that headers can't be optional in wsdl 1.1</P>
<P>- There must be 2 interfaces: the SOAP and the HTTP interface because the interface has to know whether to put the "procedure" as the child or not. A classic leaky abstraction. I also observe the inability to separate soap from http in the abstract layer. </P>
<P>- There must be 3 http bindings and 3 http endpoints because there are 3 different HTTP uris - POST, ENTRY, and FEED. hmmm.</P>
<P>- The Atom WSDL 1.1 did not provide an HTTP binding, so any comparison of bindings of WSDL is misleading.</P>
<P>- In summary, there are 2 interfaces, 4 bindings, 2 services and 4 endpoints. This doesn't seem very simple from an HTTP perspective. The SOAP binding does look markedly simpler, especially if the ws-security is removed.</P>
<DIV>&nbsp;</DIV></DIV><p>
		<hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/mail_us/taglines/aac/*http://promotions.yahoo.com/new_mail/static/ease.html">Yahoo! Mail Address AutoComplete</a> - You start. We finish.
--0-323245546-1089227681=:88121--



From owner-atom-syntax@mail.imc.org  Wed Jul  7 16:01:43 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14445
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 16:01: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 i67JomJS055350;
	Wed, 7 Jul 2004 12: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 i67JomjE055349;
	Wed, 7 Jul 2004 12: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-out4.apple.com (mail-out4.apple.com [17.254.13.23])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i67JolRH055338
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 12:50:47 -0700 (PDT)
	(envelope-from jens@apple.com)
Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225])
	by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id i67JolAP008149
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 12:50:47 -0700 (PDT)
Received: from relay4.apple.com (relay4.apple.com) by mailgate1.apple.com
 (Content Technologies SMTPRS 4.3.12) with ESMTP id <T6aa610b803118064e1398@mailgate1.apple.com>;
 Wed, 7 Jul 2004 12:50:46 -0700
Received: from [17.202.21.229] (snej.apple.com [17.202.21.229])
	by relay4.apple.com (8.12.11/8.12.11) with ESMTP id i67JoTvk015399;
	Wed, 7 Jul 2004 12:50:30 -0700 (PDT)
In-Reply-To: <73766b16040707113051a74e40@mail.gmail.com>
References: <5FC8FF2B-CF71-11D8-9E41-000A95A51C9E@sun.com> <73766b16040707113051a74e40@mail.gmail.com>
Mime-Version: 1.0 (Apple Message framework v667)
Content-Type: multipart/alternative; boundary=Apple-Mail-1--746523758
Message-Id: <E402D036-D04E-11D8-B708-000A95A0ACC4@apple.com>
Cc: Atom Syntax <atom-syntax@imc.org>
From: Jens Alfke <jens@apple.com>
Subject: Re: PaceEntryOrigin, composite feeds and inheritance
Date: Wed, 7 Jul 2004 12:50:25 -0700
To: Kevin Marks <kevinmarks@gmail.com>
X-Mailer: Apple Mail (2.667)
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--746523758
Content-Type: text/plain;
	charset=WINDOWS-1252;
	format=flowed
Content-Transfer-Encoding: quoted-printable


On Jul 7, 2004, at 11:30 AM, Kevin Marks wrote:

> The goal of this element is to make the sources of a composite  feed
> clearer. However, just a source URl is nto really sufficient for this,
> as the other semantic elements of a feed can be affected too.
>
> There is an alternative here, which was discussed briefly at the end
> of the atom community meeting and mentioned here before. This is to
> expand and clarify the feed/entry inheritance model such that an entry
> can declare the feed-level elements for its original feed.

Why not represent each of the components of a composite feed as=20
separate <feed> elements?

Either allow multiple top-level <feed> elements in the XML document, or=20=

allow a <feed> element to contain another <feed> element as a child, to=20=

indicate grouping.

This has the advantage over Kevin's suggestion that the feed-level data=20=

won't have to be repeated in every entry: this saves space and parsing=20=

time, and eliminates potential ambiguities like the possibility of=20
multiple entries with conflicting metadata for the same feed.

(Apologies if this has been suggested before; I'm new here. By way of=20
introduction, I work on Safari RSS.)

_______________________________________
Jens Alfke =97 Atom/RSS Wrangler =97 Apple Computer
he took a duck in the face at 250 knots

--Apple-Mail-1--746523758
Content-Type: text/enriched;
	charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable



On Jul 7, 2004, at 11:30 AM, Kevin Marks wrote:


<excerpt>The goal of this element is to make the sources of a
composite  feed

clearer. However, just a source URl is nto really sufficient for this,

as the other semantic elements of a feed can be affected too.


There is an alternative here, which was discussed briefly at the end

of the atom community meeting and mentioned here before. This is to

expand and clarify the feed/entry inheritance model such that an entry

can declare the feed-level elements for its original feed.

</excerpt>

Why not represent each of the components of a composite feed as
separate <<feed> elements?


Either allow multiple top-level <<feed> elements in the XML document,
or allow a <<feed> element to contain another <<feed> element as a
child, to indicate grouping.


This has the advantage over Kevin's suggestion that the feed-level
data won't have to be repeated in every entry: this saves space and
parsing time, and eliminates potential ambiguities like the
possibility of multiple entries with conflicting metadata for the same
feed.


<x-tad-smaller>(Apologies if this has been suggested before; I'm new
here. By way of introduction, I work on Safari RSS.)

</x-tad-smaller>

<flushright><bold>_______________________________________</bold>

<bold>Jens Alfke</bold> =97 Atom/RSS Wrangler =97 Apple Computer

<italic><color><param>8383,A9A9,7D7D</param>he took a duck in the face
at 250 knots</color></italic>

</flushright>=

--Apple-Mail-1--746523758--



From owner-atom-syntax@mail.imc.org  Wed Jul  7 16: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 QAA16074
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 16: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 i67KOC0S057419;
	Wed, 7 Jul 2004 13:24: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 i67KOCCH057418;
	Wed, 7 Jul 2004 13:24: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 i67KOCV3057412
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 13:24:12 -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 i67KOGn6016839
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 13:24:16 -0700 (PDT)
Received: from [10.232.32.232] ([17.255.240.130])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin01/MantshX 4.0) with ESMTP id i67KOFkI018740
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 13:24:15 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v618)
In-Reply-To: <0F3A98F9-CECB-11D8-9691-003065EA6144@geckotribe.com>
References: <0F3A98F9-CECB-11D8-9691-003065EA6144@geckotribe.com>
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--744478095; protocol="application/pkcs7-signature"
Message-Id: <A7523988-D053-11D8-9CA1-000A95DC3D90@mac.com>
From: Graham <dtcd@mac.com>
Subject: Re: PaceEntryOrigin
Date: Wed, 7 Jul 2004 16:24:31 -0400
To: Atom Syntax <atom-syntax@imc.org>
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--744478095
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed
Content-Transfer-Encoding: 7bit

On 5 Jul 2004, at 5:34 pm, Antone Roundy wrote:

> I don't think we can throw a feature out on the basis of it's having  
> been abused while in development.

The point was that it's incredibly open to abuse and confusion.

> But if that's what you really want to do, how about writing proposals  
> to replace each of the @rel values.  And please don't lump them all  
> together into one.

The proposal would be to make a separate element (probably all Link  
Constructs [1]) out of every current rel value, and then see how (and  
whether) we need to group them together from there. I would write a  
Pace but it would require spec text for all of the current @rel values,  
which at present doesn't seem to exist (another reason to ditch the  
stupid things).

Graham

[1]  
http://www.mnot.net/drafts/draft-nottingham-atom-format 
-02.html#rfc.section.3.4
--Apple-Mail-2--744478095
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
9w0BCQUxDxcNMDQwNzA3MjAyNDMxWjAjBgkqhkiG9w0BCQQxFgQU4hhL3d/IF/AKlEtuqBIDROlD
saoweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAaR+Gfz7/Dmv7xj7ucofHdl0x
93skPHJKhmDX9kEnurk3JJWeeG+gDDg196MGp7cSnQp4LswCst2LC1PnNJRHudF0h2o+pG255SCk
/uBPD4PRBTt9nvVR8r7EaexVUGozQPXAxvfN7UOOvJhyVwQfCWMdsY1tgiUoeC/68wLxzSBFBX0k
GZpg170B6CwZwytCJNH8twUqwfveddqzsRSJmBqjQwUEq/WH6S3N2gObDXVQQfjlvlIo59lFvVlc
4Qll7v38yledhEdAL3bXx1PiPYWWwRmBdhgrkuPGDR2pDBktmq8W4tyuZHCrXE8bMb+C63dzC9Zd
GmZwR3PqP71LAQAAAAAAAA==

--Apple-Mail-2--744478095--



From owner-atom-syntax@mail.imc.org  Wed Jul  7 18:50:39 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25622
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 18:50: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 i67McDAm065824;
	Wed, 7 Jul 2004 15:38:13 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i67McD4k065823;
	Wed, 7 Jul 2004 15:38:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i67McA8j065806
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 15:38:11 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 8 Jul 2004 08:42:33 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Thu, 08 Jul 2004 08:37:33 +1000
Subject: Re: PaceEntryOrigin
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD12B84D.1DEF0%eric.scheid@ironclad.net.au>
In-Reply-To: <A7523988-D053-11D8-9CA1-000A95DC3D90@mac.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


On 8/7/04 6:24 AM, "Graham" <dtcd@mac.com> wrote:

> I would write a  Pace but it would require spec text for all of the current
> @rel values,  which at present doesn't seem to exist (another reason to ditch
> the  stupid things).
> 
please clarify: ditch the mechanism for specifying URIs of interest to the
feed/entry, or ditch the concept of different URIs being distinguishable
from each other in some machine readable manner, or ditch the current set of
URI relationships?

e.



From owner-atom-syntax@mail.imc.org  Wed Jul  7 19:01:54 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26416
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 19:01:54 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i67MbbeZ065802;
	Wed, 7 Jul 2004 15:37:37 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i67Mbb5r065801;
	Wed, 7 Jul 2004 15:37:37 -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 i67MbaAP065795
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 15:37:36 -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 i67Me5hA001863;
	Wed, 7 Jul 2004 18:40:05 -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 BHJ12567 (AUTH bob@wyman.us);
	Wed, 7 Jul 2004 18:35:37 -0400 (EDT)
Message-Id: <200407072235.BHJ12567@ms8.netsolmail.com>
Reply-To: <bob@wyman.us>
From: "Bob Wyman" <bob@wyman.us>
To: "'Jens Alfke'" <jens@apple.com>, "'Kevin Marks'" <kevinmarks@gmail.com>
Cc: "'Atom Syntax'" <atom-syntax@imc.org>
Subject: RE: PaceEntryOrigin, composite feeds and inheritance
Date: Wed, 7 Jul 2004 18:35:38 -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: <E402D036-D04E-11D8-B708-000A95A0ACC4@apple.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Thread-Index: AcRkXldxc8G4BKVGQ0izaMj+ASjpVwAEsaeA
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


Jens Alfke wrote:
>Why not represent each of the components of a composite feed as separate
<feed> elements?
	This has been proposed before, however, the general consensus seems
to be that we should avoid this solution since it may lead to the creation
of "feeds-of-feeds" -- something which we would all like to avoid. 
	The fear is that if a feed can contain feeds, then we'll rapidly see
"feed-of-feed-of-feed-of-feed...". i.e. Atom feeds will start looking like
OPML files... The intent of atom is not to provide for arbitrarily deep
nesting of data but rather to model simple, one-level deep collections of
entries.
	Of course, as you suggest, supporting "feed-of-feeds" would have the
nice attribute that "feed-level data won't have to be repeated in every
entry." However, I think the consensus is that potentially increased size of
entries is a valid trade-off to avoid the problems and complexities that
come from supporting nested feeds. Also, there is some anecdotal data that
indicates that at least in some composite feed applications (such as
PubSub.com's), the normal case is for an aggregate feed to be dominated by
entries that wouldn't be able to share meta-data with other entries in the
same aggregate feed. (i.e. in a single aggregate feed, you might have 30 or
50 entries, but each of them was extracted from a different source feed.)
	The solution we've been using is one of the ones that was discussed
at the end of the Atom Community Meeting... We insert a <ps:source-feed>
element that contains an extract of the feed-level metadata for each item we
pack into the aggregate feeds. For an example, look at the feed below:
(Note: I am aware that this is *not* a valid Atom feed for a number of
reasons. This is *not* part of our released system.)

http://atom.pubsub.com/c3/cd/7a625435c020f57b2536e64cc6.xml

		bob wyman




From owner-atom-syntax@mail.imc.org  Wed Jul  7 19:29: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 TAA27657
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 19: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 i67N2NwU067959;
	Wed, 7 Jul 2004 16:02: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 i67N2NZ1067958;
	Wed, 7 Jul 2004 16:02: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.89])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i67N2MA1067952
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 16:02:22 -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 i67N2S2G029062;
	Wed, 7 Jul 2004 16:02:28 -0700 (PDT)
Received: from [10.232.32.232] ([17.255.240.130])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id i67N2QZt028840;
	Wed, 7 Jul 2004 16:02:27 -0700 (PDT)
In-Reply-To: <BD12B84D.1DEF0%eric.scheid@ironclad.net.au>
References: <BD12B84D.1DEF0%eric.scheid@ironclad.net.au>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7--734986493; protocol="application/pkcs7-signature"
Message-Id: <C0C1CD40-D069-11D8-9CA1-000A95DC3D90@mac.com>
Cc: Atom Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: PaceEntryOrigin
Date: Wed, 7 Jul 2004 19:02:42 -0400
To: Eric Scheid <eric.scheid@ironclad.net.au>
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-7--734986493
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 7 Jul 2004, at 6:37 pm, Eric Scheid wrote:

>
> On 8/7/04 6:24 AM, "Graham" <dtcd@mac.com> wrote:
>
>> I would write a  Pace but it would require spec text for all of the 
>> current
>> @rel values,  which at present doesn't seem to exist (another reason 
>> to ditch
>> the  stupid things).
>>
> please clarify: ditch the mechanism for specifying URIs of interest to 
> the
> feed/entry, or ditch the concept of different URIs being 
> distinguishable
> from each other in some machine readable manner, or ditch the current 
> set of
> URI relationships?

None of the above. Ditch the way rel is currently expressed, such that:

  <link rel="XXX" href="a" title="b" type="c" />
becomes:
  <XXX href="a" title="b" type="c">

In other words, the rel value becomes the element name. No lost 
functionality, just changed syntax. This is already how the various 
different date constructs (and content constructs and person 
constructs) distinguish their meaning in a machine readable manner.

Graham Parks
--Apple-Mail-7--734986493
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
9w0BCQUxDxcNMDQwNzA3MjMwMjQzWjAjBgkqhkiG9w0BCQQxFgQUXLhdN/9yZCIIphfxVp0etPn/
CQwweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAEuR36uFdVnFjfRJiV9ktsKI9
ZCWg3HzudMAe8SrtshwGNqlfl1zCsB81vGLEZ8ExL/ZgX5EhpbpdsWLGEM5ossyJNRsPUlwvIVFm
yAn5A0wUMJE7Doe4auoRyTwmM2ULhz36+uarQU2UsP3D4j4wotrBfkLnQDX4Uxs6qR+xLhXTPfoK
zfrEsl6l8vnwpdqtEPoHqH3M6AGIz16vn1kRTEJF4zSmHkZhYahzGLMwUyCey6f6jVXcMrhx9kvR
89SU/nxto5D3Ut/rdeYiKt5BDDt5q0W2pdf5/cbgU43XMOXcpKEtk1D5oScj+3kSOUg2FpJs7D7F
PcywjKKbQY/TCwAAAAAAAA==

--Apple-Mail-7--734986493--



From owner-atom-syntax@mail.imc.org  Wed Jul  7 20:02: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 UAA29257
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 20:02: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 i67Nna5a070280;
	Wed, 7 Jul 2004 16: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 i67NnasM070279;
	Wed, 7 Jul 2004 16:49:36 -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 i67NnZVM070272
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 16:49:35 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040707234936.92326.qmail@web41208.mail.yahoo.com>
Received: from [131.107.3.85] by web41208.mail.yahoo.com via HTTP; Wed, 07 Jul 2004 16:49:35 PDT
Date: Wed, 7 Jul 2004 16:49:35 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: PaceEntryOrigin
To: Eric Scheid <eric.scheid@ironclad.net.au>,
        Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <BD0FCACC.1D6E1%eric.scheid@ironclad.net.au>
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>


--- Eric Scheid <eric.scheid@ironclad.net.au> wrote:
> 
> Please identify in what ways <link> is
> underspecified. Perhaps all that is
> needed is, um, specification text to be written.
> 
> So ... what parts of the 0.3 spec is
> ambiguous/contradictory/silent w.r.t.
> <link>? In what ways can <link> be interpreted in
> more than one way that
> will lead to confusion or interoperability problems?

In the Atom 0.3 syndication spec it implies that there
is a fixed list of rel values which seems to
contradict the Atom API spec which implies that there
can be user defined rel values. 

If the list is fixed, then the link element is merely
inconsistent as opposed to underspecified. However if
it allows user defined rel values then it is grossly
underspecified. The question is which is it? 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


	
		
__________________________________
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 Jul  7 20:18: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 UAA29729
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 20:18: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 i680BEFw071583;
	Wed, 7 Jul 2004 17:11: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 i680BEaE071582;
	Wed, 7 Jul 2004 17:11:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.195])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i680BEqd071576
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 17:11:14 -0700 (PDT)
	(envelope-from kevinmarks@gmail.com)
Received: by mproxy.gmail.com with SMTP id 62so201543rni
        for <atom-syntax@imc.org>; Wed, 07 Jul 2004 17:11:07 -0700 (PDT)
Received: by 10.38.9.68 with SMTP id 68mr132141rni;
        Wed, 07 Jul 2004 17:11:07 -0700 (PDT)
Message-ID: <73766b16040707171136323e6a@mail.gmail.com>
Date: Wed, 7 Jul 2004 17:11:07 -0700
From: Kevin Marks <kevinmarks@gmail.com>
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Validing parser required?
In-Reply-To: <6EC38B00-CC52-11D8-A54F-000A95A51C9E@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <40E57909.4040808@intertwingly.net>
 <20040702160222.GO5957@tartarus.org> <40E58C3C.7010908@franklinmint.fm> <6EC38B00-CC52-11D8-A54F-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 Jul 2, 2004, at 9:24 AM, Robert Sayre wrote:
> 
> > Cribbing a bit from the section 5.2 of the XML spec:
> >
> > "Atom documents can be processed by non-validating XML processors. An
> > Atom document MUST NOT rely on any behaviors not required of such
> > processors."

Can you apply De Moivres theorem to that  so it gets fewer negatives in it?



From owner-atom-syntax@mail.imc.org  Wed Jul  7 20:42: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 UAA00944
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 20: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 i680Wtq1074099;
	Wed, 7 Jul 2004 17:32: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 i680WtQ4074098;
	Wed, 7 Jul 2004 17:32: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.199])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i680WsAO074090
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 17:32:54 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d19so112519rnf
        for <atom-syntax@imc.org>; Wed, 07 Jul 2004 17:32:33 -0700 (PDT)
Received: by 10.38.3.58 with SMTP id 58mr175990rnc;
        Wed, 07 Jul 2004 17:32:32 -0700 (PDT)
Message-ID: <14be96d304070717323dd139a@mail.gmail.com>
Date: Wed, 7 Jul 2004 20:32:32 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Atom Syntax <atom-syntax@imc.org>
Subject: PaceUriOrItsSuccessor
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


http://intertwingly.net/wiki/pie/PaceUriOrItsSuccessor

== Abstract ==

[MarkPilgrim] Make all references to RFC 2396 into "RFC 2396 or its
successor" so that when RFC 2396bis is done, Atom can inherit it
without revving the spec.

== Status ==

Open

== Rationale ==

RFC 2396bis adds internationalization support to URIs.  It will become
the new standard for URIs very shortly after its release (it is
already the de facto standard in modern browsers).  Atom should plan
for its arrival by referencing "RFC 2396 or its successor" to define
URIs.

== Proposal ==

In section 3.2.2, change "The content of atom:url in a Person
construct MUST be a  URI [RFC2396]." to "The content of atom:url in a
Person construct MUST be a  URI [RFC2396 or its successor]."

In section 3.4.3, change "Link constructs MUST have a href attribute,
whose value MUST be a URI [RFC2396]." to "Link constructs MUST have a
href attribute, whose value MUST be a URI [RFC2396 or its successor]."

In section 4.8, change "The content of this element, when present,
MUST be a URI." to "The content of this element, when present, MUST be
a URI [RFC2396 or its successor]."

In section 4.9, change "The atom:generator element MAY have a "url" 
attribute whose value MUST be a URI" to "The atom:generator element
MAY have a "url"  attribute whose value MUST be a URI [RFC 2396 or its
successor]"

== Impacts ==

Unknown (FIXME)

== Notes ==


----

CategoryProposals

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Wed Jul  7 20: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 UAA01425
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 20:56: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 i680jHQo075156;
	Wed, 7 Jul 2004 17: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 i680jHMB075155;
	Wed, 7 Jul 2004 17:45: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 i680jG6p075149
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 17:45:17 -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 i680jh3p031651
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 20:45:47 -0400
Message-ID: <40EC9915.4050406@intertwingly.net>
Date: Wed, 07 Jul 2004 20:45:09 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: New AtomPubIssuesList for 2004/07/07
References: <40E16215.6070507@intertwingly.net>
In-Reply-To: <40E16215.6070507@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:

http://www.intertwingly.net/wiki/pie/AtomPubIssuesList

I'm suggesting two security related items to proceed: 
PaceSecurityServices, PaceFeedSignature (one affecting the protocol, one 
the format).

PaceConsistentMimeType, PaceElementOrder, and PaceSyntaxGuidelines are 
minor/editorial.

PaceInterop, PaceContentTypeHandling, PaceXmlValidity,
ErrorReportingMechanism all have been withdrawn by their respective 
authors without an objection noted on the mailing list.  Unless somebody 
objects, these will proceed to closure.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Wed Jul  7 21:11:53 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02123
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 21:11:52 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i680nsJr075400;
	Wed, 7 Jul 2004 17:49: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 i680ns4g075399;
	Wed, 7 Jul 2004 17:49:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i680ns2Y075393
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 17:49:54 -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 i680nxil020903
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 18:49:59 -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 <0I0I008WUCZBYK@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Wed, 07 Jul 2004 18:49:59 -0600 (MDT)
Received: from [192.168.1.100] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0I00FJNCZA46@mail.sun.net> for atom-syntax@imc.org; Wed,
 07 Jul 2004 18:49:59 -0600 (MDT)
Date: Wed, 07 Jul 2004 17:49:54 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceUriOrItsSuccessor
In-reply-to: <14be96d304070717323dd139a@mail.gmail.com>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <BA632E7C-D078-11D8-B2D0-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: <14be96d304070717323dd139a@mail.gmail.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 Jul 7, 2004, at 5:32 PM, Mark Pilgrim wrote:

+1, but the rationale could be strengthened by pointing out that 
2396bis has *many* improvements; and we only need to change the 
referent of [2396] in the References section, right?  No need for 
changes in multiple places in the text. -Tim



From owner-atom-syntax@mail.imc.org  Wed Jul  7 21:15: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 VAA02251
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 21:15: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 i68175Mx077490;
	Wed, 7 Jul 2004 18:07: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 i68175MC077489;
	Wed, 7 Jul 2004 18:07: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 i68173hh077482
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 18:07:04 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 8 Jul 2004 11:11:57 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Thu, 08 Jul 2004 11:05:16 +1000
Subject: Re: PaceEntryOrigin
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD12DAEC.1DF57%eric.scheid@ironclad.net.au>
In-Reply-To: <20040707234936.92326.qmail@web41208.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 8/7/04 9:49 AM, "Dare Obasanjo" <kpako@yahoo.com> wrote:

> If the list is fixed, then the link element is merely
> inconsistent as opposed to underspecified. However if
> it allows user defined rel values then it is grossly
> underspecified. The question is which is it?

I would prefer allowing user-specified values, but in what way is that
under-specified? You say it is under-specified, but you don't say in what
way -- that is not helpful.

Surely you are not asking that all future user-specified values be specified
now?

Perhaps what is needed is spec text along the lines of "an Atom aggregator
MAY ignore links with @rel values it does not recognise". That, combined
with PaceLinkPurpose to limit use of <link> to user-actionable links
retrieved via GET would just about cover it, no?

e.



From owner-atom-syntax@mail.imc.org  Wed Jul  7 21: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 VAA02316
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 21: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 i68183nH077552;
	Wed, 7 Jul 2004 18:08: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 i68183UM077551;
	Wed, 7 Jul 2004 18:08: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 (mproxy.gmail.com [216.239.56.245])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i68183JV077545
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 18:08:03 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so6526565cwc
        for <atom-syntax@imc.org>; Wed, 07 Jul 2004 18:08:06 -0700 (PDT)
Received: by 10.11.118.71 with SMTP id q71mr558045cwc;
        Wed, 07 Jul 2004 18:08:06 -0700 (PDT)
Message-ID: <3f1451f50407071808130cc410@mail.gmail.com>
Date: Wed, 7 Jul 2004 21:08:06 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Sam Ruby <rubys@intertwingly.net>
Subject: PaceSecurityServices
Cc: atom-syntax <atom-syntax@imc.org>
In-Reply-To: <40EC9915.4050406@intertwingly.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <40E16215.6070507@intertwingly.net> <40EC9915.4050406@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


-1 

For the following reasons:

1. The Pace is rather vauge. 
    Is there a definitive list of security services could be placed in
such an element?
    If there are more than one such security service how is priority set?
    Does 'security' applied to an atom:feed imply the same security
for all the entries?
2. Encryption and possibly signatures require XML to be canonicalized,
    which is not only a burden but is not mentioned anywhere in the Pace.
3. Because of the complexity of producing and consuming such a feed
    I do not believe this functionality belongs in the core of Atom.

   Thanks,
   -joe



From owner-atom-syntax@mail.imc.org  Wed Jul  7 21:25:07 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02721
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 21:25: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 i681B2Fs077962;
	Wed, 7 Jul 2004 18:11:02 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i681B21b077961;
	Wed, 7 Jul 2004 18:11:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from vspmail.nscp.aoltw.net (h-64-236-138-233.aoltw.net [64.236.138.233])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i681B2rm077938
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 18:11:02 -0700 (PDT)
	(envelope-from jpanzer@AOL.NET)
Received: from h-10-169-146-121.nscp.aoltw.net (h-10-169-146-121.nscp.aoltw.net [10.169.146.121])
	by vspmail.nscp.aoltw.net (8.11.6/8.11.6) with ESMTP id i681G0s00379
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 18:16:00 -0700
Date: Wed, 7 Jul 2004 18:11:00 -0700
From: "John Panzer" <jpanzer@aol.net>
Subject: Thought experiment: Using a synthetic feed to find out about other feeds
To: atom-syntax <atom-syntax@imc.org>
Message-ID: <40EC9F23.1010102@AOL.NET>
X-Mailer: AOL Communicator (20030919.3 Win)
MIME-Version: 1.0
Content-Type: TEXT/HTML; 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>


<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
<font size="2"><font face="Arial,sans-serif">All,<br>
<br>
Note: I'm not attempting to continue the discussion about introspection
and feeds in this post, or at least I want to focus on a different
angle.&nbsp; Let's ignore introspection completely for the moment (I pick it
up again in the P.S. below).<br>
<br>
Suppose I want to offer a service in which people can subscribe to a
collection of pointers to Atom feeds.&nbsp; Given that we already have RSS
feeds for doing things like <a
 href="http://www.benhammersley.com/tools/fedex_package_tracking_in_rss.html"
 style="white-space: nowrap;">tracking FedEx packages</a>, this doesn't
seem too outlandish.&nbsp; Sample use cases:<br>
<br>
o List of blogs that I own and publish for others to read.<br>
o List of blogs that I recommend/link to via an "other blogs" section,
that my friends can use to see what I'm reading.<br>
o List of blogs that have linked to me via an "other blogs" section.<br>
o List of "top 10" blogs by some metric.<br>
<br>
Now, I can of course just compose a feed with regular entries, each of
which has a hyperlink off to the relevant web page.&nbsp; But what if I want
to allow automatic processing of the feed into something else useful?<br>
<br>
This sounds like another use for synthetic feeds; so, I'm lazily
borrowing from Bob Wyman's example synthetic feed below to see what
this might look like.&nbsp; Imagine this is a feed which you can subscribe
to via <a class="moz-txt-link-freetext" href="http://example.com/bugsbunny/atom-feeds:">http://example.com/bugsbunny/atom-feeds:</a><br>
</font></font>
<pre id="line46"><span class="pi">&lt;?xml version='1.0'encoding="utf-8"?&gt;</span><br>&lt;<span
 class="start-tag">feed</span><span class="attribute-name"> version</span>=<span
 class="attribute-value">'0.3' </span><span class="attribute-name">xmlns</span>=<span
 class="attribute-value">'<a class="moz-txt-link-freetext" href="http://purl.org/atom/ns#">http://purl.org/atom/ns#</a>' </span><span
 class="attribute-name">xmlns:ps</span>=<span class="attribute-value">'<a class="moz-txt-link-freetext" href="http://www.pubsub.com/xmlns">http://www.pubsub.com/xmlns</a>'</span>&gt;<br>   &lt;<span
 class="start-tag">link</span><span class="attribute-name"> rel</span>=<span
 class="attribute-value">'alternate' </span><span class="attribute-name">type</span>=<span
 class="attribute-value">'text/html' </span><span class="attribute-name">href</span>=<span
 class="attribute-value">'<a class="moz-txt-link-freetext" href="http://example.com/bugsbunny">http://example.com/bugsbunny</a>'</span><span
 class="attribute-name">/</span>&gt;<br>   &lt;<span class="start-tag">modified</span>&gt;2004-07-07T18:36:11-04:00&lt;/<span
 class="end-tag">modified</span>&gt;<br>   &lt;<span class="start-tag">author</span>&gt;<br>      &lt;<span
 class="start-tag">name</span>&gt;Bugs Bunny&lt;/<span class="end-tag">name</span>&gt;<br>   &lt;/<span
 class="end-tag">author</span>&gt;<br>&lt;<span class="start-tag">title</span>&gt;<span
 class="cdata">&lt;![CDATA[Bugs Bunny's Blogs]]&gt;</span>&lt;/<span
 class="end-tag">title</span>&gt;<br><br>&lt;<span class="start-tag">entry</span>&gt;<br>&lt;<span
 class="start-tag">ps:source-feed</span>&gt;<br>&lt;<span
 class="start-tag">title</span>&gt;<span class="cdata">&lt;![CDATA[Title of my First Blog]]&gt;</span>&lt;/<span
 class="end-tag">title</span>&gt;<br>&lt;<span class="start-tag">link</span><span
 class="attribute-name"> rel</span>=<span class="attribute-value">'alternate' </span><span
 class="attribute-name">type</span>=<span class="attribute-value">'text/html' </span><span
 class="attribute-name">href</span>=<span class="attribute-value">'<a class="moz-txt-link-freetext" href="http://example.com/bugsbunny/MyFirstBlog">http://example.com/bugsbunny/MyFirstBlog</a>'</span><span
 class="attribute-name">/</span>&gt;<br>&lt;link rel="service.post" type="application/atom+xml" href=<a class="moz-txt-link-rfc2396E" href="http:/example.com/bugsbunny/MyFirstBlog/atompost.cgi">"http:/example.com/bugsbunny/MyFirstBlog/atompost.cgi"</a>/&gt;<br>&lt;/<span
 class="end-tag">ps:source-feed</span>&gt;<br>&lt;<span
 class="start-tag">modified</span>&gt;2004-07-07T19:34:10-04:00&lt;/<span
 class="end-tag">modified</span>&gt;<br>&lt;<span class="start-tag">issued</span>&gt;2004-07-07T19:34:10-04:00&lt;/<span
 class="end-tag">issued</span>&gt;<br>&lt;/<span class="end-tag">entry</span>&gt;<br><br>&lt;<span
 class="start-tag">entry</span>&gt;<br>&lt;<span class="start-tag">ps:source-feed</span>&gt;<br>&lt;<span
 class="start-tag">title</span>&gt;<span class="cdata">&lt;![CDATA[Title of my Second Blog]]&gt;</span>&lt;/<span
 class="end-tag">title</span>&gt;<br>&lt;<span class="start-tag">link</span><span
 class="attribute-name"> rel</span>=<span class="attribute-value">'alternate' </span><span
 class="attribute-name">type</span>=<span class="attribute-value">'text/html' </span><span
 class="attribute-name">href</span>=<span class="attribute-value">'</span><span
 class="attribute-value"><a class="moz-txt-link-freetext" href="http://example.com/bugsbunny/MySecondBlog">http://example.com/bugsbunny/MySecondBlog</a></span><span
 class="attribute-value">'</span><span class="attribute-name">/</span>&gt;<br>&lt;link rel="service.post" type="application/atom+xml" href=<a class="moz-txt-link-rfc2396E" href="http:/example.com/bugsbunny/MySecondBlog/atompost.cgi">"http:/example.com/bugsbunny/MySecondBlog/atompost.cgi"</a>/&gt;<br>&lt;/<span
 class="end-tag">ps:source-feed</span>&gt;<br>&lt;<span
 class="start-tag">modified</span>&gt;2004-07-05T04:44:00-04:00&lt;/<span
 class="end-tag">modified</span>&gt;<br>&lt;<span class="start-tag">issued</span>&gt;2004-07-05T04:44:00-04:00&lt;/<span
 class="end-tag">issued</span>&gt;<br>&lt;/<span class="end-tag">entry</span>&gt;<br>&lt;/feed&gt;<br></pre>
<font size="2"><font face="Arial,sans-serif">o Note that this doesn't
make much use of real entry fields, except atom:modified and
atom:issued, which I'm imagining would be calculated in the obvious way
from the originating feeds' entries.<br>
o Most of the interesting information is in the ps:source-feed
element.&nbsp; Which can contain HTML URIs as well as endpoints -- taken
from the originating feeds -- giving URIs for, say, posting.&nbsp; Or other
feed-level pieces of information.<br>
<br>
The only oddity about this 'feed' is that, of course, the 'entries' are
themselves synthesized out of non-entry data.&nbsp; But this is exactly what
happens in the FedEx tracking example.&nbsp; So it's a synthetic feed of
synthetic entries, which doesn't seem unreasonable.<br>
<br>
Note, of course, that it's perfectly possible to add atom:content
elements to the above with nicely formatted human readable HTML content
pointing at the relevant HTML web pages, if someone subscribes to this
feed in a 'regular' RSS reader.&nbsp; This would be useful.&nbsp; <br>
<br>
It would be even more useful, though, if someone used a 'feed tracker'
feature pointing at </font></font><font size="2"
 face="Arial,sans-serif"><font face="Arial,sans-serif"><a class="moz-txt-link-freetext" href="http://example.com/bugsbunny/atom-feeds">http://example.com/bugsbunny/atom-feeds</a>;
this could do interesting things with the results, given the knowledge
that what it's pointing at is really a synthesized feed of other
(indirect) feeds.&nbsp; For example, tracking new feeds for possible
subscription in a special area of the UI.&nbsp; (Though actually that seems
like a generally useful feature for _all_ synthetic feeds...)<br>
<br>
So, let me ask this:&nbsp; Does this seem like a reasonable use of synthetic
feeds?&nbsp; Does anyone see problems with this sort of usage?<br>
<br>
-John Panzer<br>
<br>
P.S.: If you look at the feed above closely, you might notice that it
contains elements that you might consider to be 'introspective'.&nbsp; But
that's just a consequence of the synthetic feed format; it falls out
naturally, though of course the choice of precisely which elements to
include is up to the feed generator.&nbsp; So, the question here is:&nbsp; If
this is a reasonable use of the synthetic feed format, would it meet
most or all needs that would be met by a 'pure' introspection API?&nbsp; I
dunno, honestly.&nbsp; What do you think?<br>
<br>
</font></font>
</body>
</html>



From owner-atom-syntax@mail.imc.org  Wed Jul  7 21:34:40 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03395
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 21:34:39 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i681QVxF078774;
	Wed, 7 Jul 2004 18:26: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 i681QV2e078773;
	Wed, 7 Jul 2004 18:26: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 (mproxy.gmail.com [216.239.56.252])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i681Q0dS078756
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 18:26:30 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so6538517cwc
        for <atom-syntax@imc.org>; Wed, 07 Jul 2004 18:26:00 -0700 (PDT)
Received: by 10.11.116.72 with SMTP id o72mr563839cwc;
        Wed, 07 Jul 2004 18:26:00 -0700 (PDT)
Message-ID: <3f1451f504070718267c5526b4@mail.gmail.com>
Date: Wed, 7 Jul 2004 21:26:00 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Sam Ruby <rubys@intertwingly.net>
Subject: PaceSecurityServices
Cc: atom-syntax <atom-syntax@imc.org>
In-Reply-To: <40EC9915.4050406@intertwingly.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <40E16215.6070507@intertwingly.net> <40EC9915.4050406@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


There is too much in this one Pace to just +1 or -1
the whole thing.

In the section on the AtomAPI:
---------------------------------------------

+1 on Digest and TLS

I support referencing and strongly encouraging
the use of standard authentication and 
encryption mechanisms.

-1 to WSSE

On the other hand I do not like the WSSE
mechanism ( wide open to man in the middle
attacks and requires both the client and the
server to store plaintext passwords ). 
If we must create a new authentication mechanism 
I would prefer to use an updated version of [1] that supports
multiple kinds of hashes and mandates 'auth-int'. 
This will provide better security to implementors, 
easier implementations for systems that already store
hashed values of passwords, and provides protection
against man in the middle attacks.

If we must create a new authentication mechanism
than I would also like it to be a seperate RFC from the
the AtomAPI, just as HTTP is broken into 
RFC 2616 and 2617.

[1] http://bitworking.org/news/New_AtomAPI_Implementation_Release2



From owner-atom-syntax@mail.imc.org  Wed Jul  7 21:51:44 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04824
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 21: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 i681gGro080070;
	Wed, 7 Jul 2004 18:42: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 i681gGBV080069;
	Wed, 7 Jul 2004 18:42: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.201])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i681gEP4080062
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 18:42:15 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d15so26381rng
        for <atom-syntax@imc.org>; Wed, 07 Jul 2004 18:42:17 -0700 (PDT)
Received: by 10.38.3.58 with SMTP id 58mr181642rnc;
        Wed, 07 Jul 2004 18:35:37 -0700 (PDT)
Message-ID: <14be96d3040707183525233978@mail.gmail.com>
Date: Wed, 7 Jul 2004 21:35:37 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Tim Bray <tim.bray@sun.com>
Subject: Re: PaceUriOrItsSuccessor
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <BA632E7C-D078-11D8-B2D0-000A95A51C9E@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <14be96d304070717323dd139a@mail.gmail.com> <BA632E7C-D078-11D8-B2D0-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 Wed, 07 Jul 2004 17:49:54 -0700, Tim Bray <tim.bray@sun.com> wrote:
> +1, but the rationale could be strengthened by pointing out that
> 2396bis has *many* improvements;

Perhaps someone more experienced could explain what they are, besides i18n.

>  and we only need to change the
> referent of [2396] in the References section, right?  No need for
> changes in multiple places in the text. -Tim

OK, if that's how these things work.

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Wed Jul  7 22:53:10 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06999
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 22:53:09 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i682Zcbt084531;
	Wed, 7 Jul 2004 19:35:38 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i682ZcXc084530;
	Wed, 7 Jul 2004 19:35:38 -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 i682Zbwk084492
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 19:35:37 -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 i682Zc53019822
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 21:35:38 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i682ZbUE019818;
	Wed, 7 Jul 2004 21:35:37 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: <atom-syntax@imc.org>
Subject: Re: PaceEntryOrigin, composite feeds and inheritance
References: <200407072235.BHJ12567@ms8.netsolmail.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 07 Jul 2004 21:35:37 -0500
In-Reply-To: <200407072235.BHJ12567@ms8.netsolmail.com>
Message-ID: <m3n02bql8m.fsf@bitsko.slc.ut.us>
Lines: 106
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: <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> writes:

> Jens Alfke wrote:
> >Why not represent each of the components of a composite feed as
> separate <feed> elements?
> 	This has been proposed before, however, the general consensus
> seems to be that we should avoid this solution since it may lead to
> the creation of "feeds-of-feeds" -- something which we would all
> like to avoid.

I have another possible solution.

This solution is based on breaking the strong association of a "feed"
to its site, section, or category.  By breaking this association, the
"feed" can be used solely for the protocol aspect, and the
relationship of entries to sites, authors, categories, sections, and
contributors can be made explicit, and then easily and explicitly
replicated.

    http://intertwingly.net/wiki/pie/FeedVsSite

This is what a current "feed" looks like:

    <?xml version="1.0" encoding="UTF-8"?>
    <feed xmlns="http://example.com/newformat#">
      <title>Kitty Adventures.</title>
      <id>tag:example.com,2004:kitties</id>
      <link rel="alternate" type="text/html" href="http://example.com/kitties/"/>
      <author>
        <name>Kitty Owner</name>
      </author>
      <modified>2003-06-07T09:30:00+02:00</modified>

      <entry>
        <title>Russian Blue</title>
        <id>tag:example.com,2004:kitties/russian-blue</id>
        <link rel="alternate" type="text/html" href="http://example.com/kitties/russian-blue.html"/>
        <issued>2003-06-07T09:30:00+02:00</issued>
        <modified>2003-06-07T09:30:00+02:00</modified>
        <content src="http://example.com/kitties/russian-blue.jpg">
      </entry>
    </feed>

Here is a "protocol instance" of a "feed" with its information
refactored to be separate from the physical feed:

    <?xml version="1.0" encoding="UTF-8"?>
    <feed xmlns="http://example.com/newformat#">
      <modified>2003-06-07T09:30:00+02:00</modified>

      <site>
        <title>Kitty Adventures.</title>
        <id>tag:example.com,2004:kitties</id>
        <link rel="alternate" type="text/html" href="http://example.com/kitties/"/>
        <author ref="tag:example.com,2004:authors/kitty"/>
      </site>

      <author>
        <id>tag:example.com,2004:authors/kitty</id>
        <name>Kitty Owner</name>
      </author>

      <entry>
        <title>Russian Blue</title>
        <id>tag:example.com,2004:kitties/russian-blue</id>
        <origin ref="tag:example.com,2004:kitties"/>
        <link rel="alternate" type="text/html" href="http://example.com/kitties/russian-blue.html"/>
        <issued>2003-06-07T09:30:00+02:00</issued>
        <modified>2003-06-07T09:30:00+02:00</modified>
        <author ref="tag:example.com,2004:authors/kitty"/>
        <content src="http://example.com/kitties/russian-blue.jpg">
      </entry>
    </feed>


This has the following features:

 * The entry does not *inherit* information, it explicitly refers to
   its origin <site> and explicitly refers to its <author>, even if it
   is the same author as the site.

 * The referenced constructs (aka entities, resources) can be copied
   whole to new feeds.

 * The link type, @ref, of the reference makes this "deep copy"
   linking explicit for that purpose (processing and recursion can be
   specified).

 * The concept of "site" (or "section" or "category") is more concrete
   than "feed".

This differs from, or expands on, earlier "include by reference"
proposals by dissociating the "logical information" of what we call a
"feed" and puts it more precisely its own entity construct ("site").
By doing so, it also enables the entry to be explicit about things
like authors and contributors, without "inheriting" from a feed.

This also scales well when "physical feeds" are used as indexes, when
sites, sections, or categories can have multiple physical feeds
(minimal, full), and for entries that "exist" in multiple categories
or sections to indicate both their origin category/section *and* site.

More examples to follow in the wiki page.  Note, this is not yet a
proposal (Pace), just exploration and discussion.

  -- Ken



From owner-atom-syntax@mail.imc.org  Wed Jul  7 22:54:14 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07041
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 22:54: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 i682iMdL085097;
	Wed, 7 Jul 2004 19:44: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 i682iMqZ085096;
	Wed, 7 Jul 2004 19:44: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 i682iLih085088
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 19:44: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 i682iRil026650
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 20:44:27 -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 <0I0I000G4IA2GE@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Wed, 07 Jul 2004 20:44:27 -0600 (MDT)
Received: from [192.168.1.100] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0I003I9IA2L2@mail.sun.net> for atom-syntax@imc.org; Wed,
 07 Jul 2004 20:44:26 -0600 (MDT)
Date: Wed, 07 Jul 2004 19:44:22 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceUriOrItsSuccessor
In-reply-to: <14be96d3040707183525233978@mail.gmail.com>
To: Mark Pilgrim <pilgrim@gmail.com>
Cc: Atom Syntax <atom-syntax@imc.org>
Message-id: <B7DFF268-D088-11D8-B2D0-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: <14be96d304070717323dd139a@mail.gmail.com>
 <BA632E7C-D078-11D8-B2D0-000A95A51C9E@sun.com>
 <14be96d3040707183525233978@mail.gmail.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 Jul 7, 2004, at 6:35 PM, Mark Pilgrim wrote:

> On Wed, 07 Jul 2004 17:49:54 -0700, Tim Bray <tim.bray@sun.com> wrote:
>> +1, but the rationale could be strengthened by pointing out that
>> 2396bis has *many* improvements;
>
> Perhaps someone more experienced could explain what they are, besides 
> i18n.

Well, the BNF actually has been tested heavily and can be used to 
generate parsers.  Plus it's got a coherent discussion of how to 
compare URIs.  Plus there's less handwaving about when/how to escape.  
Plus the discussion of what a resource is is less mystical. -Tim



From owner-atom-syntax@mail.imc.org  Wed Jul  7 22:59:08 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07173
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 22:59: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 i682hdLG085055;
	Wed, 7 Jul 2004 19: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 i682hdxS085054;
	Wed, 7 Jul 2004 19:43:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from homer.w3.org (homer.w3.org [18.29.0.30])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i682hdQs085047
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 19:43:39 -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 58F7D4F05B;
	Wed,  7 Jul 2004 22:43:23 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040708104642.02abc140@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Thu, 08 Jul 2004 11:33:28 +0900
To: Mark Pilgrim <pilgrim@gmail.com>, Atom Syntax <atom-syntax@imc.org>
From: Martin Duerst <duerst@w3.org>
Subject: Re: IRIs, URIs, and RFC 2396bis
In-Reply-To: <14be96d3040707103826ba6c34@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>


Hello Mark,

Thanks for asking these questions.

At 13:38 04/07/07 -0400, Mark Pilgrim wrote:

>The Atom 0.3 draft [1] states that "Link constructs MUST have a href
>attribute, whose value MUST be a URI [RFC2396]" [2].  Should this be
>changed to "whose value MUST be a URI, as defined by RFC2396 or its
>successor," so that Atom can benefit from RFC2396bis? [3]
>
>Alternatively, we could state "whose value MUST be an IRI" [4].

In my view, this is the right thing to do.

What would be the actual difference?

For the users of the Atom format, it would allow to put into
the href attribute International Domain Names (IDNs) and path/document
names with non-ASCII characters, rather than to escape/encrypt them
as punicode (for IDNs) and %-escapes (for the rest).

For implementers, it would mean that whenever you dereference one of
these hrefs (i.e. follow a link), the following is needed:
1) If you don't work with UTF-8 internally (e.g. UTF-16), then
    convert the attribute to UTF-8. From then on, make sure your
    code is 8-bit clean.
2) Before handing it over to your URI resolver, escape non-ASCII
    characters with %HH.
3) Before resolving the domain name, revert the %-encoding, and
    hand over the domain name to an IDN library (various open-source
    implementations already available) for conversion to punycode.

1) is about one call to a library function that if you do XML, you'll
have around anyway. 2) is a few lines of code. 3) is a few lines
of code plus something like 200k in library code, mostly due to the
tables needed for nameprep. In terms of implementation, this should
be on the order of a few minutes to a few hours, depending on coding
skills. In terms of footprint, the IDN library can be a problem e.g.
on mobile phones, but should not be an issue on bigger systems.
I have done 3) for Amaya, and it was really no big deal.

I'd be glad to work with any project implementing Atom to help them
do IRIs; in my experience, such things go extremely easily if you
put have two people work together, one familliar with the existing
code and the other familliar with the addition being made.

I'd also be very glad to help with tests; Mark, if you can send
me a very simple example of an Atom feed with a few hrefs, and
the documents it points to, I can convert that to an example using
IRIs, and make sure the documents are correctly hosted so that
the tests are not affected by side-effects.


>After
>reading all three specs (RFC 2396, RFC 2396bis, and the IRI draft), I
>am not entirely sure what their relationship is.

I hope that my mail to Tim explains this well enough. If not,
I'm glad to try again.


>RFC 2396bis appears
>to obsolete RFC 2396, and IRIs appear to "have a dependency on RFC
>2396bis" [5].

IRIs not only appear to have a dependency on 2396bis (which is not
an RFC, and if and when it becomes an RFC, it will have a new number),
they actually have a dependency on 2396bis. The IRI syntax parallels
the URI syntax, and it was simply thought a bad idea to leave out
all the fixes to the URI spec from the IRI spec.

Regards,    Martin.


>Currently Atom mandates RFC 2396 only.  I do not see
>any discussion of this on the Atom wiki [6], and only one passing
>mention of it in the list archives. [7]
>
>Could someone with more experience shed some light on this situation?
>
>[1] http://www.mnot.net/drafts/draft-nottingham-atom-format-02.html
>[2] http://www.ietf.org/rfc/rfc2396.txt
>[3] http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html
>[4] http://www.w3.org/International/iri-edit/draft-duerst-iri.html
>[5] 
>http://lists.w3.org/Archives/Public/public-webarch-comments/2004Feb/0001.html
>[6] http://intertwingly.net/wiki/pie/UniversalResourceIdentifier
>[7] http://www.imc.org/atom-syntax/mail-archive/msg02941.html
>
>--
>Cheers,
>-Mark



From owner-atom-syntax@mail.imc.org  Wed Jul  7 23:00: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 XAA07239
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 23:00: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 i682lpsP085362;
	Wed, 7 Jul 2004 19:47: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 i682lpTh085361;
	Wed, 7 Jul 2004 19:47: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 i682loYK085354
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 19:47:50 -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 1BiOx0-0006tu-ER; Thu, 08 Jul 2004 02:47:54 +0000
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Wed, 07 Jul 2004 22:47:59 -0400
Subject: Re: PaceEntryOrigin
From: Robert Sayre <mint@franklinmint.fm>
To: Eric Scheid <eric.scheid@ironclad.net.au>,
        Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD122E1F.11FD2%mint@franklinmint.fm>
In-Reply-To: <BD12DAEC.1DF57%eric.scheid@ironclad.net.au>
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: <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 7/7/04 9:05 PM, "Eric Scheid" <eric.scheid@ironclad.net.au> wrote:

> 
> Perhaps what is needed is spec text along the lines of "an Atom aggregator
> MAY ignore links with @rel values it does not recognise". That, combined
> with PaceLinkPurpose to limit use of <link> to user-actionable links
> retrieved via GET would just about cover it, no?
> 

No, it really doesn't. There have been numerous technical objections to
<link>, and none of them have been adequately addressed, IMO.

I can't think of a single technical reason to use <link>. Everything
argument for it is aesthetic or social. Furthermore, it is usually the same
3 or 4 vociferous people that defend it on those grounds.


On 7/7/04 7:02 PM, "Graham" <dtcd@mac.com> wrote:

>
> None of the above. Ditch the way rel is currently expressed, such that:
> 
> <link rel="XXX" href="a" title="b" type="c" />
> becomes:
> <XXX href="a" title="b" type="c">
>

Graham's suggestion would seem to be superior in every respect.

Robert Sayre



From owner-atom-syntax@mail.imc.org  Wed Jul  7 23:02: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 XAA07325
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 23:02: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 i682h4em085028;
	Wed, 7 Jul 2004 19: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 i682h484085027;
	Wed, 7 Jul 2004 19:43:04 -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 i682h4CZ085020
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 19:43:04 -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 98DD04F05B;
	Wed,  7 Jul 2004 22:43:08 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040708094546.05e2e650@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Thu, 08 Jul 2004 10:42:08 +0900
To: Tim Bray <Tim.Bray@Sun.COM>, Mark Pilgrim <pilgrim@gmail.com>
From: Martin Duerst <duerst@w3.org>
Subject: Re: IRIs, URIs, and RFC 2396bis
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <14670C09-D046-11D8-B2D0-000A95A51C9E@sun.com>
References: <14be96d3040707103826ba6c34@mail.gmail.com>
 <14be96d3040707103826ba6c34@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>


Hello Tim, others,

At 11:47 04/07/07 -0700, Tim Bray wrote:

>On Jul 7, 2004, at 10:38 AM, Mark Pilgrim wrote:
>
>>The Atom 0.3 draft [1] states that "Link constructs MUST have a href
>>attribute, whose value MUST be a URI [RFC2396]" [2].  Should this be
>>changed to "whose value MUST be a URI, as defined by RFC2396 or its
>>successor," so that Atom can benefit from RFC2396bis? [3]
>
>+1. 2396bis is very nearly finished, not controversial as far as I know, 
>and immensely better than "2396 Classic".

I agree. The main problem is timing, but the list of issues that the
Atom spec has to go through and agree is vastly longer than the issue
remaining to be resolved for 2396bis, so I don't think this is an issue.


>>Alternatively, we could state "whose value MUST be an IRI" [4].
>
>Less cooked,

I'm very surprised to hear this! It is correct to say that the
IRI spec is less cooked than the URI spec, but the cooking of
the IRI spec started around 1997, so I don't really think 'not
enough cooking' is a valid argument. Also, the IRI spec has been
submitted to the IESG for further processing and approval after
a successful 2-week mailing list last call. Of course, this does
not guarantee that the IESG will approve the IRI spec, and there
is no guarantee when it will be published as an RFC, but the same
(and more) can easily be said for Atom at this point in time.


>more controversial,

Given that Opera, Safari, and Mozilla actually implement IRIs,
and that IE implements the parts it was able to implement when it
was put out,..., and given that the XML spec specifies what amounts
to IRIs (but wasn't called IRI at the time the XML spec was baked)
for system identifiers, and specs such as XLink and XML Schema
do the same, I'm not really sure what the big 'controversy' is
all about. Also, given that it took about 1 (read 'one') test case
to for example get Opera and Mozilla on the right track, and given
that I have never received any serious questions or comments regarding
the spec from actual implementers (as opposed to people just reading
the spec).


>I'd be nervous about this.

Would some test cases be able to reduce this nervousness?


>>   After
>>reading all three specs (RFC 2396, RFC 2396bis, and the IRI draft), I
>>am not entirely sure what their relationship is.
>
>You are *not* the only one.

Okay. Maybe the following helps:

- RFC 2396bis is an update to RFC 2396, mostly finished, but still
   with one known open issue.

- The IRI spec defines IRIs as different from, but related, to URIs.
   IRIs can contain non-ASCII characters, URIs can't.
   IRIs can be used as *protocol elements* (see e.g. the list of XML
   specs above, and that's what Atom would do), or they can be used
   as *presentation elements* (e.g. if you type an URI with a long
   sequence of %-escapes into some browsers such as Opera, it will
   convert this for you in the location/address bar to meaningful
   non-ASCII characters if this is possible according to the IRI spec).

Please feel free to ask actual technical questions (rather than
just throwing non-technical conjectures into the air), or to
comment on the IRI spec (preferably copying public-iri@w3.org
if you think something in the IRI spec needs improvement).


Regards,    Martin.



From owner-atom-syntax@mail.imc.org  Wed Jul  7 23:24: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 XAA08477
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 23:24: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 i683C07H087079;
	Wed, 7 Jul 2004 20:12: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 i683C0wG087078;
	Wed, 7 Jul 2004 20:12:00 -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 i683C0FC087066
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 20:12:00 -0700 (PDT)
	(envelope-from distobj@acm.org)
Received: from mbaker by bork.markbaker.ca with local (Exim 3.35 #1 (Debian))
	id 1BiPKp-0006SX-00; Wed, 07 Jul 2004 23:12:31 -0400
Date: Wed, 7 Jul 2004 23:12:31 -0400
To: Mark Pilgrim <pilgrim@gmail.com>
Cc: Atom Syntax <atom-syntax@imc.org>
Subject: Re: IRIs, URIs, and RFC 2396bis
Message-ID: <20040708031231.GL30868@markbaker.ca>
References: <14be96d3040707103826ba6c34@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <14be96d3040707103826ba6c34@mail.gmail.com>
User-Agent: Mutt/1.3.28i
From: Mark Baker <distobj@acm.org>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


On Wed, Jul 07, 2004 at 01:38:50PM -0400, Mark Pilgrim wrote:
> Should this be
> changed to "whose value MUST be a URI, as defined by RFC2396 or its
> successor," so that Atom can benefit from RFC2396bis? [3]

It's my understanding that "or its successor" is implied in RFCs.
That is, when one RFC obsoletes another, all references to the
obsoleted RFC are considered to be updated.

2026 doesn't say, but I'm sure I've heard that on at least a couple
of occasions.  Paul?

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

  Seeking work on large scale application/data integration projects
  and/or the enabling infrastructure for same.



From owner-atom-syntax@mail.imc.org  Wed Jul  7 23:26:04 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08561
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 23:26:03 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i683IA3l087555;
	Wed, 7 Jul 2004 20:18: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 i683IAvV087554;
	Wed, 7 Jul 2004 20:18:10 -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 i683IAni087546
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 20:18:10 -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 UAA10106
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 20:18:11 -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 UAA20449
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 20:18:11 -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); Wed, 07 Jul 2004 20:18:11 -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 <0I0I00BETJU9WD@shazam.verity.com> for atom-syntax@imc.org; Wed,
 07 Jul 2004 20:18:10 -0700 (PDT)
Date: Wed, 07 Jul 2004 20:18:10 -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: New AtomPubIssuesList for 2004/07/07
In-reply-to: <40EC9915.4050406@intertwingly.net>
To: atom-syntax <atom-syntax@imc.org>
Message-id: 
 <6722BB3613E347863AE55786@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
MIME-version: 1.0
X-Mailer: Mulberry/3.1.5 (Mac OS X)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <40E16215.6070507@intertwingly.net>
 <40EC9915.4050406@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 Wednesday, July 7, 2004 8:45 PM -0400 Sam Ruby <rubys@intertwingly.net> wrote:
>
> PaceInterop, PaceContentTypeHandling, PaceXmlValidity,
> ErrorReportingMechanism all have been withdrawn by their respective authors without an objection noted on the mailing list.  Unless somebody objects, these will proceed to closure.

I think that PaceInterop is very useful and should continue.

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Wed Jul  7 23: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 XAA08602
	for <atompub-archive@lists.ietf.org>; Wed, 7 Jul 2004 23: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 i683HC66087506;
	Wed, 7 Jul 2004 20: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 i683HC6H087505;
	Wed, 7 Jul 2004 20:17:12 -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 i683HBCo087497
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 20:17:11 -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 UAA09973
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 20:17:13 -0700 (PDT)
Received: from mx-rr.verity.com (mx-rr.verity.com [10.3.100.59])
	by mx-rr.verity.com (8.9.3/8.9.3) with SMTP id UAA20378
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 20:17:12 -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); Wed, 07 Jul 2004 20:17:12 -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 <0I0I00BEQJSMWD@shazam.verity.com> for atom-syntax@imc.org; Wed,
 07 Jul 2004 20:17:12 -0700 (PDT)
Date: Wed, 07 Jul 2004 20:17: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: IRIs, URIs, and RFC 2396bis
In-reply-to: <4.2.0.58.J.20040708094546.05e2e650@localhost>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: 
 <1D5C6B6BB1642D1334DCF72C@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
MIME-version: 1.0
X-Mailer: Mulberry/3.1.5 (Mac OS X)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <14be96d3040707103826ba6c34@mail.gmail.com>
 <14be96d3040707103826ba6c34@mail.gmail.com>
 <4.2.0.58.J.20040708094546.05e2e650@localhost>
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 don't agree with "2396 or its successor", because that means
the Atom spec changes when other specs change. What happens
when "2396ter" comes out?

We should specify "2396bis" and update the references when the
that spec is ready.

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Thu Jul  8 00:08: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 AAA10718
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 00:08: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 i683pnoO090425;
	Wed, 7 Jul 2004 20:51: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 i683pnYM090424;
	Wed, 7 Jul 2004 20:51: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 i683plJL090415
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 20:51:49 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 22047 messnum 9207914 invoked from network[83.70.35.17/83-70-35-17.bas2.prp.dublin.eircom.net]); 8 Jul 2004 03:51:48 -0000
Received: from 83-70-35-17.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.35.17)
  by mail10.svc.cra.dublin.eircom.net (qp 22047) with SMTP; 8 Jul 2004 03:51:48 -0000
Message-ID: <40ECC4D1.3010003@dehora.net>
Date: Thu, 08 Jul 2004 04:51:45 +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: New AtomPubIssuesList for 2004/07/07
References: <40E16215.6070507@intertwingly.net> <40EC9915.4050406@intertwingly.net>
In-Reply-To: <40EC9915.4050406@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:


> PaceInterop, PaceContentTypeHandling, PaceXmlValidity,
> ErrorReportingMechanism all have been withdrawn by their respective 
> authors without an objection noted on the mailing list.  Unless somebody 
> objects, these will proceed to closure.

Please consider adding PacePutIpAddrInEntry to that list.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Thu Jul  8 00:24: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 AAA11415
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 00:24: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 i684D8CR092677;
	Wed, 7 Jul 2004 21:13: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 i684D8rL092676;
	Wed, 7 Jul 2004 21:13:08 -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 i684D7WK092668
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 21:13:07 -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 i684DdAo008913;
	Thu, 8 Jul 2004 00:13:40 -0400
Message-ID: <40ECC9D1.1070707@intertwingly.net>
Date: Thu, 08 Jul 2004 00:13:05 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>
CC: atom-syntax <atom-syntax@imc.org>
Subject: Re: New AtomPubIssuesList for 2004/07/07
References: <40E16215.6070507@intertwingly.net> <40EC9915.4050406@intertwingly.net> <40ECC4D1.3010003@dehora.net>
In-Reply-To: <40ECC4D1.3010003@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:

> Sam Ruby wrote:
> 
>> PaceInterop, PaceContentTypeHandling, PaceXmlValidity,
>> ErrorReportingMechanism all have been withdrawn by their respective 
>> authors without an objection noted on the mailing list.  Unless 
>> somebody objects, these will proceed to closure.
> 
> Please consider adding PacePutIpAddrInEntry to that list.

My mistake:

http://www.imc.org/atom-syntax/mail-archive/msg06028.html

I've added it to the list.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Thu Jul  8 00: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 AAA11475
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 00:28: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 i6844hTA091248;
	Wed, 7 Jul 2004 21:04:43 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6844hpR091247;
	Wed, 7 Jul 2004 21:04:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6844dfm091183
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 21:04:42 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 8 Jul 2004 14:09:11 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Thu, 08 Jul 2004 14:04:08 +1000
Subject: Re: PaceEntryOrigin
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD1304D8.1DFE1%eric.scheid@ironclad.net.au>
In-Reply-To: <BD122E1F.11FD2%mint@franklinmint.fm>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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 8/7/04 12:47 PM, "Robert Sayre" <mint@franklinmint.fm> wrote:

>> On 7/7/04 9:05 PM, "Eric Scheid" <eric.scheid@ironclad.net.au> wrote:

>[various opinions]

I'm taking this thread off list for now since it isn't in AtomPubIssuesList

My apologies for the noise.

e.



From owner-atom-syntax@mail.imc.org  Thu Jul  8 00:41:58 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12087
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 00:41: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 i684NdrO093479;
	Wed, 7 Jul 2004 21:23: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 i684NduE093478;
	Wed, 7 Jul 2004 21:23:39 -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 i684NckP093472
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 21:23:38 -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 i684Njil026725
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 22:23:45 -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 <0I0I000WWMVLGE@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Wed, 07 Jul 2004 22:23:45 -0600 (MDT)
Received: from [192.168.1.100] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0I00FNLMVK46@mail.sun.net> for atom-syntax@imc.org; Wed,
 07 Jul 2004 22:23:45 -0600 (MDT)
Date: Wed, 07 Jul 2004 21:23:41 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: PaceElementOrder
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <97774BF0-D096-11D8-B2D0-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: <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 propose a modification to this Pace 
(http://www.intertwingly.net/wiki/pie/PaceElementOrder).  I don't know 
what the right section number is in the about-to-appear -00 drafts, but 
I'd like language like this:

  The child elements of <atom:feed> may appear in any order, subject 
only to
  the constraint that the the <atom:entry> children appear in a group 
after all
  other child elements.  That is to say, the "feed-level" elements must 
all
  appear before the first <atom:entry> element.  The order in which the
  child elements of <atom:feed> appear is not considered significant.

It's also been proposed that we consider imposing a *strict* ordering, 
something like
title/author/copyright/dates/.../entries.  It might simplify some 
software tasks, I could go either way on that.

But I think forcing the <entry> children to the end is just good 
practice, because a feed parser that wants to do anything to an 
<atom:entry> involving any of the feed-level metadata can be built 
using a stream interface; otherwise loading the whole thing into a DOM 
or equivalent will be necessary. -Tim



From owner-atom-syntax@mail.imc.org  Thu Jul  8 01:21: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 BAA13941
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 01:21: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 i684wqeb095554;
	Wed, 7 Jul 2004 21: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 i684wqa2095553;
	Wed, 7 Jul 2004 21:58:52 -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 i684wqZr095543
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 21:58: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 (rwcrmhc11) with SMTP
          id <20040708045853013008i4gse>; Thu, 8 Jul 2004 04:58:53 +0000
Date: Wed, 7 Jul 2004 22:58:51 -0600
Subject: Re: PaceLinkPurpose
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: <BD12DAEC.1DF57%eric.scheid@ironclad.net.au>
Message-Id: <817B4C06-D09B-11D8-871D-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


I'm warming somewhat (but not entirely convinced yet) to the idea of 
having a number of elements that are Link Constructs rather than 
putting everything into <link>. I'd still be in favor of 
PaceLinkPurpose to tighten the purpose of Link Constructs, even if the 
<link> element goes away.

On Wednesday, July 7, 2004, at 07:05  PM, Eric Scheid wrote:
> That, combined
> with PaceLinkPurpose to limit use of <link> to user-actionable links
> retrieved via GET would just about cover it, no?

Some nice wording in here, which I've used or adapted to improve 
PaceLinkPurpose, getting rid of the word "clickable", among other 
things. Here's the changed text:

3.4 Link Constructs
A Link construct specifies a hyperlink primarily intended to be 
activated through explicit user interactions such as clicking, 
selecting a menu item, drag and drop, etc. The resource pointed to by 
the href attribute MUST be accessed using the GET method.


One other change made to PaceLinkPurpose was to add a "Key Questions" 
section which I believe addresses the main arguments I've heard on this 
topic. The idea behind question #2 is largely responsible for my 
warming to abolishing the <link> element. If we have an easy, 
foolproof, in the spec way of identifying a Link Construct, and know 
that we can handle ANY Link Construct in a generic way if we don't 
understand it specifically, one of the major advantages of <link 
@rel="?" /> (as altered by PaceLinkPurpose, ie. extensibility) 
disappears.

The "Key Questions" are:

    1. Do we want an extensible linking mechanism to enable software 
agents that don't understand the extension to be able to render 
extended links without the risk of rendering them in a manner 
inconsistent with their purpose?
    2. Are there preferable methods for specifying an extensible linking 
mechanism? (For example, could we say that any element with an href 
attribute MUST be a Link Construct, with all the specified attributes 
for Link Constructs, which could be rendered as a user-activatable link 
to be loaded using GET, and which does not require understanding of any 
additional attributes in order to process it in an acceptable way?)
    3. Are we satisfied with <link> as it is, with a closed list of @rel 
values?
    4. Do we want a multiplicity of Link Constructs, or one <link> 
element whose @rel (ore @rev) attribute determines what it is?



From owner-atom-syntax@mail.imc.org  Thu Jul  8 02:43: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 CAA02014
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 02:43: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 i686YNve037828;
	Wed, 7 Jul 2004 23:34: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 i686YNwo037827;
	Wed, 7 Jul 2004 23:34: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 (imap.gmx.net [213.165.64.20])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i686YLPn037783
	for <atom-syntax@imc.org>; Wed, 7 Jul 2004 23:34:21 -0700 (PDT)
	(envelope-from julian.reschke@gmx.de)
Received: (qmail 19271 invoked by uid 65534); 8 Jul 2004 06:34:14 -0000
Received: from pD9E51CFC.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.28.252)
  by mail.gmx.net (mp001) with SMTP; 08 Jul 2004 08:34:14 +0200
X-Authenticated: #1915285
Message-ID: <40ECEAE2.8030305@gmx.de>
Date: Thu, 08 Jul 2004 08:34:10 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mark Baker <distobj@acm.org>
CC: Mark Pilgrim <pilgrim@gmail.com>, Atom Syntax <atom-syntax@imc.org>
Subject: Re: IRIs, URIs, and RFC 2396bis
References: <14be96d3040707103826ba6c34@mail.gmail.com> <20040708031231.GL30868@markbaker.ca>
In-Reply-To: <20040708031231.GL30868@markbaker.ca>
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


Mark Baker wrote:

> It's my understanding that "or its successor" is implied in RFCs.
> That is, when one RFC obsoletes another, all references to the
> obsoleted RFC are considered to be updated.
> 
> 2026 doesn't say, but I'm sure I've heard that on at least a couple
> of occasions.  Paul?

I've heard that as well; but it would be nice if somebody could clarify. 
  For instance, if RFCxx refers to a specific feature of RFCyy, and that 
feature gets dropped in RFCyy-bis, what does this mean?

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From owner-atom-syntax@mail.imc.org  Thu Jul  8 03:30:43 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03988
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 03:30: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 i687KwNh055782;
	Thu, 8 Jul 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 i687Kw9V055781;
	Thu, 8 Jul 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 homer.w3.org (homer.w3.org [18.29.0.30])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i687KwIK055771
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 00:20:58 -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 D32A54EEC5;
	Thu,  8 Jul 2004 03:20:56 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040708150825.05af4ae0@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Thu, 08 Jul 2004 15:23:44 +0900
To: Mark Pilgrim <pilgrim@gmail.com>, Atom Syntax <atom-syntax@imc.org>
From: Martin Duerst <duerst@w3.org>
Subject: Re: PaceUriOrItsSuccessor
In-Reply-To: <14be96d304070717323dd139a@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>


Hello Mark,

At 20:32 04/07/07 -0400, Mark Pilgrim wrote:

>http://intertwingly.net/wiki/pie/PaceUriOrItsSuccessor
>
>== Abstract ==
>
>[MarkPilgrim] Make all references to RFC 2396 into "RFC 2396 or its
>successor" so that when RFC 2396bis is done, Atom can inherit it
>without revving the spec.
>
>== Status ==
>
>Open
>
>== Rationale ==
>
>RFC 2396bis adds internationalization support to URIs.

I'm somewhat surprised by this statement. I have changed it
to "RFC 2396bis slightly improves internationalization support for URIs."
2396bis is somewhat clearer than 2396 that using UTF-8 for encoding
character into octets is a good thing. It also contains a new section
explaining encoding issues in much more detail. If you want real
internationalization, you need IRIs.

I also added some of the points listed by Tim, except for his
last one, "Plus the discussion of what a resource is is less mystical.",
because the exact definition of 'resource' is still under discussion,
and the result may be in the eye of the beholder (not that it matters
in any way for implementations).


>It will become
>the new standard for URIs very shortly after its release

I don't understand "very shortly after it's release".
How shortly? One week? One month? I just removed  that
phrase, but please feel free to put it back if you can
explain it.


Is the intent of this Pace just to settle between 2396 and 2396bis,
or does it also take a position on whether to use IRIs or not?
If yes, that would just be implicit; I think it should be explicit.

Regards,    Martin.

>(it is
>already the de facto standard in modern browsers).  Atom should plan
>for its arrival by referencing "RFC 2396 or its successor" to define
>URIs.
>
>== Proposal ==
>
>In section 3.2.2, change "The content of atom:url in a Person
>construct MUST be a  URI [RFC2396]." to "The content of atom:url in a
>Person construct MUST be a  URI [RFC2396 or its successor]."
>
>In section 3.4.3, change "Link constructs MUST have a href attribute,
>whose value MUST be a URI [RFC2396]." to "Link constructs MUST have a
>href attribute, whose value MUST be a URI [RFC2396 or its successor]."
>
>In section 4.8, change "The content of this element, when present,
>MUST be a URI." to "The content of this element, when present, MUST be
>a URI [RFC2396 or its successor]."
>
>In section 4.9, change "The atom:generator element MAY have a "url"
>attribute whose value MUST be a URI" to "The atom:generator element
>MAY have a "url"  attribute whose value MUST be a URI [RFC 2396 or its
>successor]"
>
>== Impacts ==
>
>Unknown (FIXME)
>
>== Notes ==
>
>
>----
>
>CategoryProposals
>
>--
>Cheers,
>-Mark



From owner-atom-syntax@mail.imc.org  Thu Jul  8 03:35: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 DAA04156
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 03:35: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 i687L1sI055819;
	Thu, 8 Jul 2004 00: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 i687L13A055818;
	Thu, 8 Jul 2004 00:21:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from homer.w3.org (homer.w3.org [18.29.0.30])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i687L0f3055797
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 00:21:00 -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 1CAB94EEC5;
	Thu,  8 Jul 2004 03:20:58 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040708152409.022ccc78@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Thu, 08 Jul 2004 15:26:26 +0900
To: Mark Pilgrim <pilgrim@gmail.com>, Tim Bray <tim.bray@sun.com>
From: Martin Duerst <duerst@w3.org>
Subject: Re: PaceUriOrItsSuccessor
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <14be96d3040707183525233978@mail.gmail.com>
References: <BA632E7C-D078-11D8-B2D0-000A95A51C9E@sun.com>
 <14be96d304070717323dd139a@mail.gmail.com>
 <BA632E7C-D078-11D8-B2D0-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>


At 21:35 04/07/07 -0400, Mark Pilgrim wrote:

>On Wed, 07 Jul 2004 17:49:54 -0700, Tim Bray <tim.bray@sun.com> wrote:
> > +1, but the rationale could be strengthened by pointing out that
> > 2396bis has *many* improvements;
>
>Perhaps someone more experienced could explain what they are, besides i18n.
>
> >  and we only need to change the
> > referent of [2396] in the References section, right?  No need for
> > changes in multiple places in the text. -Tim
>
>OK, if that's how these things work.

Well, having [2396] in the text, but this then being something different
in the reference section isn't really nice to the reader.

The way to do it that I have been told by a friendly Area Director is
to use something like [RFC XXXX], with instructions to the RFC editor
to fix things up when they know the number. That's also, as far as
I understand, the way to do references between specs that will move
to RFC together.

Regards,    Martin.



From owner-atom-syntax@mail.imc.org  Thu Jul  8 06:27: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 GAA11450
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 06:27: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 i68AA4BR024570;
	Thu, 8 Jul 2004 03:10: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 i68AA4UX024551;
	Thu, 8 Jul 2004 03:10:04 -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 i68A9xLO024350
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 03:10: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 174217C12B; Thu,  8 Jul 2004 13:08:50 +0200 (CEST)
To: "Graham Parks" <dtcd@mac.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Q: modfied vs issued vs created
References: <14543268.1088887310064.JavaMail.dtcd@mac.com>
Message-ID: <opsatdbjsxuvpchu@quark>
Date: Thu, 08 Jul 2004 12:12:45 +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: <14543268.1088887310064.JavaMail.dtcd@mac.com>
User-Agent: Opera M2/7.51 (Win32, build 3798)
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, 03 Jul 2004 21:41:50 +0100, Graham Parks <dtcd@mac.com> wrote:

> You're talking as if PaceEntryDates removes the <created> field.

No, not really. I'm more talking of that it's important that if <issued>  
is going to exist as an alternative for <created>, then <issued> MUST  
NEVER be updated, changed or fiddled with after it's first set.

> As I said before, issuing is the only event that all systems will
> have in common, and is therefore the only date that can be mandatory.

True, but I don't think it's a good idea to not only allow, but to  
encourage, publishers to update this field whenever they reissue the  
article. If so, we should have both <first-issued> and <last-issued>  
elements.

-- 
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 Jul  8 06:31:46 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11697
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 06:31:46 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i68AIfZN026090;
	Thu, 8 Jul 2004 03: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 i68AIfTb026089;
	Thu, 8 Jul 2004 03:18:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i68AIenV026080
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 03:18:40 -0700 (PDT)
	(envelope-from asbjorn@tigerstaden.no)
Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19])
	by smtpgateway.itweb.no (Postfix) with ESMTP
	id 5814A7C12E; Thu,  8 Jul 2004 13:17:36 +0200 (CEST)
To: "Mark Pilgrim" <pilgrim@gmail.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceUriOrItsSuccessor
References: <14be96d304070717323dd139a@mail.gmail.com>
Message-ID: <opsatdp9k4uvpchu@quark>
Date: Thu, 08 Jul 2004 12:21:35 +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: <14be96d304070717323dd139a@mail.gmail.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Wed, 7 Jul 2004 20:32:32 -0400, Mark Pilgrim <pilgrim@gmail.com> wrote:

> [MarkPilgrim] Make all references to RFC 2396 into "RFC 2396 or its
> successor" so that when RFC 2396bis is done, Atom can inherit it
> without revving the spec.

+1. I agree with Tim that the rationale probably should say more about why  
2396bis is better than 2396, but I'm not one of those who know the details  
of either of the RFC's, unfortunately.

-- 
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 Jul  8 07:20: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 HAA13968
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 07:20: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 i68B9FnZ030289;
	Thu, 8 Jul 2004 04:09: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 i68B9FfE030288;
	Thu, 8 Jul 2004 04:09:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i68B9EXi030279
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 04:09:14 -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 8A1867C119
	for <atom-syntax@imc.org>; Thu,  8 Jul 2004 14:08:10 +0200 (CEST)
Date: Thu, 08 Jul 2004 13:12:22 +0200
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Atom terminology
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: <opsatf2wh3uvpchu@quark>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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've created AtomTerminology[1]. This page is not yet something we can  
squeeze into the specification, but it would be nice to have it in the  
specification if it gets thorough enough. Anyway, if we get the  
definitions down, it would be a good way to know what everyone is talking  
about when they're flinging out all kinds of words and phrases related to  
syndication and aggregation.

I hope that there are others on this list that might be interested in  
helping me write it up, because it is something not only the specification  
could have use for, but us. Now. Other specifications[2] has terminology  
definitions, so it wouldn't hurt if Atom had one as well. But initially, I  
see the page as clarifying for us when discussing Atom.

____
[1] <url: http://intertwingly.net/wiki/pie/AtomTerminology>
[2] <url:  
http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part1.html#terminology>

-- 
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 Jul  8 08:49: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 IAA17871
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 08:49: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 i68CbSPq036938;
	Thu, 8 Jul 2004 05:37: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 i68CbSAt036937;
	Thu, 8 Jul 2004 05:37: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.192])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i68CbRLW036930
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 05:37:27 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d19so135681rnf
        for <atom-syntax@imc.org>; Thu, 08 Jul 2004 05:37:17 -0700 (PDT)
Received: by 10.38.71.16 with SMTP id t16mr211086rna;
        Thu, 08 Jul 2004 05:37:17 -0700 (PDT)
Message-ID: <14be96d304070805371d46387c@mail.gmail.com>
Date: Thu, 8 Jul 2004 08:37:17 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Martin Duerst <duerst@w3.org>
Subject: Re: PaceUriOrItsSuccessor
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <4.2.0.58.J.20040708150825.05af4ae0@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <4.2.0.58.J.20040708150825.05af4ae0@localhost>
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 Thu, 08 Jul 2004 15:23:44 +0900, Martin Duerst <duerst@w3.org> wrote:
> Is the intent of this Pace just to settle between 2396 and 2396bis,
> or does it also take a position on whether to use IRIs or not?
> If yes, that would just be implicit; I think it should be explicit.

The Pace was written yesterday after I got on-list feedback that all
seemed to be converging on the idea of supporting 2396bis to the
exclusion of IRIs.  Now we appear to be diverging from that consensus,
so perhaps the Pace was premature.

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Thu Jul  8 09: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 JAA18993
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 09: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 i68D2bvJ038705;
	Thu, 8 Jul 2004 06:02: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 i68D2b1l038704;
	Thu, 8 Jul 2004 06:02:37 -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 i68D2aue038696
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 06:02:36 -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 i68D32WC001362;
	Thu, 8 Jul 2004 09:03:02 -0400
Message-ID: <40ED45E2.7080004@intertwingly.net>
Date: Thu, 08 Jul 2004 09:02:26 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 Pilgrim <pilgrim@gmail.com>
CC: Martin Duerst <duerst@w3.org>, Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceUriOrItsSuccessor
References: <4.2.0.58.J.20040708150825.05af4ae0@localhost> <14be96d304070805371d46387c@mail.gmail.com>
In-Reply-To: <14be96d304070805371d46387c@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


Mark Pilgrim wrote:

> On Thu, 08 Jul 2004 15:23:44 +0900, Martin Duerst <duerst@w3.org> wrote:
> 
>>Is the intent of this Pace just to settle between 2396 and 2396bis,
>>or does it also take a position on whether to use IRIs or not?
>>If yes, that would just be implicit; I think it should be explicit.
> 
> The Pace was written yesterday after I got on-list feedback that all
> seemed to be converging on the idea of supporting 2396bis to the
> exclusion of IRIs.  Now we appear to be diverging from that consensus,
> so perhaps the Pace was premature.

Suggestion on how to proceed: perhaps Martin or somebody else could 
write up a PaceIri which would contain the precise wording that should 
be included in the Atom spec in anticipation of a future completed IRI 
specification.

This would help in the identification of the specific differences which 
could then be explored.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Thu Jul  8 10:17: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 KAA23841
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 10:16: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 i68E56Gh043459;
	Thu, 8 Jul 2004 07:05: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 i68E56B0043458;
	Thu, 8 Jul 2004 07:05:06 -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 i68E56aL043444
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 07:05: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 (rwcrmhc11) with SMTP
          id <20040708140501013008jrcae>; Thu, 8 Jul 2004 14:05:01 +0000
Date: Thu, 8 Jul 2004 08:05:00 -0600
Subject: Re: PaceLinkPurpose
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: <817B4C06-D09B-11D8-871D-003065EA6144@geckotribe.com>
Message-Id: <CD113255-D0E7-11D8-879F-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 Wednesday, July 7, 2004, at 10:58  PM, Antone Roundy wrote:
> The resource pointed to by the href attribute MUST be accessed using 
> the GET method.
Eric pointed out to me that requiring GET would exclude non-HTTP 
access, so I've changed this sentence to "When accessing the resource 
pointed to by the href attribute using HTTP, the GET method MUST be 
used."

> If we have an easy, foolproof, in the spec way of identifying a Link 
> Construct, and know that we can handle ANY Link Construct in a generic 
> way if we don't understand it specifically, one of the major 
> advantages of <link @rel="?" /> (as altered by PaceLinkPurpose, ie. 
> extensibility) disappears.
Perhaps I should have said that one of the major advantages is 
lessened--it WOULD be more difficult to find Link Constructs that one 
didn't fully understand than to find <link> types that one didn't fully 
understand, because the one would require looking at all elements, and 
the other would only require looking at all <link> elements.  Still, 
that's something I think I could live with.

One other change that occurs to me might make abolishing <link> more 
palatable would be if the spec[1] were to group the elements that are 
Link Constructs under a common heading--for example, if section 4.4 
were to be changed from '"atom:link" Element' to  "Link Constructs", 
and have '4.4.1 "atom:start" Element', '4.4.2 "atom:next" Element', 
etc. added underneath it (as opposed to '4.4 "atom:start" Element', 
'4.5 "atom:next" Element', etc.).  The same could be done at 4.13.2, 
and also for date and content constructs.  One of the objections that 
has been raised to abolishing <link> is that it results in a large 
number of elements, which LOOKS more daunting than less elements with 
more options for each.  Grouping similar elements wouldn't shorten the 
list, but by organizing it, would make it more approachable.

[1] http://www.mnot.net/drafts/draft-nottingham-atom-format-02.html -- 
the link, for your convenience



From owner-atom-syntax@mail.imc.org  Thu Jul  8 10:29:36 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26390
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 10:29:35 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i68EEO4t044096;
	Thu, 8 Jul 2004 07:14: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 i68EEOTA044095;
	Thu, 8 Jul 2004 07:14:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web41502.mail.yahoo.com (web41502.mail.yahoo.com [66.218.93.85])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i68EEOvp044018
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 07:14:24 -0700 (PDT)
	(envelope-from randymorin@yahoo.com)
Message-ID: <20040708141421.36970.qmail@web41502.mail.yahoo.com>
Received: from [66.46.139.106] by web41502.mail.yahoo.com via HTTP; Thu, 08 Jul 2004 07:14:21 PDT
Date: Thu, 8 Jul 2004 07:14:21 -0700 (PDT)
From: Randy Charles Morin <randymorin@yahoo.com>
Reply-To: randy@kbcafe.com
Subject: Re: Atom terminology 
To: Atomlist <atom-syntax@imc.org>
Cc: "Asbjørn_Ulsberg" <asbjorn@tigerstaden.no>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1816107248-1089296061=:36758"
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>


--0-1816107248-1089296061=:36758
Content-Type: text/plain; charset=us-ascii

Thanks, that's great work.
 
Randy
http://www.kbcafe.com
 

		
---------------------------------
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
--0-1816107248-1089296061=:36758
Content-Type: text/html; charset=us-ascii

<DIV>Thanks, that's great work.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Randy</DIV>
<DIV><A href="http://www.kbcafe.com">http://www.kbcafe.com</A></DIV>
<DIV>&nbsp;</DIV><p>
		<hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/mail_us/taglines/10/*http://promotions.yahoo.com/new_mail/static/efficiency.html">New and Improved Yahoo! Mail</a> - Send 10MB messages!
--0-1816107248-1089296061=:36758--



From owner-atom-syntax@mail.imc.org  Thu Jul  8 10:40: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 KAA27235
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 10:40: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 i68ET9VA045134;
	Thu, 8 Jul 2004 07:29:09 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i68ET9qJ045133;
	Thu, 8 Jul 2004 07:29:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web41506.mail.yahoo.com (web41506.mail.yahoo.com [66.218.93.89])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i68ET85p045123
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 07:29:08 -0700 (PDT)
	(envelope-from randymorin@yahoo.com)
Message-ID: <20040708142906.30607.qmail@web41506.mail.yahoo.com>
Received: from [66.46.139.106] by web41506.mail.yahoo.com via HTTP; Thu, 08 Jul 2004 07:29:06 PDT
Date: Thu, 8 Jul 2004 07:29:06 -0700 (PDT)
From: Randy Charles Morin <randymorin@yahoo.com>
Reply-To: randy@kbcafe.com
Subject: Re: PaceElementOrder 
To: tim.bray@sun.com, Atomlist <atom-syntax@imc.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-30846395-1089296946=:28974"
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>


--0-30846395-1089296946=:28974
Content-Type: text/plain; charset=us-ascii

As the resident "please order your XML" Dude, I would just like to second this movement. Just as an aside, this will help a bit in creating the Atom XSD, which is inherited by both the Atom WSDL 1.1 and WSDL 2.0. Full ordering would help immensely. The current WSDL does not respect http://www.intertwingly.net/wiki/pie/PaceElementOrder, but it's on my list of things TODO.
Thanks,
 
Randy
http://www.kbcafe.com
 

		
---------------------------------
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
--0-30846395-1089296946=:28974
Content-Type: text/html; charset=us-ascii

<DIV>As the resident "please order your XML"&nbsp;Dude, I would just like to second this movement. Just as an aside, this will help a bit in creating the Atom XSD, which is inherited by both the Atom WSDL 1.1 and WSDL 2.0. Full ordering would help immensely. The current WSDL does not respect <A href="http://www.intertwingly.net/wiki/pie/PaceElementOrder"><FONT face="Courier New">http://www.intertwingly.net/wiki/pie/PaceElementOrder</FONT></A>, but it's on my list of things TODO.</DIV>
<DIV>Thanks,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Randy</DIV>
<DIV><A href="http://www.kbcafe.com">http://www.kbcafe.com</A></DIV>
<DIV>&nbsp;</DIV><p>
		<hr size=1>Do you Yahoo!?<br>
Yahoo! Mail is new and improved - <a href="http://us.rd.yahoo.com/mail_us/taglines/new/*http://promotions.yahoo.com/new_mail">Check it out!</a>
--0-30846395-1089296946=:28974--



From owner-atom-syntax@mail.imc.org  Thu Jul  8 11: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 LAA01106
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 11:19: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 i68F9BR6047805;
	Thu, 8 Jul 2004 08:09:11 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i68F9BkO047804;
	Thu, 8 Jul 2004 08:09: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 i68F9AXd047793
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 08:09: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 1BiaWK-00042p-Gd; Thu, 08 Jul 2004 15:09:08 +0000
Message-ID: <40ED6392.2000107@franklinmint.fm>
Date: Thu, 08 Jul 2004 11:09:06 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Joe Gregorio <joe.gregorio@gmail.com>
CC: Sam Ruby <rubys@intertwingly.net>, atom-syntax <atom-syntax@imc.org>
Subject: Re: PaceSecurityServices
References: <40E16215.6070507@intertwingly.net> <40EC9915.4050406@intertwingly.net> <3f1451f504070718267c5526b4@mail.gmail.com>
In-Reply-To: <3f1451f504070718267c5526b4@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - web02.designerslab.net
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - franklinmint.fm
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


Joe Gregorio wrote:

>In the section on the AtomAPI:
>---------------------------------------------
>
>+1 on Digest and TLS
>
>I support referencing and strongly encouraging
>the use of standard authentication and 
>encryption mechanisms.
>
>  
>
+1

>-1 to WSSE
>
>  
>
...

>If we must create a new authentication mechanism
>than I would also like it to be a seperate RFC from the
>the AtomAPI, just as HTTP is broken into 
>RFC 2616 and 2617.
>  
>
I'm fine with accepting the Pace as is. If we want to make AuthForBob a 
seperate document, we can do that at any time. Saying it should go in a 
document that's not (yet) a deliverable resembles handwaving a little 
too closely for me. I'm not a big fan of WSSE, but it will be easy to 
replace that section with something else. Let's just get it in there for 
now.

There's also the section "Security Considerations"*//*/**/, which I 
generally agree with. I would rewrite it a bit to highlight the fact 
that all authentication is based on RFC 2617, it's just that we've added 
an extension authentication scheme (the RFC allows this).

Robert Sayre



From owner-atom-syntax@mail.imc.org  Thu Jul  8 11:23: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 LAA02053
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 11:23: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 i68F9XYw047837;
	Thu, 8 Jul 2004 08: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 i68F9XWN047836;
	Thu, 8 Jul 2004 08:09: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 i68F9WTt047830
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 08:09: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 i68F8g6i003548;
	Thu, 8 Jul 2004 11:08:43 -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 BHL93328 (AUTH bob@wyman.us);
	Thu, 8 Jul 2004 11:09:29 -0400 (EDT)
Message-Id: <200407081509.BHL93328@ms8.netsolmail.com>
Reply-To: <bob@wyman.us>
From: "Bob Wyman" <bob@wyman.us>
To: "'Ken MacLeod'" <ken@bitsko.slc.ut.us>, <atom-syntax@imc.org>
Subject: RE: PaceEntryOrigin, composite feeds and inheritance
Date: Thu, 8 Jul 2004 11:09: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
In-Reply-To: <m3n02bql8m.fsf@bitsko.slc.ut.us>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Thread-Index: AcRkl7FC/v6XVIpYTVKkwx7PA4d9NwAYWFew
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


Ken MacLeod proposes:
Creating <site/> and </author> elements which are peers to entries and are
referenced by the entries rather than inherited by them.
	Does this mean that a composite feed that contained entries from 30
different sites, written by 30 different authors, would have 30 <site/>
elements and 30 <author/> elements at the feed level which would then be
linked to the corresponding entries using URN's (the tags)?
	I think the RDF-folk would like this idea. It takes us away from
monolithic chunks of XML and moves us towards lots of little pieces that are
linked together in semantic networks... Of course, the RDF-folk would not be
happy with the syntax you propose.
	Ideas, and specifications, have a habit of evolving and morphing...
I can see in your proposal a number of fairly obvious and potentially
inevitable evolutions. My gut feel tells me that the URN's will evolve into
URI's, so that they can be used like URLs, and then into IRIs. The idea will
be that you shouldn't be forced to include the <site/> element in the feed
itself. People will want to be able to save bytes by making these things
resources that can be referenced externally from the feed itself. Then, when
we have <site/> objects on the web, we'll see arguments for expanding the
number and variety of elements that are in <site/> "documents." The "Site
Description Language" will be born and will provide for all sorts of
interesting data -- including links to WSDL files (i.e. UDDI like stuff),
etc. Site Description Documents will serve as "super DNS entries" that
eventually grow into the "Rich Site Description Language." A similar
evolution would occur with <author/> elements -- the "Rich Author
Description Language" isn't far away but would eventually be replaced by the
"Rich Person Description Language." In that case, we would have all sorts of
debates about alignment with FOAF and various bibliographic standards for
the description of authors and their relationships to organizations, other
authors, etc.
	While the scheme, after some evolution, would allow for some really
wonderful semantic analysis opportunities, it would increase the complexity
of handling feeds -- when parsing feeds, you would have to build separate
buffers for <site/>, <author/> and <entry/> elements so that you could
correlate them when necessary. If URI's are used and thus external
references were allowed, you'd have to build a cache of these elements in
order to reduce the network traffic involved in correlating them to entries
at processing time. That, of course, would introduce all the problems which
are related to currency of data. We'd need to introduce a "time-to-live"
element or attribute to ensure that people didn't rely on too-old instances
of the site or author data. A few other cache-control flags and attributes
would also serve us well...
	But, perhaps I exaggerate. It's an interesting proposal, but I think
one that would have to be very, very carefully considered before moving
forward.

		bob wyman




From owner-atom-syntax@mail.imc.org  Thu Jul  8 11:28: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 LAA02447
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 11:28: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 i68FLbdB048808;
	Thu, 8 Jul 2004 08:21: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 i68FLbL9048807;
	Thu, 8 Jul 2004 08:21:37 -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 i68FLboE048801
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 08:21:37 -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 i68FGDuo017856;
	Thu, 8 Jul 2004 11:16:13 -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 BHL98254 (AUTH bob@wyman.us);
	Thu, 8 Jul 2004 11:21:36 -0400 (EDT)
Message-Id: <200407081521.BHL98254@ms8.netsolmail.com>
Reply-To: <bob@wyman.us>
From: "Bob Wyman" <bob@wyman.us>
To: "'Mark Baker'" <distobj@acm.org>, "'Mark Pilgrim'" <pilgrim@gmail.com>
Cc: "'Atom Syntax'" <atom-syntax@imc.org>
Subject: RE: IRIs, URIs, and RFC 2396bis
Date: Thu, 8 Jul 2004 11:21:38 -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: <20040708031231.GL30868@markbaker.ca>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Thread-Index: AcRknB7wroL/1N9XQs+e0WJGeQXbBwAYkQDA
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 Baker wrote:
> It's my understanding that "or its successor" is implied in RFCs.
	This would not be a good policy. It would mean that any RFC that has
a dependency on another would have an indeterminate definition. The
maintainers of such a specification would have no ability to manage the
evolution of their specification since it could, in essence, by modified at
anytime by some other group. RFC's are immutable and version-free for a
reason -- a good one. Once you know the content and meaning of RFC-XXXX, you
can go to your grave knowing that it is now and ever more shall be the same.
	The "or its successor" language should be explicitly provided if
desired and then only in special cases. I think the language code case is,
in fact, one of the cases where we can assume that a link to "successors"
is, in fact, safe. In many other cases, such an open ended dependency would
be chaotic and would probably result in people begin forced to copy the
content of other specifications into their own rather than referencing the
other specs.

		bob wyman




From owner-atom-syntax@mail.imc.org  Thu Jul  8 12: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 MAA07494
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 12:32: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 i68GMTcg054817;
	Thu, 8 Jul 2004 09:22: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 i68GMTMi054816;
	Thu, 8 Jul 2004 09:22: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-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 i68GMSlM054769
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 09:22:28 -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 i68GKQ53021963
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 10:20:26 -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 <0I0J009Z7K5GAA@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Thu, 08 Jul 2004 10:22:29 -0600 (MDT)
Received: from [192.168.1.100] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0J00HP7K5GX3@mail.sun.net> for atom-syntax@imc.org; Thu,
 08 Jul 2004 10:22:28 -0600 (MDT)
Date: Thu, 08 Jul 2004 09:22:25 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceUriOrItsSuccessor
In-reply-to: <40ED45E2.7080004@intertwingly.net>
To: Sam Ruby <rubys@intertwingly.net>
Cc: Atom Syntax <atom-syntax@imc.org>, Mark Pilgrim <pilgrim@gmail.com>,
        Martin Duerst <duerst@w3.org>
Message-id: <FF8A333D-D0FA-11D8-B2D0-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: <4.2.0.58.J.20040708150825.05af4ae0@localhost>
 <14be96d304070805371d46387c@mail.gmail.com> <40ED45E2.7080004@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


> Suggestion on how to proceed: perhaps Martin or somebody else could 
> write up a PaceIri which would contain the precise wording that should 
> be included in the Atom spec in anticipation of a future completed IRI 
> specification.

Yes, please. -Tim



From owner-atom-syntax@mail.imc.org  Thu Jul  8 12:33: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 MAA07531
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 12:33: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 i68GErxa053941;
	Thu, 8 Jul 2004 09: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 i68GErOV053940;
	Thu, 8 Jul 2004 09:14:53 -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 i68GEqns053932
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 09:14:52 -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 i68G9Uuo010671;
	Thu, 8 Jul 2004 12:09:30 -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 BHM20108 (AUTH bob@wyman.us);
	Thu, 8 Jul 2004 12:14:52 -0400 (EDT)
Message-Id: <200407081614.BHM20108@ms8.netsolmail.com>
Reply-To: <bob@wyman.us>
From: "Bob Wyman" <bob@wyman.us>
To: "'John Panzer'" <jpanzer@aol.net>, "'atom-syntax'" <atom-syntax@imc.org>
Subject: RE: Thought experiment: Using a synthetic feed to find out about other feeds
Date: Thu, 8 Jul 2004 12:14:54 -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: <40EC9F23.1010102@AOL.NET>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Thread-Index: AcRki6jkBoya1ORkSQWJsFwdQRPUHgAePBFw
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


John Panzer wrote:
> Suppose I want to offer a service in which people can subscribe to a
collection of pointers to Atom feeds.
	Let me add a few additional applications to John's list:
1. List of "new blogs" on a site. i.e. Whenever AOL Journals creates a new
journal (blog), it could add it to the list of "new journals" so that
services like Feedster, Technorati, PubSub, etc. that wish to discover and
then monitor these things could discover the new journals immediately. The
usage would be somewhat like what is done today with "new entry" feeds at
places like weblogs.com, blo.gs, livejournal, etc.
2. Cooperating blog searching or matching services could send "new atom
file" feeds to each other from time to time to propogate information about
the new feeds that they had discovered.
3. Search engines could return lists of blogs that tend to discuss certain
subjects.
4. FOAF applications could return lists of blogs "within three links" of
someone's entry.
5. Various services could build lists of "feeds updated during the last X
minutes."

       This proposal has some similarities to Ken MacLeod's recent proposal
for a <site/> element that would be linked to by entries. The similarity is
in making the <feed/> data stand on it's own as a first-class object
independent of any entries. Thus, it moves us toward RDF-in-spirit, if not
syntax: independent, reusable, re-combinable elements that can stand on
their own or be composed into aggregates that convey what we expect from a
feed today.
       
       	bob wyman
       



From owner-atom-syntax@mail.imc.org  Thu Jul  8 13:23: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 NAA10744
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 13: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 i68HAFdK058456;
	Thu, 8 Jul 2004 10:10: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 i68HAF6C058454;
	Thu, 8 Jul 2004 10:10: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 (mproxy.gmail.com [216.239.56.241])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i68HAEPR058445
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 10:10:14 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so6958798cwc
        for <atom-syntax@imc.org>; Thu, 08 Jul 2004 10:10:15 -0700 (PDT)
Received: by 10.11.116.8 with SMTP id o8mr251821cwc;
        Thu, 08 Jul 2004 10:10:15 -0700 (PDT)
Message-ID: <3f1451f504070810104a5122e7@mail.gmail.com>
Date: Thu, 8 Jul 2004 13:10:15 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: mint@franklinmint.fm
Subject: Re: PaceSecurityServices
Cc: Sam Ruby <rubys@intertwingly.net>, atom-syntax <atom-syntax@imc.org>
In-Reply-To: <40ED6392.2000107@franklinmint.fm>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <40E16215.6070507@intertwingly.net> <40EC9915.4050406@intertwingly.net> <3f1451f504070718267c5526b4@mail.gmail.com> <40ED6392.2000107@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 Thu, 08 Jul 2004 11:09:06 -0400, Robert Sayre <mint@franklinmint.fm> wrote:
> Joe Gregorio wrote:
> 
> >In the section on the AtomAPI:
> >---------------------------------------------
> >
> >+1 on Digest and TLS
> >
> >I support referencing and strongly encouraging
> >the use of standard authentication and
> >encryption mechanisms.
> >
> >
> >
> +1
> 
> >-1 to WSSE
> >
> >
> >
> ...
> 
> >If we must create a new authentication mechanism
> >than I would also like it to be a seperate RFC from the
> >the AtomAPI, just as HTTP is broken into
> >RFC 2616 and 2617.
> >
> >
> I'm fine with accepting the Pace as is. If we want to make AuthForBob a
> seperate document, we can do that at any time. Saying it should go in a
> document that's not (yet) a deliverable resembles handwaving a little
> too closely for me. I'm not a big fan of WSSE, but it will be easy to
> replace that section with something else. Let's just get it in there for
> now.

Agreed.


    Thanks,
    -joe



From owner-atom-syntax@mail.imc.org  Thu Jul  8 13:46:03 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12539
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 13:46:03 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i68HT6sl060206;
	Thu, 8 Jul 2004 10:29: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 i68HT6eI060205;
	Thu, 8 Jul 2004 10:29: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 (mproxy.gmail.com [216.239.56.243])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i68HT6FW060196
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 10:29:06 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so6987263cwc
        for <atom-syntax@imc.org>; Thu, 08 Jul 2004 10:29:03 -0700 (PDT)
Received: by 10.11.118.68 with SMTP id q68mr596490cwc;
        Thu, 08 Jul 2004 10:29:03 -0700 (PDT)
Message-ID: <3f1451f504070810296ca252e7@mail.gmail.com>
Date: Thu, 8 Jul 2004 13:29:03 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: mint@franklinmint.fm
Subject: Re: PaceSecurityServices
Cc: Sam Ruby <rubys@intertwingly.net>, atom-syntax <atom-syntax@imc.org>
In-Reply-To: <3f1451f504070810104a5122e7@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <40E16215.6070507@intertwingly.net> <40EC9915.4050406@intertwingly.net> <3f1451f504070718267c5526b4@mail.gmail.com> <40ED6392.2000107@franklinmint.fm> <3f1451f504070810104a5122e7@mail.gmail.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 Thu, 8 Jul 2004 13:10:15 -0400, Joe Gregorio <joe.gregorio@gmail.com> wrote:
> On Thu, 08 Jul 2004 11:09:06 -0400, Robert Sayre <mint@franklinmint.fm> wrote:
> > I'm fine with accepting the Pace as is. If we want to make AuthForBob a
> > seperate document, we can do that at any time. Saying it should go in a
> > document that's not (yet) a deliverable resembles handwaving a little
> > too closely for me. I'm not a big fan of WSSE, but it will be easy to
> > replace that section with something else. Let's just get it in there for
> > now.
> 
> Agreed.

Ok, let me clarify that a little, *if* we agree to keep WSSE
then I am not opposed to starting documenting it in the current I-D and 
then moving it off into it's own document later.

> 
>     Thanks,
>     -joe
>



From owner-atom-syntax@mail.imc.org  Thu Jul  8 14:10: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 OAA14628
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 14:10: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 i68I0QSX062579;
	Thu, 8 Jul 2004 11:00: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 i68I0QUu062578;
	Thu, 8 Jul 2004 11:00: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 i68I0QrI062570
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 11:00: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 LAA19976
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 11:00: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 LAA18969
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 11:00:24 -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); Thu, 08 Jul 2004 11:00:23 -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 <0I0J006XIJ4MJL@shazam.verity.com> for atom-syntax@imc.org; Thu,
 08 Jul 2004 09:00:23 -0700 (PDT)
Date: Thu, 08 Jul 2004 09:00:24 -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: Q: modfied vs issued vs created
In-reply-to: <opsatdbjsxuvpchu@quark>
To: Atom-Syntax <atom-syntax@imc.org>
Message-id: 
 <B3BCF453B616D4D7E8AFDE67@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
MIME-version: 1.0
X-Mailer: Mulberry/3.1.5 (Mac OS X)
Content-type: text/plain; charset=iso-8859-1; format=flowed
Content-disposition: inline
References: <14543268.1088887310064.JavaMail.dtcd@mac.com>
 <opsatdbjsxuvpchu@quark>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i68I0QrI062572
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 Thursday, July 8, 2004 12:12 PM +0200 Asbjørn Ulsberg <asbjorn@tigerstaden.no> wrote:
> On Sat, 03 Jul 2004 21:41:50 +0100, Graham Parks <dtcd@mac.com> wrote:
>
>> You're talking as if PaceEntryDates removes the <created> field.
>
> No, not really. I'm more talking of that it's important that if <issued>
> is going to exist as an alternative for <created>, then <issued> MUST
> NEVER be updated, changed or fiddled with after it's first set.

Never? Even if there is a mistake in the issued date? The server is
required to send the wrong date forever?

I would prefer "published" instead of "issued" by the way. Blog
software mostly talks about publishing entries, not issuing them.

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Thu Jul  8 14:14: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 OAA14917
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 14:14: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 i68I6hVF062966;
	Thu, 8 Jul 2004 11:06: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 i68I6h6K062965;
	Thu, 8 Jul 2004 11:06:43 -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 i68I6gNX062954
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 11:06:42 -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 i68I6e53000620
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 13:06:41 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i68I6eWW000616;
	Thu, 8 Jul 2004 13:06:40 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: <atom-syntax@imc.org>
Subject: Re: Thought experiment: Using a synthetic feed to find out about other feeds
References: <200407081614.BHM20108@ms8.netsolmail.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 08 Jul 2004 13:06:40 -0500
In-Reply-To: <200407081614.BHM20108@ms8.netsolmail.com>
Message-ID: <m3hdsiqspb.fsf@bitsko.slc.ut.us>
Lines: 59
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: <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> writes:

> John Panzer wrote:
> > Suppose I want to offer a service in which people can subscribe to
> > a collection of pointers to Atom feeds.

> 	Let me add a few additional applications to John's list:
> 1. List of "new blogs" on a site. i.e. Whenever AOL Journals creates
> a new journal (blog), it could add it to the list of "new journals"
> so that services like Feedster, Technorati, PubSub, etc. that wish
> to discover and then monitor these things could discover the new
> journals immediately. The usage would be somewhat like what is done
> today with "new entry" feeds at places like weblogs.com, blo.gs,
> livejournal, etc.
> 2. Cooperating blog searching or matching services could send "new
> atom file" feeds to each other from time to time to propogate
> information about the new feeds that they had discovered.
> 3. Search engines could return lists of blogs that tend to discuss
> certain subjects.
> 4. FOAF applications could return lists of blogs "within three
> links" of someone's entry.
> 5. Various services could build lists of "feeds updated during the
> last X minutes."

I think these cut right to the core of Beecher's suggestion of
defining how "a set of entries" differ from "lists", particularly "a
set of recently changed entries", and how an "entry" is different from
a "generic metadata record".

An aggregator works on the principle of displaying new entries when
they appear, and sometimes holding "old" entries for perusal, and
re-showing updated entries if they're changed.

I understand the interest in thinking of a "feed" as a "list" in
contrast to a "a set of recently changed entries", but to fit that
perception I always expect the justification for why that "list"
should be presented as "a set of recently changed entries" as a
default.

In this case, "a set of feeds" (which is really an "index", a complete
set of "sites" that are not merely "recently changed") and "a set of
recently changed feeds" don't match my concept of "a set of recently
changed entries".

I'm good with a "list of sites", that is either an "index" or a "set
of recently changed sites", and allowing a client to properly display
that to a user, such as, "site Foo just added feed Bar, subscribe?"

But when a "list of sites" is co-mingled conceptually with a "list of
entries", I can see an aggregator a) hiding all the feeds you already
know about, and showing you a new feed when it appears as a new entry,
but I'm perplexed by b) what the concept of "modified" should cause
the aggregator to do.  Should the aggregator re-display the "modified
feed" like it would a modified entry?  or should it know that it's a
feed and that feeds get modified all the time?  The current *default*
behavior of aggregators would be re-displaying "feed entries" every
time those feeds themselves had new entries!

  -- Ken



From owner-atom-syntax@mail.imc.org  Thu Jul  8 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 OAA17667
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 14: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 i68IeZ4w065301;
	Thu, 8 Jul 2004 11:40:35 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i68IeZR1065300;
	Thu, 8 Jul 2004 11:40: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 i68IeY1Z065289
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 11:40: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 D1CC67C0F3; Thu,  8 Jul 2004 21:39:24 +0200 (CEST)
To: "Walter Underwood" <wunder@verity.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Q: modfied vs issued vs created
References: <14543268.1088887310064.JavaMail.dtcd@mac.com> <opsatdbjsxuvpchu@quark> <B3BCF453B616D4D7E8AFDE67@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
Message-ID: <opsat0zze1uvpchu@quark>
Date: Thu, 08 Jul 2004 20:44:13 +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: <B3BCF453B616D4D7E8AFDE67@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Thu, 08 Jul 2004 09:00:24 -0700, Walter Underwood <wunder@verity.com>  
wrote:

> Never? Even if there is a mistake in the issued date? The server is
> required to send the wrong date forever?

Of course not. I'm sure you know what I'm talking about. The <issued> date  
should not change once it's first set (correctly).

> I would prefer "published" instead of "issued" by the way. Blog
> software mostly talks about publishing entries, not issuing them.

I know, but we're trying to be conformant with Dublin Core which uses the  
term 'issued'.

-- 
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 Jul  8 17: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 RAA03552
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 17: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 i68LSbCn082876;
	Thu, 8 Jul 2004 14:28: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 i68LSbLt082875;
	Thu, 8 Jul 2004 14:28: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.47])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i68LSaUN082869
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 14:28:36 -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 i68LSfVN029242
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 14:28:41 -0700 (PDT)
Received: from [10.232.32.152] ([17.255.240.130])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id i68LSehp018411
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 14:28:41 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v618)
In-Reply-To: <opsatdbjsxuvpchu@quark>
References: <14543268.1088887310064.JavaMail.dtcd@mac.com> <opsatdbjsxuvpchu@quark>
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1--654210668; protocol="application/pkcs7-signature"
Message-Id: <D2E68A4E-D125-11D8-ACB6-000A95DC3D90@mac.com>
From: Graham <dtcd@mac.com>
Subject: Re: Q: modfied vs issued vs created
Date: Thu, 8 Jul 2004 17:28:58 -0400
To: Atom Syntax <atom-syntax@imc.org>
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--654210668
Content-Type: text/plain;
	charset=ISO-8859-1;
	format=flowed
Content-Transfer-Encoding: quoted-printable

On 8 Jul 2004, at 6:12 am, Asbj=F8rn Ulsberg wrote:

>
> On Sat, 03 Jul 2004 21:41:50 +0100, Graham Parks <dtcd@mac.com> wrote:
>
>> You're talking as if PaceEntryDates removes the <created> field.
>
> No, not really. I'm more talking of that it's important that if=20
> <issued> is going to exist as an alternative for <created>, then=20
> <issued> MUST NEVER be updated, changed or fiddled with after it's=20
> first set.

Not necessarily. The other way to do it is to say that you must also=20
supply a <created> date if you change <issued> - or in other words,=20
<created> is required if it differs significantly from <issued>.

> True, but I don't think it's a good idea to not only allow, but to=20
> encourage, publishers to update this field whenever they reissue the=20=

> article. If so, we should have both <first-issued> and <last-issued>=20=

> elements.

I'd imagine <first-issued> ~=3D <created> would be true in most cases.=20=

And anyway, I don't think it's necessary for entries to include their=20
full history - do they also have to supply details of older revisions?

Graham=

--Apple-Mail-1--654210668
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
9w0BCQUxDxcNMDQwNzA4MjEyODU5WjAjBgkqhkiG9w0BCQQxFgQUooLqw5jU8MWt3OG4dPxwZTAu
d4EweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEARu+sTp5lrAR6IvBHyc9yrHZk
TraI4OY1hSDnBp+Nj8+9Xla47ddS7eXR5nWMtKZeZqtOw4o1INzvWmmjcJjdiJpEXZ5i0v5cwR+/
1jKAnGrkmuyAavDohyH8x4WBaUZxVHDhpHK5iJaRQsbE5De6TPBIfqWG9f+8Nwssepmz32+dbU/S
Jb0lo387+/CzImAXR5LVw6AD2ZQJnYH+o75kJM/V6Q86YqaDsLgdiEe4lMNOcQUMX0Km3Fylqzva
ggtmtoenH0F21H4ovDx9Y5UVDz5zVt73WA4TY0/73UKDHuDg++/NAJjiFocUZVrnM6H6rjelyImr
JiS9OEX5eZ32JAAAAAAAAA==

--Apple-Mail-1--654210668--



From owner-atom-syntax@mail.imc.org  Thu Jul  8 18: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 SAA07594
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 18: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 i68MC19d087281;
	Thu, 8 Jul 2004 15:12: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 i68MC1Cf087280;
	Thu, 8 Jul 2004 15:12:01 -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 i68MC0l0087267
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 15:12:01 -0700 (PDT)
	(envelope-from djpowell@djpowell.net)
Received: from [81.111.201.190] by mta10-svc.ntlworld.com
          (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP
          id <20040708221056.IGF9859.mta10-svc.ntlworld.com@[81.111.201.190]>;
          Thu, 8 Jul 2004 23:10:56 +0100
Date: Thu, 8 Jul 2004 23:12:00 +0100
From: David Powell <djpowell@djpowell.net>
X-Mailer: The Bat! (v2.12 Beta/7) Business
Reply-To: David Powell <djpowell@djpowell.net>
X-Priority: 3 (Normal)
Message-ID: <1945027093.20040708231200@djpowell.net>
To: Joe Gregorio <joe.gregorio@gmail.com>
CC: atom-syntax@imc.org
Subject: Re: Avoiding duplicate entries / Idempotent posting
In-Reply-To: <3f1451f5040706083331333d4a@mail.gmail.com>
References: <1089118870.40eaa2964b912@webmail.djpowell.net>
 <3f1451f50407060639164fbe53@mail.gmail.com>
 <1089125855.40eabddf30bdd@webmail.djpowell.net>
 <3f1451f5040706083331333d4a@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: <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


Tuesday, July 6, 2004, 4:33:26 PM, joe.gregorio@gmail.com wrote:

> Now I get it, and Mark has pointed out one such solution:

> http://www.mnot.net/blog/2003/09/13/click_submit_only_once

> The other possibility is to do a GET on the PostURI
> to retrieve a partially filled in atom 'entry' which 
> you stuff your content into before submitting
> it back to PostURI to create an Entry. A nonce value
> in a namespaced element could be added to such
> a 'template' to avoid multiple submissions of the same
> entry.

> The idea of a 'template' entry retrieved from PostURI 
> came up previously during a discussion of querying
> server capabilities:

> http://intertwingly.net/wiki/pie/AtomApiContentNegotiation

>    -joe

I think that it is important to consider this problem, because as Mark
as shown, this problem is solvable in typical browser-based apps, so I
think that we should ensure that it is also solvable for users of the
Atom API too.  Currently, I don't think it is without some
modifications.

It isn't straightforward to apply Mark's suggestion to Atom directly,
because unlike browser apps, the PostURI is public and there is only
one PostURI. As it is the server's general responsibility to issue
URIs, this would need some extra process that issued unique PostURIs
which adds quite a bit of complexity to what we have at the moment. I
prefer the idea of having a single PostURI for a feed.


Do people think that this issue is worth tackling?

(I'm a bit ignorant of the WG's process - is it bad timing to suggest
new issues at the moment?)

-- 
Dave



From owner-atom-syntax@mail.imc.org  Thu Jul  8 18:56: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 SAA11360
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 18:56: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 i68MkpwQ090797;
	Thu, 8 Jul 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 i68Mko36090796;
	Thu, 8 Jul 2004 15:46:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-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 i68MkoA0090790
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 15:46: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 i68Mkoil007195
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 16:46: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 <0I0K00FTD1Y1ML@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Thu, 08 Jul 2004 16:46:50 -0600 (MDT)
Received: from [192.168.1.27] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0K00H431Y1Q8@mail.sun.net> for atom-syntax@imc.org; Thu,
 08 Jul 2004 16:46:49 -0600 (MDT)
Date: Thu, 08 Jul 2004 15:46:45 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Avoiding duplicate entries / Idempotent posting
In-reply-to: <1945027093.20040708231200@djpowell.net>
To: David Powell <djpowell@djpowell.net>
Cc: Joe Gregorio <joe.gregorio@gmail.com>, atom-syntax@imc.org
Message-id: <B065B871-D130-11D8-B2D0-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: <1089118870.40eaa2964b912@webmail.djpowell.net>
 <3f1451f50407060639164fbe53@mail.gmail.com>
 <1089125855.40eabddf30bdd@webmail.djpowell.net>
 <3f1451f5040706083331333d4a@mail.gmail.com>
 <1945027093.20040708231200@djpowell.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 Jul 8, 2004, at 3:12 PM, David Powell wrote:

> Do people think that this issue is worth tackling?
>
> (I'm a bit ignorant of the WG's process - is it bad timing to suggest
> new issues at the moment?)

Suggesting a new issue is always OK, but to be taken seriously it needs 
to be accompanied by draft language, i.e. to be a Pace. -Tim



From owner-atom-syntax@mail.imc.org  Thu Jul  8 19:33: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 TAA13866
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 19: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 i68NMOnm093970;
	Thu, 8 Jul 2004 16:22: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 i68NMOLF093969;
	Thu, 8 Jul 2004 16:22:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i68NMOTo093961
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 16:22:24 -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 1BiiDf-0006Hv-Gi; Thu, 08 Jul 2004 23:22:23 +0000
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Thu, 08 Jul 2004 19:22:32 -0400
Subject: Re: Avoiding duplicate entries / Idempotent posting
From: Robert Sayre <mint@franklinmint.fm>
To: David Powell <djpowell@djpowell.net>,
        Joe Gregorio <joe.gregorio@gmail.com>
CC: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD134F78.1200C%mint@franklinmint.fm>
In-Reply-To: <1945027093.20040708231200@djpowell.net>
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: <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 7/8/04 6:12 PM, "David Powell" <djpowell@djpowell.net> wrote:

> 
> Tuesday, July 6, 2004, 4:33:26 PM, joe.gregorio@gmail.com wrote:
> 
>> Now I get it, and Mark has pointed out one such solution:
> 
>> http://www.mnot.net/blog/2003/09/13/click_submit_only_once
> 

> It isn't straightforward to apply Mark's suggestion to Atom directly,
> because unlike browser apps, the PostURI is public and there is only
> one PostURI. As it is the server's general responsibility to issue
> URIs, this would need some extra process that issued unique PostURIs
> which adds quite a bit of complexity to what we have at the moment. I
> prefer the idea of having a single PostURI for a feed.
> 
> 
> Do people think that this issue is worth tackling?
>

Yes, but perhaps something like PacePutToCreate[1] would do the trick.

Robert Sayre


[1] http://www.intertwingly.net/wiki/pie/PacePutToCreate



From owner-atom-syntax@mail.imc.org  Thu Jul  8 19:37: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 TAA14140
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 19:37: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 i68NQ3nW094207;
	Thu, 8 Jul 2004 16:26:03 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i68NQ3N4094206;
	Thu, 8 Jul 2004 16:26:03 -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 i68NPwZ2094197
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 16:26:03 -0700 (PDT)
	(envelope-from distobj@acm.org)
Received: from mbaker by bork.markbaker.ca with local (Exim 3.35 #1 (Debian))
	id 1BiiHX-0001Gu-00; Thu, 08 Jul 2004 19:26:23 -0400
Date: Thu, 8 Jul 2004 19:26:23 -0400
To: Bob Wyman <bob@wyman.us>
Cc: "'Atom Syntax'" <atom-syntax@imc.org>
Subject: Re: IRIs, URIs, and RFC 2396bis
Message-ID: <20040708232623.GM30868@markbaker.ca>
References: <20040708031231.GL30868@markbaker.ca> <200407081521.BHL98254@ms8.netsolmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200407081521.BHL98254@ms8.netsolmail.com>
User-Agent: Mutt/1.3.28i
From: Mark Baker <distobj@acm.org>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


On Thu, Jul 08, 2004 at 11:21:38AM -0400, Bob Wyman wrote:
> Mark Baker wrote:
> > It's my understanding that "or its successor" is implied in RFCs.
> 	This would not be a good policy. It would mean that any RFC that has
> a dependency on another would have an indeterminate definition.

Or it would mean that documents which obsolete other documents would
need to be developed with the utmost care for compatibility issues.
Oh wait, that's what happens. 8-)

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

  Seeking work on large scale application/data integration projects
  and/or the enabling infrastructure for same.



From owner-atom-syntax@mail.imc.org  Thu Jul  8 20:51: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 UAA18578
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 20:51: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 i690ekSf000738;
	Thu, 8 Jul 2004 17: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 i690ekWe000737;
	Thu, 8 Jul 2004 17:40:46 -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 i690ekxO000731
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 17:40:46 -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 D33884F05B
	for <atom-syntax@imc.org>; Thu,  8 Jul 2004 20:40:49 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040709091221.060d8590@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Fri, 09 Jul 2004 09:40:27 +0900
To: Atom Syntax <atom-syntax@imc.org>
From: Martin Duerst <duerst@w3.org>
Subject: Wiki setup issues: IRI
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>


When working on http://intertwingly.net/wiki/pie/PaceIRI
(not at all complete yet), I put my name (the real one, with umlaut,
not the one I have to use in my outdated Japanese mailer) in square
brackets at the start of the Abstract like I had seen it on other Paces
such as http://intertwingly.net/wiki/pie/PaceUriOrItsSuccessor.

When I then clicked on it, I got to
http://intertwingly.net/wiki/pie/MartinD_fcrst, which shows
that with a few, probably very simple, changes to the wiki
setup/code, this could be made compatible with IRIs.

Two changes are necessary:
1) Change the wiki to use UTF-8 for its page encoding rather than
    iso-8859-1. For a new wiki, this should just be a setup issue
    (otherwise, choose another wiki software, or maybe another ISP).
    For the current wiki, pages with non-ASCII characters have to be
    converted to UTF-8 at the same time the setup is changed.
    Doing that is easy if you have access to the actual files.
    In line with http://intertwingly.net/stories/2004/04/14/i18n.html,
    I would suggest that we do that anyway, and I'm ready to help.
    This would then change the above URI from
    http://intertwingly.net/wiki/pie/MartinD_fcrst to
    http://intertwingly.net/wiki/pie/MartinD_c3_bcrst.

2) Change the escape character from '_' to '%'. This would change
    the above URI from
    http://intertwingly.net/wiki/pie/MartinD_c3_bcrst to
    http://intertwingly.net/wiki/pie/MartinD%c3%bcrst.
    While at it, please also change escaping from lowercase to
    upper case, in accordance with 2396bis. This would give
    http://intertwingly.net/wiki/pie/MartinD%C3%BCrst.

The two changes are largely independent, and can be done in any order.
If everything goes well, the file names are then actually readable,
on an Unix/Linux system assuming you have selected an UTF-8 locale (most
new Linux systems are shipped that way, as far as I understand).

As I said, I'd be very glad to help get this fixed.
I don't really care too much about my own name, I could
use 'Duerst' as a fallback, but it'd really be better
to fix this on this occasion.

Regards,    Martin.



From owner-atom-syntax@mail.imc.org  Thu Jul  8 20:53: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 UAA18701
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 20:53: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 i690UjAu000128;
	Thu, 8 Jul 2004 17: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 i690UjHl000126;
	Thu, 8 Jul 2004 17:30:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i690UgeQ099964
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 17:30:43 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 9 Jul 2004 10:35:11 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Fri, 09 Jul 2004 10:27:41 +1000
Subject: Re: Thought experiment: Using a synthetic feed to find out about
	other feeds
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD14239D.1E278%eric.scheid@ironclad.net.au>
In-Reply-To: <m3hdsiqspb.fsf@bitsko.slc.ut.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


On 9/7/04 4:06 AM, "Ken MacLeod" <ken@bitsko.slc.ut.us> wrote:

> I'm perplexed by b) what the concept of "modified" should cause
> the aggregator to do.  Should the aggregator re-display the "modified
> feed" like it would a modified entry?  or should it know that it's a
> feed and that feeds get modified all the time?

and perhaps deliberately retrieve those feeds which are (a) modified, and
(b) already in your subscription list?

sounds a bit like a ping interface, but one which can penetrate firewalls
because it is pulled, not pushed; and one which could be tailored to only
reference feeds you are interested in.

e.



From owner-atom-syntax@mail.imc.org  Thu Jul  8 21:13: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 VAA19685
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 21:13: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 i690onG9001145;
	Thu, 8 Jul 2004 17: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 i690onM9001144;
	Thu, 8 Jul 2004 17:50:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i690omJU001138
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 17:50:48 -0700 (PDT)
	(envelope-from stevej@google.com)
Received: from [172.24.72.132] (dhcp-172-24-72-132.corp.google.com [172.24.72.132])
	(authenticated bits=0)
	by 216-239-45-4.google.com (8.12.11/8.12.9) with ESMTP id i690ob0P020491
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Thu, 8 Jul 2004 17:50:37 -0700
In-Reply-To: <BD134F78.1200C%mint@franklinmint.fm>
References: <BD134F78.1200C%mint@franklinmint.fm>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <FD509586-D141-11D8-91E3-000A95B09B46@google.com>
Content-Transfer-Encoding: 7bit
Cc: Atom Syntax <atom-syntax@imc.org>
From: steve jenson <stevej@google.com>
Subject: Re: PacePutToCreate
Date: Thu, 8 Jul 2004 17:50:36 -0700
To: Robert Sayre <mint@franklinmint.fm>
X-Mailer: Apple Mail (2.613)
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 Jul 8, 2004, at 4:22 PM, Robert Sayre wrote:

>> Do people think that this issue is worth tackling?
>>
>
> Yes, but perhaps something like PacePutToCreate[1] would do the trick.

If I'm an endpoint that enforces complete control (really, any 
overriding control) over the URI space, should a client be using POST 
instead of PUT? Is it ok for me to _not_ create the Resource with the 
Request-URI asked for if a PUT is sent?

More concretely, if a User PUTs an entry dated 12-25-04 with a 
Request-URI of http://blogger.com/atom/$blogID/2004/11/title.html 
(please note a different month than the entry's date), and I instead 
create it at http://example.com/2004/12/title.html, am I in violation 
of the semantics of PUT?

Also, I understand that a PUT can cause side effects in multiple URIs 
but do I also have to serve this newly created Entry at the 
Request-URI? PUT seems to require that or at least strongly lean in 
that direction.

Thanks,
Steve



From owner-atom-syntax@mail.imc.org  Thu Jul  8 21: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 VAA21145
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 21: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 i691HrSD003139;
	Thu, 8 Jul 2004 18:17:53 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i691HrrP003138;
	Thu, 8 Jul 2004 18:17:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rongo.sixapart.com (dsl081-057-015.sfo1.dsl.speakeasy.net [64.81.57.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i691HrPm003127
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 18:17:53 -0700 (PDT)
	(envelope-from ezra@sixapart.com)
Received: from [192.168.100.250] (Aphrodite.sm.sixapart.com [192.168.100.250])
	by rongo.sixapart.com (Postfix) with ESMTP id A273547E9C
	for <atom-syntax@imc.org>; Thu,  8 Jul 2004 17:14:51 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v618)
Content-Transfer-Encoding: 7bit
Message-Id: <CBD5A500-D145-11D8-89D5-000A95CFF6CC@sixapart.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: atom-syntax@imc.org
From: Ezra Cooper <ezra@sixapart.com>
Subject: PaceSecurityServices--do we need WSSE?
Date: Thu, 8 Jul 2004 18:17:51 -0700
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>
Content-Transfer-Encoding: 7bit


OK, since we're proceeding on PaceSecurityServices, I think we should 
move to tighten up the language a bit.

Here's a drawback to WSSE that I haven't seen discussed yet: If a legit 
client has its time set in the future, then its requests could be 
denied by the server, and yet an eavesdropper could store those tokens 
until such time as they fall within the window. For example, suppose 
Bob tries to make an Atom post at 12:00 UTC, but his computer's time 
reads 1:00 UTC (this is a common scenario where the time appears 
correct but is in the wrong timezone). The wsse digest is rejected 
because its timestamp is in the future. Bob wonders why his client is 
giving him errors. But Alice, who was listening in on Bob's TCP traffic 
at the corner cafe, has stored this PasswordDigest, with its timestamp 
of 1:00. Alice simply waits until 1:00 and then uses that token as a 
header on some mischievous update to Bob's blog. If Bob keeps retrying, 
getting frustrated, then Alice might collect any number of these 
freebies.

Digest doesn't have this problem because it doesn't rely on Bob having 
the correct timezone set.

I prefer Digest because a) it lets the server expire the tokens at its 
will, b) it already has spec text to allow for storing the password in 
a hashed form, and c) clock synchronization is not an issue. What's 
more, it has a mechanism for hashing the body (the auth-int qop), to 
protect against modification. It seems that all of the issues with 
Digest Auth that are listed in Mark's xml.com article [1] have been 
dealt with.

I haven't heard any support on-list for WSSE-style auth in some time. 
Is there still support for it? If not, can we drop it from the spec? If 
there is support I'm not opposed to allowing it, but in that case we 
need to fill in it's definition. I don't mean to squelch it if there's 
a need.

Thoughts on this?

Ezra

[1] http://www.xml.com/pub/a/2003/12/17/dive.html



From owner-atom-syntax@mail.imc.org  Thu Jul  8 21:35: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 VAA21543
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 21:35: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 i691Oje1003907;
	Thu, 8 Jul 2004 18:24: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 i691OjZm003906;
	Thu, 8 Jul 2004 18:24:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i691OivU003897
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 18:24:44 -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 1Bik8A-00024z-WE; Fri, 09 Jul 2004 01:24:51 +0000
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Thu, 08 Jul 2004 21:24:56 -0400
Subject: Re: PacePutToCreate
From: Robert Sayre <mint@franklinmint.fm>
To: steve jenson <stevej@google.com>
CC: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD136C28.12015%mint@franklinmint.fm>
In-Reply-To: <FD509586-D141-11D8-91E3-000A95B09B46@google.com>
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: <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 7/8/04 8:50 PM, "steve jenson" <stevej@google.com> wrote:

> On Jul 8, 2004, at 4:22 PM, Robert Sayre wrote:
> 
>>> Do people think that this issue is worth tackling?
>>> 
>> 
>> Yes, but perhaps something like PacePutToCreate[1] would do the trick.
> 

> 
> More concretely, if a User PUTs an entry dated 12-25-04 with a
> Request-URI of http://blogger.com/atom/$blogID/2004/11/title.html
> (please note a different month than the entry's date), and I instead
> create it at http://example.com/2004/12/title.html, am I in violation
> of the semantics of PUT?

Yes, I think so. What you can do is send 301, and let the client decide if
it wants to PUT it there. Not much different from asking for a one-off URI
to POST to, the other suggestion we've had.

> 
> Also, I understand that a PUT can cause side effects in multiple URIs
> but do I also have to serve this newly created Entry at the
> Request-URI? PUT seems to require that or at least strongly lean in
> that direction.
> 

"A single resource MAY be identified by many different URIs. For  example,
an article might have a URI for identifying 'the current version' which is
separate from the URI identifying each particular  version. In this case, a
PUT request on a general URI might result in  several other URIs being
defined by the origin server.

 HTTP/1.1 does not define how a PUT method affects the state of an origin
server."[1]

Although the definition of PUT says the effect on the server state is
undefined, the 201 Response definition[2] states that you have to create the
resource. So it would appear that you have to serve it there, at least for
GET. I'll note that the AtomAPI doesn't currently require the EditURI to be
the same URI created by POSTing to the PostURI.

Robert Sayre

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6
[2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.2



From owner-atom-syntax@mail.imc.org  Thu Jul  8 21:47: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 VAA22602
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 21:47: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 i691cJG0004702;
	Thu, 8 Jul 2004 18:38: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 i691cJd6004701;
	Thu, 8 Jul 2004 18:38:19 -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 i691cIxs004685
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 18:38:18 -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 i691bY6g003332
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 21:37: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 BHO40267 (AUTH bob@wyman.us);
	Thu, 8 Jul 2004 21:38:21 -0400 (EDT)
Message-Id: <200407090138.BHO40267@ms8.netsolmail.com>
Reply-To: <bob@wyman.us>
From: "Bob Wyman" <bob@wyman.us>
To: "'Atom Syntax'" <atom-syntax@imc.org>
Subject: RE: Thought experiment: Using a synthetic feed to find out aboutother feeds
Date: Thu, 8 Jul 2004 21:38: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.1409
Thread-Index: AcRlUUuzeMAoI2+vSrein7ssZl/0ugABAkKw
In-Reply-To: <BD14239D.1E278%eric.scheid@ironclad.net.au>
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:
> sounds a bit like a ping interface, but one which can penetrate 
> firewalls because it is pulled, not pushed; and one which could be 
> tailored to only reference feeds you are interested in.
	Right. But, if that is what you want, you could subscribe to
pings[1] using the Jabber/XMPP-based PubSub system that we provide at
PubSub.com.[2,3,4] The pings would be "pushed" to you, so you wouldn't
suffer the latency inherent to a polling solution. These pings would
penetrate the firewall since Jabber/XMPP opens a persistent connection from
the client within the firewall to the server. 
	By leveraging broadly accepted and deployed instant messaging
technology, we can do all sorts of things with Atom and syndication that
were much more difficult before. Atom over Jabber via PubSub offers a new
set of interesting ways to work with blogs and feeds...

		bob wyman

[1] You can get the effect of "pings" from a blog named
"http://example.com/foo.xml" by creating a PubSub subscription to
"SOURCE:example.com/foo.xml" (i.e. "Show me new items whose source is:
"example.com/foo.xml".) Using the Jabber/XMPP PubSub Interface, if you only
want the "ping" data, not the actual content of the new item/entry, just set
the subscription option "show-content" to the value "exclude" (actually,
that's the default so you don't need to set it...). (See the tutorial at
[2]).
[2] http://developers.pubsub.com
[3] http://developers.pubsub.com/pubsub_xmpp_draft.html
[4] http://sourceforge.net/projects/pubsubxmpp (open source C# code and
binaries for a really simple (and very "beta") client that uses the PubSub
Jabber/XMPP interface).





From owner-atom-syntax@mail.imc.org  Thu Jul  8 21:47: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 VAA22626
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 21:47: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 i691b755004640;
	Thu, 8 Jul 2004 18:37:07 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i691b7F2004639;
	Thu, 8 Jul 2004 18:37:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.pubsub.com (mail.pubsub.com [209.11.36.150])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i691b73N004630
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 18:37:07 -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 ED628171D7E; Thu,  8 Jul 2004 21:37:57 -0400 (EDT)
Reply-To: <bobwyman@pubsub.com>
From: "Bob Wyman" <bobwyman@pubsub.com>
To: "'Eric Scheid'" <eric.scheid@ironclad.net.au>,
        "'Atom Syntax'" <atom-syntax@imc.org>
Subject: RE: Thought experiment: Using a synthetic feed to find out aboutother feeds
Date: Thu, 8 Jul 2004 21:37: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.1409
Thread-Index: AcRlUUuzeMAoI2+vSrein7ssZl/0ugAAVX2g
In-Reply-To: <BD14239D.1E278%eric.scheid@ironclad.net.au>
Message-Id: <20040709013757.ED628171D7E@mail.pubsub.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


Eric Scheid wrote:
> sounds a bit like a ping interface, but one which can penetrate
> firewalls because it is pulled, not pushed; and one which could
> be tailored to only reference feeds you are interested in.
	Right. But, if that is what you want, you could subscribe to
pings[1] using the Jabber/XMPP-based PubSub system that we provide at
PubSub.com.[2,3,4] The pings would be "pushed" to you, so you wouldn't
suffer the latency inherent to a polling solution. These pings would
penetrate the firewall since Jabber/XMPP opens a persistent connection from
the client within the firewall to the server. 
	By leveraging broadly accepted and deployed instant messaging
technology, we can do all sorts of things with Atom and syndication that
were much more difficult before. Atom over Jabber via PubSub offers a new
set of interesting ways to work with blogs and feeds...

		bob wyman

[1] You can get the effect of "pings" from a blog named
"http://example.com/foo.xml" by creating a PubSub subscription to
"SOURCE:example.com/foo.xml" (i.e. "Show me new items whose source is:
"example.com/foo.xml".) Using the Jabber/XMPP PubSub Interface, if you only
want the "ping" data, not the actual content of the new item/entry, just set
the subscription option "show-content" to the value "exclude" (actually,
that's the default so you don't need to set it...). (See the tutorial at
[2]).
[2] http://developers.pubsub.com
[3] http://developers.pubsub.com/pubsub_xmpp_draft.html
[4] http://sourceforge.net/projects/pubsubxmpp (open source C# code and
binaries for a really simple (and very "beta") client that uses the PubSub
Jabber/XMPP interface).





From owner-atom-syntax@mail.imc.org  Thu Jul  8 23:17: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 XAA12560
	for <atompub-archive@lists.ietf.org>; Thu, 8 Jul 2004 23:17: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 i6931UT6011333;
	Thu, 8 Jul 2004 20: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 i6931UGP011332;
	Thu, 8 Jul 2004 20:01:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.198])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6931SlH011299
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 20:01:29 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d15so115109rng
        for <atom-syntax@imc.org>; Thu, 08 Jul 2004 20:01:30 -0700 (PDT)
Received: by 10.38.88.79 with SMTP id l79mr94720rnb;
        Thu, 08 Jul 2004 20:01:30 -0700 (PDT)
Message-ID: <14be96d3040708200146689971@mail.gmail.com>
Date: Thu, 8 Jul 2004 23:01:30 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Ezra Cooper <ezra@sixapart.com>
Subject: Re: PaceSecurityServices--do we need WSSE?
Cc: atom-syntax@imc.org
In-Reply-To: <CBD5A500-D145-11D8-89D5-000A95CFF6CC@sixapart.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <CBD5A500-D145-11D8-89D5-000A95CFF6CC@sixapart.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 Thu, 8 Jul 2004 18:17:51 -0700, Ezra Cooper <ezra@sixapart.com> wrote:
> I haven't heard any support on-list for WSSE-style auth in some time.

Contrary to popular belief, I have always been opposed to WSSE.  Joe
and I were early proponents of an algorithm that was as close to
Digest as possible, while still working in early adopter environments
such as Movable Type. [1]

My XML.com article was a description of the algorithm that I
understood Blogger and Typepad would be deploying, based on Ben's
implementation in his XML:Atom Perl module.  The article was never
meant to be a statement of support.  Apparently my naturally bubbly
personality shined through and confused people.  I'll try to ensure
that doesn't happen in the future.

[1] http://bitworking.org/news/New_AtomAPI_Implementation_Release2

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Fri Jul  9 02:29: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 CAA05628
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 02: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 i696EkZs055379;
	Thu, 8 Jul 2004 23:14: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 i696EkQV055378;
	Thu, 8 Jul 2004 23:14:46 -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 i696EjUD055316
	for <atom-syntax@imc.org>; Thu, 8 Jul 2004 23:14: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 B105E7C0F3; Fri,  9 Jul 2004 09:13:34 +0200 (CEST)
Date: Fri, 09 Jul 2004 08:17:44 +0200
To: "Jens Alfke" <jens@apple.com>
Subject: Re: Atom terminology
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <opsatf2wh3uvpchu@quark> <CBE6C974-D12E-11D8-A027-000A95A0ACC4@apple.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: <opsauw3uweuvpchu@quark>
In-Reply-To: <CBE6C974-D12E-11D8-A027-000A95A0ACC4@apple.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Thu, 8 Jul 2004 15:33:12 -0700, Jens Alfke <jens@apple.com> wrote:

>> I've created AtomTerminology[1].
>
> Thanks! Could you consider adding "Pace" to that list?

Done. I separated the list so it can contain both syndication and «other  
stuff», and I'm not sure these are the best headlines. Feel free to edit  
the page if you have a suggestion of better headlines and also better  
description of any of the words and phrases.

-- 
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 Jul  9 05: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 FAA12653
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 05:12: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 i698tcJo015426;
	Fri, 9 Jul 2004 01:55: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 i698tcsv015425;
	Fri, 9 Jul 2004 01:55: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 i698tbF4015382
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 01:55: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 2079F7C0F3
	for <atom-syntax@imc.org>; Fri,  9 Jul 2004 11:54:23 +0200 (CEST)
Date: Fri, 09 Jul 2004 10:59:12 +0200
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Patent threatens autodiscovery
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: <opsau4kyb0uvpchu@quark>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 just read the «U.S. Patent 5,892,908: Method of extracting network  
information»[1] and immediately thought about syndication and more  
specifically autodiscovery. Patent 5,892,908 seems to apply to a LAN and  
not a WAN as the Internet, but still as good as all discovery mechanisms  
(UDDI and so on) will infringe this patent. The patent description is as  
follows:

   A method of extracting network information first receives an
   initial link address (102) and retrieves a file (104)
   associated with the initial link address.

   The file is then parsed (106) to find a hyper text link. Next
   it is determined (108) if the hyper text link has a link
   address that contains the network address as a root.

   When the link address contains the initial link address as
   the root, a link file associated with the link address is
   retrieved (110).

What are your reactions to this patent? I find it pretty amazing that the  
US patent service approves a vague patent like this, and that it's  
actually possible to patent an abstract idea, seemingly no matter what the  
idea is about.

The patent was filed September 10th 1996 and approved April 6th 1999. Does  
anyone know of working code that existed before any of these dates that  
may render the patent useless? The group of people holding the patent has  
sued Adobe for infringing it, because Acrobat Reader does something  
similar to the incredibly vague description in it. If Adobe can be sued  
for infringement on this patent, surely all aggregator writers can as well.

____
[1] <url:  
http://patft.uspto.gov/netacgi/nph-Parser?u=/netahtml/srchnum.htm&Sect1=PTO1&Sect2=HITOFF&p=1&r=1&l=50&f=G&d=PALL&s1=5892908.WKU.&OS=PN/5892908&RS=PN/5892908>

-- 
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 Jul  9 07:24:37 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19758
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 07:24:36 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i69BDY6q051146;
	Fri, 9 Jul 2004 04:13:34 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i69BDYGe051145;
	Fri, 9 Jul 2004 04:13: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 i69BDXYJ051123
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 04:13:33 -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 i69BDxe4031185;
	Fri, 9 Jul 2004 07:13:59 -0400
Message-ID: <40EE7DD3.7000501@intertwingly.net>
Date: Fri, 09 Jul 2004 07:13:23 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 Baker <distobj@acm.org>
CC: "'Atom Syntax'" <atom-syntax@imc.org>
Subject: Re: IRIs, URIs, and RFC 2396bis
References: <20040708031231.GL30868@markbaker.ca> <200407081521.BHL98254@ms8.netsolmail.com> <20040708232623.GM30868@markbaker.ca>
In-Reply-To: <20040708232623.GM30868@markbaker.ca>
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


Mark Baker wrote:

> On Thu, Jul 08, 2004 at 11:21:38AM -0400, Bob Wyman wrote:
> 
>>Mark Baker wrote:
>>
>>>It's my understanding that "or its successor" is implied in RFCs.
>>
>>	This would not be a good policy. It would mean that any RFC that has
>>a dependency on another would have an indeterminate definition.
> 
> Or it would mean that documents which obsolete other documents would
> need to be developed with the utmost care for compatibility issues.
> Oh wait, that's what happens. 8-)

Counter example, from The Atom Syndication Format 0.3 (PRE-DRAFT) [1]:

     the canonical serialization of an Atom document is XML 1.0, and this
     is the only serialization that can be identified with the
     "application/atom+xml" media type.

- Sam Ruby

[1]<http://www.mnot.net/drafts/draft-nottingham-atom-format-02.html#rfc.section.2>




From owner-atom-syntax@mail.imc.org  Fri Jul  9 07: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 HAA20269
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 07:30: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 i69BL68d051981;
	Fri, 9 Jul 2004 04:21: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 i69BL6eB051979;
	Fri, 9 Jul 2004 04:21: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 i69BL54u051972
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 04:21:05 -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 i69BLXb5031642;
	Fri, 9 Jul 2004 07:21:33 -0400
Message-ID: <40EE7F98.6040207@intertwingly.net>
Date: Fri, 09 Jul 2004 07:20:56 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Ken MacLeod <ken@bitsko.slc.ut.us>
CC: atom-syntax@imc.org
Subject: Re: Thought experiment: Using a synthetic feed to find out about
 other feeds
References: <200407081614.BHM20108@ms8.netsolmail.com> <m3hdsiqspb.fsf@bitsko.slc.ut.us>
In-Reply-To: <m3hdsiqspb.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: <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


Ken MacLeod wrote:

> An aggregator works on the principle of displaying new entries when
> they appear, and sometimes holding "old" entries for perusal, and
> re-showing updated entries if they're changed.

Some form of that statement should make its way into AtomTerminology[1].

- Sam Ruby

[1] http://www.intertwingly.net/wiki/pie/AtomTerminology



From owner-atom-syntax@mail.imc.org  Fri Jul  9 08: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 IAA21878
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 08: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 i69BhKlb054654;
	Fri, 9 Jul 2004 04:43: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 i69BhKWa054653;
	Fri, 9 Jul 2004 04:43:20 -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 i69BhJYr054646
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 04:43:20 -0700 (PDT)
	(envelope-from distobj@acm.org)
Received: from mbaker by bork.markbaker.ca with local (Exim 3.35 #1 (Debian))
	id 1BitnB-0002up-00; Fri, 09 Jul 2004 07:43:49 -0400
Date: Fri, 9 Jul 2004 07:43:49 -0400
To: Sam Ruby <rubys@intertwingly.net>
Cc: "'Atom Syntax'" <atom-syntax@imc.org>
Subject: Re: IRIs, URIs, and RFC 2396bis
Message-ID: <20040709114349.GN30868@markbaker.ca>
References: <20040708031231.GL30868@markbaker.ca> <200407081521.BHL98254@ms8.netsolmail.com> <20040708232623.GM30868@markbaker.ca> <40EE7DD3.7000501@intertwingly.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <40EE7DD3.7000501@intertwingly.net>
User-Agent: Mutt/1.3.28i
From: Mark Baker <distobj@acm.org>
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>


Sorry, I just meant RFCs which obsolete other RFCs.  And by "that's
what happens", I mean that's what I've observed in the IETF in the past
viz a viz RFCs 2068/2616 and 2396/2396bis.

On Fri, Jul 09, 2004 at 07:13:23AM -0400, Sam Ruby wrote:
> >Or it would mean that documents which obsolete other documents would
> >need to be developed with the utmost care for compatibility issues.
> >Oh wait, that's what happens. 8-)
> 
> Counter example, from The Atom Syndication Format 0.3 (PRE-DRAFT) [1]:
> 
>     the canonical serialization of an Atom document is XML 1.0, and this
>     is the only serialization that can be identified with the
>     "application/atom+xml" media type.
> 
> - Sam Ruby
> 
> [1]<http://www.mnot.net/drafts/draft-nottingham-atom-format-02.html#rfc.section.2>

-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

  Seeking work on large scale application/data integration projects
  and/or the enabling infrastructure for same.



From owner-atom-syntax@mail.imc.org  Fri Jul  9 08:08: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 IAA22078
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 08:08: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 i69BxnDR056838;
	Fri, 9 Jul 2004 04:59: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 i69BxnfD056837;
	Fri, 9 Jul 2004 04:59:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from lakermmtao10.cox.net (lakermmtao10.cox.net [68.230.240.29])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i69BxmhZ056824
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 04:59:48 -0700 (PDT)
	(envelope-from millennium@spoonybards.net)
Received: from [10.0.1.2] (really [68.105.186.6]) by lakermmtao10.cox.net
          (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with ESMTP
          id <20040709115943.EBDF25843.lakermmtao10.cox.net@[10.0.1.2]>;
          Fri, 9 Jul 2004 07:59:43 -0400
Message-ID: <40EE88B0.5010607@spoonybards.net>
Date: Fri, 09 Jul 2004 07:59:44 -0400
From: Beecher Greenman <millennium@spoonybards.net>
User-Agent: Mozilla Thunderbird 0.7 (Macintosh/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
CC: Walter Underwood <wunder@verity.com>, Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Q: modfied vs issued vs created
References: <14543268.1088887310064.JavaMail.dtcd@mac.com> <opsatdbjsxuvpchu@quark> <B3BCF453B616D4D7E8AFDE67@adsl-64-166-133-244.dsl.snfc21.pacbell.net> <opsat0zze1uvpchu@quark>
In-Reply-To: <opsat0zze1uvpchu@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 Thu, 08 Jul 2004 09:00:24 -0700, Walter Underwood 
> <wunder@verity.com>  wrote:
> 
>> Never? Even if there is a mistake in the issued date? The server is
>> required to send the wrong date forever?
> 
> Of course not. I'm sure you know what I'm talking about. The <issued> 
> date  should not change once it's first set (correctly).

Perhaps there should be some kind of clarification on when <issued> 
should change, in that case? The real-world issue date never changes; 
once you've done it, you've done it. The <atom:issued> date, therefore, 
should only change if the previous date was incorrect.

>> I would prefer "published" instead of "issued" by the way. Blog
>> software mostly talks about publishing entries, not issuing them.
> 
> I know, but we're trying to be conformant with Dublin Core which uses 
> the  term 'issued'.

Indeed. Although "published" is the established term in blog software, 
using it here when a more general term exists would move us back towards 
blog-centricity. As I understand it, that's something we're trying to avoid.

- Beecher Greenman



From owner-atom-syntax@mail.imc.org  Fri Jul  9 08:11: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 IAA22205
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 08: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 i69BrgaT056282;
	Fri, 9 Jul 2004 04:53:42 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i69Brg6h056281;
	Fri, 9 Jul 2004 04:53:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from lakermmtao09.cox.net (lakermmtao09.cox.net [68.230.240.30])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i69BrfuL056273
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 04:53:42 -0700 (PDT)
	(envelope-from millennium@spoonybards.net)
Received: from [10.0.1.2] (really [68.105.186.6]) by lakermmtao09.cox.net
          (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with ESMTP
          id <20040709115338.VYIF12076.lakermmtao09.cox.net@[10.0.1.2]>
          for <atom-syntax@imc.org>; Fri, 9 Jul 2004 07:53:38 -0400
Message-ID: <40EE8741.4020703@spoonybards.net>
Date: Fri, 09 Jul 2004 07:53:37 -0400
From: Beecher Greenman <millennium@spoonybards.net>
User-Agent: Mozilla Thunderbird 0.7 (Macintosh/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Atom-Syntax <atom-syntax@imc.org>
Subject: PaceIntrospection: New Examples for Feed-Based Introspection
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


I apologize for my extended absence from the list. I've been asked to 
provide some use cases for the feed-based introspection we've been 
discussing; here are two.

Use Case: Presenting a list of services to a service's owner
============================================================

A user "bob" is responsible for several services on example.org. He 
wants to see a list of every service for which he is responsible, in 
order that he may choose between them inside his client. The client 
requests this at a URL dedicated to this task, perhaps 
http://example.org/users/bob/services.atom. The server returns an Atom 
feed, similar to the following (comments have been added to the first 
entry):

Example
-------

<feed version="0.3"
   xmlns="http://purl.org/atom/ns#" xml:lang="en">
   <title>Blogs for bob</title>
   <!-- link rel="alternate": This could point to an HTML-based list
     ** of sites, or possibly a user's profile, be it public
     ** or private. -->
   <link rel="alternate" type="text/html" 
href="http://manyblogs.org/users/bob"/>
   <author>
     <name>bob</name>
   </author>
   <!-- modified: Time when the last service was created or updated -->
   <modified>2004-06-24T19:14:06Z</modified>
   <entry>
     <title>First Site</title>
     <link rel="alternate" type="text/html" 
href="http://manyblogs.org/bob/FirstSite"/>
     <!-- Feed and Post URLs -->
     <link type="application/atom+xml" rel="service.post" 
href="http://manyblogs.org/bob/FirstSite/post"/>
     <link type="application/atom+xml" rel="service.feed" 
href="http://manyblogs.org/bob/FirstSite/feed"/>
     <!-- issued: Time when service was first published. -->
     <issued>2004-06-24T19:14:06Z</issued>
     <!-- modified: Time when blog was last updated -->
     <modified>2004-06-24T19:14:06Z</modified>
     <id>tag:manyblogs.org,2004-06-24:/bob/FirstSite</id>
   </entry>
   <entry>
     <title>Second Site</title>
     <link rel="alternate" type="text/html" 
href="http://manyblogs.org/bob/SecondSite"/>
     <link type="application/atom+xml" rel="service.post" 
href="http://manyblogs.org/bob/SecondSite/post"/>
     <link type="application/atom+xml" rel="service.feed" 
href="http://manyblogs.org/bob/SecondSite/feed"/>
     <issued>2004-06-24T19:14:06Z</issued>
     <modified>2004-06-24T19:14:06Z</modified>
     <id>tag:manyblogs.org,2004-06-24:/bob/SecondSite</id>
   </entry>
   <entry>
     <title>Third Site</title>
     <link rel="alternate" type="text/html" 
href="http://manyblogs.org/bob/ThirdSite"/>
     <link type="application/atom+xml" rel="service.post" 
href="http://manyblogs.org/bob/ThirdSite/post"/>
     <link type="application/atom+xml" rel="service.feed" 
href="http://manyblogs.org/bob/ThirdSite/feed"/>
     <issued>2004-06-24T19:14:06Z</issued>
     <modified>2004-06-24T19:14:06Z</modified>
     <id>tag:manyblogs.org,2004-06-24:/bob/ThirdSite</id>
   </entry>
</feed>


Use Case 2: Answering Silly Questions
=====================================

There has been some debate on whether an introspection file ought to 
include the site's capabilities or not, since these can be found in the 
<link> tags of the service's HTML (and usually its associated feed) as 
well. While I disagree with the idea of disallowing capabilities 
completely, I can see utility in making capabilities optional. A server 
might, for example, only send capabilities to people authorized to use 
them. In any case, here is a use case which covers one possible scenario.

It was bound to happen someday: MemeGen has been ported to use 
example.org. While the original MemeGen scrapes a single blog's RSS feed 
to gather the data used to answer online quizzes, this version attempts 
to scrape the feeds for all of a user's blogs. Bob decides to use this 
site, one day, to find out what race he would be in Tolkien's _Lord of 
the Rings_. He provides MemeGen with the URL for one of his sites.

The first thing MemeGen does is look for an introspection file, which it 
finds from that site's <link rel="service.introspection" /> tag. It then 
sends a request to the URL given in that site's tag. Because it is not 
authenticated, the server decides not to send all of the sites' 
capabilities. MemeGen receives the following:

Example
-------

<feed version="0.3"
   xmlns="http://purl.org/atom/ns#" xml:lang="en">
   <title>Blogs for bob</title>
   <link rel="alternate" type="text/html" 
href="http://manyblogs.org/users/bob"/>
   <author>
     <name>bob</name>
   </author>
   <modified>2004-06-24T19:14:06Z</modified>
   <entry>
     <title>First Site</title>
     <link rel="alternate" type="text/html" 
href="http://manyblogs.org/bob/FirstSite"/>
     <issued>2004-06-24T19:14:06Z</issued>
     <modified>2004-06-24T19:14:06Z</modified>
     <id>tag:manyblogs.org,2004-06-24:/bob/FirstSite</id>
   </entry>
   <entry>
     <title>Second Site</title>
     <link rel="alternate" type="text/html" 
href="http://manyblogs.org/bob/SecondSite"/>
     <issued>2004-06-24T19:14:06Z</issued>
     <modified>2004-06-24T19:14:06Z</modified>
     <id>tag:manyblogs.org,2004-06-24:/bob/SecondSite</id>
   </entry>
   <entry>
     <title>Third Site</title>
     <link rel="alternate" type="text/html" 
href="http://manyblogs.org/bob/ThirdSite"/>
     <issued>2004-06-24T19:14:06Z</issued>
     <modified>2004-06-24T19:14:06Z</modified>
     <id>tag:manyblogs.org,2004-06-24:/bob/ThirdSite</id>
   </entry>
</feed>

MemeGen then requests each site in turn, scrapes their data (possibly 
using feeds as discovered from each page), and presents Bob with the 
happy news that he would be an elf.

It's worth noting that Ken MacLeod and Steve Jenson have recently 
proposed that <title> and <id> elements be added to the current 
PaceIntrospection proposal's <site> tag. Both of these seem to have been 
inspired by the similar tags in the feed format, and since what I'm 
proposing uses that format, it already includes both of those tags.

- Beecher Greenman



From owner-atom-syntax@mail.imc.org  Fri Jul  9 08:21:48 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22656
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 08:21:48 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i69C6sMa057656;
	Fri, 9 Jul 2004 05:06: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 i69C6scM057655;
	Fri, 9 Jul 2004 05:06:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from lakermmtao04.cox.net (lakermmtao04.cox.net [68.230.240.35])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i69C6ruo057643
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 05:06:54 -0700 (PDT)
	(envelope-from millennium@spoonybards.net)
Received: from [10.0.1.2] (really [68.105.186.6]) by lakermmtao04.cox.net
          (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with ESMTP
          id <20040709120650.VOQD29176.lakermmtao04.cox.net@[10.0.1.2]>;
          Fri, 9 Jul 2004 08:06:50 -0400
Message-ID: <40EE8A59.7090607@spoonybards.net>
Date: Fri, 09 Jul 2004 08:06:49 -0400
From: Beecher Greenman <millennium@spoonybards.net>
User-Agent: Mozilla Thunderbird 0.7 (Macintosh/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonas Galvez <jg@jonasgalvez.com>
CC: AtomSyntax <atom-syntax@imc.org>
Subject: Re: Q: modfied vs issued vs created
References: <40E5C9C2.4060507@jonasgalvez.com> <m34qoqt8ts.fsf@bitsko.slc.ut.us> <40E5E922.1070909@jonasgalvez.com>
In-Reply-To: <40E5E922.1070909@jonasgalvez.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


Jonas Galvez wrote:

> 
> Ken MacLeod wrote:
>  > <issued> is nominally a user-provided value whereas <created> and
>  > <modified> are publishing system provided values.
>  >
>  > <issued> can be in the future, for example, to indicate, to a
>  > publishing systems that supports it, that the entry should be
>  > published at a future time.  <created> would still reflect the time
>  > the entry was created.
>  >
>  > <created> is logically the first value ever of <modified>, but if
>  > it's missing you can use any current value of <modified>
>  >
>  > This topic comes up often enough that it should be clarified in the
>  > spec, particularly as clarifies interoperable behavior for clients
>  > and servers.
> 
> Asbjørn Ulsberg wrote:
>  > This has been explained on numerous occasions, but I'll do it again:
>  > The difference between 'issued' and 'created' is that an article can
>  > be created, edited for six years, and then published to a public web
>  > site. 'created' is then the initial creation date, and 'issued' is
>  > the date of when the article was publicly available (created + six
>  > years in this case).
> 
> Paul Hoffman / IMC wrote:
>  > Please don't apologize. If the spec is unclear on this (and as a
>  > native speaker of English, even I have a hard time keeping the three
>  > straight), it's perfectly reasonable to ask for clarification.
> 
> 
> Thanks all, it makes sense to me now.
> 
> I think this explanation should definitely go into the spec.
>
+1 on that. I had the same questions myself once, and from the 
explanation given to me then it seems that this confuses a lot of 
people. However, I have one more question: does issuing an entry count 
as a modification in and of itself?

Suppose that an article is created on April 1. It is modified on April 2 
and then sits around for a week. It is finally published on April 8, but 
no changes made to the text. Are <atom:issued> and <atom:modified> both 
April 8, or is <atom:modified> still April 2, since that is when the 
last change was made to the content?

- Beecher Greenman



From owner-atom-syntax@mail.imc.org  Fri Jul  9 09: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 JAA25613
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 09: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 i69Ctk17063360;
	Fri, 9 Jul 2004 05:55: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 i69Ctk73063359;
	Fri, 9 Jul 2004 05:55:46 -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 i69CtiLE063333
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 05:55: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 B0D097C117; Fri,  9 Jul 2004 15:54:25 +0200 (CEST)
Date: Fri, 09 Jul 2004 14:59:01 +0200
To: "Beecher Greenman" <millennium@spoonybards.net>
Subject: Re: Q: modfied vs issued vs created
References: <40E5C9C2.4060507@jonasgalvez.com> <m34qoqt8ts.fsf@bitsko.slc.ut.us> <40E5E922.1070909@jonasgalvez.com> <40EE8A59.7090607@spoonybards.net>
Cc: Atom-Syntax <atom-syntax@imc.org>
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: <opsavfonjtuvpchu@quark>
In-Reply-To: <40EE8A59.7090607@spoonybards.net>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 09 Jul 2004 08:06:49 -0400, Beecher Greenman  
<millennium@spoonybards.net> wrote:

>>  I think this explanation should definitely go into the spec.
>
> +1 on that.

Yup: <url: http://intertwingly.net/wiki/pie/PaceEntryDates>

> does issuing an entry count as a modification in and of itself?

I hope not. I would at least not see it as a modification. This should  
probably also be noted in the pace, so I've edited it so it does.

> Are <atom:issued> and <atom:modified> both April 8, or is
> <atom:modified> still April 2, since that is when the last change
> was made to the content?

'atom:modified' should reflect the last change to the _content_ of the  
entry, and the dates of the entry is not a part of the content. Imho. This  
should be clear, as well as what should happen with 'atom:issued' when an  
article is re-issued. I think an article should retain the original  
'issued' date for the whole lifetime of an entry, and never change.

-- 
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 Jul  9 09:34:33 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26862
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 09:34:32 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i69DCUIC065753;
	Fri, 9 Jul 2004 06:12: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 i69DCUU7065751;
	Fri, 9 Jul 2004 06:12: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 i69DCT39065738
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 06:12: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 D55457C11E; Fri,  9 Jul 2004 16:11:14 +0200 (CEST)
To: "Sam Ruby" <rubys@intertwingly.net>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Thought experiment: Using a synthetic feed to find out about other feeds
References: <200407081614.BHM20108@ms8.netsolmail.com> <m3hdsiqspb.fsf@bitsko.slc.ut.us> <40EE7F98.6040207@intertwingly.net>
Message-ID: <opsavggornuvpchu@quark>
Date: Fri, 09 Jul 2004 15:15:50 +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: <40EE7F98.6040207@intertwingly.net>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 09 Jul 2004 07:20:56 -0400, Sam Ruby <rubys@intertwingly.net>  
wrote:

>> An aggregator works on the principle of displaying new entries when
>> they appear, and sometimes holding "old" entries for perusal, and
>> re-showing updated entries if they're changed.
>
> Some form of that statement should make its way into AtomTerminology[1].

Done. I've also sorted the definition terms alphabetically, to make the  
list more readable.

-- 
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 Jul  9 09:43: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 JAA27157
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 09:43: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 i69DSOTg067620;
	Fri, 9 Jul 2004 06:28: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 i69DSOcn067619;
	Fri, 9 Jul 2004 06:28: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 i69DSNV7067607
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 06:28: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 73FD37C117; Fri,  9 Jul 2004 16:27:08 +0200 (CEST)
Date: Fri, 09 Jul 2004 15:31:47 +0200
To: "Beecher Greenman" <millennium@spoonybards.net>
Subject: Re: Q: modfied vs issued vs created
Cc: "Walter Underwood" <wunder@verity.com>, Atom-Syntax <atom-syntax@imc.org>
References: <14543268.1088887310064.JavaMail.dtcd@mac.com> <opsatdbjsxuvpchu@quark> <B3BCF453B616D4D7E8AFDE67@adsl-64-166-133-244.dsl.snfc21.pacbell.net> <opsat0zze1uvpchu@quark> <40EE88B0.5010607@spoonybards.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: <opsavg69xpuvpchu@quark>
In-Reply-To: <40EE88B0.5010607@spoonybards.net>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 09 Jul 2004 07:59:44 -0400, Beecher Greenman  
<millennium@spoonybards.net> wrote:

> Perhaps there should be some kind of clarification on when <issued>  
> should change, in that case?

In my humble opinion, it should never change -- unless, of course -- the  
first time it's set incorrectly. That goes for 'atom:created' too; it  
shouldn't change once it's first set (correctly).

> The real-world issue date never changes; once you've done it, you've
> done it. The <atom:issued> date, therefore, should only change if
> the previous date was incorrect.

Bulls eye. :-)

> Indeed. Although "published" is the established term in blog software,
> using it here when a more general term exists would move us back towards  
> blog-centricity. As I understand it, that's something we're trying to  
> avoid.

Bulls eye again. I'm very satisfied with the term 'issued', and I'm one of  
the lonely developers on Atom that aren't going to (primarily) implement  
it in a blog, but rather on a pretty huge (in Norwegian scale ;) news  
publishing service.

-- 
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 Jul  9 10:06:50 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28283
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 10:06: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 i69Dn0JV069985;
	Fri, 9 Jul 2004 06: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 i69Dn0bn069984;
	Fri, 9 Jul 2004 06:49:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from imo-m20.mx.aol.com (imo-m20.mx.aol.com [64.12.137.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i69Dmxdg069968
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 06:49:00 -0700 (PDT)
	(envelope-from Svgdeveloper@aol.com)
Received: from Svgdeveloper@aol.com
	by imo-m20.mx.aol.com (mail_out_v37_r2.6.) id 7.bd.428e9aba (3842)
	 for <atom-syntax@imc.org>; Fri, 9 Jul 2004 09:48:53 -0400 (EDT)
From: Svgdeveloper@aol.com
Message-ID: <bd.428e9aba.2e1ffc45@aol.com>
Date: Fri, 9 Jul 2004 09:48:53 EDT
Subject: [Atom] Issued "publicly" - It doesn't always happen
To: atom-syntax@imc.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_bd.428e9aba.2e1ffc45_boundary"
X-Mailer: 8.0 for Windows sub 670
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>



--part1_bd.428e9aba.2e1ffc45_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

It seems to me that there is an assumption being made currently about 
"issued" which is not necessarily correct.

One source of information I use plans to have password protected information 
feeds. By design those information feeds will never be *publicly* issued, yet 
they will be issued to those authorised to access that information.

Since the definition of "issued" on 
http://intertwingly.net/wiki/pie/PaceEntryDates refers to public availability it seems to me that some other term is 
more appropriate.

"Formally" perhaps? "Intentionally"? Something else?

Andrew Watt

--part1_bd.428e9aba.2e1ffc45_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML><FONT FACE=3Darial,helvetica><HTML><FONT  SIZE=3D2 PTSIZE=3D10 FAMILY=
=3D"SANSSERIF" FACE=3D"Arial" LANG=3D"0">It seems to me that there is an ass=
umption being made currently about "issued" which is not necessarily correct=
.<BR>
<BR>
One source of information I use plans to have password protected information=
 feeds. By design those information feeds will never be *publicly* issued, y=
et they will be issued to those authorised to access that information.<BR>
<BR>
Since the definition of "issued" on <A HREF=3D"http://intertwingly.net/wiki/=
pie/PaceEntryDates">http://intertwingly.net/wiki/pie/PaceEntryDates</A> refe=
rs to public availability it seems to me that some other term is more approp=
riate.<BR>
<BR>
"Formally" perhaps? "Intentionally"? Something else?<BR>
<BR>
Andrew Watt</FONT></HTML>

--part1_bd.428e9aba.2e1ffc45_boundary--



From owner-atom-syntax@mail.imc.org  Fri Jul  9 11:03: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 LAA04263
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 11:03: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 i69Eh0Bg077192;
	Fri, 9 Jul 2004 07:43: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 i69Eh0i2077191;
	Fri, 9 Jul 2004 07:43:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.206])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i69EgwB4077183
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 07:42:59 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d15so142685rng
        for <atom-syntax@imc.org>; Fri, 09 Jul 2004 07:42:57 -0700 (PDT)
Received: by 10.38.9.12 with SMTP id 12mr110787rni;
        Fri, 09 Jul 2004 07:42:57 -0700 (PDT)
Message-ID: <14be96d304070907427b1d83cb@mail.gmail.com>
Date: Fri, 9 Jul 2004 10:42:57 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: "Asbjørn Ulsberg" <asbjorn@tigerstaden.no>
Subject: Re: Q: modfied vs issued vs created
Cc: Beecher Greenman <millennium@spoonybards.net>,
        Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <opsavfonjtuvpchu@quark>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
References: <40E5C9C2.4060507@jonasgalvez.com> <m34qoqt8ts.fsf@bitsko.slc.ut.us> <40E5E922.1070909@jonasgalvez.com> <40EE8A59.7090607@spoonybards.net> <opsavfonjtuvpchu@quark>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i69Eh0B4077185
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, 09 Jul 2004 14:59:01 +0200, Asbjørn Ulsberg
<asbjorn@tigerstaden.no> wrote:
> Yup: <url: http://intertwingly.net/wiki/pie/PaceEntryDates>

Current Atom pre-draft says that atom:modified and atom:created MUST
include a timezone, and atom:issued MAY include a timezone.

As of today, PaceEntryDates says that atom:modified and atom:created
SHOULD include a timezone, and atom:issued MUST include a timezone.

In other words, this Pace completely redefines which timezones are
optional and which are required.  Was that intentional?  Did I miss a
meeting?

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Fri Jul  9 11:20: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 LAA05061
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 11:20: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 i69F38rU079205;
	Fri, 9 Jul 2004 08:03: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 i69F38XH079204;
	Fri, 9 Jul 2004 08:03:08 -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 i69F37QZ079195
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 08:03:07 -0700 (PDT)
	(envelope-from roger@agincourtmedia.com)
Received: from biggreen ([216.63.148.42]) by journurl.com with MailEnable ESMTP; Fri, 09 Jul 2004 10:02:37 -0500
From: "Roger B." <roger@agincourtmedia.com>
To: "=?iso-8859-1?Q?'Asbj=F8rn_Ulsberg'?=" <asbjorn@tigerstaden.no>
Cc: "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: RE: Q: modfied vs issued vs created
Date: Fri, 9 Jul 2004 10:07:45 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <opsavg69xpuvpchu@quark>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Thread-Index: AcRluNvY2wyRA0voQBm8MjZzD124UwACdcrA
Message-ID: <38BB5C3590DB423490D1A9F34DA.MAI@journurl.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i69F37QZ079199
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


> In my humble opinion, it should never change -- unless, of course -- the
> first time it's set incorrectly. That goes for 'atom:created' too; it
> shouldn't change once it's first set (correctly).

Asbjørn: Issued is an end-user feature in most systems that implement it...
it can (and will) be changed as often as the user sees fit.

Created should generally be more static, since it's usually defined by the
system. Ditto for modified. So while it might be safe to make assumptions
about those two, issued is just user-defined metadata that isn't subject to
specification.

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/ 








From owner-atom-syntax@mail.imc.org  Fri Jul  9 11:24: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 LAA05331
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 11:24: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 i69F8bZu079671;
	Fri, 9 Jul 2004 08:08: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 i69F8bNH079670;
	Fri, 9 Jul 2004 08:08:37 -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 i69F8b9D079650
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 08:08:37 -0700 (PDT)
	(envelope-from roger@agincourtmedia.com)
Received: from biggreen ([216.63.148.42]) by journurl.com with MailEnable ESMTP; Fri, 09 Jul 2004 10:08:09 -0500
From: "Roger B." <roger@agincourtmedia.com>
To: "=?iso-8859-1?Q?'Asbj=F8rn_Ulsberg'?=" <asbjorn@tigerstaden.no>
Cc: "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: RE: Q: modfied vs issued vs created
Date: Fri, 9 Jul 2004 10:13:15 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <opsavfonjtuvpchu@quark>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Thread-Index: AcRltE8ro9f4UnZASrOAvfVn52QNJQAEeSDw
Message-ID: <C31A0E20DFF24B11A68DEFC78B8B3.MAI@journurl.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i69F8b9D079663
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


> > does issuing an entry count as a modification in and of itself?
> 
> I hope not. I would at least not see it as a modification. This should
> probably also be noted in the pace, so I've edited it so it does.

Asbjørn: Bad idea. The issued date is generally going to be set within the
context of an entry editor, just like keywords or any other metadata. And
when the user hits "Submit", the modified date is likely to change, just as
it would if the summary, category, or any other user-defined info was
touched.

> 'atom:modified' should reflect the last change to the _content_ of the
> entry, and the dates of the entry is not a part of the content.

From the user's perspective, the issued date is most certainly part of the
content.

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/ 







From owner-atom-syntax@mail.imc.org  Fri Jul  9 11:37: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 LAA05954
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 11:37: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 i69FQ25o081716;
	Fri, 9 Jul 2004 08: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 i69FQ2q4081715;
	Fri, 9 Jul 2004 08:26: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 i69FQ0jr081702
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 08:26: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 2DB8F7C0F3; Fri,  9 Jul 2004 18:24:41 +0200 (CEST)
To: "Mark Pilgrim" <pilgrim@gmail.com>
Cc: "Beecher Greenman" <millennium@spoonybards.net>,
        Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Q: modfied vs issued vs created
References: <40E5C9C2.4060507@jonasgalvez.com> <m34qoqt8ts.fsf@bitsko.slc.ut.us> <40E5E922.1070909@jonasgalvez.com> <40EE8A59.7090607@spoonybards.net> <opsavfonjtuvpchu@quark> <14be96d304070907427b1d83cb@mail.gmail.com>
Message-ID: <opsavmnyuouvpchu@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: Fri, 09 Jul 2004 17:29:48 +0200
In-Reply-To: <14be96d304070907427b1d83cb@mail.gmail.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 9 Jul 2004 10:42:57 -0400, Mark Pilgrim <pilgrim@gmail.com> wrote:

> Current Atom pre-draft says that atom:modified and atom:created MUST
> include a timezone, and atom:issued MAY include a timezone.

+1.

> As of today, PaceEntryDates says that atom:modified and atom:created
> SHOULD include a timezone, and atom:issued MUST include a timezone.
>
> In other words, this Pace completely redefines which timezones are
> optional and which are required.  Was that intentional?  Did I miss a
> meeting?

I dunno.

-- 
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 Jul  9 11:43: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 LAA06247
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 11:43: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 i69FTj4A082252;
	Fri, 9 Jul 2004 08: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 i69FTjG6082251;
	Fri, 9 Jul 2004 08:29: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 i69FTiAX082241
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 08:29: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 2337B7C0F3; Fri,  9 Jul 2004 18:28:30 +0200 (CEST)
Date: Fri, 09 Jul 2004 17:33:40 +0200
To: "Roger B." <roger@agincourtmedia.com>
Subject: Re: Q: modfied vs issued vs created
Cc: "'Atom-Syntax'" <atom-syntax@imc.org>
References: <38BB5C3590DB423490D1A9F34DA.MAI@journurl.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: <opsavmuenauvpchu@quark>
In-Reply-To: <38BB5C3590DB423490D1A9F34DA.MAI@journurl.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 9 Jul 2004 10:07:45 -0500, Roger B. <roger@agincourtmedia.com>  
wrote:

> Asbjørn: Issued is an end-user feature in most systems that implement  
> it... it can (and will) be changed as often as the user sees fit.

Then 'created' MUST be required, because knowing when an article about  
e.g. «The next big thing: CD's» is not only important, but vital to what  
the article means when read in 2004.

> Created should generally be more static, since it's usually defined by  
> the system.

It MUST be static and imho MUST be present, at least if 'issued' is a  
«whatever you feel like» date.

> Ditto for modified. So while it might be safe to make assumptions about
> those two, issued is just user-defined metadata that isn't subject to  
> specification.

Then 'issued' should really be the optional date, since that is the most  
bogus piece of information present in the whole Atom format. I wasn't  
aware of that until just now.

-- 
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 Jul  9 11: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 LAA06436
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 11:45: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 i69FavVu082855;
	Fri, 9 Jul 2004 08:36:57 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i69FavBU082854;
	Fri, 9 Jul 2004 08:36:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i69FauD6082839
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 08:36: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 320BF7C0F3; Fri,  9 Jul 2004 18:35:42 +0200 (CEST)
Date: Fri, 09 Jul 2004 17:40:54 +0200
To: "Roger B." <roger@agincourtmedia.com>
Subject: Re: Q: modfied vs issued vs created
Cc: "'Atom-Syntax'" <atom-syntax@imc.org>
References: <C31A0E20DFF24B11A68DEFC78B8B3.MAI@journurl.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: <opsavm6g0ruvpchu@quark>
In-Reply-To: <C31A0E20DFF24B11A68DEFC78B8B3.MAI@journurl.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 9 Jul 2004 10:13:15 -0500, Roger B. <roger@agincourtmedia.com>  
wrote:

> Bad idea. The issued date is generally going to be set within the context
> of an entry editor, just like keywords or any other metadata. And when
> the user hits "Submit", the modified date is likely to change, just as it
> would if the summary, category, or any other user-defined info was  
> touched.

But what is the purpose of having 'issued' in the format at all, if it's  
basically just some random string, formatted as a W3CDTF?

> From the user's perspective, the issued date is most certainly part of  
> the content.

That would depend on the user, apparently. If Atom is going to fulfill  
more than just some wierd blog tools' needs, the perceptance of what  
'issued' is needs to change. Having worked on some major CMS's over the  
last few years, 'issued' is _not_ a random string entered by the user, and  
it is extremely important for the context and meaning of an article when  
it was initially created and/or issued to the public.

An example I just wrote on #atom:

For a twenty year old article about «The next big thing: CD's!» which have  
been re-issued ten times the last few years because of domain and URI  
restructuring, it might have the dates: <issued>2002-08-03</issued> and  
<modified>2004-03-18</modified>. (It might not even have <modified>.) Ok,  
nice to know when the article was last modified, but who the heck writes  
about «The next big thing: CD's» in 2002?!

-- 
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 Jul  9 11: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 LAA06720
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 11: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 i69Fe0g8083102;
	Fri, 9 Jul 2004 08:40: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 i69Fe05V083101;
	Fri, 9 Jul 2004 08:40:00 -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 i69Fdx0C083084
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 08:39: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 875147C0F3; Fri,  9 Jul 2004 18:38:44 +0200 (CEST)
Date: Fri, 09 Jul 2004 17:43:57 +0200
To: Svgdeveloper@aol.com
Subject: Re: [Atom] Issued "publicly" - It doesn't always happen
References: <bd.428e9aba.2e1ffc45@aol.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
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: <opsavnbjmfuvpchu@quark>
In-Reply-To: <bd.428e9aba.2e1ffc45@aol.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 9 Jul 2004 09:48:53 EDT, <Svgdeveloper@aol.com> wrote:

> One source of information I use plans to have password protected  
> information feeds. By design those information feeds will never be
> *publicly* issued, yet they will be issued to those authorised to
> access that information.

It should probably be more thoroughly specified, but «public» here does  
not necessarily mean «to the world» or «on the internet». It means «not  
only to the author»; that is when the entry was published and made  
available to whatever audience the entry was written for. I will try to  
find a good way to write this into the pace if we can just reach consensus  
on what 'issued' is first. :-)

-- 
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 Jul  9 12:04: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 MAA07454
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 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 i69FsWfv084434;
	Fri, 9 Jul 2004 08:54: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 i69FsW5K084433;
	Fri, 9 Jul 2004 08:54: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 ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i69FsViI084424
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 08:54: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 577257C0F3; Fri,  9 Jul 2004 18:53:17 +0200 (CEST)
Date: Fri, 09 Jul 2004 17:57:29 +0200
To: Graham <dtcd@mac.com>
Subject: Re: Q: modfied vs issued vs created
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <14543268.1088887310064.JavaMail.dtcd@mac.com> <opsatdbjsxuvpchu@quark> <D2E68A4E-D125-11D8-ACB6-000A95DC3D90@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: <opsavnx3k4uvpchu@quark>
In-Reply-To: <D2E68A4E-D125-11D8-ACB6-000A95DC3D90@mac.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Thu, 8 Jul 2004 17:28:58 -0400, Graham <dtcd@mac.com> wrote:

> Not necessarily. The other way to do it is to say that you must also
> supply a <created> date if you change <issued> - or in other words,
> <created> is required if it differs significantly from <issued>.

I could live with that.

>> True, but I don't think it's a good idea to not only allow, but to
>> encourage, publishers to update this field whenever they reissue the
>> article. If so, we should have both <first-issued> and <last-issued>
>> elements.
>
> I'd imagine <first-issued> ~= <created> would be true in most cases.

Absolutely. Therefore it would be better to require 'created'. If it's so  
that the system doesn't distinguish between 'created' and 'issued', then  
just have them be the same in the Atom format. No one complains if they  
are the same, but I will comlain loudly if 'issued' isn't «first issued»  
and 'created' is missing from the entry. :-)

> And anyway, I don't think it's necessary for entries to include their
> full history

Full history is not necessary. I, for one, have absolutely no interest in  
when the entry was «last issued». When it was created and/or first issued,  
though, is of high interest to me (and should be to everyone else reading  
it).

> do they also have to supply details of older revisions?

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  Fri Jul  9 12:32: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 MAA08898
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 12:32: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 i69GIq4w086550;
	Fri, 9 Jul 2004 09:18: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 i69GIqK5086549;
	Fri, 9 Jul 2004 09:18:52 -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 i69GIqgP086525
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 09:18: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 (rwcrmhc12) with SMTP
          id <2004070916184701400leu3ke>; Fri, 9 Jul 2004 16:18:47 +0000
Date: Fri, 9 Jul 2004 10:18:46 -0600
Mime-Version: 1.0 (Apple Message framework v553)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Subject: PaceElementOrder
From: Antone Roundy <antone@geckotribe.com>
To: atom-syntax@imc.org
Content-Transfer-Encoding: 7bit
Message-Id: <A79D00D0-D1C3-11D8-89AD-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


> Ordering of the atom:entry element children of atom:feed element MUST 
> NOT be considered significant.
As we all know, there is a common convention to order RSS items and 
Atom entries in reverse chronological order.  While I'm CERTAINLY in 
favor of not requiring this, this wording seems to me to frown on that 
convention--not for the generator, which can order things however it 
wants, but to frown on client software which renders the entries in the 
order they appear in the feed.  If we were to add language suggesting 
that generators MAY order the entries in the order they suggest they be 
rendered, or if we were to add an OPTIONAL capability for indicating 
the recommended ordering (I'm not a fan of RSS 1.0 partly because it 
requires the sequence list...I for one would go with ordering the 
entries in a suggested presentation order over this), there would be 
some value in that.

One could say that the date elements are sufficient to indicate 
ordering, but there are a few problems with that idea:

1) Chronological order may not always make sense.
2) Which of the Date Constructs should be used?
3) Stream-based processors which output the entries as they process 
them would have to build in provisions for reordering, which could be 
overly burdensome in some circumstances (memory requirements for large 
feeds on devices with little memory, etc.)  This is also an argument 
against adding a capability for suggesting ordering separate from the 
actual order of the entries themselves.

All that said, I'm not TOO worried about this, but thought I'd throw 
these ideas out there.

Antone



From owner-atom-syntax@mail.imc.org  Fri Jul  9 12:52: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 MAA10065
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 12:52: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 i69GfnrM088856;
	Fri, 9 Jul 2004 09:41: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 i69Gfns4088853;
	Fri, 9 Jul 2004 09:41:49 -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 i69Gfnuu088840
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 09:41: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 (rwcrmhc13) with SMTP
          id <2004070916414501500hv9fae>; Fri, 9 Jul 2004 16:41:45 +0000
Date: Fri, 9 Jul 2004 10:41:44 -0600
Subject: Re: Q: modfied vs issued vs created
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: <opsavnx3k4uvpchu@quark>
Message-Id: <DCC93720-D1C6-11D8-89AD-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


I'm getting a little lost (okay, I've been speed reading, so it's my 
fault) with the different ideas for what each of the Date Constructs 
means, and why each is important.  Here's a sequence of events that I 
can image might occur in the creation and publishing of an entry.  The 
first number is a pseudo-timestamp.  That is followed by a description 
of what happened. Next, in square brackets, is a comment which begins 
with "created", "issued" or "modified" if one of those is applicable.

1000 - Author gets an idea for a blog entry, makes a brief 
note-to-self, and saves it as a draft [created & modified - Why does 
anyone but the author need to know this?  The author MAY wish to 
publish this to let people know how long they've been thinking about 
the idea, but this date doesn't exactly equal that, since they may have 
been thinking about it, or even typing it up, for some time before 
saving it as a draft]

1050 - Author adds a few more notes and saves as a draft again [ 
modified - there's even less need for anyone but perhaps the author to 
know this]

1100 - Author posts the entry, unmodified, to their blog [ issued - 
this date matters, does modified change? ]
OR
1100 - Author cleans up the draft and posts it to their blog [ modified 
& issued - this matters ]

1150 - Author decides they want to change the timestamp on the entry, 
either for "personal" reasons or because the clock on whichever 
computer initially set the date(s) was incorrect [ ? - are there any 
that they MUST NOT change? ]

1200 - Author udpates the entry and posts it to their blog [ modified - 
this matters ]

1300 - Author posts the same entry to another of their blogs without 
any changes--the id for the two entries is the same [ is issued now 
different in the two blogs? ]

1400 - Some aggregator sees the entries in the two blogs and puts one 
of them into a synthetic feed, smartly omitting the other since they 
have the same id [ IF issued is different in the two feeds, which one 
gets used? The earlier one probably makes more sense. ]


Additional comments and questions:
1) Are any of these dates set by the server, or does the client set all 
of them?
	1a) Are we going to specify that?
	1b) Are we going to provide suggestions on that?
2) I can't think of a reason to REQUIRE created.
3) Issued seems like it should be required, and modified, if later than 
(or different from?) issued.


Comments? Corrections?

Perhaps we should have an example timeline like this on the wiki where 
we could refer to it if there's confusion about what each date means 
and when it changes.



From owner-atom-syntax@mail.imc.org  Fri Jul  9 13:10: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 NAA11619
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 13:10:11 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i69Gwr9q090204;
	Fri, 9 Jul 2004 09:58: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 i69GwrGL090203;
	Fri, 9 Jul 2004 09:58:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from beta.verity.com (beta.verity.com [192.187.143.12])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i69GwqOO090193
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 09:58:52 -0700 (PDT)
	(envelope-from wunder@verity.com)
Received: from mx-rr.verity.com ([10.3.100.59])
	by beta.verity.com (8.9.3/8.9.3) with ESMTP id JAA13974
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 09:58:48 -0700 (PDT)
Received: from mx-rr.verity.com (mx-rr.verity.com [10.3.100.59])
	by mx-rr.verity.com (8.9.3/8.9.3) with SMTP id JAA16901
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 09:57:09 -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, 09 Jul 2004 09:57:09 -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 <0I0L00GVPGF82Z@shazam.verity.com> for atom-syntax@imc.org; Fri,
 09 Jul 2004 09:57:08 -0700 (PDT)
Date: Fri, 09 Jul 2004 10:03:03 -0700
From: Walter Underwood <wunder@verity.com>
Subject: Re: [Atom] Issued "publicly" - It doesn't always happen
In-reply-to: <bd.428e9aba.2e1ffc45@aol.com>
To: atom-syntax@imc.org
Message-id: <AF11B396740825BFCE74B84C@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: <bd.428e9aba.2e1ffc45@aol.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 Friday, July 09, 2004 09:48:53 AM -0400 Svgdeveloper@aol.com wrote:

> It seems to me that there is an assumption being made currently about
> "issued" which is not necessarily correct.
>
> One source of information I use plans to have password protected
> information feeds. By design those information feeds will never be
> *publicly* issued, yet they will be issued to those authorised to access
> that information.
>
> Since the definition of "issued" on
> http://intertwingly.net/wiki/pie/PaceEntryDates refers to public
> availability it seems to me that some other term is more appropriate.
>
> "Formally" perhaps? "Intentionally"? Something else?

Since we are using the Dublin Core term we really should use the
Dublin Core definition of that term. From the current set of
defined terms (http://dublincore.org/documents/dcmi-terms/):

  Date of formal issuance (e.g., publication) of the resource.

Issuance does not require public access. It can be published to
the intended audience.

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek



From owner-atom-syntax@mail.imc.org  Fri Jul  9 13:12: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 NAA12040
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 13:12: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 i69H208Z090460;
	Fri, 9 Jul 2004 10:02: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 i69H20XU090459;
	Fri, 9 Jul 2004 10:02:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i69H207Q090448
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 10:02:00 -0700 (PDT)
	(envelope-from jens@apple.com)
Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225])
	by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id i69H1xdA021702
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 10:01:59 -0700 (PDT)
Received: from relay4.apple.com (relay4.apple.com) by mailgate1.apple.com
 (Content Technologies SMTPRS 4.3.12) with ESMTP id <T6aafc2e58a118064e1398@mailgate1.apple.com>;
 Fri, 9 Jul 2004 10:01:58 -0700
Received: from [17.112.73.138] ([17.112.73.138])
	by relay4.apple.com (8.12.11/8.12.11) with ESMTP id i69H1tHB004181;
	Fri, 9 Jul 2004 10:01:56 -0700 (PDT)
In-Reply-To: <opsau4kyb0uvpchu@quark>
References: <opsau4kyb0uvpchu@quark>
Mime-Version: 1.0 (Apple Message framework v669)
Content-Type: multipart/alternative; boundary=Apple-Mail-11--583836999
Message-Id: <ACE03413-D1C9-11D8-A027-000A95A0ACC4@apple.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
From: Jens Alfke <jens@apple.com>
Subject: Re: Patent threatens autodiscovery
Date: Fri, 9 Jul 2004 10:01:52 -0700
To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
X-Mailer: Apple Mail (2.669)
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-11--583836999
Content-Type: text/plain;
	charset=WINDOWS-1252;
	format=flowed
Content-Transfer-Encoding: quoted-printable

If you scroll down to the "SUMMARY OF THE INVENTION":

> A method of extracting network information that overcomes these and=20
> other  problems first receives an initial link address and retrieves a=20=

> file  associated with the initial link address. The file is then=20
> parsed to find  any link address contained inside the file. When a=20
> link address is found  in the file, it is determined if this link=20
> address has the same "root" as  the initial link address. If the link=20=

> address found has the same "root" as  the initial link address, the=20
> file associated with the link address is  then retrieved. Retrieved=20
> files are then further processed so that the  hypertext links they=20
> contain can be made to point to other local files,  rather than to=20
> files of the Internet. Any image maps in the retrieved  files are=20
> converted so they will execute locally. In this manner the  invention=20=

> creates a bundle of content that can be executed locally,  without the=20=

> need for Internet connectivity.

In other words, spidering a single website and converting it into a=20
local archive by copying the pages to disk and rewriting the links.=20
Which implicates MSIE and any other browser that can save "web=20
archives"; does Adobe have tools that can do this and generate PDFs?=20
That would explain why they're being sued.

IANAL, but: The patent as a whole doesn't seem to cover the general=20
process of traversing a hyperlink, though the specific algorithms=20
listed are so laughably vague that they could be interpreted that way.

_______________________________________
Jens Alfke =97 Atom/RSS Wrangler =97 Apple Computer
You know, I hate to ask, but are "friends" electric?

--Apple-Mail-11--583836999
Content-Type: text/enriched;
	charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable

If you scroll down to the "SUMMARY OF THE INVENTION":


<excerpt><fontfamily><param>Georgia</param><x-tad-bigger>A method of
extracting network information that overcomes these and other=20
problems first receives an initial link address and retrieves a file=20
associated with the initial link address. The file is then parsed to
find  any link address contained inside the file. When a link address
is found  in the file, it is determined if this link address has the
same "root" as  the initial link address. If the link address found
has the same "root" as  the initial link address, the file associated
with the link address is  then retrieved. Retrieved files are then
further processed so that the  hypertext links they contain can be
made to point to other local files,  rather than to files of the
Internet. Any image maps in the retrieved  files are converted so they
will execute locally. In this manner the  invention creates a bundle
of content that can be executed locally,  without the need for
Internet connectivity. </x-tad-bigger></fontfamily>

</excerpt>

In other words, spidering a single website and converting it into a
local archive by copying the pages to disk and rewriting the links.
Which implicates MSIE and any other browser that can save "web
archives"; does Adobe have tools that can do this and generate PDFs?
That would explain why they're being sued.


IANAL, but: The patent as a whole doesn't seem to cover the general
process of traversing a hyperlink, though the specific algorithms
listed are so laughably vague that they could be interpreted that way.


<flushright><bold>_______________________________________</bold>

<bold>Jens Alfke</bold> =97 Atom/RSS Wrangler =97 Apple Computer

<italic><color><param>8383,A9A9,7D7D</param><x-tad-smaller>You know, I
hate to ask, but are "friends" =
electric?</x-tad-smaller></color></italic>

</flushright>=

--Apple-Mail-11--583836999--



From owner-atom-syntax@mail.imc.org  Fri Jul  9 13:27: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 NAA13142
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 13:27: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 i69HCTsO091119;
	Fri, 9 Jul 2004 10:12: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 i69HCTSk091118;
	Fri, 9 Jul 2004 10:12:29 -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 i69HCSEn091110
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 10:12:28 -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 i69HD1l9016226;
	Fri, 9 Jul 2004 13:13:01 -0400
Message-ID: <40EED1F9.9000601@intertwingly.net>
Date: Fri, 09 Jul 2004 13:12:25 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Martin Duerst <duerst@w3.org>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Wiki setup issues: IRI
References: <4.2.0.58.J.20040709091221.060d8590@localhost>
In-Reply-To: <4.2.0.58.J.20040709091221.060d8590@localhost>
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


Martin Duerst wrote:
> 
> When working on http://intertwingly.net/wiki/pie/PaceIRI
> (not at all complete yet), I put my name (the real one, with umlaut,
> not the one I have to use in my outdated Japanese mailer) in square
> brackets at the start of the Abstract like I had seen it on other Paces
> such as http://intertwingly.net/wiki/pie/PaceUriOrItsSuccessor.
> 
> When I then clicked on it, I got to
> http://intertwingly.net/wiki/pie/MartinD_fcrst, which shows
> that with a few, probably very simple, changes to the wiki
> setup/code, this could be made compatible with IRIs.
> 
> Two changes are necessary:
> 1) Change the wiki to use UTF-8 for its page encoding rather than
>    iso-8859-1. For a new wiki, this should just be a setup issue
>    (otherwise, choose another wiki software, or maybe another ISP).
>    For the current wiki, pages with non-ASCII characters have to be
>    converted to UTF-8 at the same time the setup is changed.
>    Doing that is easy if you have access to the actual files.
>    In line with http://intertwingly.net/stories/2004/04/14/i18n.html,
>    I would suggest that we do that anyway, and I'm ready to help.
>    This would then change the above URI from
>    http://intertwingly.net/wiki/pie/MartinD_fcrst to
>    http://intertwingly.net/wiki/pie/MartinD_c3_bcrst.

In moin_config.py, there is the following:

   charset = 'iso-8859-1'

While this looks hopeful, it seems to me that such a change would not 
only affect the character set used within the pages, but would also 
change the NAME of the page.  Simply put, MartinD_fcrst and 
MartinD_c3_bcrst are separate pages, and changing the encoding used in 
the page would change which one of these pages were the target of the link.

Examples of pages it would affect:

http://www.intertwingly.net/wiki/pie/Fran_e7oisGranger?action=fullsearch&value=Fran%E7oisGranger&literal=1&case=1&context=40

Thinking about it a bit, my preference is to NOT directly fix the source 
files.  It seems to me that the number of issues should be small - I am 
quite willing to write programs to generate reports of potentially 
problematic pages, but unless the changes required are massive AND 
readily and safely automatable, then I would prefer that the change be 
made by hand.

> 2) Change the escape character from '_' to '%'. This would change
>    the above URI from
>    http://intertwingly.net/wiki/pie/MartinD_c3_bcrst to
>    http://intertwingly.net/wiki/pie/MartinD%c3%bcrst.
>    While at it, please also change escaping from lowercase to
>    upper case, in accordance with 2396bis. This would give
>    http://intertwingly.net/wiki/pie/MartinD%C3%BCrst.

This also changes the name of the page.  In particular, some of the help 
pages delivered with Moin have URI escaped slash characters in their 
name (example: http://www.intertwingly.net/wiki/pie/HelpOnInstalling).

However, it looks like the code change itself should be simple as the 
mapping is done in exactly one place.

> The two changes are largely independent, and can be done in any order.
> If everything goes well, the file names are then actually readable,
> on an Unix/Linux system assuming you have selected an UTF-8 locale (most
> new Linux systems are shipped that way, as far as I understand).

It looks to me that the way to proceed is to pick some relatively quiet 
time (perhaps this weekend), make both changes at once, and then fix 
what breaks.

> As I said, I'd be very glad to help get this fixed.
> I don't really care too much about my own name, I could
> use 'Duerst' as a fallback, but it'd really be better
> to fix this on this occasion.
> 
> Regards,    Martin.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Fri Jul  9 13:31:54 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13508
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 13:31:54 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i69HJApa091742;
	Fri, 9 Jul 2004 10:19: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 i69HJArv091741;
	Fri, 9 Jul 2004 10:19:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i69HJAEX091733
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 10:19:10 -0700 (PDT)
	(envelope-from jens@apple.com)
Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204])
	by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id i69HJ8Gg025176
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 10:19:08 -0700 (PDT)
Received: from relay2.apple.com (relay2.apple.com) by mailgate2.apple.com
 (Content Technologies SMTPRS 4.3.6) with ESMTP id <T6aafd29c26118064cc638@mailgate2.apple.com>;
 Fri, 9 Jul 2004 10:19:08 -0700
Received: from [17.112.73.138] ([17.112.73.138])
	by relay2.apple.com (8.12.11/8.12.11) with ESMTP id i69HJ6rL022821;
	Fri, 9 Jul 2004 10:19:06 -0700 (PDT)
In-Reply-To: <DCC93720-D1C6-11D8-89AD-003065EA6144@geckotribe.com>
References: <DCC93720-D1C6-11D8-89AD-003065EA6144@geckotribe.com>
Mime-Version: 1.0 (Apple Message framework v669)
Content-Type: multipart/alternative; boundary=Apple-Mail-12--582807176
Message-Id: <12B2C71C-D1CC-11D8-A027-000A95A0ACC4@apple.com>
Cc: atom-syntax@imc.org
From: Jens Alfke <jens@apple.com>
Subject: Re: Q: modfied vs issued vs created
Date: Fri, 9 Jul 2004 10:19:02 -0700
To: Antone Roundy <antone@geckotribe.com>
X-Mailer: Apple Mail (2.669)
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-12--582807176
Content-Type: text/plain;
	charset=WINDOWS-1252;
	format=flowed
Content-Transfer-Encoding: quoted-printable

Just to make things even more complicated, consider a feed that=20
contains items with multiple access privileges. Depending on the=20
credentials used to access the feed, different sets of items will be=20
returned. (This is not hypothetical: this is how LiveJournal works.=20
Posts can be "friends-only" so that only a specific set of LJ users can=20=

see them. A journal's feed's contents vary depending on what LJ user is=20=

fetching it.)

If I initially post an entry as friends-only, then at some later time=20
make it public, what are the implications for its dates? I'm not sure=20
of the answers, in fact I'm more unsure after reading this thread than=20=

I was before :) But it does seem like the Issued and Created dates=20
shouldn't change.
_______________________________________
Jens Alfke =97 Atom/RSS Wrangler =97 Apple Computer
=93Crow struggled, limply bedraggled his remnant.
He was his own leftover, the spat-out scrag.
He was what his brain could make nothing of.=94
=97Ted Hughes=

--Apple-Mail-12--582807176
Content-Type: text/enriched;
	charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable

Just to make things even more complicated, consider a feed that
contains items with multiple access privileges. Depending on the
credentials used to access the feed, different sets of items will be
returned. (This is not hypothetical: this is how LiveJournal works.
Posts can be "friends-only" so that only a specific set of LJ users
can see them. A journal's feed's contents vary depending on what LJ
user is fetching it.)


If I initially post an entry as friends-only, then at some later time
make it public, what are the implications for its dates? I'm not sure
of the answers, in fact I'm more unsure after reading this thread than
I was before :) But it does seem like the Issued and Created dates
shouldn't change.

<flushright><bold>_______________________________________</bold>

<bold>Jens Alfke</bold> =97 Atom/RSS Wrangler =97 Apple Computer

<italic><color><param>8383,A9A9,7D7D</param><x-tad-smaller>=93Crow
struggled, limply bedraggled his remnant.

He was his own leftover, the spat-out scrag.

He was what his brain could make nothing of.=94

=97Ted Hughes</x-tad-smaller></color></italic></flushright>=

--Apple-Mail-12--582807176--



From owner-atom-syntax@mail.imc.org  Fri Jul  9 13:47:17 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14431
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 13:47:17 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i69HZZSe093098;
	Fri, 9 Jul 2004 10:35: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 i69HZZd2093097;
	Fri, 9 Jul 2004 10:35: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 i69HZZni093084
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 10:35:35 -0700 (PDT)
	(envelope-from mint@franklinmint.fm)
Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94])
	by web02.designerslab.net with asmtp (Exim 4.34)
	id 1BizHW-000760-1D; Fri, 09 Jul 2004 17:35:30 +0000
Message-ID: <40EED75F.9060202@franklinmint.fm>
Date: Fri, 09 Jul 2004 13:35:27 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jens Alfke <jens@apple.com>
CC: Antone Roundy <antone@geckotribe.com>, atom-syntax@imc.org
Subject: Re: Q: modfied vs issued vs created
References: <DCC93720-D1C6-11D8-89AD-003065EA6144@geckotribe.com> <12B2C71C-D1CC-11D8-A027-000A95A0ACC4@apple.com>
In-Reply-To: <12B2C71C-D1CC-11D8-A027-000A95A0ACC4@apple.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


Jens Alfke wrote:

> If I initially post an entry as friends-only, then at some later time 
> make it public, what are the implications for its dates? I'm not sure 
> of the answers, in fact I'm more unsure after reading this thread than 
> I was before :) But it does seem like the Issued and Created dates 
> shouldn't change.


I don't think dcterms:issued has anything to do with when the entry was 
published. That's dcterms:available.
dcterms:issued would seem to correspond to the date on a magazine. For 
example, I'm sure I can pick up the "August issue" of many magazines 
right now.

Can anyone tell me if this interpretation is correct?
http://dublincore.org/documents/2003/03/04/dcmi-terms/

Robert Sayre



From owner-atom-syntax@mail.imc.org  Fri Jul  9 14:23: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 OAA17428
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 14:23: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 i69IBO1i095377;
	Fri, 9 Jul 2004 11:11: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 i69IBOQB095376;
	Fri, 9 Jul 2004 11:11:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from beta.verity.com (beta.verity.com [192.187.143.12])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i69IBOrs095367
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 11:11:24 -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 LAA18828
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 11:11:22 -0700 (PDT)
Received: from mx-rr.verity.com (mx-rr.verity.com [10.3.100.59])
	by mx-rr.verity.com (8.9.3/8.9.3) with SMTP id LAA27747
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 11:11:22 -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, 09 Jul 2004 11:11:21 -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 <0I0L00GUWJUW2Z@shazam.verity.com> for atom-syntax@imc.org; Fri,
 09 Jul 2004 11:11:21 -0700 (PDT)
Date: Fri, 09 Jul 2004 11:11:20 -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: Patent threatens autodiscovery
In-reply-to: <opsau4kyb0uvpchu@quark>
To: Atom-Syntax <atom-syntax@imc.org>
Message-id: <637DD3CC3464070D384557EA@[192.168.168.164]>
MIME-version: 1.0
X-Mailer: Mulberry/3.1.5 (Mac OS X)
Content-type: text/plain; charset=iso-8859-1; format=flowed
Content-disposition: inline
References: <opsau4kyb0uvpchu@quark>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i69IBOrs095371
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 Friday, July 9, 2004 10:59 AM +0200 Asbjørn Ulsberg <asbjorn@tigerstaden.no> wrote:
>
> The patent was filed September 10th 1996 and approved April 6th 1999.
> Does  anyone know of working code that existed before any of these dates
> that  may render the patent useless?

Jef Poskanzer wrote WebCopy around that time. There isn't a date on
that specific bit of code, but WebCat is copyright 1996. WebCopy can
rewrite local absolute URLs to be relative.

  <http://www.acme.com/java/software/WebCopy.html>

Infoseek used the sitelist.txt file to give hints to spiders. This was
described at the W3C Distributed Indexing/Searching Workshop in May 1996.
sitelist.txt is a list of the documents on the site with their sizes
and modification dates. The spider would read that file, extract the
links, and fetch the files which had changed.

  <http://www.w3.org/Search/9605-Indexing-Workshop/>
  <http://www.w3.org/Search/9605-Indexing-Workshop/Papers/Kirsch@Infoseek.html>
  <http://www.skirsch.com/papers/distributed.html>

The original location for the sitelist.txt standard is long gone, but
you can get it from the WayBack Machine. Their earliest copy is from
1997, but Steve Kirsch talked about it at the workshop above, and the
Infoseek spider was working by then.

  <http://web.archive.org/web/19970529104229/http://software.infoseek.com/products/ultraseek/docs/sitelist.html>

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Fri Jul  9 15: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 PAA21807
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 15:14:22 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i69J2Nb9098318;
	Fri, 9 Jul 2004 12:02: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 i69J2NEV098317;
	Fri, 9 Jul 2004 12:02:23 -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 i69J2MsV098310
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 12:02:22 -0700 (PDT)
	(envelope-from wkearney@syndic8.com)
Received: (qmail 27411 invoked from network); 9 Jul 2004 19:02:26 -0000
Received: from xbox.wkearney.com (HELO media) ([66.92.145.79])
          (envelope-sender <wkearney@syndic8.com>)
          by mail3.speakeasy.net (qmail-ldap-1.03) with SMTP
          for <atom-syntax@imc.org>; 9 Jul 2004 19:02:26 -0000
Message-ID: <012e01c465e7$462ecee0$200ca8c0@wkearney.com>
From: "Bill Kearney" <wkearney@syndic8.com>
Cc: <atom-syntax@imc.org>
References: <DCC93720-D1C6-11D8-89AD-003065EA6144@geckotribe.com> <12B2C71C-D1CC-11D8-A027-000A95A0ACC4@apple.com>
Subject: Re: Q: modfied vs issued vs created
Date: Fri, 9 Jul 2004 15:02:25 -0400
Organization: http://www.ideaspace.net/users/wkearney/foaf.xrdf
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
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



What's in control of distinguishing how the consumers can "tell" the
distribution scope?

In the context of a feed it seems entirely reasonable to think the item should
reflect some sort of modification time.  You did modfiy it, if only to change
the scope of who can consume it.  Now, do the users /care/ that you did this?
Should their reader program "do something" to bring this to their attention?
Should we spend any time whatsoever on crafting a mechanism for it?

You created the item at a fixed instant in time.  The server should need this to
remain unchanged if just for the sake of not wasting huge amounts of energies on
trying to maintain some sense of editing progression.  You offered it up for
consumption by others and this date should likewise remain fixed as the users
will likely depend on it.  You then altered the item and the system would
likewise probably want to keep track of this.  Did you change it "enough" for
the feed consuming programs to somehow present that?   Depends on how
"significantly" you want it to appear to the consuming audience.  Try screwing
around with it too much and you'll lose that audience (rightly so).

-Bill Kearney
Syndic8.com


----- Original Message ----- 
From: "Jens Alfke" <jens@apple.com>
To: "Antone Roundy" <antone@geckotribe.com>
Cc: <atom-syntax@imc.org>
Sent: Friday, July 09, 2004 1:19 PM
Subject: Re: Q: modfied vs issued vs created


Just to make things even more complicated, consider a feed that
contains items with multiple access privileges. Depending on the
credentials used to access the feed, different sets of items will be
returned. (This is not hypothetical: this is how LiveJournal works.
Posts can be "friends-only" so that only a specific set of LJ users can
see them. A journal's feed's contents vary depending on what LJ user is
fetching it.)

If I initially post an entry as friends-only, then at some later time
make it public, what are the implications for its dates? I'm not sure
of the answers, in fact I'm more unsure after reading this thread than
I was before :) But it does seem like the Issued and Created dates
shouldn't change.



From owner-atom-syntax@mail.imc.org  Fri Jul  9 15:32: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 PAA24133
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 15:32: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 i69JN9Mw099520;
	Fri, 9 Jul 2004 12:23: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 i69JN97a099519;
	Fri, 9 Jul 2004 12:23:09 -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 i69JN8Z1099507
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 12:23:09 -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 PAA23323;
	Fri, 9 Jul 2004 15:23:10 -0400 (EDT)
Message-Id: <200407091923.PAA23323@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: i-d-announce@ietf.org
Cc: atom-syntax@imc.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-atompub-protocol-00.txt
Date: Fri, 09 Jul 2004 15:23:10 -0400
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>


--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Atom Publishing Format and Protocol Working Group of the IETF.

	Title		: The Atom Publishing Protocol
	Author(s)	: J. Gregorio, et al.
	Filename	: draft-ietf-atompub-protocol-00.txt
	Pages		: 17
	Date		: 2004-7-9
	
This memo presents a protocol for using XML (Extensible Markup
   Language) and HTTP (HyperText Transport Protocol) to edit content.

   The Atom Publishing Protocol is an application-level protocol for
   publishing and editing Web resources belonging to periodically
   updated websites.  The protocol at its core is the HTTP transport of
   Atom-formatted representations.  The Atom format is documented in the
   Atom Syndication Format 0.3 PRE-DRAFT

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-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-protocol-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-protocol-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-7-9154626.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-atompub-protocol-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-atompub-protocol-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2004-7-9154626.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-atom-syntax@mail.imc.org  Fri Jul  9 15:32: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 PAA24165
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 15:32: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 i69JHYnU099201;
	Fri, 9 Jul 2004 12:17: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 i69JHY1D099200;
	Fri, 9 Jul 2004 12:17:34 -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 i69JHXJi099194
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 12:17:34 -0700 (PDT)
	(envelope-from wkearney@syndic8.com)
Received: (qmail 24080 invoked from network); 9 Jul 2004 19:17:38 -0000
Received: from xbox.wkearney.com (HELO media) ([66.92.145.79])
          (envelope-sender <wkearney@syndic8.com>)
          by mail3.speakeasy.net (qmail-ldap-1.03) with SMTP
          for <antone@geckotribe.com>; 9 Jul 2004 19:17:37 -0000
Message-ID: <015101c465e9$659fe6e0$200ca8c0@wkearney.com>
From: "Bill Kearney" <wkearney@syndic8.com>
To: "Antone Roundy" <antone@geckotribe.com>, <atom-syntax@imc.org>
References: <DCC93720-D1C6-11D8-89AD-003065EA6144@geckotribe.com>
Subject: Re: Q: modfied vs issued vs created
Date: Fri, 9 Jul 2004 15:17:06 -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.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
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



In the context of using Atom as a format for editing between a client-side
program and a server-side repository it seems entirely useful to have "real"
timestamps be employed.  If only to facilitate properly tracking changes.

In the context of the format being used to publish content intended for external
distribution there are other factors to consider.  A driving force behind
timestamps in items has been tracking read/unread status and avoiding
duplicates.  There have been any number of arguments and half-assed solutions
proposed and implemented.

The bottom line is different for each situation.

Back into the situation from the consuming reader's perspective.  What means can
be employed that effectively manage the detection of the uniqueness of an item
and tracking it?  Timestamps are one way, UIDs another.  For feed-like exchanges
either could be employed but without some consistency it's going to be a
hopeless mess.  For editing sessions it's hard to rationalize the against the
value of using multiple timestamps.

When dealing with calculations regarding the uniqueness of something it's
entirely reasonable to expect to see a creation date.  If the item is modified
it's likewise helpful to see both the original creation timestamp and the
modification.

"Vanity" timestamping is a quagmire.  Thus using some sort of publication or
issuance timestamps is often advisable.  But if people are going to ceaslessly
fuck around with the timestamps on their items they shouldn't be surprised when
the software fucks it up and the users complain.   Know that if you publish
something the users will make use of it based on the timestamps.  If you futz
around with those timestamps you will antagonize your audience.  Do so at your
peril but do not come crawling to the spec begging acceptance of bad habits.

Conflict resolution for uniqueness cannot rationally allow open-ended gobbling
of CPU just to accomodate stupidity or ludicrous edge-cases.

> 1000 - Author gets an idea for a blog entry, makes a brief
> note-to-self, and saves it as a draft [created & modified - Why does
> anyone but the author need to know this?

For a feed?  No it's entirely reasonable to have the option to use 'publication'
oriented timestamps.  For editing sessions it's sort of crazy /not/ to use them.

> 1050 - Author adds a few more notes and saves as a draft again [
> modified - there's even less need for anyone but perhaps the author to
> know this]

But critical to whatever system the host might be using to deal with
syncronizing entries.

> 1100 - Author posts the entry, unmodified, to their blog [ issued -
> this date matters, does modified change? ]
> OR
> 1100 - Author cleans up the draft and posts it to their blog [ modified
> & issued - this matters ]

Ah so, in a feed we're talking about:

    New item: [issued]
    Same item, edited somewhat [issued, modified]

> 1150 - Author decides they want to change the timestamp on the entry,
> either for "personal" reasons or because the clock on whichever
> computer initially set the date(s) was incorrect [ ? - are there any
> that they MUST NOT change? ]

Realizing, of course, that by doing so they'll be causing grief to their
audience.  They COULD change anything they liked.  But they probably SHOULD seek
to publish useful data and stick with it.

> 1300 - Author posts the same entry to another of their blogs without
> any changes--the id for the two entries is the same [ is issued now
> different in the two blogs? ]

This being a place where conflict resolution starts getting messy.

Honestly, what are we trying to facilitate here?  There are going to be
situations where "a story" has some sort of on-going development.  Should it
only be published "once" and modified a bajillion times as it grows?  That seems
like a pretty bad idea.  But I can imagine some git with their
one-true-favorite-tool that they've only figured out how to use one way that
thinks it's a perfect FINE idea!   But for a feed driven publication method it
seems a lot more reasonable to look at the progression of the "story" as a
series of individual pieces that have some relation to each other.  Does this
"need" to be automated?  Not as many situations need this as some will doubtless
insist.

> 1400 - Some aggregator sees the entries in the two blogs and puts one
> of them into a synthetic feed, smartly omitting the other since they
> have the same id

>[ IF issued is different in the two feeds, which one
> gets used? The earlier one probably makes more sense. ]

How so?  I'd think it'd be more along the lines of seeing which one was modified
last and using that one.  In most situations "later" is usually what's intended
for consumption.

Likewise DC has means to indicate that an item is related to another.

-Bill Kearney



From owner-atom-syntax@mail.imc.org  Fri Jul  9 15:33: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 PAA24243
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 15:33: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 i69JL7S5099410;
	Fri, 9 Jul 2004 12: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 i69JL7oP099409;
	Fri, 9 Jul 2004 12:21:07 -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 i69JL7bn099403
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 12:21:07 -0700 (PDT)
	(envelope-from wkearney@syndic8.com)
Received: (qmail 21478 invoked from network); 9 Jul 2004 19:21:10 -0000
Received: from xbox.wkearney.com (HELO media) ([66.92.145.79])
          (envelope-sender <wkearney@syndic8.com>)
          by mail1.speakeasy.net (qmail-ldap-1.03) with SMTP
          for <roger@agincourtmedia.com>; 9 Jul 2004 19:21:10 -0000
Message-ID: <015201c465e9$e47cdc70$200ca8c0@wkearney.com>
From: "Bill Kearney" <wkearney@syndic8.com>
To: "Roger B." <roger@agincourtmedia.com>,
        "Asbjørn Ulsberg" <asbjorn@tigerstaden.no>
Cc: "'Atom-Syntax'" <atom-syntax@imc.org>
References: <C31A0E20DFF24B11A68DEFC78B8B3.MAI@journurl.com> <opsavm6g0ruvpchu@quark>
Subject: Re: Q: modfied vs issued vs created
Date: Fri, 9 Jul 2004 15:21:10 -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: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
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


> For a twenty year old article about «The next big thing: CD's!» which have
> been re-issued ten times the last few years because of domain and URI
> restructuring, it might have the dates: <issued>2002-08-03</issued> and
> <modified>2004-03-18</modified>. (It might not even have <modified>.) Ok,
> nice to know when the article was last modified, but who the heck writes
> about «The next big thing: CD's» in 2002?!

Hmmm, an edge case argument masquerading as important?

In the context of the entry being edited it well seems likely the dates matter.
But in a feed, well, why would this item be in a feed?  Just because something
changed doesn't mean it's automagically going to need to be republished. Of
course that raises the question of how the entry editing activities should
affect publishing status.  Being that the item didn't change 'enough' to merit
republishing in a feed, well, that raises the question of how does a system
decide what is or isn't to be included?    If the feed is news-like then it
seems pretty lame to bother annoying the audience with such trivialities.  If
the data was used for some sort of data synchronization tool then it might.
Seems pretty application specific however and may well be beyond the scope of
what this generation of Atom expect to clarify.

-Bill Kearney



From owner-atom-syntax@mail.imc.org  Fri Jul  9 15:43:45 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25323
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 15:43: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 i69JUr8j099944;
	Fri, 9 Jul 2004 12: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 i69JUrB2099943;
	Fri, 9 Jul 2004 12:30:53 -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 i69JUq2D099937
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 12:30:53 -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 i69JUt9L014167;
	Fri, 9 Jul 2004 12:30:56 -0700 (PDT)
Received: from [12.40.111.35] (wireless-12-40-111-35.bryantpark.org [12.40.111.35] (may be forged))
	(authenticated bits=0)
	by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id i69JUqhp025943;
	Fri, 9 Jul 2004 12:30:53 -0700 (PDT)
In-Reply-To: <14be96d304070907427b1d83cb@mail.gmail.com>
References: <40E5C9C2.4060507@jonasgalvez.com> <m34qoqt8ts.fsf@bitsko.slc.ut.us> <40E5E922.1070909@jonasgalvez.com> <40EE8A59.7090607@spoonybards.net> <opsavfonjtuvpchu@quark> <14be96d304070907427b1d83cb@mail.gmail.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4--574876179; protocol="application/pkcs7-signature"
Message-Id: <89F0CD62-D1DE-11D8-ACB6-000A95DC3D90@mac.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: Q: modfied vs issued vs created
Date: Fri, 9 Jul 2004 15:31:13 -0400
To: Mark Pilgrim <pilgrim@gmail.com>
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-4--574876179
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 9 Jul 2004, at 10:42 am, Mark Pilgrim wrote:

> Current Atom pre-draft says that atom:modified and atom:created MUST
> include a timezone, and atom:issued MAY include a timezone.
>
> As of today, PaceEntryDates says that atom:modified and atom:created
> SHOULD include a timezone, and atom:issued MUST include a timezone.
>
> In other words, this Pace completely redefines which timezones are
> optional and which are required.  Was that intentional?  Did I miss a
> meeting?

Yes. The pre-draft contains lots of nonsense and internal conflicts 
(see the rationale), and doesn't seem to have been thought through as a 
system, but as three separate elements. PaceEntryDates attempts to 
rectify this.

Graham
--Apple-Mail-4--574876179
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
9w0BCQUxDxcNMDQwNzA5MTkzMTEzWjAjBgkqhkiG9w0BCQQxFgQUEUv65AC72spXVsHzbbbhiWvK
sxIweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEA1ISGwJ5cvkBEddonWX1N5h8c
4U6lnh2hwOHJwQJANeY1FK4cfg1cX3YfOEwgk9XP95xRqG2/jG/tcYwOzFi5oaUrhvNVxX28YkAJ
tgTkeLyyHfvTTZvpiBnfq1xt6fk99EfdXk2QslpW2O3bd2J89WTJdeVn8l7sR+wV/KxhI13rOKZz
QT8kC1x4WPoHGPXw/vbZAIPj/MY4NSohn5gO0G+1D2y75kJnHa8JgIdLlOwww9/MxtYqTxTYLtSH
RiQs1yy4Z319Tp6HXoA27fBW4SvRxDOCNH7tuNS4JORpQ5j9o6JNH7NCAQx+m8Kj8trOUEqvwRLi
n8WkMDlJD2uroAAAAAAAAA==

--Apple-Mail-4--574876179--



From owner-atom-syntax@mail.imc.org  Fri Jul  9 15:59: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 PAA26040
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 15:59: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 i69JjQi7001629;
	Fri, 9 Jul 2004 12:45: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 i69JjQ9x001628;
	Fri, 9 Jul 2004 12:45:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.240])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i69JjQYd001620
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 12:45:26 -0700 (PDT)
	(envelope-from rtomayko@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so8227891cwc
        for <atom-syntax@imc.org>; Fri, 09 Jul 2004 12:45:25 -0700 (PDT)
Received: by 10.11.99.64 with SMTP id w64mr639267cwb;
        Fri, 09 Jul 2004 12:45:25 -0700 (PDT)
Message-ID: <f732822d04070912452a5538ee@mail.gmail.com>
Date: Fri, 9 Jul 2004 15:45:25 -0400
From: Ryan Tomayko <rtomayko@gmail.com>
To: atom-syntax@imc.org
Subject: Re: I-D ACTION:draft-ietf-atompub-format-00.txt
In-Reply-To: <200407091923.PAA23330@ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <200407091923.PAA23330@ietf.org>
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


Where might one find the XML representation of these documents?

Thanks,
Ryan

On Fri, 09 Jul 2004 15:23:24 -0400, internet-drafts@ietf.org
<internet-drafts@ietf.org> wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Atom Publishing Format and Protocol Working Group of the IETF.
> 
>         Title           : The Atom Syndication Format
>         Author(s)       : M. Nottingham
>         Filename        : draft-ietf-atompub-format-00.txt
>         Pages           : 19
>         Date            : 2004-7-9
> 
> This specification describes Atom, an XML-based Web content and
>    metadata syndication format.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-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-format-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-format-00.txt".
> 
> NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> 
>



From owner-atom-syntax@mail.imc.org  Fri Jul  9 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 PAA24134
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 15:32: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 i69JNO5F099540;
	Fri, 9 Jul 2004 12:23: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 i69JNO2O099539;
	Fri, 9 Jul 2004 12:23:24 -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 i69JNNLj099532
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 12:23:23 -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 PAA23330;
	Fri, 9 Jul 2004 15:23:24 -0400 (EDT)
Message-Id: <200407091923.PAA23330@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: i-d-announce@ietf.org
Cc: atom-syntax@imc.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-atompub-format-00.txt
Date: Fri, 09 Jul 2004 15:23:24 -0400
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>


--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Atom Publishing Format and Protocol Working Group of the IETF.

	Title		: The Atom Syndication Format
	Author(s)	: M. Nottingham
	Filename	: draft-ietf-atompub-format-00.txt
	Pages		: 19
	Date		: 2004-7-9
	
This specification describes Atom, an XML-based Web content and
   metadata syndication format.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-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-format-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-format-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-7-9154639.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-atompub-format-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-atompub-format-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2004-7-9154639.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-atom-syntax@mail.imc.org  Fri Jul  9 16:23: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 QAA27551
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 16: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 i69JwveL002447;
	Fri, 9 Jul 2004 12:58: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 i69JwvaK002446;
	Fri, 9 Jul 2004 12:58:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.83])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i69JwvoD002440
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 12:58:57 -0700 (PDT)
	(envelope-from dtcd@mac.com)
Received: from mac.com (smtpin08-en2 [10.13.10.153])
	by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i69Jx0gH010106;
	Fri, 9 Jul 2004 12:59:00 -0700 (PDT)
Received: from [12.40.111.35] (wireless-12-40-111-35.bryantpark.org [12.40.111.35] (may be forged))
	(authenticated bits=0)
	by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id i69Jue0u006892;
	Fri, 9 Jul 2004 12:58:15 -0700 (PDT)
In-Reply-To: <bd.428e9aba.2e1ffc45@aol.com>
References: <bd.428e9aba.2e1ffc45@aol.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-6--573313859; protocol="application/pkcs7-signature"
Message-Id: <2D27FEEC-D1E2-11D8-ACB6-000A95DC3D90@mac.com>
Cc: Atom-Syntax Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: [Atom] Issued "publicly" - It doesn't always happen
Date: Fri, 9 Jul 2004 15:57:15 -0400
To: Svgdeveloper@aol.com
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-6--573313859
Content-Type: text/plain;
	charset=ISO-8859-1;
	format=flowed
Content-Transfer-Encoding: quoted-printable

The word publicly was added to the proposal by Asbj=F8rn Ulsberg for no=20=

discernible reason. The original version has been restored.

Graham Parks

--Apple-Mail-6--573313859
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
9w0BCQUxDxcNMDQwNzA5MTk1NzE2WjAjBgkqhkiG9w0BCQQxFgQUC/4fFPMGE3gu8HicDHTWo9wM
wa0weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAt+WSSZCdZlJLGcU/qw9VlxVD
pw7R4CkmTwNdpXNKWRjG7X4PQViO0jdC2yYc98J6PWRP3ktQjEPcChMTds/1VrCp6kBh/AvcwYxT
269+CkJxh5U5Ks5KaSVQozXesYAYFTSDwOyStN4gjtl2Q+o+4BuDC/1iNuu318TDqFQc3b6nJCS4
dFF+riSuHPtEClG52ZvG7Uo8GnVnl3vTxfpV0XdLOYum6rJqySFPO9yfqQv06bD+yZz5InIxDsgQ
K274Sh88IBZZvymW84Kb88H0bhE45Gntgf7JUQeoMKADdF/BYEMut1T5iQRQKlGDK94VzEDqoXWy
frvGecfZx7x5oAAAAAAAAA==

--Apple-Mail-6--573313859--



From owner-atom-syntax@mail.imc.org  Fri Jul  9 16:36: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 QAA28556
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 16:36: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 i69KBlIp003465;
	Fri, 9 Jul 2004 13: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 i69KBl6q003464;
	Fri, 9 Jul 2004 13:11:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail4.edisontel.com (mail4.edisontel.com [62.94.0.37])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i69KBjwo003442
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 13:11:46 -0700 (PDT)
	(envelope-from danny666@virgilio.it)
Received: from virgilio.it (62.94.3.44) by mail4.edisontel.com (7.0.024)
        id 3FB4847C0092B9FB for atom-syntax@imc.org; Fri, 9 Jul 2004 22:11:47 +0200
Message-ID: <40EEFB88.3020403@virgilio.it>
Date: Fri, 09 Jul 2004 22:09:44 +0200
From: Danny Ayers <danny666@virgilio.it>
Reply-To: danny666@virgilio.it
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Resource terminology
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


Can someone please tell me if this was intentional (and if so, why?!) -

The charter, early on says:

Atom consists of:
    * A conceptual model of a resource


Is this a resource in the URI sense, or a new term for an Atom thing?

Either way, this seems very confusing.
Come back "Well-Formed Log Entry", all is forgiven...

Cheers,
Danny.

-- 

Raw
http://dannyayers.com



From owner-atom-syntax@mail.imc.org  Fri Jul  9 16: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 QAA29433
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 16: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 i69KXuL8005082;
	Fri, 9 Jul 2004 13:33: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 i69KXuFO005081;
	Fri, 9 Jul 2004 13:33: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 (mproxy.gmail.com [216.239.56.244])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i69KXtG2005075
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 13:33:55 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so8303935cwc
        for <atom-syntax@imc.org>; Fri, 09 Jul 2004 13:34:00 -0700 (PDT)
Received: by 10.11.118.71 with SMTP id q71mr651820cwc;
        Fri, 09 Jul 2004 13:33:59 -0700 (PDT)
Message-ID: <3f1451f504070913332f4647c2@mail.gmail.com>
Date: Fri, 9 Jul 2004 16:33:59 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Ryan Tomayko <rtomayko@gmail.com>
Subject: Re: I-D ACTION:draft-ietf-atompub-format-00.txt
Cc: atom-syntax@imc.org
In-Reply-To: <f732822d04070912452a5538ee@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <200407091923.PAA23330@ietf.org> <f732822d04070912452a5538ee@mail.gmail.com>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


On Fri, 9 Jul 2004 15:45:25 -0400, Ryan Tomayko <rtomayko@gmail.com> wrote:
> 
> Where might one find the XML representation of these documents?

With the lawyerly statement up front that 
*Only the .TXT versions served from 
http://www.ietf.org/internet-drafts are normative* :)

The .xml and .html versions of the protocol
can be viewed here along with an HTML
file that gives a color side-by-side diff
between the last version and the latest version:

http://bitworking.org/projects/atom/

   Thanks,
   -joe



From owner-atom-syntax@mail.imc.org  Fri Jul  9 17:05:12 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00272
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 17:05:12 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i69Kk8Td006205;
	Fri, 9 Jul 2004 13:46: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 i69Kk84T006204;
	Fri, 9 Jul 2004 13:46:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.246])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i69KjfTY006183
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 13:46:08 -0700 (PDT)
	(envelope-from rtomayko@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so8324402cwc
        for <atom-syntax@imc.org>; Fri, 09 Jul 2004 13:45:34 -0700 (PDT)
Received: by 10.11.116.64 with SMTP id o64mr644010cwc;
        Fri, 09 Jul 2004 13:45:33 -0700 (PDT)
Message-ID: <f732822d0407091345be33949@mail.gmail.com>
Date: Fri, 9 Jul 2004 16:45:33 -0400
From: Ryan Tomayko <rtomayko@gmail.com>
To: Joe Gregorio <joe.gregorio@gmail.com>
Subject: Re: I-D ACTION:draft-ietf-atompub-format-00.txt
Cc: atom-syntax@imc.org
In-Reply-To: <3f1451f504070913332f4647c2@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <200407091923.PAA23330@ietf.org> <f732822d04070912452a5538ee@mail.gmail.com> <3f1451f504070913332f4647c2@mail.gmail.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


you rock.

On Fri, 9 Jul 2004 16:33:59 -0400, Joe Gregorio <joe.gregorio@gmail.com> wrote:
> On Fri, 9 Jul 2004 15:45:25 -0400, Ryan Tomayko <rtomayko@gmail.com> wrote:
> >
> > Where might one find the XML representation of these documents?
> 
> With the lawyerly statement up front that
> *Only the .TXT versions served from
> http://www.ietf.org/internet-drafts are normative* :)
> 
> The .xml and .html versions of the protocol
> can be viewed here along with an HTML
> file that gives a color side-by-side diff
> between the last version and the latest version:
> 
> http://bitworking.org/projects/atom/
> 
>    Thanks,
>    -joe
>



From owner-atom-syntax@mail.imc.org  Fri Jul  9 17:44:16 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03345
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 17:44:16 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i69LYSdV009371;
	Fri, 9 Jul 2004 14: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 i69LYSBq009370;
	Fri, 9 Jul 2004 14:34:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf16.cluster1.charter.net (mxsf16.cluster1.charter.net [209.225.28.216])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i69LXRY6009317
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 14:34:27 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip17.cluster1.charter.net (mxip17a.cluster1.charter.net [209.225.28.147])
	by mxsf16.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i69LaFZB019446
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 17:36:15 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip17.cluster1.charter.net with ESMTP; 09 Jul 2004 17:33:24 -0400
X-Ironport-AV: i="3.81R,160,1083556800"; 
   d="scan'208"; a="98890582:sNHT16891984"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1Bj2ma-00025x-00
	for <atom-syntax@imc.org>; Fri, 09 Jul 2004 17:19:48 -0400
To: atom-syntax@imc.org
Subject: Comments on I-D ACTION:draft-ietf-atompub-format-00.txt
References: <200407091923.PAA23330@ietf.org>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Fri, 09 Jul 2004 17:19:37 -0400
In-Reply-To: <200407091923.PAA23330@ietf.org> (Internet-Drafts@ietf.org's
 message of "Fri, 09 Jul 2004 15:23:24 -0400")
Message-ID: <878ydsubdi.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: <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-Type: text/plain

I find I'm having difficulty keeping up with the volume of traffic on
this list and with the Wiki as a development medium for the spec. But
I will try to carefully read the drafts as they are published.

[...]
|    Therefore, when this specification uses the term "element," it is
|    refering to an Element Information Item in Infoset terms.  Likewise,
|    when it uses the term "attribute," it is refering to an Attribute
|    Information Item.

What about entity, document, etc.? Are those words shorthand as well?

| 2.  Atom Documents
| 
|    An Atom document

Am I to assume document information item here?

|    is an XML document whose document element is the
|    atom:feed element, as described below.
| 
|    Atom documents are specified in terms of the XML Information Set,
|    serialised as XML 1.0 and identified with the "application/atom+xml"
|    media type.

I find the mention of the serialization format here a bit odd. If the
spec is going to describe things in terms of the infoset, then the
serialization form is irrelevant. If the spec wants to mandate a
serialization form, that's fine too, but I don't think it should do
that without justification.

|    Atom documents SHOULD NOT contain Processing Instructions, unless

Why not? And what's the value of saying "should not" anyway. The spec
goes on to say that comments are allowed, but provides no semantics
for them. Why can't we just say PIs are allowed but provide no
semantics for them.

|    All elements and attributes in an Atom document MUST be
|    namespace-qualified.

Does this apply only to top-level elements in an atom:feed or
atom:entry element? If I want to ship around a content constructor
containing DocBook V4.3 content (which has no namespace), I'm allowed
to, aren't I?

|    [RFC3066].  When determining element content's natural language, the
|    first xml:lang attribute encountered in that element's ancestors MUST
|    be used.

"...encountered on that element or the first of its ancestors..." or
words to that effect. "Ancestor" can be construed to not include the
current element.

|    the author.  It MAY be the name of a corporation or other entity no
                                                                     ^ when?
|    individual authors can be named.  Person constructs MUST contain

| 3.2.2  "atom:url" Element

Can we call this atom:uri? It looks really odd to say "atom:url, the
URI that..."

|    The "rel" attribute indicates the type of relationship that the link
|    represents.  Link constructs MUST have a rel attribute, whose value
|    MUST be a string, and MUST be one of the values enumerated in the
|    Atom Protocol specification [Atom-protocol].

Please duplicate that list here. I don't care about the protocol and it's
tedious to go read another spec just for a flat list.

|    link.  Link constructs MAY have a title attribute, whose value MUST
|    be a string.

"MUST be a string"? How can an attribute *not* be a string. Does this
add anything?

| 4.  The "atom:feed" Element
| 
|    The "atom:feed" element is the document (i.e., top-level) element of
|    the format described by this specification.  Its children are a
|    (potentially partial) representation of the state of the feed.
| 
|    The atom:feed element MAY contain any namespace-qualified
|    [W3C.REC-xml-names-19990114] elements as children.  Ordering of the
|    element children of atom:feed element MUST NOT be considered
|    significant.

May it contain (non-whitespace) character information item children? I
assume not, but it doesn't say.

| 4.3  "atom:title" Element
| 
|    The "atom:title" element is a Content construct that conveys a

It seems slightly odd to me that the title is a Content construct. I think
I'd be happier if the title was a string.

| 4.11  "atom:info" Element
| 
|    The "atom:info" element is a Content construct that conveys a
|    human-readable explanation of the feed format itself.  atom:feed
|    elements MAY contain an atom:info element, but MUST NOT contain more
|    than one.
| 
|    The atom:info element SHOULD NOT considered meaningful by processors;
|    it is a convenience to publishers in certain situations.

If it's not meaningful to processors and may be a convenience to
publishers, I suggest that sometimes it will be a convenience that
more than one publisher will simultaneously want to use. Therefore,
more than one should be allowed.

| 4.12  "atom:modified" Element
| 
|    The "atom:modified" element is a Date construct that indicates the
|    time when the state of the feed was last modified, including any
|    changes to entries therein.  atom:feed elements MUST contain exactly
|    one atom:modified element.
| 
|    The content of an atom:modified element SHOULD have a time zone whose
|    value MUST be "UTC".

Are "SHOULD" and "MUST" reversed in that sentence?

| 4.13  "atom:entry" Element
[...]
|    The atom:entry element MAY contain any namespace-qualified
|    [W3C.REC-xml-names-19990114] elements as children.  Ordering of the
|    element children of atom:entry element MUST NOT be considered
|    significant.

May it contain (non-whitespace) character information item children? I
assume not, but it doesn't say.

| 4.13.7  "atom:issued" Element
| 
|    The "atom:issued" element is a Date construct that indicates the time
|    that the entry was issued.  atom:entry elements MUST contain an
|    atom:issued element, but MUST NOT contain more than one.
| 
|    The content of an atom:issued element MAY omit a time zone.

Why is issued special? If everyone else has to have a time zone, why
not require it here too for consistency?

| 4.13.9  "atom:summary" Element
| 
|    The "atom:summary" element is a Content construct that conveys a
|    short summary, abstract or excerpt of the entry.  atom:entry elements
|    MAY contain an atom:created element, but MUST NOT contain more than
                         ^summary (not created)

| 4.13.10  "atom:content" Element
| 
|    The "atom:content" element is a Content construct that conveys the
|    content of the entry.  atom:entry elements MAY contain one or more
|    atom:content elements.
| 
|    If @type="multipart/alternative", @mode MUST NOT be specified, and
|    content element MUST contain 1 or more content elements.  These

This discussion of multipart/alternative needs expansion. I'm pretty
sure I don't understand what's intended based on just this text.

A couple of general comments:

1. A schema, RELAX NG would be my preference, even if it's
non-normative would be very helpful. I'll volunteer to write and
maintain it, if that helps.

2. No where does the document talk about significant whitespace. I'm
guessing that some folks are expecting that leading and trailing
whitespace isn't significant in some elements, but it doesn't say so.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | A polar bear is just another way of
http://nwalsh.com/            | expressing a rectangular bear.

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA7wvpOyltUcwYWjsRAkSfAJ9tTXyuMEBgC0vtGRvf2dHSiHFhNgCfcPgx
0DKWxHf5FNffKYPfPfqJbyw=
=+yhY
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Fri Jul  9 18:01: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 SAA04873
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 18:01: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 i69LpeDh010582;
	Fri, 9 Jul 2004 14:51:40 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i69LpeEV010581;
	Fri, 9 Jul 2004 14:51:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rongo.sixapart.com (dsl081-057-015.sfo1.dsl.speakeasy.net [64.81.57.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i69Lpet8010573
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 14:51:40 -0700 (PDT)
	(envelope-from ezra@sixapart.com)
Received: from [192.168.100.250] (unknown [192.168.100.250])
	by rongo.sixapart.com (Postfix) with ESMTP id 09ADA47E9C
	for <atom-syntax@imc.org>; Fri,  9 Jul 2004 13:48:36 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v618)
Content-Transfer-Encoding: 7bit
Message-Id: <28400F40-D1F2-11D8-B5BD-000A95CFF6CC@sixapart.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: atom-syntax@imc.org
From: Ezra Cooper <ezra@sixapart.com>
Subject: Re: PacePutToCreate
Date: Fri, 9 Jul 2004 14:51:39 -0700
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>
Content-Transfer-Encoding: 7bit


On Jul 8, 2004, at 6:24 PM, Robert Sayre wrote:

> Although the definition of PUT says the effect on the server state is
> undefined, the 201 Response definition[2] states that you have to 
> create the
> resource. So it would appear that you have to serve it there, at least 
> for
> GET. I'll note that the AtomAPI doesn't currently require the EditURI 
> to be
> the same URI created by POSTing to the PostURI.

If I understand this right, you have to serve the entry for a GET to 
the URI where the resource was successfully created; but to Steve's 
question, the server could deny a PUT to any path where the server 
didn't want to serve it up again. So, an example series of transactions 
where the client stubbornly tried to choose it's own path:

   Client:   PUT /base-uri/some/crazy/path
   Server:  301 That's a Crazy Path
   Server:  Location: /base-uri/good-path/nonce-value-1

   Client:  PUT /base-uri/good-path/nonce-value-1
   Server:  201 Created
   Server:  Location: /base-uri/good-path/nonce-value-1

   Client:   PUT /base-uri/some/crazy/path
   Server:  301 That's a Crazy Path
   Server:  Location: /base-uri/good-path/nonce-value-2

   Client:   PUT /base-uri/some-other-crazy/path
   Server:  301 That's a Crazy Path
   Server:  Location: /base-uri/good-path/nonce-value-3

   Client:  PUT /base-uri/good-path/nonce-value-3
   Server:  201 Created
   Server:  Location: /base-uri/good-path/nonce-value-3

   Client:  PUT /archives/2004/07/08/pace_put_to_cre.html
   Server:  201 I Love Your Path
   Server:  Location: /archives/2004/07/08/pace_put_to_cre.html

This seems to me an elegant way to solve the non-idempotence problem, 
together with the question of non-entry-resources.

The only negative I see is that it always requires an extra round-trip 
so that the client knows the right path (of course that's the same with 
any of these magic-token approaches to idempotence). That would 
definitely be an issue when putting big images, or any images from cell 
phones. But the client could post an empty (or minimal) entry until it 
succeeds and knows the URI. Then it could "fill in" that resource with 
a second PUT. To save on bandwidth, maybe we should specify that 
behavior, of PUTting a minimal entry until you have a legit URI?

Would this proposal entail dropping the ability to create a top-level 
resource with POST?

Ezra



From owner-atom-syntax@mail.imc.org  Fri Jul  9 18: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 SAA05393
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 18: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 i69Lubru010927;
	Fri, 9 Jul 2004 14:56: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 i69LubT4010926;
	Fri, 9 Jul 2004 14:56:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i69Lubuk010918
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 14:56:37 -0700 (PDT)
	(envelope-from jens@apple.com)
Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204])
	by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id i69LvFjv029533
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 14:57:15 -0700 (PDT)
Received: from relay2.apple.com (relay2.apple.com) by mailgate2.apple.com
 (Content Technologies SMTPRS 4.3.6) with ESMTP id <T6ab0d0a516118064cc638@mailgate2.apple.com>;
 Fri, 9 Jul 2004 14:56:37 -0700
Received: from [17.202.21.229] (snej.apple.com [17.202.21.229])
	by relay2.apple.com (8.12.11/8.12.11) with ESMTP id i69LuYgf013445;
	Fri, 9 Jul 2004 14:56:35 -0700 (PDT)
In-Reply-To: <878ydsubdi.fsf@nwalsh.com>
References: <200407091923.PAA23330@ietf.org> <878ydsubdi.fsf@nwalsh.com>
Mime-Version: 1.0 (Apple Message framework v669)
Content-Type: multipart/alternative; boundary=Apple-Mail-16--566157425
Message-Id: <D6B92BD6-D1F2-11D8-A027-000A95A0ACC4@apple.com>
Cc: atom-syntax@imc.org
From: Jens Alfke <jens@apple.com>
Subject: Re: Comments on I-D ACTION:draft-ietf-atompub-format-00.txt
Date: Fri, 9 Jul 2004 14:56:32 -0700
To: Norman Walsh <ndw@nwalsh.com>
X-Mailer: Apple Mail (2.669)
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-16--566157425
Content-Type: text/plain;
	charset=WINDOWS-1252;
	format=flowed
Content-Transfer-Encoding: quoted-printable


On Jul 9, 2004, at 2:19 PM, Norman Walsh wrote:

> It seems slightly odd to me that the title is a Content construct. I=20=

> think
> I'd be happier if the title was a string.

That's so the feed's title can contain markup, without the annoying=20
ambiguities present in RSS. I agree that it seems less likely that a=20
feed title will require markup than an entry title; but it's still a=20
reasonable thing to allow.

(One possible example: some blogs give every post its own feed of=20
comments. In this case the title of the comment feed would naturally be=20=

based on the title of the original post, which can contain markup, most=20=

likely italics.)

> | 4.11  "atom:info" Element
...
> If it's not meaningful to processors and may be a convenience to
> publishers, I suggest that sometimes it will be a convenience that
> more than one publisher will simultaneously want to use. Therefore,
> more than one should be allowed.

But a feed can have only one publisher, so I don't see how "more than=20
one publisher" applies here.

_______________________________________
Jens Alfke =97 Atom/RSS Wrangler =97 Apple Computer
=93Understand that you are another world in miniature,
and that in you are the sun, the moon & also stars=94

--Apple-Mail-16--566157425
Content-Type: text/enriched;
	charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable



On Jul 9, 2004, at 2:19 PM, Norman Walsh wrote:


<excerpt>It seems slightly odd to me that the title is a Content
construct. I think

I'd be happier if the title was a string.

</excerpt>

That's so the feed's title can contain markup, without the annoying
ambiguities present in RSS. I agree that it seems less likely that a
feed title will require markup than an entry title; but it's still a
reasonable thing to allow.


(One possible example: some blogs give every post its own feed of
comments. In this case the title of the comment feed would naturally
be based on the title of the original post, which can contain markup,
most likely italics.)


<excerpt>| 4.11  "atom:info" Element

</excerpt>...

<excerpt>If it's not meaningful to processors and may be a convenience
to

publishers, I suggest that sometimes it will be a convenience that

more than one publisher will simultaneously want to use. Therefore,

more than one should be allowed.

</excerpt>

But a feed can have only one publisher, so I don't see how "more than
one publisher" applies here.


<flushright><bold>_______________________________________</bold>

<bold>Jens Alfke</bold> =97 Atom/RSS Wrangler =97 Apple Computer

<italic><color><param>8383,A9A9,7D7D</param><x-tad-smaller>=93Understand
that you are another world in miniature,

and that in you are the sun, the moon & also =
stars=94</x-tad-smaller></color></italic>

</flushright>=

--Apple-Mail-16--566157425--



From owner-atom-syntax@mail.imc.org  Fri Jul  9 18:18: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 SAA07564
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 18:18: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 i69LvsIt011035;
	Fri, 9 Jul 2004 14:57: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 i69LvsOS011034;
	Fri, 9 Jul 2004 14:57:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.71.10.67] (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 i69LvqJk011025
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 14:57:53 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p06110431bd14c3d710f2@[10.71.10.67]>
Date: Fri, 9 Jul 2004 14:58:04 -0700
To: Atom WG <atom-syntax@imc.org>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: How to (and how not to) create subject lines
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>


Greetings again. As you have possibly noticed, the first versions of 
our two WG items were just published. Some of you are probably 
reading them right now; great! Some of you will even want to respond 
to what is in the documents: great!

When you do respond, please create a succinct and useful subject line 
for you message. Do *not* simply reply to the original message that 
said that the documents were available. That is, to *not* reply to 
the message whose subject is "I-D 
ACTION:draft-ietf-atompub-format-00.txt" and so on.

This may seem obvious, but it is incredibly common in the IETF for 
people to reply to the I-D ACTION announcements with comments about 
the documents. Someone who is scanning the subject lines has no idea 
that such messages say anything useful, and such messages are often 
ignored.

And, having said that, please start discussing! And, of course, 
please keep discussing the topics-of-the-week from the issuese list.

Topics-of-the-week (for this week):
    <http://www.imc.org/atom-syntax/mail-archive/msg06348.html>
Issues list:
    <http://www.intertwingly.net/wiki/pie/AtomPubIssuesList>

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Fri Jul  9 18:30: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 SAA08921
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 18:30: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 i69MKgdr013510;
	Fri, 9 Jul 2004 15: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 i69MKgfb013509;
	Fri, 9 Jul 2004 15:20: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 i69MKgWL013501
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 15:20:42 -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 1Bj3jY-00030t-Fv; Fri, 09 Jul 2004 22:20:44 +0000
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Fri, 09 Jul 2004 18:20:55 -0400
Subject: Re: PacePutToCreate
From: Robert Sayre <mint@franklinmint.fm>
To: Ezra Cooper <ezra@sixapart.com>, Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD149287.12059%mint@franklinmint.fm>
In-Reply-To: <28400F40-D1F2-11D8-B5BD-000A95CFF6CC@sixapart.com>
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: <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 7/8/04 10:47 PM, "Ezra Cooper" <ezra@sixapart.com> wrote:

> On Jul 8, 2004, at 6:24 PM, Robert Sayre wrote:
> 
> If I understand this right, you have to serve the entry for a GET to
> the URI where the resource was successfully created; but to Steve's
> question, I believe the server could deny a PUT to any path where the
> server didn't want to serve it up again. So, an example series of
> transactions where the client stubbornly tried to choose it's own path:
> 

[examples]

> 
> Is that right?

Yes, but I'm not sure that doing this on purpose is following the spirit of
the RFC. The client should be making a good-faith guess for the path.

> 
> This seems to me an elegant way to solve the non-idempotence problem.
> The only negative I see is that it always requires an extra round-trip
> so that the client knows the right path (of course that's the same with
> any of these magic-token approaches to idempotence).

We could mix the two approaches. Instead of asking for a magic token, ask
for a URI to PUT.

> That would 
> definitely be an issue when putting big images, or any images from cell
> phones. But the client could post an empty (or minimal) entry until it
> succeeds and knows the URI. Then it could update that resource with a
> second PUT? Is that correct?
> 

Yes, it could then update with a second PUT.

Robert Sayre



From owner-atom-syntax@mail.imc.org  Fri Jul  9 18:44:24 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09678
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 18:44: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 i69MX4H2014648;
	Fri, 9 Jul 2004 15: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 i69MX4aA014647;
	Fri, 9 Jul 2004 15:33:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.71.10.67] (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 i69MX2Dn014641
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 15:33:03 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p06110436bd14cbc1ebd0@[10.71.10.67]>
In-Reply-To: <637DD3CC3464070D384557EA@[192.168.168.164]>
References: <opsau4kyb0uvpchu@quark>
 <637DD3CC3464070D384557EA@[192.168.168.164]>
Date: Fri, 9 Jul 2004 15:33:22 -0700
To: Atom-Syntax <atom-syntax@imc.org>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Armchair lawyers (was: Patent threatens autodiscovery)
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>


Ah, another rite of passage into the IETF. Here is the first of what 
might be many forays into the world of "I am not a patent lawyer but 
that doesn't stop me from saying what I think about this patent".

Imagine how useful it would be if donut bakers sitting around the 
room said "I don't know anything about XML or syndication, but let's 
start critiquing this new Atom protocol."

As someone who is not a lawyer, and is not a patent lawyer, but is 
someone who has been taught a few things about patent law, let me 
assure us all that trying to figure this out on our own is a complete 
waste of time. Most lawyers wouldn't even try to figure out patent 
law, so it is even more absurd for non-lawyers to do so.

If you know of a patent that you think affects the WGs work, by all 
means let either Tim and I know. That's part of our job.

If you have an expert opinion on a particular patent from a patent 
lawyer that you want to share with the list, go ahead. Everyone who 
likes to rely on free legal advice might be interested. Otherwise, 
please think about whether what you want to post is of any value to 
the WG. Thanks!

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Fri Jul  9 18:52: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 SAA10451
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 18:52: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 i69MguVN015299;
	Fri, 9 Jul 2004 15:42: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 i69MguIX015298;
	Fri, 9 Jul 2004 15:42:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.71.10.67] (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 i69MgtAH015292
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 15:42:56 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p06110437bd14cedca63b@[10.71.10.67]>
In-Reply-To: <20040708031231.GL30868@markbaker.ca>
References: <14be96d3040707103826ba6c34@mail.gmail.com>
 <20040708031231.GL30868@markbaker.ca>
Date: Fri, 9 Jul 2004 15:43:16 -0700
To: Atom Syntax <atom-syntax@imc.org>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: IRIs, URIs, and RFC 2396bis
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 11:12 PM -0400 7/7/04, Mark Baker wrote:
>On Wed, Jul 07, 2004 at 01:38:50PM -0400, Mark Pilgrim wrote:
>  > Should this be
>>  changed to "whose value MUST be a URI, as defined by RFC2396 or its
>>  successor," so that Atom can benefit from RFC2396bis? [3]
>
>It's my understanding that "or its successor" is implied in RFCs.
>That is, when one RFC obsoletes another, all references to the
>obsoleted RFC are considered to be updated.
>
>2026 doesn't say, but I'm sure I've heard that on at least a couple
>of occasions.  Paul?

Sorry for the delay in getting to this. Talking about references to 
RFCs in general here.

If we say "or its successor", we get that. If we don't say it, we 
point *exactly* to the RFC in question. Successors are *not* implied.

This is very important for many reasons. Successors might change some 
bits-on-the-wire; that would be Very Bad for us. Successors might 
change only some unclear parts, but those changes might be things 
that we as a group thought we understood.

That is why very few RFCs ever refer to other "and its successors" of an RFC.

In the specific case, if we point to RFC2396, that's what we get. If 
we point to the Internet Draft of the successor to RFC 2396, that's 
what we get. In the latter case, we also cannot finish with Atom 
until that document is finished. And before you say "oh, but 
rfc2396bis is far ahead of us", remember that they have been far 
ahead of us for years and are still not finished.

This is one of the un-fun things of making standards: guessing which 
thing that we rely on are going to be out of the oven before us. Tim 
and I will look at this later in the baking process.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Fri Jul  9 19:08: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 TAA11756
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 19:08: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 i69MhEXL015329;
	Fri, 9 Jul 2004 15: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 i69MhEWh015328;
	Fri, 9 Jul 2004 15:43:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i69MhDV9015322
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 15:43:14 -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 1Bj45M-0003jq-RN
	for atom-syntax@imc.org; Fri, 09 Jul 2004 22:43:16 +0000
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Fri, 09 Jul 2004 18:43:22 -0400
Subject: Pace409Response
From: Robert Sayre <mint@franklinmint.fm>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD1497CA.1205C%mint@franklinmint.fm>
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: <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



http://www.intertwingly.net/wiki/pie/Pace409Response


--Abstract--

Add sections about "409 Conflict" response status codes to the APP draft.

--Status--

Active. Please direct discussion to the atom-syntax list.

--Rationale--

Currently, some AtomAPI implementations return status code 400 when they
receive a valid Atom representation that conflicts with the state on the
server. Status code 400 is reserved for problems arising from malformed
syntax.

--Proposal--

Atom Publishing Protocol

PostURI 

3.1.3  Response

   The possible status codes from a POST are 201, 303, 400, 401, 404, 409,
410, and 500.

3.1.3.x Status Code 409

   The request contained a valid Atom Entry, but it conflicts with state on
the server.The response SHOULD contain enough for information for the user
to resolve the conflict.
   
[[ more about response body format ]]



EditURI 

3.2.x  Response to PUT Requests

   The possible status codes from a PUT are ...409, ...

3.2.x.x Status Code 409

   The request contained a valid Atom Entry, but it conflicts with the state
of the resource, or other state on the server.

   For example, a server could signal that client has erred in this manner
if it receives a request containing an atom:id element whose value differs
from that of the resource found at the requested URI.

   The response SHOULD contain enough for information for the user to
resolve the conflict.

[[ more about response body format ]]

--Impacts--

Atom Publishing Protocol status codes.



From owner-atom-syntax@mail.imc.org  Fri Jul  9 19:24: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 TAA12351
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 19:24: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 i69N1OQF016638;
	Fri, 9 Jul 2004 16: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 i69N1Owd016637;
	Fri, 9 Jul 2004 16:01:24 -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 i69N1BKi016614
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 16:01:24 -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 i69N1953022610
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 18:01:09 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i69N19lO022606;
	Fri, 9 Jul 2004 18:01:09 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceIntrospection: New Examples for Feed-Based Introspection
References: <40EE8741.4020703@spoonybards.net>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 09 Jul 2004 18:01:08 -0500
In-Reply-To: <40EE8741.4020703@spoonybards.net>
Message-ID: <m3briordjf.fsf@bitsko.slc.ut.us>
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


Beecher Greenman <millennium@spoonybards.net> writes:

>    <entry>
>      <title>First Site</title>
>      <link rel="alternate" type="text/html"
> href="http://manyblogs.org/bob/FirstSite"/>
>      <!-- Feed and Post URLs -->
>      <link type="application/atom+xml" rel="service.post"
> href="http://manyblogs.org/bob/FirstSite/post"/>
>      <link type="application/atom+xml" rel="service.feed"
> href="http://manyblogs.org/bob/FirstSite/feed"/>
>      <!-- issued: Time when service was first published. -->
>      <issued>2004-06-24T19:14:06Z</issued>
>      <!-- modified: Time when blog was last updated -->
>      <modified>2004-06-24T19:14:06Z</modified>
>      <id>tag:manyblogs.org,2004-06-24:/bob/FirstSite</id>
>    </entry>

If this resource description in the list of resource were a <site>
resource instead of an <entry> resource, the client would know better
what to do with it.  Does a client discover that this "entry" is
really a "site" by merely the presence of, say, the "service.post" and
"service.feed" link?  Main-level entries have the same links (they may
have a PostURI and FeedURI for the entry and its comments).

> It's worth noting that Ken MacLeod and Steve Jenson have recently
> proposed that <title> and <id> elements be added to the current
> PaceIntrospection proposal's <site> tag. Both of these seem to have
> been inspired by the similar tags in the feed format, and since what
> I'm proposing uses that format, it already includes both of those
> tags.

It's worth noting that thousands of resource types can have titles and
identifiers, but not all resource types are entries.

If we want to make <feed>s into generic lists and <entry>s into
generic metadata containers, then fine, lets get consensus on *that*
so that we can start specifying a new technique, rather than their
element type name, for discovering the resource type that really is
being dealt with.

    <entry>
      <resource-type>site</resource-type>
      <title>First Site</title>
      <link rel="alternate" type="text/html"
         href="http://manyblogs.org/bob/FirstSite"/>
      ...
    </entry>

It's @rel, all over again.

  -- Ken



From owner-atom-syntax@mail.imc.org  Fri Jul  9 20:07:12 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15190
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 20:07: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 i69NhRK6019375;
	Fri, 9 Jul 2004 16:43:27 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i69NhRm9019374;
	Fri, 9 Jul 2004 16:43:27 -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 i69NhQu4019363
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 16:43:26 -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 <2004070923432701300j34ume>; Fri, 9 Jul 2004 23:43:27 +0000
Date: Fri, 9 Jul 2004 17:43:26 -0600
Subject: Re: PaceIntrospection: New Examples for Feed-Based Introspection
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: <m3briordjf.fsf@bitsko.slc.ut.us>
Message-Id: <C5B0A5DC-D201-11D8-89AD-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 Friday, July 9, 2004, at 05:01  PM, Ken MacLeod wrote:
> If we want to make <feed>s into generic lists and <entry>s into
> generic metadata containers, then fine, lets get consensus on *that*
> so that we can start specifying a new technique, rather than their
> element type name, for discovering the resource type that really is
> being dealt with.
>
>     <entry>
>       <resource-type>site</resource-type>
>       <title>First Site</title>
>       <link rel="alternate" type="text/html"
>          href="http://manyblogs.org/bob/FirstSite"/>
>       ...
>     </entry>
>
> It's @rel, all over again.
>
So, we have a few options to choose between--here are those that come 
to my mind:

1) Use <feed> and <entry> for everything, with something like 
<resource-type> or @resource-type to differentiate them.
2) Use <feed> and <entry> for everything, with nothing concrete to 
differentiate them--rely on context somehow.
3) Invent new elements for things that don't fit the model of what a 
<feed> or <entry> is (whatever those models are...).
4) Create a definition of a List Construct and an Entry Construct 
(similar to how we have Date Constructs, Content Constructs, and Link 
Constructs), and then create elements based on those (List Construct = 
feed, introspection..., Entry Construct = entry, site...).

As long as the structure of a List Construct and Entry Construct will 
work for all the kinds of data we want to shove into them, I think #4 
would be my preferred method.  If they're too different from each 
other, I'd prefer #3.

Finally, an idea I don't know that I'd support, but would like to raise 
for comment: would there be value in having all 
List|Entry|Date|Person|Link Construct element names start with a common 
prefix. For example: date-created, date-modified, date-issued, 
list-feed, list-introspection, person-author, person-contributor, 
entry-entry, entry-site...?  It leads to longer names, but MIGHT have 
some sort of "partial understanding" benefits.  I guess this is really 
an extensibility question--if we do this in the core spec, I'd expect 
it would be recommended for extensions, for example foo:list-bar, 
foo:person-bar, foo:date-bar...

Antone

P.S. On a different but similar subject, one might ask why I prefer #4 
but support link/@rel. First, because there are a lot more @rel values 
than there would be List & Entry Constructs. Second, as mentioned 
elsewhere, I'm warming to dumping link/@rel.



From owner-atom-syntax@mail.imc.org  Fri Jul  9 21:25:27 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20734
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 21:25:26 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6A1DTbD025621;
	Fri, 9 Jul 2004 18: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 i6A1DTc0025620;
	Fri, 9 Jul 2004 18:13:29 -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 i6A1DStP025609
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 18:13:28 -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 8EFD64EFBA;
	Fri,  9 Jul 2004 21:13:31 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040710094503.03c13580@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Sat, 10 Jul 2004 10:08:17 +0900
To: Sam Ruby <rubys@intertwingly.net>
From: Martin Duerst <duerst@w3.org>
Subject: Re: Wiki setup issues: IRI
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <40EED1F9.9000601@intertwingly.net>
References: <4.2.0.58.J.20040709091221.060d8590@localhost>
 <4.2.0.58.J.20040709091221.060d8590@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


Hello Sam,

Many thanks for looking into this. There is a slight additional catch
that I realized a few hours after writing my mail. See below.

At 13:12 04/07/09 -0400, Sam Ruby wrote:

>Martin Duerst wrote:
>>When working on http://intertwingly.net/wiki/pie/PaceIRI
>>(not at all complete yet), I put my name (the real one, with umlaut,
>>not the one I have to use in my outdated Japanese mailer) in square
>>brackets at the start of the Abstract like I had seen it on other Paces
>>such as http://intertwingly.net/wiki/pie/PaceUriOrItsSuccessor.
>>When I then clicked on it, I got to
>>http://intertwingly.net/wiki/pie/MartinD_fcrst, which shows
>>that with a few, probably very simple, changes to the wiki
>>setup/code, this could be made compatible with IRIs.
>>Two changes are necessary:
>>1) Change the wiki to use UTF-8 for its page encoding rather than
>>    iso-8859-1. For a new wiki, this should just be a setup issue
>>    (otherwise, choose another wiki software, or maybe another ISP).
>>    For the current wiki, pages with non-ASCII characters have to be
>>    converted to UTF-8 at the same time the setup is changed.
>>    Doing that is easy if you have access to the actual files.
>>    In line with http://intertwingly.net/stories/2004/04/14/i18n.html,
>>    I would suggest that we do that anyway, and I'm ready to help.
>>    This would then change the above URI from
>>    http://intertwingly.net/wiki/pie/MartinD_fcrst to
>>    http://intertwingly.net/wiki/pie/MartinD_c3_bcrst.
>
>In moin_config.py, there is the following:
>
>   charset = 'iso-8859-1'
>
>While this looks hopeful, it seems to me that such a change would not only 
>affect the character set used within the pages, but would also change the 
>NAME of the page.  Simply put, MartinD_fcrst and MartinD_c3_bcrst are 
>separate pages, and changing the encoding used in the page would change 
>which one of these pages were the target of the link.

Yes. I didn't mention this because I didn't actually create my page,
but as you point out, we already have such cases.


>Examples of pages it would affect:
>
>http://www.intertwingly.net/wiki/pie/Fran_e7oisGranger?action=fullsearch&va 
>lue=Fran%E7oisGranger&literal=1&case=1&context=40
>
>Thinking about it a bit, my preference is to NOT directly fix the source 
>files.  It seems to me that the number of issues should be small - I am 
>quite willing to write programs to generate reports of potentially 
>problematic pages, but unless the changes required are massive AND readily 
>and safely automatable, then I would prefer that the change be made by hand.

Would be fine by me, but I have to admit that I have no clue about
how much non-ASCII content there is in the various pages. But I can
provide scripts for checking.


>>2) Change the escape character from '_' to '%'. This would change
>>    the above URI from
>>    http://intertwingly.net/wiki/pie/MartinD_c3_bcrst to
>>    http://intertwingly.net/wiki/pie/MartinD%c3%bcrst.
>>    While at it, please also change escaping from lowercase to
>>    upper case, in accordance with 2396bis. This would give
>>    http://intertwingly.net/wiki/pie/MartinD%C3%BCrst.
>
>This also changes the name of the page.  In particular, some of the help 
>pages delivered with Moin have URI escaped slash characters in their name 
>(example: http://www.intertwingly.net/wiki/pie/HelpOnInstalling).

Oh well. Leaving the slash escaped as _2f is probably best.
Prohibiting the creation of such pages, or actually creating
subdirectories and using a real slash, would have been better.


>However, it looks like the code change itself should be simple as the 
>mapping is done in exactly one place.

Here's the catch. The _hh escape and the %HH escape work on a
slightly different level. Here's a table comparing the two:

escape     File system      URI            href          <a> content
_hh        _hh              _hh            _hh           raw text
%HH        raw text (1)     %HH            %HH (2)       raw text

Column legend:
escape:       what escaping convention is used
File system:  how do the file names appear in the file system
URI:          what gets sent to the server in a GET request
href:         what's in the href attribute of a link
<a> content:  what's in the content of a link

(1) is the catch: While with _hh escaping, the file name in the file system
     is _hh, with %HH escaping, the file name has to use raw bytes. This is
     both desired (because then you can look at the files with a
     finder/explorer or with dir/ls and see the real names) as well as
     necessary (an URI sent with %HH escaping will be converted to raw bytes
     by the server).
     So this means that you have to be slightly more careful with the change;
     just changing the escaping convention is unfortunately not enough.
     I still hope it will be easy enoungh.

(2) Instead of %HH, it is also possible to use raw text. This would then
     be an IRI. While full IRI functionality isn't implemented in all browsers
     yet, I haven't heard about any browser that wouldn't let this work
     as long as the actual page is encoded in UTF-8.


>>The two changes are largely independent, and can be done in any order.
>>If everything goes well, the file names are then actually readable,
>>on an Unix/Linux system assuming you have selected an UTF-8 locale (most
>>new Linux systems are shipped that way, as far as I understand).
>
>It looks to me that the way to proceed is to pick some relatively quiet 
>time (perhaps this weekend), make both changes at once, and then fix what 
>breaks.

That would be great. Please tell me if you need further help.

Regards,    Martin.


>>As I said, I'd be very glad to help get this fixed.
>>I don't really care too much about my own name, I could
>>use 'Duerst' as a fallback, but it'd really be better
>>to fix this on this occasion.
>>Regards,    Martin.
>
>- Sam Ruby



From owner-atom-syntax@mail.imc.org  Fri Jul  9 22:07: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 WAA23950
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 22:07: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 i6A1vtLY029792;
	Fri, 9 Jul 2004 18:57: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 i6A1vtcN029791;
	Fri, 9 Jul 2004 18:57: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.194])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6A1vslv029784
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 18:57:54 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d19so257975rnf
        for <atom-syntax@imc.org>; Fri, 09 Jul 2004 18:57:48 -0700 (PDT)
Received: by 10.38.9.55 with SMTP id 55mr112482rni;
        Fri, 09 Jul 2004 18:57:48 -0700 (PDT)
Message-ID: <14be96d304070918576165a6a1@mail.gmail.com>
Date: Fri, 9 Jul 2004 21:57:48 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Norman Walsh <ndw@nwalsh.com>
Subject: Processing instructions (was Re: Comments on I-D ACTION:draft-ietf-atompub-format-00.txt)
Cc: atom-syntax@imc.org
In-Reply-To: <878ydsubdi.fsf@nwalsh.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <200407091923.PAA23330@ietf.org> <878ydsubdi.fsf@nwalsh.com>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


On Fri, 09 Jul 2004 17:19:37 -0400, Norman Walsh <ndw@nwalsh.com> wrote:
> |    Atom documents SHOULD NOT contain Processing Instructions, unless
> 
> Why not? And what's the value of saying "should not" anyway. The spec
> goes on to say that comments are allowed, but provides no semantics
> for them. Why can't we just say PIs are allowed but provide no
> semantics for them.

+1.  My Atom feed has PIs for browser-based XSLT transforms. 
Blogger's feeds have PIs for some minimal CSS styling.  There may be
other uses in the future.

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Fri Jul  9 22:09:02 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24222
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 22:09: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 i6A20bJL030006;
	Fri, 9 Jul 2004 19:00: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 i6A20bjr030005;
	Fri, 9 Jul 2004 19:00:37 -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 i6A20bOl029999
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 19:00:37 -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 DD84F4F36E;
	Fri,  9 Jul 2004 22:00:41 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040710104808.062757b8@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Sat, 10 Jul 2004 10:50:20 +0900
To: Norman Walsh <ndw@nwalsh.com>, atom-syntax@imc.org
From: Martin Duerst <duerst@w3.org>
Subject: atom:title as content construct (was: Re: Comments on I-D
  ACTION:draft-ietf-atompub-format-00.txt)
In-Reply-To: <878ydsubdi.fsf@nwalsh.com>
References: <200407091923.PAA23330@ietf.org>
 <200407091923.PAA23330@ietf.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: <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 17:19 04/07/09 -0400, Norman Walsh wrote:

>| 4.3  "atom:title" Element
>|
>|    The "atom:title" element is a Content construct that conveys a
>
>It seems slightly odd to me that the title is a Content construct. I think
>I'd be happier if the title was a string.

Given that people might want to put mathematical formulas into titles,
that they may want to put ruby in a title, that they may want to put
multilingual strings in a title and want to clearly indicate that,
and so on, I'd be much happier if title stayed a content construct.

Regards,    Martin.




From owner-atom-syntax@mail.imc.org  Fri Jul  9 22: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 WAA24345
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 22: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 i6A1u2TY029602;
	Fri, 9 Jul 2004 18: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 i6A1u2AU029601;
	Fri, 9 Jul 2004 18:56: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.203])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6A1u1G5029595
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 18:56:01 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d19so257919rnf
        for <atom-syntax@imc.org>; Fri, 09 Jul 2004 18:55:51 -0700 (PDT)
Received: by 10.38.72.47 with SMTP id u47mr56703rna;
        Fri, 09 Jul 2004 18:55:51 -0700 (PDT)
Message-ID: <14be96d3040709185577f98ea0@mail.gmail.com>
Date: Fri, 9 Jul 2004 21:55:51 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Norman Walsh <ndw@nwalsh.com>
Subject: Serialization matters (was Re: Comments on I-D ACTION:draft-ietf-atompub-format-00.txt)
Cc: atom-syntax@imc.org
In-Reply-To: <878ydsubdi.fsf@nwalsh.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <200407091923.PAA23330@ietf.org> <878ydsubdi.fsf@nwalsh.com>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


On Fri, 09 Jul 2004 17:19:37 -0400, Norman Walsh <ndw@nwalsh.com> wrote:
> |    Atom documents are specified in terms of the XML Information Set,
> |    serialised as XML 1.0 and identified with the "application/atom+xml"
> |    media type.
> 
> I find the mention of the serialization format here a bit odd. If the
> spec is going to describe things in terms of the infoset, then the
> serialization form is irrelevant. If the spec wants to mandate a
> serialization form, that's fine too, but I don't think it should do
> that without justification.

This has been discussed at length.  Everyone seems to want Atom to be
described in terms of the InfoSet.  There is a small camp that wants
Atom to be serializable in any InfoSet-compatible form, and a
relatively larger camp that wants Atom to only ever be serializable as
text-based XML 1.0.  See
http://www.imc.org/atom-syntax/mail-archive/msg06161.html and
following thread for a recent flare-up of this discussion.

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Fri Jul  9 22: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 WAA24624
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 22: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 i6A1xrgx029942;
	Fri, 9 Jul 2004 18: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 i6A1xrWE029940;
	Fri, 9 Jul 2004 18:59: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.206])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6A1xop5029933
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 18:59:52 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d15so183873rng
        for <atom-syntax@imc.org>; Fri, 09 Jul 2004 18:59:56 -0700 (PDT)
Received: by 10.38.92.40 with SMTP id p40mr242987rnb;
        Fri, 09 Jul 2004 18:59:56 -0700 (PDT)
Message-ID: <14be96d3040709185954a33b28@mail.gmail.com>
Date: Fri, 9 Jul 2004 21:59:56 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Norman Walsh <ndw@nwalsh.com>
Subject: Embedding non-namespaced elements (was Re: Comments on I-D ACTION:draft-ietf-atompub-format-00.txt)
Cc: atom-syntax@imc.org
In-Reply-To: <878ydsubdi.fsf@nwalsh.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <200407091923.PAA23330@ietf.org> <878ydsubdi.fsf@nwalsh.com>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


On Fri, 09 Jul 2004 17:19:37 -0400, Norman Walsh <ndw@nwalsh.com> wrote:
> |    All elements and attributes in an Atom document MUST be
> |    namespace-qualified.
> 
> Does this apply only to top-level elements in an atom:feed or
> atom:entry element? If I want to ship around a content constructor
> containing DocBook V4.3 content (which has no namespace), I'm allowed
> to, aren't I?

Not currently.

How is DocBook usually embedded in other formats if it doesn't have a namespace?

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Fri Jul  9 22:22:16 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24909
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 22:22:15 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6A2716t030547;
	Fri, 9 Jul 2004 19:07: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 i6A271bE030546;
	Fri, 9 Jul 2004 19:07: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.201])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6A26uhY030535
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 19:07:00 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d15so184040rng
        for <atom-syntax@imc.org>; Fri, 09 Jul 2004 19:06:57 -0700 (PDT)
Received: by 10.38.9.12 with SMTP id 12mr190914rni;
        Fri, 09 Jul 2004 19:06:54 -0700 (PDT)
Message-ID: <14be96d3040709190645bc2207@mail.gmail.com>
Date: Fri, 9 Jul 2004 22:06:36 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Norman Walsh <ndw@nwalsh.com>
Subject: Language identification (was Re: Comments on I-D ACTION:draft-ietf-atompub-format-00.txt)
Cc: atom-syntax@imc.org
In-Reply-To: <878ydsubdi.fsf@nwalsh.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <200407091923.PAA23330@ietf.org> <878ydsubdi.fsf@nwalsh.com>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


On Fri, 09 Jul 2004 17:19:37 -0400, Norman Walsh <ndw@nwalsh.com> wrote:
> |    [RFC3066].  When determining element content's natural language, the
> |    first xml:lang attribute encountered in that element's ancestors MUST
> |    be used.
> 
> "...encountered on that element or the first of its ancestors..." or
> words to that effect. "Ancestor" can be construed to not include the
> current element.

The wording here is poor.  I think the intent is simply to follow
section 2.12 of the XML specification [1], which defines the
inheritance model for xml:lang.

Note that the XML specification also makes a passing reference to HTTP
as a transport that may also carry language identification.  I was
researching this earlier this afternoon.  HTTP has a Content-Language
header [2], but it's unclear whether this should be used as the
default language (in the absence of any xml:lang attributes).

Also note that the XML specification does specifically state that
xml:lang (if present) overrides the external language identification. 
This is notable in that it is different in some cases from the
precedence rules for character encoding (RFC 3023), of which we are
all now painfully aware.

To sum up, I think the wording here needs to be clarified and also
possibly include a normative reference to section 14.12 of RFC 2616. 
Can someone wise and knowledgeable in the art of HTTP header
maintenance instruct us on the appropriate semantics of the
Content-Language header?

[1] http://www.w3.org/TR/REC-xml/#sec-lang-tag
[2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.12

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Fri Jul  9 22:25: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 WAA25101
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 22:25: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 i6A2CVJc030946;
	Fri, 9 Jul 2004 19:12: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 i6A2CVfd030945;
	Fri, 9 Jul 2004 19:12: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.193])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6A2CUWb030938
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 19:12:30 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d19so258349rnf
        for <atom-syntax@imc.org>; Fri, 09 Jul 2004 19:12:24 -0700 (PDT)
Received: by 10.38.72.47 with SMTP id u47mr58782rna;
        Fri, 09 Jul 2004 19:12:24 -0700 (PDT)
Message-ID: <14be96d3040709191248065fe@mail.gmail.com>
Date: Fri, 9 Jul 2004 22:12:24 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Norman Walsh <ndw@nwalsh.com>
Subject: Possible rel values (was Re: Comments on I-D ACTION:draft-ietf-atompub-format-00.txt)
Cc: atom-syntax@imc.org
In-Reply-To: <878ydsubdi.fsf@nwalsh.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <200407091923.PAA23330@ietf.org> <878ydsubdi.fsf@nwalsh.com>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


On Fri, 09 Jul 2004 17:19:37 -0400, Norman Walsh <ndw@nwalsh.com> wrote:
> |    The "rel" attribute indicates the type of relationship that the link
> |    represents.  Link constructs MUST have a rel attribute, whose value
> |    MUST be a string, and MUST be one of the values enumerated in the
> |    Atom Protocol specification [Atom-protocol].
> 
> Please duplicate that list here. I don't care about the protocol and it's
> tedious to go read another spec just for a flat list.

This has been discussed at length, but useful discussion of possible
rel values has been derailed by several proposals that would do away
with this link @rel syntax altogether, in favor of something else
(separate elements, namespaces, etc.).

For background, see http://intertwingly.net/wiki/pie/PaceLinkPurpose
and the list of "related and conflicting proposals."

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Fri Jul  9 22:29: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 WAA25267
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 22:29: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 i6A2JWPI031663;
	Fri, 9 Jul 2004 19:19: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 i6A2JWmE031662;
	Fri, 9 Jul 2004 19:19: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.199])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6A2JVZJ031654
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 19:19:31 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d15so184365rng
        for <atom-syntax@imc.org>; Fri, 09 Jul 2004 19:19:28 -0700 (PDT)
Received: by 10.38.92.40 with SMTP id p40mr245490rnb;
        Fri, 09 Jul 2004 19:19:28 -0700 (PDT)
Message-ID: <14be96d304070919193bf494de@mail.gmail.com>
Date: Fri, 9 Jul 2004 22:19:28 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Norman Walsh <ndw@nwalsh.com>
Subject: Subjective vs. objective dates (was Re: Comments on I-D ACTION:draft-ietf-atompub-format-00.txt)
Cc: atom-syntax@imc.org
In-Reply-To: <878ydsubdi.fsf@nwalsh.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <200407091923.PAA23330@ietf.org> <878ydsubdi.fsf@nwalsh.com>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


On Fri, 09 Jul 2004 17:19:37 -0400, Norman Walsh <ndw@nwalsh.com> wrote:
> | 4.13.7  "atom:issued" Element
> |
> |    The "atom:issued" element is a Date construct that indicates the time
> |    that the entry was issued.  atom:entry elements MUST contain an
> |    atom:issued element, but MUST NOT contain more than one.
> |
> |    The content of an atom:issued element MAY omit a time zone.
> 
> Why is issued special? If everyone else has to have a time zone, why
> not require it here too for consistency?

The original thinking behind issued's lack of timezone is here:
http://intertwingly.net/blog/2003/07/01/Subjective-and-objective-dates

Note that recently, "issued" seems to have drifted into other
meanings.  It is a point of active discussion, and the original use
case seems to be getting lost in the shuffle.  See for example this
recent flare-up of this discussion:
http://www.imc.org/atom-syntax/mail-archive/msg06186.html

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Fri Jul  9 22:31: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 WAA25403
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 22:31: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 i6A2LHxS031844;
	Fri, 9 Jul 2004 19:21: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 i6A2LHGO031843;
	Fri, 9 Jul 2004 19:21: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.192])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6A2LG9G031837
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 19:21:17 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d15so184451rng
        for <atom-syntax@imc.org>; Fri, 09 Jul 2004 19:21:22 -0700 (PDT)
Received: by 10.38.208.57 with SMTP id f57mr101124rng;
        Fri, 09 Jul 2004 19:21:22 -0700 (PDT)
Message-ID: <14be96d304070919213f8a1ee9@mail.gmail.com>
Date: Fri, 9 Jul 2004 22:21:22 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Norman Walsh <ndw@nwalsh.com>
Subject: RELAX NG schema (was Re: Comments on I-D ACTION:draft-ietf-atompub-format-00.txt)
Cc: atom-syntax@imc.org
In-Reply-To: <878ydsubdi.fsf@nwalsh.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <200407091923.PAA23330@ietf.org> <878ydsubdi.fsf@nwalsh.com>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


On Fri, 09 Jul 2004 17:19:37 -0400, Norman Walsh <ndw@nwalsh.com> wrote:
> 1. A schema, RELAX NG would be my preference, even if it's
> non-normative would be very helpful. I'll volunteer to write and
> maintain it, if that helps.

http://www.dpawson.co.uk/relaxng/atom03/

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Fri Jul  9 22:34:30 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25621
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 22:34:29 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6A2GHs6031290;
	Fri, 9 Jul 2004 19:16: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 i6A2GHWh031289;
	Fri, 9 Jul 2004 19:16: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.199])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6A2GGh5031282
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 19:16:16 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d19so258473rnf
        for <atom-syntax@imc.org>; Fri, 09 Jul 2004 19:16:10 -0700 (PDT)
Received: by 10.38.9.55 with SMTP id 55mr114417rni;
        Fri, 09 Jul 2004 19:16:10 -0700 (PDT)
Message-ID: <14be96d30407091916b62507c@mail.gmail.com>
Date: Fri, 9 Jul 2004 22:16:10 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Norman Walsh <ndw@nwalsh.com>
Subject: Markup in titles (was Re: Comments on I-D ACTION:draft-ietf-atompub-format-00.txt)
Cc: atom-syntax@imc.org
In-Reply-To: <878ydsubdi.fsf@nwalsh.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <200407091923.PAA23330@ietf.org> <878ydsubdi.fsf@nwalsh.com>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


On Fri, 09 Jul 2004 17:19:37 -0400, Norman Walsh <ndw@nwalsh.com> wrote:
> | 4.3  "atom:title" Element
> |
> |    The "atom:title" element is a Content construct that conveys a
> 
> It seems slightly odd to me that the title is a Content construct. I think
> I'd be happier if the title was a string.

Very early snapshots of Atom had title has a string, but Blogger
allows markup in post titles, and they are adamant about preserving
this.  It seemed easier to make it a Content construct than something
halfway.

Note that the default content type for all Content constructs,
including title, is plain text.  If the title contains escaped markup,
it must be specified as type="text/html".  (Or, since I know you hate
the idea of escaped markup, type="application/xhtml+xml" plus inline
XHTML markup in the appropriate namespace.)

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Fri Jul  9 22: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 WAA25905
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 22: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 i6A2ULuK032895;
	Fri, 9 Jul 2004 19: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 i6A2ULTG032894;
	Fri, 9 Jul 2004 19:30:21 -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 i6A2UKwM032885
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 19:30:20 -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 i6A2UOil025120
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 20:30:24 -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 <0I0M001JY6YOG4@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Fri, 09 Jul 2004 20:30:24 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0M003IH6YNKJ@mail.sun.net> for atom-syntax@imc.org; Fri,
 09 Jul 2004 20:30:24 -0600 (MDT)
Date: Fri, 09 Jul 2004 19:30:21 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Embedding non-namespaced elements (was Re: Comments on I-D
 ACTION:draft-ietf-atompub-format-00.txt)
In-reply-to: <14be96d3040709185954a33b28@mail.gmail.com>
To: Mark Pilgrim <pilgrim@gmail.com>
Cc: atom-syntax@imc.org, Norman Walsh <ndw@nwalsh.com>
Message-id: <178C4DF8-D219-11D8-B2D0-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: <200407091923.PAA23330@ietf.org> <878ydsubdi.fsf@nwalsh.com>
 <14be96d3040709185954a33b28@mail.gmail.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 Jul 9, 2004, at 6:59 PM, Mark Pilgrim wrote:

>
> On Fri, 09 Jul 2004 17:19:37 -0400, Norman Walsh <ndw@nwalsh.com> 
> wrote:
>> |    All elements and attributes in an Atom document MUST be
>> |    namespace-qualified.

Norm's right to call this out, it's silly as stated.  First of all, 
*not* all attributes are namespace-qualified, consider <atom:link 
href=""> or <atom:content type="">, neither href= nor type= are in a 
namespace nor need they be.

Also, it seems completely unreasonable to rule out the use of legacy 
XML vocabularies that have no namespace in <atom:content>.  Like, for 
example, RSS2. -Tim



From owner-atom-syntax@mail.imc.org  Fri Jul  9 23:21: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 XAA29989
	for <atompub-archive@lists.ietf.org>; Fri, 9 Jul 2004 23:21:28 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6A36Yp4035921;
	Fri, 9 Jul 2004 20:06: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 i6A36YZ3035920;
	Fri, 9 Jul 2004 20:06: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 i6A36XZI035914
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 20:06: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 i6A37B2A014045
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 23:07:11 -0400
Message-ID: <40EF5D39.2020401@intertwingly.net>
Date: Fri, 09 Jul 2004 23:06:33 -0400
From: Sam Ruby <rubys@intertwingly.net>
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@imc.org
Subject: Re: Embedding non-namespaced elements (was Re: Comments on I-D ACTION:draft-ietf-atompub-format-00.txt)
References: <200407091923.PAA23330@ietf.org> <878ydsubdi.fsf@nwalsh.com> <14be96d3040709185954a33b28@mail.gmail.com> <178C4DF8-D219-11D8-B2D0-000A95A51C9E@sun.com>
In-Reply-To: <178C4DF8-D219-11D8-B2D0-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 Jul 9, 2004, at 6:59 PM, Mark Pilgrim wrote:
> 
>> On Fri, 09 Jul 2004 17:19:37 -0400, Norman Walsh <ndw@nwalsh.com> wrote:
>>
>>> |    All elements and attributes in an Atom document MUST be
>>> |    namespace-qualified.
> 
> Norm's right to call this out, it's silly as stated.  First of all, 
> *not* all attributes are namespace-qualified, consider <atom:link 
> href=""> or <atom:content type="">, neither href= nor type= are in a 
> namespace nor need they be.
> 
> Also, it seems completely unreasonable to rule out the use of legacy XML 
> vocabularies that have no namespace in <atom:content>.  Like, for 
> example, RSS2. -Tim

In general, I have found it easier to talk in terms of such vocabularies 
being in a namespace consisting of an empty string.  IMHO, the following 
should be legal:

<feed xmlns="http://purl.org/atom/ns#">
   <content>
     <book xmlns="">
       <chapter>
       </chapter>
     </book>
   </content>
</feed>

Annoyingly, <db:book xmlns:db=""> is not allowed in XML.  This namespace 
declaration is outright illegal in XML 1.0, and has the effect of 
undeclaring the db prefix in XML 1.1.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Sat Jul 10 01:12: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 BAA08525
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 01:11: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 i6A4sYCj044066;
	Fri, 9 Jul 2004 21:54:34 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6A4sY51044065;
	Fri, 9 Jul 2004 21:54:34 -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 i6A4sRA6044057
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 21:54:33 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.17] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id E8AE0728A; Fri,  9 Jul 2004 21:54:34 -0700 (PDT)
In-Reply-To: <178C4DF8-D219-11D8-B2D0-000A95A51C9E@sun.com>
References: <200407091923.PAA23330@ietf.org> <878ydsubdi.fsf@nwalsh.com> <14be96d3040709185954a33b28@mail.gmail.com> <178C4DF8-D219-11D8-B2D0-000A95A51C9E@sun.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <3C66303C-D22D-11D8-9A61-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: Mark Pilgrim <pilgrim@gmail.com>, atom-syntax@imc.org,
        Norman Walsh <ndw@nwalsh.com>
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: Embedding non-namespaced elements (was Re: Comments on I-D ACTION:draft-ietf-atompub-format-00.txt)
Date: Fri, 9 Jul 2004 21:54:33 -0700
To: Tim Bray <Tim.Bray@Sun.COM>
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>
Content-Transfer-Encoding: 7bit


+1

This was noticed early on, but there's never been a discussion of what 
the proper thing to say is.


On Jul 9, 2004, at 7:30 PM, Tim Bray wrote:

>
>
> On Jul 9, 2004, at 6:59 PM, Mark Pilgrim wrote:
>
>>
>> On Fri, 09 Jul 2004 17:19:37 -0400, Norman Walsh <ndw@nwalsh.com> 
>> wrote:
>>> |    All elements and attributes in an Atom document MUST be
>>> |    namespace-qualified.
>
> Norm's right to call this out, it's silly as stated.  First of all, 
> *not* all attributes are namespace-qualified, consider <atom:link 
> href=""> or <atom:content type="">, neither href= nor type= are in a 
> namespace nor need they be.
>
> Also, it seems completely unreasonable to rule out the use of legacy 
> XML vocabularies that have no namespace in <atom:content>.  Like, for 
> example, RSS2. -Tim
>

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Sat Jul 10 01:13: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 BAA08595
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 01: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 i6A52P9h045382;
	Fri, 9 Jul 2004 22: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 i6A52Poh045381;
	Fri, 9 Jul 2004 22: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.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 i6A52OP5045372
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 22:02:24 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.17] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id B976A727D; Fri,  9 Jul 2004 22:02:31 -0700 (PDT)
In-Reply-To: <878ydsubdi.fsf@nwalsh.com>
References: <200407091923.PAA23330@ietf.org> <878ydsubdi.fsf@nwalsh.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <58709D28-D22E-11D8-9A61-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: Editorial issues [was: Comments on I-D ACTION:draft-ietf-atompub-format-00.txt]
Date: Fri, 9 Jul 2004 22:02:30 -0700
To: Norman Walsh <ndw@nwalsh.com>
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>
Content-Transfer-Encoding: 7bit


Unless there's an objection, I'll consider the issues marked 
'Editorial' below as such, and will incorporate proposals for them into 
the next I-D.

On Jul 9, 2004, at 2:19 PM, Norman Walsh wrote:
> [...]
> |    Therefore, when this specification uses the term "element," it is
> |    refering to an Element Information Item in Infoset terms.  
> Likewise,
> |    when it uses the term "attribute," it is refering to an Attribute
> |    Information Item.
>
> What about entity, document, etc.? Are those words shorthand as well?
>
> | 2.  Atom Documents
> |
> |    An Atom document
>
> Am I to assume document information item here?

Editorial.


> |    [RFC3066].  When determining element content's natural language, 
> the
> |    first xml:lang attribute encountered in that element's ancestors 
> MUST
> |    be used.
>
> "...encountered on that element or the first of its ancestors..." or
> words to that effect. "Ancestor" can be construed to not include the
> current element.

Editorial.


> |    the author.  It MAY be the name of a corporation or other entity 
> no
>                                                                      ^ 
> when?
> |    individual authors can be named.  Person constructs MUST contain

Editorial.


> |    The "rel" attribute indicates the type of relationship that the 
> link
> |    represents.  Link constructs MUST have a rel attribute, whose 
> value
> |    MUST be a string, and MUST be one of the values enumerated in the
> |    Atom Protocol specification [Atom-protocol].
>
> Please duplicate that list here. I don't care about the protocol and 
> it's
> tedious to go read another spec just for a flat list.

This has not been done because that list is not stable, and may 
ultimately end up in an IANA registry.


> |    link.  Link constructs MAY have a title attribute, whose value 
> MUST
> |    be a string.
>
> "MUST be a string"? How can an attribute *not* be a string. Does this
> add anything?

Editorial.


> | 4.12  "atom:modified" Element
> |
> |    The "atom:modified" element is a Date construct that indicates the
> |    time when the state of the feed was last modified, including any
> |    changes to entries therein.  atom:feed elements MUST contain 
> exactly
> |    one atom:modified element.
> |
> |    The content of an atom:modified element SHOULD have a time zone 
> whose
> |    value MUST be "UTC".
>
> Are "SHOULD" and "MUST" reversed in that sentence?

This isn't a mistake; i.e., AFAIK it reflects current consensus 
(although personally I don't agree with this approach).


> | 4.13.9  "atom:summary" Element
> |
> |    The "atom:summary" element is a Content construct that conveys a
> |    short summary, abstract or excerpt of the entry.  atom:entry 
> elements
> |    MAY contain an atom:created element, but MUST NOT contain more 
> than
>                          ^summary (not created)

Editorial.


--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Sat Jul 10 01:14: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 BAA08650
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 01:14: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 i6A55Flr046355;
	Fri, 9 Jul 2004 22:05: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 i6A55FMH046354;
	Fri, 9 Jul 2004 22:05:15 -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 i6A55EBJ046342
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 22:05:14 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.17] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id 185BA727D; Fri,  9 Jul 2004 22:05:22 -0700 (PDT)
In-Reply-To: <878ydsubdi.fsf@nwalsh.com>
References: <200407091923.PAA23330@ietf.org> <878ydsubdi.fsf@nwalsh.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <BE332F7D-D22E-11D8-9A61-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: atom:info [was: Comments on I-D ACTION:draft-ietf-atompub-format-00.txt]
Date: Fri, 9 Jul 2004 22:05:20 -0700
To: Norman Walsh <ndw@nwalsh.com>
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>
Content-Transfer-Encoding: 7bit



The only use case for atom:info that I'm aware of does not require 
standardisation; it could be achieved just as effectively with a 
site-specific extension. Therefore, I propose we drop this element.

On Jul 9, 2004, at 2:19 PM, Norman Walsh wrote:
> | 4.11  "atom:info" Element
> |
> |    The "atom:info" element is a Content construct that conveys a
> |    human-readable explanation of the feed format itself.  atom:feed
> |    elements MAY contain an atom:info element, but MUST NOT contain 
> more
> |    than one.
> |
> |    The atom:info element SHOULD NOT considered meaningful by 
> processors;
> |    it is a convenience to publishers in certain situations.
>
> If it's not meaningful to processors and may be a convenience to
> publishers, I suggest that sometimes it will be a convenience that
> more than one publisher will simultaneously want to use. Therefore,
> more than one should be allowed.

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Sat Jul 10 01:14: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 BAA08668
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 01:14: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 i6A5627J046646;
	Fri, 9 Jul 2004 22: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 i6A562v7046641;
	Fri, 9 Jul 2004 22:06:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6A55sKj046411
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 22:06:00 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 10 Jul 2004 15:10:14 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sat, 10 Jul 2004 15:05:07 +1000
Subject: Re: AtomPub-00: W3C Date-Time: "UTC" is NOT a valid timezone
	designator.
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD15B623.1E6FE%eric.scheid@ironclad.net.au>
In-Reply-To: <878ydsubdi.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: <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 content of an atom:modified element SHOULD have a time zone whose
> |    value MUST be "UTC".

is this a valid W3C Date-Time string?

    2003-12-13T18:30:02UTC

no.

there are actually three ways of writing a W3C Date-Time string whose time
zone is UTC, and that is with the time zone part being "+00:00" or "-00:00"
or "Z". Sticking UTC in there is invalid (and feedvalidator.org concurs).

The "Z" signifies UTC, and is equivalent to "+00:00". The "+00:00" is a
valid timezone offset string, which coincidentally is also of the same value
as UTC. The "-00:00" is just me being pedantic. :-P

By the way, the "Z" MUST be capital "Z".

http://www.w3.org/TR/NOTE-datetime

e.



From owner-atom-syntax@mail.imc.org  Sat Jul 10 01:20: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 BAA08811
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 01:20: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 i6A562kQ046647;
	Fri, 9 Jul 2004 22: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 i6A562Ox046645;
	Fri, 9 Jul 2004 22:06:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6A55s6E046425
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 22:06:00 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 10 Jul 2004 15:10:22 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sat, 10 Jul 2004 14:35:12 +1000
Subject: Re: Comments on I-D ACTION:draft-ietf-atompub-format-00.txt
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD15AF20.1E6F4%eric.scheid@ironclad.net.au>
In-Reply-To: <878ydsubdi.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: <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 10/7/04 7:19 AM, "Norman Walsh" <ndw@nwalsh.com> wrote:

> |    link.  Link constructs MAY have a title attribute, whose value MUST
> |    be a string.
> 
> "MUST be a string"? How can an attribute *not* be a string. Does this
> add anything?

maybe the intent is to avoid people using title="&lt;b&gt;B&lt;/b&gt;old is
old" and hoping they'll get *B*old is old.

if so, +1

e.

*B* is of course the letter B in BOLD.



From owner-atom-syntax@mail.imc.org  Sat Jul 10 01:23: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 BAA08929
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 01:23: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 i6A59jkD047901;
	Fri, 9 Jul 2004 22: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 i6A59j3K047900;
	Fri, 9 Jul 2004 22:09:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6A59i84047886
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 22:09:45 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 10 Jul 2004 15:14:52 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sat, 10 Jul 2004 15:09:46 +1000
Subject: Re: Q: modfied vs issued vs created
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD15B73A.1E883%eric.scheid@ironclad.net.au>
In-Reply-To: <40EE8A59.7090607@spoonybards.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: <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 9/7/04 10:06 PM, "Beecher Greenman" <millennium@spoonybards.net> wrote:

> Suppose that an article is created on April 1. It is modified on April 2
> and then sits around for a week. It is finally published on April 8, but
> no changes made to the text. Are <atom:issued> and <atom:modified> both
> April 8, or is <atom:modified> still April 2, since that is when the
> last change was made to the content?

(1) Did the author re-read what they last wrote a week ago, checking for
anything that might have changed in the last week, and finding none
published it? If so, then <modified> = <issued>.

(2) Did the author not bother re-reading what they wrote, and simply punched
the publish button? ... <modified> != <issued>

(3) Did the author write what they wrote, and left it for a week thinking
they'll re-word it once they cool off a bit, but one week later when
re-reading it they feel just as steamed up? <modified> = <issued>

(4) Did the author write what they did, waited a week, found that they have
in fact cooled off, but none the less still want to put on the record just
how steamed they were 7 days ago? <modified> != <issued>

(5) Same as (4), but while re-reading it noticed some inconsequential
spelling/syntax error which they fix, but otherwise feel as they did in (4)?
<modified> != <issued>

Now before someone gets upset, lets look at each of them from the
perspective of the recipient (which is really what counts, right?) ...

(1) here is something as of today, and it is up to date too.
(2) here is something as of today, but it might be out of date
(3) here is something as of today, and it is accurate as of today too.
(4) here is something as of today, reflecting a situation of 7 days past.
(5) Same as (4), who cares if a spelling error was fixed today.

No, this behaviour is not programmable, at least not until AI arrives and
our blog tools come with an ESP module.

e.



From owner-atom-syntax@mail.imc.org  Sat Jul 10 01:52: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 BAA09960
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 01:52: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 i6A5cBKu060341;
	Fri, 9 Jul 2004 22:38: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 i6A5cBV3060340;
	Fri, 9 Jul 2004 22:38:11 -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 i6A5c6OU060285
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 22:38:06 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.17] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id AC6A8727D; Fri,  9 Jul 2004 22:38:13 -0700 (PDT)
In-Reply-To: <40EEFB88.3020403@virgilio.it>
References: <40EEFB88.3020403@virgilio.it>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <55668634-D233-11D8-9A61-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: Atom-Syntax <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: Re: Resource terminology
Date: Fri, 9 Jul 2004 22:38:12 -0700
To: danny666@virgilio.it
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>
Content-Transfer-Encoding: 7bit



On Jul 9, 2004, at 1:09 PM, Danny Ayers wrote:

> Can someone please tell me if this was intentional (and if so, why?!) -
>
> The charter, early on says:
>
> Atom consists of:
>    * A conceptual model of a resource
>
>
> Is this a resource in the URI sense, or a new term for an Atom thing?

In the Web sense, yes.

> Either way, this seems very confusing.
> Come back "Well-Formed Log Entry", all is forgiven...

What exactly does that mean?


--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Sat Jul 10 01: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 BAA10166
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 01:56: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 i6A5gW7c063351;
	Fri, 9 Jul 2004 22:42:32 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6A5gWP1063350;
	Fri, 9 Jul 2004 22:42:32 -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 i6A5gVWn063338
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 22:42:31 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.17] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id 5681C727D; Fri,  9 Jul 2004 22:42:39 -0700 (PDT)
In-Reply-To: <97774BF0-D096-11D8-B2D0-000A95A51C9E@sun.com>
References: <97774BF0-D096-11D8-B2D0-000A95A51C9E@sun.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <F3C7FAC8-D233-11D8-9A61-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: Atom Syntax <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: Re: PaceElementOrder
Date: Fri, 9 Jul 2004 22:42:38 -0700
To: Tim Bray <Tim.Bray@Sun.COM>
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>
Content-Transfer-Encoding: 7bit



On Jul 7, 2004, at 9:23 PM, Tim Bray wrote:

> I propose a modification to this Pace 
> (http://www.intertwingly.net/wiki/pie/PaceElementOrder).  I don't know 
> what the right section number is in the about-to-appear -00 drafts, 
> but I'd like language like this:
>
>  The child elements of <atom:feed> may appear in any order, subject 
> only to
>  the constraint that the the <atom:entry> children appear in a group 
> after all
>  other child elements.  That is to say, the "feed-level" elements must 
> all
>  appear before the first <atom:entry> element.  The order in which the
>  child elements of <atom:feed> appear is not considered significant.

+1: I don't understand the Pace at it sits.


> It's also been proposed that we consider imposing a *strict* ordering, 
> something like
> title/author/copyright/dates/.../entries.  It might simplify some 
> software tasks, I could go either way on that.

-1: how would extensions be ordered?




--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Sat Jul 10 02:00: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 CAA11170
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 02: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 i6A5pgTZ068353;
	Fri, 9 Jul 2004 22:51: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 i6A5pgXQ068352;
	Fri, 9 Jul 2004 22:51:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.mnot.net (adsl-67-119-69-242.dsl.sntc01.pacbell.net [67.119.69.242])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6A5pfHB068314
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 22:51:41 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.17] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id 1499D727D; Fri,  9 Jul 2004 22:51:49 -0700 (PDT)
In-Reply-To: <14be96d30407061142441f70ee@mail.gmail.com>
References: <14be96d30407061142441f70ee@mail.gmail.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <3B72AB44-D235-11D8-9A61-000A95BD86C0@mnot.net>
Cc: Atom Syntax <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: Re: PaceMustBeWellFormed
Date: Fri, 9 Jul 2004 22:51:47 -0700
To: Mark Pilgrim <pilgrim@gmail.com>
X-Mailer: Apple Mail (2.618)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6A5pfHB068331
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


-1

This is great advice, but it restates a number of requirements in other 
specifications that are referred to by Atom. That's not good 
specification practice, as it very often results in conflicts of 
interpretation. Furthermore, this places a large number of requirements 
on "clients" that are difficult to test and constrain their behaviours 
in frankly unrealistic ways. Finally, many of the other requirements 
are made upon "publishers" -- an audience that almost assuredly will 
never read the Atom specification.

I strongly suggest this be moved to a primer, another non-normative 
document, or to WG-external supporting documentation.


On Jul 6, 2004, at 11:42 AM, Mark Pilgrim wrote:

>
> http://intertwingly.net/wiki/pie/PaceMustBeWellFormed
>
> == Abstract ==
>
> [MarkPilgrim] Clarify the rules for determining well-formedness of an
> Atom feed served over HTTP, covering issues of character encoding and
> MIME types.  Also, client requirements for handling non-well-formed
> feeds.
>
> == Status ==
>
> Open
>
> == Rationale ==
>
> RFC 3023 defines rules for determining the character encoding of a
> feed (or any other XML document served over HTTP).  The default
> configuration for most web servers is to serve ".xml" files as
> "text/xml" with no charset parameter.  According to RFC 3023, all of
> these feeds MUST be parsed as "us-ascii".  This leaves
> UnprivilegedUsers without a way to publish Atom feeds in any other
> encoding except us-ascii.  Furthermore, the Atom-enabled applications
> that the UnprivilegedUsers are running may not even have enough
> privileges to determine that they are, in fact, unprivileged in this
> way.
>
> Therefore, this proposal recommends that all Atom-enabled publishers
> "assume the worst" and only emit ASCII-compatible XML.
>
> == Proposal ==
>
> Insert as section 6:
>
> 6. Client processing requirements
>
> Atom feeds served over HTTP MUST be well-formed XML 1.0, as defined in
> Section 2.1 of the XML specification
> <http://www.w3.org/TR/REC-xml/#sec-well-formed>.  Furthermore, the
> concept of XML well-formedness relies on first determining the
> character encoding of the XML document.  RFC 3023 defines how to
> determine the character encoding of XML documents served over HTTP.
>
> 6.1 Determining the character encoding of an Atom feed
>
> The rules for determining the character encoding of an Atom feed are
> the same as determining the character encoding of any XML document
> served over HTTP.  The rules are wholely defined by RFC 3023, but they
> are summarized here because there has been widespread confusion over
> how RFC 3023 should be interpreted:
>
>  1. When serving an Atom feed, it is RECOMMENDED that publishers
> include the charset parameter along with the media type in the
> Content-type HTTP header.  If the charset parameter is present,
> clients MUST parse the Atom feed in that charset, ignoring any charset
> declared in the encoding attribute of the XML declaration.
>  1. Publishers SHOULD serve all Atom feeds with the media type
> "application/atom+xml" (registered in Section 8 of this document).
> Clients MUST treat "application/atom+xml" as "application/xml" and
> determine the character encoding as per RFC 3023 or its successor.
>  1. If a publisher wishes to serve an Atom feed over HTTP, but for
> some reason they are unable to use the "application/atom+xml" media
> type, the publisher SHOULD use "application/xml", and clients MUST
> determine the character encoding as per RFC 3023 or its successor.
>  1. If a publisher is unable to serve their Atom feed with a
> Content-Type of "application/atom+xml" or "application/xml", they MAY
> use "text/xml".  According to RFC 3023, XML documents served as
> "text/xml" with no charset parameter have a character encoding of
> "us-ascii".
>   1. When serving an Atom feed as "text/xml", publishers MUST escape
> all non-US-ASCII characters as
> [http://www.w3.org/TR/REC-xml/#sec-references character references].
> For example, '&#xf8;' for the character 'ø'.
>   1. When retrieving an Atom feed served with a Content-type of
> "text/xml", clients MUST parse it with a "us-ascii" encoding.  If such
> a feed contains non-US-ASCII characters, and clients MUST reject it as
> non-well-formed.
>  1. Publishers MUST NOT serve Atom feeds with a media type other than
> "application/atom+xml" (registered in this Section 8 of document) or
> one of the XML media types defined in RFC 3023 or its successor.  In
> particular, "text/plain" is never an appropriate media type for an
> Atom feed.  When retrieving an Atom feed served with a non-XML media
> type, clients MUST reject it as non-well-formed.
>
> 6.2 Handling well-formedness errors
>
> After determining the character encoding by the rules in section 6.1
> of this document, clients MUST use a conforming XML parser to parse an
> Atom feed.  In particular, clients MUST stop processing at the first
> well-formedness error, although they MAY display any information they
> have parsed before the first well-formedness error.
>
> Here is a non-comprehensive list of things clients have been known to
> do after encountering a well-formedness error, which this document
> specifically prohibits:
>
>  * Clients MUST NOT reparse the feed in any other character encoding.
>  * Clients MUST NOT "tidy" the feed to attempt to fix mismatched start
> and end tags.
>  * Clients MUST NOT guess at the meaning of undefined entities,
> including entities defined in the HTML specification.
>
> == Impacts ==
>
> This proposal has significant impact for both publishers and clients.
> Publishers must be aware of their web server configuration and ensure
> that Atom feeds are served with the appropriate media type, or, if
> that is not possible, that all non-US-ASCII characters are properly
> escaped.  Clients must ensure that they properly implement RFC 3023,
> which few tools currently support.
>
> -----
>
> CategoryProposals
>
> -- 
> Cheers,
> -Mark
>

--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org  Sat Jul 10 02:12: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 CAA23183
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 02:12: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 i6A61Qnq072185;
	Fri, 9 Jul 2004 23: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 i6A61QRJ072184;
	Fri, 9 Jul 2004 23:01:26 -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 i6A61PYK072173
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 23:01:25 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.17] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP id 228CA727D
	for <atom-syntax@imc.org>; Fri,  9 Jul 2004 23:01:33 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v618)
In-Reply-To: <opr99igudbuvpchu@quark>
References: <opr99igudbuvpchu@quark>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <9784AD46-D236-11D8-9A61-000A95BD86C0@mnot.net>
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: Proposal: PaceSyntaxGuidelines
Date: Fri, 9 Jul 2004 23:01:31 -0700
To: Atom-Syntax <atom-syntax@imc.org>
X-Mailer: Apple Mail (2.618)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6A61PYK072176
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


Can we hold off on this one until we've solidified what the format and 
protocol are first? Even then, I'm not sure it's a great idea to put 
purely stylistic naming conventions into the spec...


On Jun 27, 2004, at 9:51 AM, Asbjørn Ulsberg wrote:

>
> I've created PaceSyntaxGuidelines to get some specification text out 
> of the SyntaxGuidelines[1]:
>
> <url: http://www.intertwingly.net/wiki/pie/PaceSyntaxGuidelines>
>
> == Abstract ==
>
> [AsbjornUlsberg] Try to define a naming principle for the Atom syntax. 
> This supersedes the SyntaxGuidelines with a concrete specification 
> proposal. All future updates of the SyntaxGuidelines will happen here.
>
> == Status ==
>
> Open.
>
> == Rationale ==
>
> This pace tries to define some simple syntax guidelines, which should 
> apply to the Atom format -- both existing and future extensions of it. 
> Except where explicitly stated otherwise, all examples provided are 
> fictional: the elements and attributes given, may or may not exist in 
> the Atom Format syntax.
>
> == Proposal ==
>
> Replace (the currently empty) section 7 with the following:
>
> === 7 Guidelines for Extending Atom ===
>
> [This section is non-normative]. Extending Atom should follow these 
> syntax guidelines:
>
> ==== 7.1 Naming ====
>
> Names should be all lower-case, and if possible, one word only. If 
> names need to be two or more words, they should be separated with a 
> hyphen.
>
> Element Example:
> <create-entry />
>
> Attribute Example:
> <link service-type="..." />
>
> Enumerated Attribute or Element Values Example:
> <link rel="in-reply-to" ... />
>
> ==== 7.2 Common element usage ====
>
> The following actual elements should only be used in the ways 
> specified below.
>
> * link: Purposes of link elements are specified by a list of legal 
> values for link/@rel, and we are considering allowing extensions to 
> specify additional values. If the external resource being referred to 
> is not one that would make sense to present to the user as a clickable 
> link, some other element should be used instead. For example, link is 
> used to point to an alternate representation of the content of the 
> entry, to the next set of entries in a feed, etc. The link element is 
> not appropriate for pointing to things like a stylesheet for the feed, 
> an XSL template, etc., which are not intended for viewing by the user.
>
> ==== 7.3 Common attribute names ====
>
> The following attribute names should be used only in the ways 
> specified below. For attributes with other purposes, please choose 
> another name:
>
> * href: specifies the URI of something that will usually be 
> conceptually external to the entry, such as a PDF report on a website 
> to which the entry refers.
> * src: specifies the URI of some external entity intended to be 
> "imported into" the entry--something that is conceptually an integral 
> part of the entry. For example, <content src="..." />.
> * type: specifies a MIME type, such as "text/html" or "image/jpeg".
>
> ==== 7.4 How to embed content ====
>
> This section tries to explain how different data types of XML 
> documents should be embedded in Atom documents.
>
> ===== 7.4.1 Presentable content =====
>
> This is content that will be visually, audibly or in some other way, 
> presented to the user. It is not hidden behind the scenes, and it is 
> not insignificant for various presentations of an Atom entry. It is 
> valuable information the visual or audible representation needs or 
> somehow can utilize in the user interface.
>
> This content should be embedded in Atom as element values:
> <title>I am a visually or audibly presentable piece of text!</title>
>
> ===== 7.4.2 Non-presentable content =====
>
> This is content that will be completely hidden from the user. The user 
> should never have to need or care what the hidden content is, unless 
> he or she is doing debugging or some other developmental activities 
> with the document.
>
> This content should be embedded in Atom as attribute values:
> <link rel="alternate" />
>
> ===== 7.4.3 «Nice to know» content =====
>
> This is content that may or may not be presented to the user. Whether 
> it should be presented or not, is defined by the situation.
>
> This content can be in either elements or attributes.
>
> - Depending on the use-case. If a value will be presented to the user 
> in more than 50% of the use-cases, it should be embedded as an element 
> value. If it is presented to the user in less than 50% of the 
> use-cases, it should be embedded as an attribute value. The method of 
> embedding must be either as an element or attribute value; it cannot 
> be both.
>
> == Impacts ==
>
> This impacts how new Atom elements, attributes or enumerated values 
> are syntactically constructed. It may also impact the current 
> specification if it consists of anything breaking these guidelines. 
> The current finding is that the atom:url element and title attribute 
> breaks these guidelines to some extent.
>
> ____
> [1] <url: http://www.intertwingly.net/wiki/pie/SyntaxGuidelines>
>
> -- 
> Asbjørn Ulsberg         -=|=-        asbjornu@hotmail.com
> «He's a loathsome offensive brute, yet I can't look away»
>

--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org  Sat Jul 10 02: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 CAA24283
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 02: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 i6A67AmF075698;
	Fri, 9 Jul 2004 23: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 i6A67ATt075695;
	Fri, 9 Jul 2004 23:07:10 -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 i6A679Tv075683
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 23:07:09 -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 i6A67Hil013512
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 00:07: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 <0I0M008TYH04PS@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sat, 10 Jul 2004 00:07:17 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0M00CHEH04E4@mail.sun.net> for atom-syntax@imc.org; Sat,
 10 Jul 2004 00:07:16 -0600 (MDT)
Date: Fri, 09 Jul 2004 23:07:14 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceElementOrder
In-reply-to: <F3C7FAC8-D233-11D8-9A61-000A95BD86C0@mnot.net>
To: Mark Nottingham <mnot@mnot.net>
Cc: Atom Syntax <atom-syntax@imc.org>
Message-id: <63690128-D237-11D8-B2D0-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: <97774BF0-D096-11D8-B2D0-000A95A51C9E@sun.com>
 <F3C7FAC8-D233-11D8-9A61-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 Jul 9, 2004, at 10:42 PM, Mark Nottingham wrote:

>> It's also been proposed that we consider imposing a *strict* 
>> ordering, something like
>> title/author/copyright/dates/.../entries.  It might simplify some 
>> software tasks, I could go either way on that.
>
> -1: how would extensions be ordered?

Urgh, indeed, good catch.  I *guess* you could say they could go 
anywhere in-between the fixed-order Atom elements, or reserve a spot 
after all the feed-level stuff and before the Entries and say 
"Extensions go here", but those both feel kludgy.

On the other hand, leaving the order semi-unconstrained (i.e. requiring 
only that the <atom:entry> crowd bring up the rear) is going to result 
in serious ugliness in any XSD we produce, which may spill over into 
SOAP/WSDL territory... still, I lean to -1. -Tim



From owner-atom-syntax@mail.imc.org  Sat Jul 10 02:24: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 CAA24904
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 02: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 i6A68b6m076683;
	Fri, 9 Jul 2004 23:08: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 i6A68bj0076682;
	Fri, 9 Jul 2004 23:08:37 -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 i6A68b9B076670
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 23:08:37 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.17] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id F2E4B727D; Fri,  9 Jul 2004 23:08:44 -0700 (PDT)
In-Reply-To: <63690128-D237-11D8-B2D0-000A95A51C9E@sun.com>
References: <97774BF0-D096-11D8-B2D0-000A95A51C9E@sun.com> <F3C7FAC8-D233-11D8-9A61-000A95BD86C0@mnot.net> <63690128-D237-11D8-B2D0-000A95A51C9E@sun.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <98FB4CE4-D237-11D8-9A61-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: Atom Syntax <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: Re: PaceElementOrder
Date: Fri, 9 Jul 2004 23:08:43 -0700
To: Tim Bray <Tim.Bray@Sun.COM>
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>
Content-Transfer-Encoding: 7bit



On Jul 9, 2004, at 11:07 PM, Tim Bray wrote:
>
> On the other hand, leaving the order semi-unconstrained (i.e. 
> requiring only that the <atom:entry> crowd bring up the rear) is going 
> to result in serious ugliness in any XSD we produce, which may spill 
> over into SOAP/WSDL territory... still, I lean to -1. -Tim

XSD's problem, not mine.

:)

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Sat Jul 10 02:28: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 CAA25179
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 02:28:21 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6A6Idtn080404;
	Fri, 9 Jul 2004 23: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 i6A6IdFs080403;
	Fri, 9 Jul 2004 23:18: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.85])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6A6IcjJ080395
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 23:18:38 -0700 (PDT)
	(envelope-from dtcd@mac.com)
Received: from webmail27-en1.mac.com (webmail27-en1 [10.13.10.127])
	by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i6A6Ic3n019951
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 23:18:38 -0700 (PDT)
Received: from webmail27 (localhost.mac.com [127.0.0.1])
	by webmail27-en1.mac.com (8.12.6/8.12.6) with ESMTP id i6A6Icgv003825
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 23:18:38 -0700 (PDT)
Message-ID: <4806473.1089440318518.JavaMail.dtcd@mac.com>
Date: Sat, 10 Jul 2004 07:18:38 +0100
From: Graham Parks <dtcd@mac.com>
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceElementOrder
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: <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, July 10, 2004, at 06:56AM, Mark Nottingham <mnot@mnot.net> wrote: 

>>  The child elements of <atom:feed> may appear in any order, subject 
>> only to 
>>  the constraint that the the <atom:entry> children appear in a group 
>> after all 
>>  other child elements.  That is to say, the "feed-level" elements must 
>> all 
>>  appear before the first <atom:entry> element.  The order in which the 
>>  child elements of <atom:feed> appear is not considered significant. 
> 
>+1: I don't understand the Pace at it sits. 

Agree on both counts. I also don't like the "MUST NOT be considered significant" phrase in both the current draft and the Pace, since a simple client that passes entries straight through may break the rules. We just need to say that the client on the other end has no obligation to (and is unlikely to) preserve the ordering.

>> It's also been proposed that we consider imposing a *strict* ordering, 
>> something like 
>> title/author/copyright/dates/.../entries.  It might simplify some 
>> software tasks, I could go either way on that. 
> 
>-1: how would extensions be ordered?= 

Entries in any order please. 

Graham  



From owner-atom-syntax@mail.imc.org  Sat Jul 10 02:29: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 CAA25227
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 02:29: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 i6A6Giqv079770;
	Fri, 9 Jul 2004 23:16: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 i6A6GiGF079769;
	Fri, 9 Jul 2004 23:16: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.45])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6A6Gh9J079761
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 23:16:43 -0700 (PDT)
	(envelope-from dtcd@mac.com)
Received: from webmail27-en1.mac.com (webmail27-en1 [10.13.10.127])
	by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i6A6GpAv014000
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 23:16:51 -0700 (PDT)
Received: from webmail27 (localhost.mac.com [127.0.0.1])
	by webmail27-en1.mac.com (8.12.6/8.12.6) with ESMTP id i6A6Gogv003790
	for <atom-syntax@imc.org>; Fri, 9 Jul 2004 23:16:50 -0700 (PDT)
Message-ID: <16613462.1089440210853.JavaMail.dtcd@mac.com>
Date: Sat, 10 Jul 2004 07:16:50 +0100
From: Graham Parks <dtcd@mac.com>
To: atom-syntax@imc.org
Subject: Re: Editorial issues [was: Comments on I-D ACTION:draft-ietf-atompub-format-00.txt]
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: <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, July 10, 2004, at 06:13AM, Mark Nottingham <mnot@mnot.net> wrote:

>
>> |    The content of an atom:modified element SHOULD have a time zone 
>> whose
>> |    value MUST be "UTC".
>>
>> Are "SHOULD" and "MUST" reversed in that sentence?
>
>This isn't a mistake; i.e., AFAIK it reflects current consensus 
>(although personally I don't agree with this approach).
>

I don't recall there being enough discussion for there to be consensus. I think someone just said the UTC thing was a good idea, and it stuck (I strongly disagree with it, for reasons outlines in PaceEntryDates)

Graham Parks



From owner-atom-syntax@mail.imc.org  Sat Jul 10 07:42: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 HAA08164
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 07:42: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 i6ABQVWZ075855;
	Sat, 10 Jul 2004 04:26: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 i6ABQVvn075854;
	Sat, 10 Jul 2004 04:26:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf28.cluster1.charter.net (mxsf28.cluster1.charter.net [209.225.28.228])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ABQURC075838
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 04:26:31 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip15.cluster1.charter.net (mxip15a.cluster1.charter.net [209.225.28.145])
	by mxsf28.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6ABTG67027280
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 07:29:16 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip15.cluster1.charter.net with ESMTP; 10 Jul 2004 07:26:24 -0400
X-Ironport-AV: i="3.81R,160,1083556800"; 
   d="scan'208"; a="102334726:sNHT14831276"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BjFzj-0000kE-00
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 07:26:15 -0400
To: atom-syntax@imc.org
Subject: Re: Embedding non-namespaced elements
References: <200407091923.PAA23330@ietf.org> <878ydsubdi.fsf@nwalsh.com>
	<14be96d3040709185954a33b28@mail.gmail.com>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Sat, 10 Jul 2004 07:26:01 -0400
In-Reply-To: <14be96d3040709185954a33b28@mail.gmail.com> (Mark Pilgrim's
 message of "Fri, 9 Jul 2004 21:59:56 -0400")
Message-ID: <87u0wgrtme.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: <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-Type: text/plain

/ Mark Pilgrim <pilgrim@gmail.com> was heard to say:
| On Fri, 09 Jul 2004 17:19:37 -0400, Norman Walsh <ndw@nwalsh.com> wrote:
|> |    All elements and attributes in an Atom document MUST be
|> |    namespace-qualified.
|> 
|> Does this apply only to top-level elements in an atom:feed or
|> atom:entry element? If I want to ship around a content constructor
|> containing DocBook V4.3 content (which has no namespace), I'm allowed
|> to, aren't I?
|
| Not currently.
|
| How is DocBook usually embedded in other formats if it doesn't have a namespace?

By putting it in a container that tells the application it's DocBook.
Perhaps:

  <atom:content type="application/docbook+xml" xmlns="">
    <para>Like this, for example.</para>
  </atom:content>

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Perhaps the most valuable result of all
http://nwalsh.com/            | education is the ability to make
                              | yourself do the thing you have to do,
                              | when it ought to be done, whether you
                              | like it or not.--Thomas H. Huxley

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA79JMOyltUcwYWjsRAhSMAJ9HIYQkbAY17LStT0bSnoz/O/AKpwCfVlL1
/r4jTyeP+/CGS1ZdKnm0oY4=
=ccEh
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Sat Jul 10 07:42: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 HAA08181
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 07: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 i6ABTJxY076029;
	Sat, 10 Jul 2004 04:29: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 i6ABTJKG076028;
	Sat, 10 Jul 2004 04:29:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf11.cluster1.charter.net (mxsf11.cluster1.charter.net [209.225.28.211])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ABTJgR076020
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 04:29:19 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip19.cluster1.charter.net (mxip19a.cluster1.charter.net [209.225.28.149])
	by mxsf11.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6ABWg2C009268
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 07:32:42 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip19.cluster1.charter.net with ESMTP; 10 Jul 2004 07:29:13 -0400
X-Ironport-AV: i="3.81R,160,1083556800"; 
   d="scan'208"; a="99031938:sNHT14944928"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BjG2X-0000kW-00
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 07:29:09 -0400
To: atom-syntax@imc.org
Subject: Re: Possible rel values
References: <200407091923.PAA23330@ietf.org> <878ydsubdi.fsf@nwalsh.com>
	<14be96d3040709191248065fe@mail.gmail.com>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Sat, 10 Jul 2004 07:29:08 -0400
In-Reply-To: <14be96d3040709191248065fe@mail.gmail.com> (Mark Pilgrim's
 message of "Fri, 9 Jul 2004 22:12:24 -0400")
Message-ID: <87pt74rth7.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: <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-Type: text/plain

/ Mark Pilgrim <pilgrim@gmail.com> was heard to say:
| On Fri, 09 Jul 2004 17:19:37 -0400, Norman Walsh <ndw@nwalsh.com> wrote:
|> |    The "rel" attribute indicates the type of relationship that the link
|> |    represents.  Link constructs MUST have a rel attribute, whose value
|> |    MUST be a string, and MUST be one of the values enumerated in the
|> |    Atom Protocol specification [Atom-protocol].
|> 
|> Please duplicate that list here. I don't care about the protocol and it's
|> tedious to go read another spec just for a flat list.
|
| This has been discussed at length, but useful discussion of possible
| rel values has been derailed by several proposals that would do away
| with this link @rel syntax altogether, in favor of something else
| (separate elements, namespaces, etc.).
|
| For background, see http://intertwingly.net/wiki/pie/PaceLinkPurpose
| and the list of "related and conflicting proposals."

Fair enough, I'm not sure I like the link/@rel syntax very much
myself, but my point was simply that if the link/@rel syntax survives,
the list of legal @rel values should be enumerated explicitly in the
format spec instead of sending the poor reader off to another document
just for this one list.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | The bane of my existence is doing
http://nwalsh.com/            | things that I know the computer could
                              | do for me.--Dan Connolly

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA79MEOyltUcwYWjsRAl0zAJ4s5LHt1aj/ISEjbB8dfPuYjTENiwCfabbW
e2LFFPiHcsdRECJZeVS0/Ok=
=0dBJ
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Sat Jul 10 08:15: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 IAA09608
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 08:15: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 i6AC5UDG079522;
	Sat, 10 Jul 2004 05:05:30 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6AC5US5079521;
	Sat, 10 Jul 2004 05:05:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf25.cluster1.charter.net (mxsf25.cluster1.charter.net [209.225.28.225])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6AC5TIm079504
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 05:05:30 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip02.cluster1.charter.net (mxip02a.cluster1.charter.net [209.225.28.132])
	by mxsf25.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6AC8pok011833
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 08:08:51 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip02.cluster1.charter.net with ESMTP; 10 Jul 2004 08:05:25 -0400
X-Ironport-AV: i="3.81R,160,1083556800"; 
   d="scan'208"; a="107532544:sNHT15186104"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BjGbU-0001Et-00
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 08:05:16 -0400
To: atom-syntax@imc.org
Subject: Feed/entry titles
References: <200407091923.PAA23330@ietf.org> <878ydsubdi.fsf@nwalsh.com>
	<D6B92BD6-D1F2-11D8-A027-000A95A0ACC4@apple.com>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Sat, 10 Jul 2004 08:05:16 -0400
In-Reply-To: <D6B92BD6-D1F2-11D8-A027-000A95A0ACC4@apple.com> (Jens Alfke's
 message of "Fri, 9 Jul 2004 14:56:32 -0700")
Message-ID: <87llhsrrsz.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: <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-Type: text/plain

/ Jens Alfke <jens@apple.com> was heard to say:
| On Jul 9, 2004, at 2:19 PM, Norman Walsh wrote:
|
|> It seems slightly odd to me that the title is a Content construct. I
|> think
|> I'd be happier if the title was a string.
|
| That's so the feed's title can contain markup, without the annoying
| ambiguities present in RSS. I agree that it seems less likely that a
| feed title will require markup than an entry title; but it's still a
| reasonable thing to allow.

I suppose. It's going to make displaying the title harder though, if
your processor doesn't know the markup vocabulary. Insisting that
titles be strings wouldn't seem an undue hardship to me.

| (One possible example: some blogs give every post its own feed of
| comments. In this case the title of the comment feed would naturally
| be based on the title of the original post, which can contain markup,
| most likely italics.)


                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Anyone who can handle a needle
http://nwalsh.com/            | convincingly can make us see a thread
                              | which is not there.--E. H. Gombrich

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA79t8OyltUcwYWjsRAhZ+AKCg9HTC+Au58S+i8mluOZ5i3jyaPACgoAXZ
hVj7amWtLQQsF+ACXAc0unY=
=dqDF
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Sat Jul 10 08:17: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 IAA09874
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 08:17: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 i6AC6UaU079590;
	Sat, 10 Jul 2004 05: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 i6AC6Uj4079589;
	Sat, 10 Jul 2004 05:06:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf21.cluster1.charter.net (mxsf21.cluster1.charter.net [209.225.28.221])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6AC6UWE079577
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 05:06:30 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip19.cluster1.charter.net (mxip19a.cluster1.charter.net [209.225.28.149])
	by mxsf21.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6AC8Vsa006633
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 08:08:31 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip19.cluster1.charter.net with ESMTP; 10 Jul 2004 08:06:26 -0400
X-Ironport-AV: i="3.81R,160,1083556800"; 
   d="scan'208"; a="99186590:sNHT15089876"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BjGcR-0001F7-00
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 08:06:15 -0400
To: atom-syntax@imc.org
Subject: atom:info
References: <200407091923.PAA23330@ietf.org> <878ydsubdi.fsf@nwalsh.com>
	<D6B92BD6-D1F2-11D8-A027-000A95A0ACC4@apple.com>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Sat, 10 Jul 2004 08:06:15 -0400
In-Reply-To: <D6B92BD6-D1F2-11D8-A027-000A95A0ACC4@apple.com> (Jens Alfke's
 message of "Fri, 9 Jul 2004 14:56:32 -0700")
Message-ID: <87hdsgrrrc.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: <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-Type: text/plain

/ Jens Alfke <jens@apple.com> was heard to say:
|> | 4.11  "atom:info" Element
| ...
|> If it's not meaningful to processors and may be a convenience to
|> publishers, I suggest that sometimes it will be a convenience that
|> more than one publisher will simultaneously want to use. Therefore,
|> more than one should be allowed.
|
| But a feed can have only one publisher, so I don't see how "more than
| one publisher" applies here.

Uhm. I guess I was thinking that I might publish a feed which might be
republished by someone else. But maybe in that case, they're
republishing the entries from my feed, not my feed itself.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | It's a poor sort of memory that only
http://nwalsh.com/            | works backward.--Lewis Carroll

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA79u3OyltUcwYWjsRAmGyAKCaQ7xIdsUkyFxz+yWsnkwSg1Qd+ACePYLT
4BgSt82MuLtoyrE5RC5KRRY=
=T70Y
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Sat Jul 10 08:19: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 IAA09914
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 08:19: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 i6ACAf4Q079884;
	Sat, 10 Jul 2004 05:10: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 i6ACAfun079883;
	Sat, 10 Jul 2004 05:10: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 i6ACAe7P079875
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 05:10:41 -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 i6ACBBO3009195;
	Sat, 10 Jul 2004 08:11:11 -0400
Message-ID: <40EFDCB8.6070902@intertwingly.net>
Date: Sat, 10 Jul 2004 08:10:32 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <mnot@mnot.net>
CC: Norman Walsh <ndw@nwalsh.com>, atom-syntax@imc.org
Subject: Re: Editorial issues [was: Comments on I-D ACTION:draft-ietf-atompub-format-00.txt]
References: <200407091923.PAA23330@ietf.org> <878ydsubdi.fsf@nwalsh.com> <58709D28-D22E-11D8-9A61-000A95BD86C0@mnot.net>
In-Reply-To: <58709D28-D22E-11D8-9A61-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: <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:

>> | 4.12  "atom:modified" Element
>> |
>> |    The "atom:modified" element is a Date construct that indicates the
>> |    time when the state of the feed was last modified, including any
>> |    changes to entries therein.  atom:feed elements MUST contain exactly
>> |    one atom:modified element.
>> |
>> |    The content of an atom:modified element SHOULD have a time zone 
>> whose
>> |    value MUST be "UTC".
>>
>> Are "SHOULD" and "MUST" reversed in that sentence?
> 
> This isn't a mistake; i.e., AFAIK it reflects current consensus 
> (although personally I don't agree with this approach).

I'm not sure I can assess what the current consensus is, I can comment 
on the original intent based on what the FeedValidator currently implements:

W3DTFDateNoTimezone is a Warning (will display, but will not cause a 
feed to be marked as invalid)

W3DTFDateNonUTC is Informational (and therefore by default does not display)

I would be comfortable with reversing the "SHOULD" and "MUST" in that 
sentence.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Sat Jul 10 08:21: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 IAA09967
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 08:21: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 i6AC8X2c079723;
	Sat, 10 Jul 2004 05:08: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 i6AC8XkG079722;
	Sat, 10 Jul 2004 05:08:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf30.cluster1.charter.net (mxsf30.cluster1.charter.net [209.225.28.230])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6AC8Wu1079706
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 05:08:32 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip04.cluster1.charter.net (mxip04a.cluster1.charter.net [209.225.28.134])
	by mxsf30.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6AC8SB4029713
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 08:08:28 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip04.cluster1.charter.net with ESMTP; 10 Jul 2004 08:08:28 -0400
X-Ironport-AV: i="3.81R,160,1083556800"; 
   d="scan'208"; a="105079054:sNHT17252008"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BjGeM-0001FP-00; Sat, 10 Jul 2004 08:08:14 -0400
To: Mark Pilgrim <pilgrim@gmail.com>
Cc: atom-syntax@imc.org
Subject: Re: Serialization matters
References: <200407091923.PAA23330@ietf.org> <878ydsubdi.fsf@nwalsh.com>
	<14be96d3040709185577f98ea0@mail.gmail.com>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Sat, 10 Jul 2004 08:08:14 -0400
In-Reply-To: <14be96d3040709185577f98ea0@mail.gmail.com> (Mark Pilgrim's
 message of "Fri, 9 Jul 2004 21:55:51 -0400")
Message-ID: <87d634rro1.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: <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-Type: text/plain

/ Mark Pilgrim <pilgrim@gmail.com> was heard to say:
| On Fri, 09 Jul 2004 17:19:37 -0400, Norman Walsh <ndw@nwalsh.com> wrote:
|> |    Atom documents are specified in terms of the XML Information Set,
|> |    serialised as XML 1.0 and identified with the "application/atom+xml"
|> |    media type.
|> 
|> I find the mention of the serialization format here a bit odd. If the
|> spec is going to describe things in terms of the infoset, then the
|> serialization form is irrelevant. If the spec wants to mandate a
|> serialization form, that's fine too, but I don't think it should do
|> that without justification.
|
| This has been discussed at length.  Everyone seems to want Atom to be
| described in terms of the InfoSet.  There is a small camp that wants
| Atom to be serializable in any InfoSet-compatible form, and a
| relatively larger camp that wants Atom to only ever be serializable as
| text-based XML 1.0.  See
| http://www.imc.org/atom-syntax/mail-archive/msg06161.html and
| following thread for a recent flare-up of this discussion.

I understand that. I favor 1.0 or its successors myself. In
particular, I think taking the position that Ethopic blogs can't use
Atom is short-sighted.

But the point of my comment was that the spec should have a section
about the serialized form, it shouldn't mention it only in passing.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | History teaches us that men and nations
http://nwalsh.com/            | behave wisely once they have exhausted
                              | all other alternatives.--Abba Eban

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA79wuOyltUcwYWjsRAsZ4AJ9RAstcUFZ5yKV8/Fkkd0fH0FW67QCfUUg0
zGq1p4rJzz6dy9ZvahHBH1Y=
=1+gv
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Sat Jul 10 08: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 IAA10031
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 08: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 i6ACBv2l080013;
	Sat, 10 Jul 2004 05:11: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 i6ACBvrf080012;
	Sat, 10 Jul 2004 05:11:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf27.cluster1.charter.net (mxsf27.cluster1.charter.net [209.225.28.227])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ACBuFt079994
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 05:11:56 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip09.cluster1.charter.net (mxip09a.cluster1.charter.net [209.225.28.139])
	by mxsf27.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6ACEums011375
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 08:14:56 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip09.cluster1.charter.net with ESMTP; 10 Jul 2004 08:11:53 -0400
X-Ironport-AV: i="3.81R,160,1083556800"; 
   d="scan'208"; a="99324000:sNHT17217080"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BjGhj-0001Lg-00
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 08:11:43 -0400
To: atom-syntax@imc.org
Subject: Re: Editorial issues
References: <200407091923.PAA23330@ietf.org> <878ydsubdi.fsf@nwalsh.com>
	<58709D28-D22E-11D8-9A61-000A95BD86C0@mnot.net>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Sat, 10 Jul 2004 08:11:33 -0400
In-Reply-To: <58709D28-D22E-11D8-9A61-000A95BD86C0@mnot.net> (Mark
 Nottingham's message of "Fri, 9 Jul 2004 22:02:30 -0700")
Message-ID: <874qogrrii.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: <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-Type: text/plain

If the editor is content that they're editorial, I'm happy :-)

I think the MUST/MAY might not be, but I'll call that out in a message
with a separate subject.

/ Mark Nottingham <mnot@mnot.net> was heard to say:
| Unless there's an objection, I'll consider the issues marked
| 'Editorial' below as such, and will incorporate proposals for them
| into the next I-D.
|
| On Jul 9, 2004, at 2:19 PM, Norman Walsh wrote:
|> [...]
|> |    Therefore, when this specification uses the term "element," it is
|> |    refering to an Element Information Item in Infoset terms.
|> Likewise,
|> |    when it uses the term "attribute," it is refering to an Attribute
|> |    Information Item.
|>
|> What about entity, document, etc.? Are those words shorthand as well?
|>
|> | 2.  Atom Documents
|> |
|> |    An Atom document
|>
|> Am I to assume document information item here?
|
| Editorial.
|
|> |    [RFC3066].  When determining element content's natural
|> language, the
|> |    first xml:lang attribute encountered in that element's
|> ancestors MUST
|> |    be used.
|>
|> "...encountered on that element or the first of its ancestors..." or
|> words to that effect. "Ancestor" can be construed to not include the
|> current element.
|
| Editorial.
|
|> |    the author.  It MAY be the name of a corporation or other
|> entity no
|>
|> ^ when?
|> |    individual authors can be named.  Person constructs MUST contain
|
| Editorial.
|
|> |    The "rel" attribute indicates the type of relationship that the
|> link
|> |    represents.  Link constructs MUST have a rel attribute, whose
|> value
|> |    MUST be a string, and MUST be one of the values enumerated in the
|> |    Atom Protocol specification [Atom-protocol].
|>
|> Please duplicate that list here. I don't care about the protocol and
|> it's
|> tedious to go read another spec just for a flat list.
|
| This has not been done because that list is not stable, and may
| ultimately end up in an IANA registry.
|
|> |    link.  Link constructs MAY have a title attribute, whose value
|> MUST
|> |    be a string.
|>
|> "MUST be a string"? How can an attribute *not* be a string. Does this
|> add anything?
|
| Editorial.
|
|> | 4.12  "atom:modified" Element
|> |
|> |    The "atom:modified" element is a Date construct that indicates the
|> |    time when the state of the feed was last modified, including any
|> |    changes to entries therein.  atom:feed elements MUST contain
|> exactly
|> |    one atom:modified element.
|> |
|> |    The content of an atom:modified element SHOULD have a time zone
|> whose
|> |    value MUST be "UTC".
|>
|> Are "SHOULD" and "MUST" reversed in that sentence?
|
| This isn't a mistake; i.e., AFAIK it reflects current consensus
| (although personally I don't agree with this approach).
|
|> | 4.13.9  "atom:summary" Element
|> |
|> |    The "atom:summary" element is a Content construct that conveys a
|> |    short summary, abstract or excerpt of the entry.  atom:entry
|> elements
|> |    MAY contain an atom:created element, but MUST NOT contain more
|> than
|>                          ^summary (not created)
|
| Editorial.
|
| --
| Mark Nottingham     http://www.mnot.net/

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Furious activity is no substitute for
http://nwalsh.com/            | understanding.--H. H. Williams

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA79z1OyltUcwYWjsRAmsRAJ0fn/4ImsTqZXBaYcJpVzeh+tZS3wCfQe06
iXPBkqA9BtuR828tmw7SFOc=
=R7gl
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Sat Jul 10 08:25: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 IAA10083
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 08:25: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 i6ACA0dA079804;
	Sat, 10 Jul 2004 05:10: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 i6ACA0P9079803;
	Sat, 10 Jul 2004 05:10:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf10.cluster1.charter.net (mxsf10.cluster1.charter.net [209.225.28.210])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6AC9xcq079789
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 05:09:59 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip12.cluster1.charter.net (mxip12a.cluster1.charter.net [209.225.28.142])
	by mxsf10.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6ACCqHb022967
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 08:12:52 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip12.cluster1.charter.net with ESMTP; 10 Jul 2004 08:09:55 -0400
X-Ironport-AV: i="3.81R,160,1083556800"; 
   d="scan'208"; a="106797913:sNHT15095952"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BjGfn-0001Fd-00
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 08:09:43 -0400
To: atom-syntax@imc.org
Subject: Re: RELAX NG schema
References: <200407091923.PAA23330@ietf.org> <878ydsubdi.fsf@nwalsh.com>
	<14be96d304070919213f8a1ee9@mail.gmail.com>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Sat, 10 Jul 2004 08:09:42 -0400
In-Reply-To: <14be96d304070919213f8a1ee9@mail.gmail.com> (Mark Pilgrim's
 message of "Fri, 9 Jul 2004 22:21:22 -0400")
Message-ID: <878ydsrrll.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: <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-Type: text/plain

/ Mark Pilgrim <pilgrim@gmail.com> was heard to say:
| On Fri, 09 Jul 2004 17:19:37 -0400, Norman Walsh <ndw@nwalsh.com> wrote:
|> 1. A schema, RELAX NG would be my preference, even if it's
|> non-normative would be very helpful. I'll volunteer to write and
|> maintain it, if that helps.
|
| http://www.dpawson.co.uk/relaxng/atom03/

Right. I have one too, but I hadn't gone back to compare the 00 draft
with the 0.3 draft.

And my point is that I want it in the spec, as a normative or
non-normative appendix, for example.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | A facility for quotation covers the
http://nwalsh.com/            | absence of original thought.--Lord
                              | Peter Wimsey

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA79yGOyltUcwYWjsRAmk4AJ9rQDMpP6pJkAWlgco5/45QfXkkoQCfeXXD
tUgIabnT8UqbsVw53cSiWU4=
=vOf+
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Sat Jul 10 08:25: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 IAA10170
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 08:25: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 i6ACGUnr080867;
	Sat, 10 Jul 2004 05: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 i6ACGUfS080866;
	Sat, 10 Jul 2004 05:16:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf05.cluster1.charter.net (mxsf05.cluster1.charter.net [209.225.28.205])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ACGTJP080847
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 05:16:29 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip03.cluster1.charter.net (mxip03a.cluster1.charter.net [209.225.28.133])
	by mxsf05.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6ACItNR029052
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 08:18:55 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip03.cluster1.charter.net with ESMTP; 10 Jul 2004 08:16:25 -0400
X-Ironport-AV: i="3.81R,160,1083556800"; 
   d="scan'208"; a="100673488:sNHT17907260"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BjGm3-0001OK-00
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 08:16:11 -0400
To: atom-syntax@imc.org
Subject: MUST/SHOULD in atom:modified
References: <200407091923.PAA23330@ietf.org> <878ydsubdi.fsf@nwalsh.com>
	<58709D28-D22E-11D8-9A61-000A95BD86C0@mnot.net>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Sat, 10 Jul 2004 08:16:11 -0400
In-Reply-To: <58709D28-D22E-11D8-9A61-000A95BD86C0@mnot.net> (Mark
 Nottingham's message of "Fri, 9 Jul 2004 22:02:30 -0700")
Message-ID: <87zn68qcqc.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: <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-Type: text/plain

/ Mark Nottingham <mnot@mnot.net> was heard to say:
[...]
|> | 4.12  "atom:modified" Element
|> |
|> |    The "atom:modified" element is a Date construct that indicates the
|> |    time when the state of the feed was last modified, including any
|> |    changes to entries therein.  atom:feed elements MUST contain
|> exactly
|> |    one atom:modified element.
|> |
|> |    The content of an atom:modified element SHOULD have a time zone
|> whose
|> |    value MUST be "UTC".
|>
|> Are "SHOULD" and "MUST" reversed in that sentence?
|
| This isn't a mistake; i.e., AFAIK it reflects current consensus
| (although personally I don't agree with this approach).

atom:modified for atom:feed says:

   The content of an atom:modified element SHOULD have a time zone whose
   value MUST be "UTC".

atom:modified for atom:entry says:

   The content of an atom:modified element MUST have a time zone whose
   value SHOULD be "UTC".

If that's not a mistake, I can't fathom the rationale. If the
semantics of atom:modified on a feed are really that different from
atom:modified on an entry, I think maybe they need different element
names.

And if all we can say about an element is that it SHOULD have a time zone,
then I think we better say how an element without a time zone is to be
interpreted.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | I don't know the key to success, but
http://nwalsh.com/            | the key to failure is trying to please
                              | everybody.--Bill Cosby

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA794LOyltUcwYWjsRAqiEAJ9xNGgIqNJaM1XbFJRzJkhX3T8SMQCdHeW+
6tiXwu0NbRDc9MIribRqS+I=
=9VLR
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Sat Jul 10 08:33: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 IAA10477
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 08:33: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 i6ACJ69l081074;
	Sat, 10 Jul 2004 05:19: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 i6ACJ6VP081073;
	Sat, 10 Jul 2004 05:19:06 -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 i6ACJ5Td081058
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 05:19:05 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip06.cluster1.charter.net (mxip06a.cluster1.charter.net [209.225.28.136])
	by mxsf09.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6ACLf71016351
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 08:21:41 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip06.cluster1.charter.net with ESMTP; 10 Jul 2004 08:19:01 -0400
X-Ironport-AV: i="3.81R,160,1083556800"; 
   d="scan'208"; a="103603151:sNHT15134606"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BjGob-0001Oq-00
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 08:18:49 -0400
To: atom-syntax@imc.org
Subject: Re: atom:info
References: <200407091923.PAA23330@ietf.org> <878ydsubdi.fsf@nwalsh.com>
	<BE332F7D-D22E-11D8-9A61-000A95BD86C0@mnot.net>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Sat, 10 Jul 2004 08:18:44 -0400
In-Reply-To: <BE332F7D-D22E-11D8-9A61-000A95BD86C0@mnot.net> (Mark
 Nottingham's message of "Fri, 9 Jul 2004 22:05:20 -0700")
Message-ID: <87oemoqcm3.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: <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-Type: text/plain

/ Mark Nottingham <mnot@mnot.net> was heard to say:
| The only use case for atom:info that I'm aware of does not require
| standardisation; it could be achieved just as effectively with a
| site-specific extension. Therefore, I propose we drop this element.

Sounds like a good design rationale to me: +1

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | In real life, unlike in Shakespeare,
http://nwalsh.com/            | the sweetness of the rose depends upon
                              | the name it bears. Things are not only
                              | what they are. They are, in very
                              | important respects, what they seem to
                              | be.--Hubert H. Humphrey

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA796kOyltUcwYWjsRAsitAJoDPvRjw8Ag9funmD+hBQeKdiMwoACgoSYM
F2oJS2JYMU6l6UAF1ISkhlU=
=JRPp
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Sat Jul 10 08:40: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 IAA10809
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 08:40: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 i6ACI4cn080989;
	Sat, 10 Jul 2004 05:18: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 i6ACI40E080988;
	Sat, 10 Jul 2004 05:18:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf22.cluster1.charter.net (mxsf22.cluster1.charter.net [209.225.28.222])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ACI3ii080976
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 05:18:03 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip12.cluster1.charter.net (mxip12a.cluster1.charter.net [209.225.28.142])
	by mxsf22.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6ACKcAZ029276
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 08:20:39 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip12.cluster1.charter.net with ESMTP; 10 Jul 2004 08:17:59 -0400
X-Ironport-AV: i="3.81R,160,1083556800"; 
   d="scan'208"; a="106825174:sNHT15697626"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BjGng-0001Oc-00
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 08:17:52 -0400
To: atom-syntax@imc.org
Subject: MUST be UTC?
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Sat, 10 Jul 2004 08:17:51 -0400
Message-ID: <87smc0qcnk.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: <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-Type: text/plain

On the subject of time zones, is it really necessary to use UTC? How is
"2004-07-08T07:11:53-04:00" really worse than "2004-07-08T11:11:53Z"?
I can understand not using forms like "2004-07-08T07:11:53EDT" but I'd
like the freedom to use the numeric forms.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | If you want to make an apple pie from
http://nwalsh.com/            | scratch, you must first create the
                              | universe.--Carl Sagan

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA795vOyltUcwYWjsRAuQgAKCkv2dTS+Dl9DE+HK8zdilLGBFprgCghfWb
bgLMRVab3oqYpNJOnWyTzhM=
=SqTQ
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Sat Jul 10 08: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 IAA10839
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 08: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 i6ACKB0j081181;
	Sat, 10 Jul 2004 05:20: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 i6ACKBuQ081180;
	Sat, 10 Jul 2004 05:20:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf21.cluster1.charter.net (mxsf21.cluster1.charter.net [209.225.28.221])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ACKB9T081168
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 05:20:11 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip01.cluster1.charter.net (mxip01a.cluster1.charter.net [209.225.28.131])
	by mxsf21.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6ACMCYt013051
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 08:22:12 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip01.cluster1.charter.net with ESMTP; 10 Jul 2004 08:20:07 -0400
X-Ironport-AV: i="3.81R,160,1083556800"; 
   d="scan'208"; a="86257149:sNHT14621860"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BjGpc-0001P4-00
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 08:19:52 -0400
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Comments on I-D ACTION:draft-ietf-atompub-format-00.txt
References: <BD15AF20.1E6F4%eric.scheid@ironclad.net.au>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Sat, 10 Jul 2004 08:19:52 -0400
In-Reply-To: <BD15AF20.1E6F4%eric.scheid@ironclad.net.au> (Eric Scheid's
 message of "Sat, 10 Jul 2004 14:35:12 +1000")
Message-ID: <87k6xcqck7.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: <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-Type: text/plain

/ Eric Scheid <eric.scheid@ironclad.net.au> was heard to say:
| On 10/7/04 7:19 AM, "Norman Walsh" <ndw@nwalsh.com> wrote:
|
|> |    link.  Link constructs MAY have a title attribute, whose value MUST
|> |    be a string.
|> 
|> "MUST be a string"? How can an attribute *not* be a string. Does this
|> add anything?
|
| maybe the intent is to avoid people using title="&lt;b&gt;B&lt;/b&gt;old is
| old" and hoping they'll get *B*old is old.
|
| if so, +1

It's not a Content construct, so I wouldn't expect that to work. But
if that's the intent, then I think it just needs a little editorial
clarification.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | An author is a fool who, not content
http://nwalsh.com/            | with boring those he lives with,
                              | insists on boring future
                              | generations.--Charles de Montesquieu

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA797oOyltUcwYWjsRAi2sAJ40PGSNx77uwMkHoi8CKZFHfAodogCfcr5N
enL/rgSclAvYCBUXMViSgwM=
=Jhks
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Sat Jul 10 08:44: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 IAA11296
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 08:44: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 i6ACYJ89083069;
	Sat, 10 Jul 2004 05:34: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 i6ACYJe5083068;
	Sat, 10 Jul 2004 05:34:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ACYIWb083061
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 05:34:18 -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 i6ACYW1k010325;
	Sat, 10 Jul 2004 08:34:32 -0400
Message-ID: <40EFE232.6080109@intertwingly.net>
Date: Sat, 10 Jul 2004 08:33:54 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <mnot@mnot.net>
CC: Mark Pilgrim <pilgrim@gmail.com>, Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceMustBeWellFormed
References: <14be96d30407061142441f70ee@mail.gmail.com> <3B72AB44-D235-11D8-9A61-000A95BD86C0@mnot.net>
In-Reply-To: <3B72AB44-D235-11D8-9A61-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: <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:
> 
> -1
> 
> This is great advice, but it restates a number of requirements in other 
> specifications that are referred to by Atom. That's not good 
> specification practice, as it very often results in conflicts of 
> interpretation. Furthermore, this places a large number of requirements 
> on "clients" that are difficult to test and constrain their behaviours 
> in frankly unrealistic ways. Finally, many of the other requirements are 
> made upon "publishers" -- an audience that almost assuredly will never 
> read the Atom specification.
> 
> I strongly suggest this be moved to a primer, another non-normative 
> document, or to WG-external supporting documentation.

Lots of good specifications have informative notes when there are 
relevant specifications that have specific requirements that need to be 
aware of.

I'm sure that many of these non-normative notes started out lenghty 
before being boiled down to their essentials by repeated scrubbing.

I'm quite OK with a non-normative note, and brevity whenever it does not 
affect clarity is always a virtue, but I am not OK with leaving the 
effort of finding the relevant specifications as an exercise left for 
the student.  In producing the feedvalidator I have been continually 
frustrated by vague specifications and contradictory and 
non-authoritative clarifications.

So: I strongly encourage that we continue to work towards the placement 
of SOMETHING that attempts to address the problem this PACE proports to 
solve in one of the documents produced by this workgroup.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Sat Jul 10 08:55:13 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11697
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 08:55: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 i6ACeQpC083540;
	Sat, 10 Jul 2004 05: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 i6ACeQrZ083539;
	Sat, 10 Jul 2004 05:40:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.206])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6ACePkc083532
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 05:40:25 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d19so270175rnf
        for <atom-syntax@imc.org>; Sat, 10 Jul 2004 05:40:10 -0700 (PDT)
Received: by 10.38.2.58 with SMTP id 58mr38563rnb;
        Sat, 10 Jul 2004 05:40:10 -0700 (PDT)
Message-ID: <14be96d3040710054097d5bb4@mail.gmail.com>
Date: Sat, 10 Jul 2004 08:40:10 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Norman Walsh <ndw@nwalsh.com>
Subject: Re: RELAX NG schema
Cc: atom-syntax@imc.org
In-Reply-To: <878ydsrrll.fsf@nwalsh.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <200407091923.PAA23330@ietf.org> <878ydsubdi.fsf@nwalsh.com>
	<14be96d304070919213f8a1ee9@mail.gmail.com> <878ydsrrll.fsf@nwalsh.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 Sat, 10 Jul 2004 08:09:42 -0400, Norman Walsh <ndw@nwalsh.com> wrote:
> | http://www.dpawson.co.uk/relaxng/atom03/
> 
> Right. I have one too, but I hadn't gone back to compare the 00 draft
> with the 0.3 draft.
> 
> And my point is that I want it in the spec, as a normative or
> non-normative appendix, for example.

Great.  Work with Dave Pawson to update it, and write up a Pace when
you're done.

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Sat Jul 10 08: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 IAA11908
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 08:58: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 i6ACmpY9084027;
	Sat, 10 Jul 2004 05: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 i6ACmpTb084026;
	Sat, 10 Jul 2004 05:48:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf26.cluster1.charter.net (mxsf26.cluster1.charter.net [209.225.28.226])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ACmoJX084017
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 05:48:50 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip13.cluster1.charter.net (mxip13a.cluster1.charter.net [209.225.28.143])
	by mxsf26.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6ACq7UA008984
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 08:52:07 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip13.cluster1.charter.net with ESMTP; 10 Jul 2004 08:48:46 -0400
X-Ironport-AV: i="3.81R,160,1083556800"; 
   d="scan'208"; a="101236892:sNHT20582496"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BjHHR-0001kd-00
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 08:48:37 -0400
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceElementOrder
References: <97774BF0-D096-11D8-B2D0-000A95A51C9E@sun.com>
	<F3C7FAC8-D233-11D8-9A61-000A95BD86C0@mnot.net>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Sat, 10 Jul 2004 08:48:36 -0400
In-Reply-To: <F3C7FAC8-D233-11D8-9A61-000A95BD86C0@mnot.net> (Mark
 Nottingham's message of "Fri, 9 Jul 2004 22:42:38 -0700")
Message-ID: <87smc0ownv.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: <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-Type: text/plain

/ Mark Nottingham <mnot@mnot.net> was heard to say:
| On Jul 7, 2004, at 9:23 PM, Tim Bray wrote:
|
|> I propose a modification to this Pace
|> (http://www.intertwingly.net/wiki/pie/PaceElementOrder).  I don't
|> know what the right section number is in the about-to-appear -00
|> drafts, but I'd like language like this:
|>
|>  The child elements of <atom:feed> may appear in any order, subject
|> only to
|>  the constraint that the the <atom:entry> children appear in a group
|> after all
|>  other child elements.  That is to say, the "feed-level" elements
|> must all
|>  appear before the first <atom:entry> element.  The order in which the
|>  child elements of <atom:feed> appear is not considered significant.

If we want to make a distinction between atom:entry children and other
children, I suggest that we put the other children in a wrapper.

  <atom:feed>
    <atom:feedinfo>
      <atom:title>...</atom:title>
    </atom:feedinfo>
    <atom:entry>...</atom:entry>
  </atom:feed>

(I don't have any particular attachment to the name "feedinfo".)

This would make it easy to constrain the feed information to appear
first without struggling over the order of extension elements that
are peer to atom:entry.

It would also clarify extension elements that are intended to be peer
to atom:title on a feed (but not atom:entry).

In fact, now that I think about it, I think this makes oodles of sense
regardless of the ordering issues.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | A censor is a man who knows more than
http://nwalsh.com/            | he thinks you ought to.--Granville Hacks

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA7+WkOyltUcwYWjsRAhuaAJ9DKANahvvz/buc9yzr2fN1Yolm7wCeOORp
Wtx90oh59ZNiMnEvLfm51l4=
=QDjZ
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Sat Jul 10 09:00: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 JAA12040
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 09:00: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 i6ACgNw0083642;
	Sat, 10 Jul 2004 05:42: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 i6ACgNx4083641;
	Sat, 10 Jul 2004 05:42: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 i6ACgM7M083634
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 05:42: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 i6ACgtjL010800;
	Sat, 10 Jul 2004 08:42:55 -0400
Message-ID: <40EFE429.1020400@intertwingly.net>
Date: Sat, 10 Jul 2004 08:42:17 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Norman Walsh <ndw@nwalsh.com>
CC: atom-syntax@imc.org
Subject: Re: MUST/SHOULD in atom:modified
References: <200407091923.PAA23330@ietf.org> <878ydsubdi.fsf@nwalsh.com>	<58709D28-D22E-11D8-9A61-000A95BD86C0@mnot.net> <87zn68qcqc.fsf_-_@nwalsh.com>
In-Reply-To: <87zn68qcqc.fsf_-_@nwalsh.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


Norman Walsh wrote:

> And if all we can say about an element is that it SHOULD have a time zone,
> then I think we better say how an element without a time zone is to be
> interpreted.

Perhaps something like this?

http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#date

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Sat Jul 10 09: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 JAA12113
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 09: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 i6ACnKdm084061;
	Sat, 10 Jul 2004 05: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 i6ACnKiW084060;
	Sat, 10 Jul 2004 05:49:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf19.cluster1.charter.net (mxsf19.cluster1.charter.net [209.225.28.219])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ACnJ4n084046
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 05:49:19 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip03.cluster1.charter.net (mxip03a.cluster1.charter.net [209.225.28.133])
	by mxsf19.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6ACq2qK005986
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 08:52:02 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip03.cluster1.charter.net with ESMTP; 10 Jul 2004 08:49:15 -0400
X-Ironport-AV: i="3.81R,160,1083556800"; 
   d="scan'208"; a="100785265:sNHT14806856"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BjHHy-0001kr-00
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 08:49:10 -0400
To: atom-syntax@imc.org
Subject: Re: atom:title as content construct
References: <200407091923.PAA23330@ietf.org> <200407091923.PAA23330@ietf.org>
	<4.2.0.58.J.20040710104808.062757b8@localhost>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Sat, 10 Jul 2004 08:49:09 -0400
In-Reply-To: <4.2.0.58.J.20040710104808.062757b8@localhost> (Martin Duerst's
 message of "Sat, 10 Jul 2004 10:50:20 +0900")
Message-ID: <87oemoowmy.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: <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-Type: text/plain

/ Martin Duerst <duerst@w3.org> was heard to say:
| At 17:19 04/07/09 -0400, Norman Walsh wrote:
|
|>| 4.3  "atom:title" Element
|>|
|>|    The "atom:title" element is a Content construct that conveys a
|>
|>It seems slightly odd to me that the title is a Content construct. I think
|>I'd be happier if the title was a string.
|
| Given that people might want to put mathematical formulas into titles,
| that they may want to put ruby in a title, that they may want to put
| multilingual strings in a title and want to clearly indicate that,
| and so on, I'd be much happier if title stayed a content construct.

Fair enough. I withdraw my comment.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | If someone tells you he is going to
http://nwalsh.com/            | make 'a realistic decision', you
                              | immediately understand that he has
                              | resolved to do something bad.--Mary
                              | McCarthy

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA7+XGOyltUcwYWjsRAt/TAKCLuI8GYvt/M73QH/pr6OLRYNBMhACgribU
cZ6Wm12VssxFEahsr84tGvE=
=2eOC
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Sat Jul 10 09:21: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 JAA13114
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 09:21: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 i6AD1iKW086082;
	Sat, 10 Jul 2004 06:01:44 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6AD1iwd086081;
	Sat, 10 Jul 2004 06:01:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf27.cluster1.charter.net (mxsf27.cluster1.charter.net [209.225.28.227])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6AD1hHF086071
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 06:01:43 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip19.cluster1.charter.net (mxip19a.cluster1.charter.net [209.225.28.149])
	by mxsf27.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6AD4ijd001054
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 09:04:44 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip19.cluster1.charter.net with ESMTP; 10 Jul 2004 09:01:40 -0400
X-Ironport-AV: i="3.81R,160,1083556800"; 
   d="scan'208"; a="99400714:sNHT14494624"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BjHTz-0001wb-00
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 09:01:35 -0400
To: Atom Syntax <atom-syntax@imc.org>
Subject: Craeted proposal: PaceProvideSchema
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Sat, 10 Jul 2004 09:01:35 -0400
Message-ID: <87eknkow28.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: <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-Type: text/plain

This Pace supports my comment that a schema should be provided as part
of the Atom format spec. Concretely, I suggest that both a RELAX NG
grammar and a W3C XML Schema should be provided.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Wink at small faults; for thou has
http://nwalsh.com/            | great ones.--Thomas Fuller (II)

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA7+ivOyltUcwYWjsRAte4AKCjfdphzF/h5i9ZJkpd87HAu6A5LwCfTf0x
edVzRwlBgDN3wBlTY6QhrPQ=
=DAQb
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Sat Jul 10 10: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 KAA16266
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 10: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 i6AE5A89090596;
	Sat, 10 Jul 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 i6AE5ACN090595;
	Sat, 10 Jul 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 rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6AE5AB1090581
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 07:05:10 -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 <2004071014050701400lgh8ue>; Sat, 10 Jul 2004 14:05:07 +0000
Date: Sat, 10 Jul 2004 08:05:06 -0600
Subject: Re: MUST be UTC?
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: <87smc0qcnk.fsf@nwalsh.com>
Message-Id: <2576D938-D27A-11D8-99EE-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, July 10, 2004, at 06:17  AM, Norman Walsh wrote:
> On the subject of time zones, is it really necessary to use UTC? How is
> "2004-07-08T07:11:53-04:00" really worse than "2004-07-08T11:11:53Z"?
> I can understand not using forms like "2004-07-08T07:11:53EDT" but I'd
> like the freedom to use the numeric forms.

+1 to both allowing other timezones and requiring non-Z timezones to be 
numeric.



From owner-atom-syntax@mail.imc.org  Sat Jul 10 11:20: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 LAA18436
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 11:20:59 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6AF7mXB095460;
	Sat, 10 Jul 2004 08: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 i6AF7mLZ095459;
	Sat, 10 Jul 2004 08:07:48 -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 i6AF7lgp095450
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 08:07:48 -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 i6AF7i53001538
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 10:07:44 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6AF7iP7001534;
	Sat, 10 Jul 2004 10:07:44 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: atom-syntax@imc.org
Subject: PaceEntryTopLevel -- editorial
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 10 Jul 2004 10:07:44 -0500
Message-ID: <m3658vrjcv.fsf@bitsko.slc.ut.us>
Lines: 32
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


== Abstract ==

  This Pace proposes making atom:entry a top-level section in the Atom
  Format document.

== Status ==

  Open -- Editorial.

  Updates: draft-ietf-atompub-format-00

== Rationale ==

  * The atom:entry is a significant element construct in the feed and
    it would read easier if it were detailed in its own major section.

  * The atom:entry element is used as a root or document type element
    in the Atom publishing protocol and is suggested for use as a
    document type in several other use-cases, some of which may
    eventually become part of the Atom Format formally.

== Proposal ==

  "Raise" section 4.13 to its own section following section 4.

  4.13 would now read:

      "atom:entry" elements represent individual entries that are
       contained by the feed.  atom:feed elements MAY contain one or
       more atom:entry elements as defined in section XX.

  -- Ken



From owner-atom-syntax@mail.imc.org  Sat Jul 10 12: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 MAA20766
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 12:14:31 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6AFwiUe099798;
	Sat, 10 Jul 2004 08:58: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 i6AFwivY099797;
	Sat, 10 Jul 2004 08:58: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-1.tiscali.it (mail-relay-1.tiscali.it [212.123.84.91])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6AFwhZn099788
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 08:58:43 -0700 (PDT)
	(envelope-from danny666@virgilio.it)
Received: from virgilio.it (62.11.121.100) by mail-relay-1.tiscali.it (7.1.021.3)
        id 40E574C200320614; Sat, 10 Jul 2004 17:58:35 +0200
Message-ID: <40F011AE.1090502@virgilio.it>
Date: Sat, 10 Jul 2004 17:56:30 +0200
From: Danny Ayers <danny666@virgilio.it>
Reply-To: danny666@virgilio.it
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mark Nottingham <mnot@mnot.net>
CC: Tim Bray <Tim.Bray@Sun.COM>, Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceElementOrder
References: <97774BF0-D096-11D8-B2D0-000A95A51C9E@sun.com> <F3C7FAC8-D233-11D8-9A61-000A95BD86C0@mnot.net> <63690128-D237-11D8-B2D0-000A95A51C9E@sun.com> <98FB4CE4-D237-11D8-9A61-000A95BD86C0@mnot.net>
In-Reply-To: <98FB4CE4-D237-11D8-9A61-000A95BD86C0@mnot.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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:

>
>
> On Jul 9, 2004, at 11:07 PM, Tim Bray wrote:
>
>>
>> On the other hand, leaving the order semi-unconstrained (i.e. 
>> requiring only that the <atom:entry> crowd bring up the rear) is 
>> going to result in serious ugliness in any XSD we produce, which may 
>> spill over into SOAP/WSDL territory... still, I lean to -1. -Tim
>
>
> XSD's problem, not mine.


Quite.

It seems like putting the cart before the horse to constrain order in 
the spec for the benefit of the schema without some reference to 
schema-validity.  If we really want a schema, we should be prepared to 
use it. I'd suggest either making schema-validity a SHOULD (and 
processor validation a MAY) or allowing any order. I suspect the latter 
is more likely to gain consensus.

Cheers,
Danny.

-- 

Raw
http://dannyayers.com



From owner-atom-syntax@mail.imc.org  Sat Jul 10 12:14:46 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20789
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 12:14: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 i6AFjFVZ098906;
	Sat, 10 Jul 2004 08:45:15 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6AFjF2b098905;
	Sat, 10 Jul 2004 08:45:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail-relay-2.tiscali.it (mail-relay-2.tiscali.it [212.123.84.92])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6AFjEIv098896
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 08:45:15 -0700 (PDT)
	(envelope-from danny666@virgilio.it)
Received: from virgilio.it (62.11.121.100) by mail-relay-2.tiscali.it (7.1.021.3)
        id 40E56D3E0032AC9C; Sat, 10 Jul 2004 17:45:04 +0200
Message-ID: <40F00E83.9020506@virgilio.it>
Date: Sat, 10 Jul 2004 17:42:59 +0200
From: Danny Ayers <danny666@virgilio.it>
Reply-To: danny666@virgilio.it
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mark Nottingham <mnot@mnot.net>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Resource terminology
References: <40EEFB88.3020403@virgilio.it> <55668634-D233-11D8-9A61-000A95BD86C0@mnot.net>
In-Reply-To: <55668634-D233-11D8-9A61-000A95BD86C0@mnot.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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:

>
>
> On Jul 9, 2004, at 1:09 PM, Danny Ayers wrote:
>
>> Can someone please tell me if this was intentional (and if so, why?!) -
>>
>> The charter, early on says:
>>
>> Atom consists of:
>>    * A conceptual model of a resource
>>
>>
>> Is this a resource in the URI sense, or a new term for an Atom thing?
>
>
> In the Web sense, yes.


Then why should a conceptual model of one appear in Atom - isn't that 
way too wide a scope? Shouldn't we just refer to the description in RFC 
2396bis, with description focussing solely on Atom-specific constructs?


>> Either way, this seems very confusing.
>> Come back "Well-Formed Log Entry", all is forgiven...
>
>
> What exactly does that mean?


Sam's original aim [1] of modelling entries got shunted to one side 
early on with the mad dash for syntax, but it remains considerably 
easier than figuring out the semiotics/semantics of a resource in general.

Cheers,
Danny.


[1] 
http://www.intertwingly.net/blog/2003/06/16/Anatomy-of-a-Well-Formed-Log-Entry

>


-- 

Raw
http://dannyayers.com



From owner-atom-syntax@mail.imc.org  Sat Jul 10 12:31: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 MAA21452
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 12:31: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 i6AGCuxJ000600;
	Sat, 10 Jul 2004 09: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 i6AGCuku000599;
	Sat, 10 Jul 2004 09:12:56 -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 i6AGCteE000593
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 09:12:55 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.18] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP id B1763727D
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 09:12:58 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <01C0B4EA-D28C-11D8-9A61-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: What kinds of Atom documents are there?
Date: Sat, 10 Jul 2004 09:12:57 -0700
To: Atom Syntax <atom-syntax@imc.org>
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>
Content-Transfer-Encoding: 7bit


So far, the format spec defines one kind of Atom document, that with 
the atom:feed root element.

In the -00 draft, a Pace was incorporated that hints that entries might 
be documents on their own; that is, we might have a document whose root 
element is atom:entry.

Did this slip by without serious consideration by the WG, or does it 
represent consensus?

If it does, we need to add language about what that document is, and 
add a media type registration for it. I'm happy to start working on 
that, but want to make sure that this is the direction we want to go.

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Sat Jul 10 12:48:19 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21966
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 12:48: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 i6AGXWdD002119;
	Sat, 10 Jul 2004 09:33: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 i6AGXWEm002118;
	Sat, 10 Jul 2004 09:33:32 -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 i6AGXWU2002101
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 09:33:32 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040710163330.6078.qmail@web41208.mail.yahoo.com>
Received: from [67.168.158.64] by web41208.mail.yahoo.com via HTTP; Sat, 10 Jul 2004 09:33:30 PDT
Date: Sat, 10 Jul 2004 09:33:30 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Serialization matters
To: Norman Walsh <ndw@nwalsh.com>, Mark Pilgrim <pilgrim@gmail.com>
Cc: atom-syntax@imc.org
In-Reply-To: <87d634rro1.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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


--- Norman Walsh <ndw@nwalsh.com> wrote:
> 
> I understand that. I favor 1.0 or its successors
> myself. In
> particular, I think taking the position that Ethopic
> blogs can't use
> Atom is short-sighted.

How does Atom prevent Ethopic blogs from being
syndicated? XML 1.0 can have Ethopic content just
fine, just not Ethopic element and attribute names.
Given that an Ethopic blogger will have to use suck it
up and deal with English element names for the Atom
namespaced elements and attributes as well as the HTML
they are using to publish on the Web I'm not sure why
they are any more disenfranchised by Atom. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 



From owner-atom-syntax@mail.imc.org  Sat Jul 10 12: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 MAA22010
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 12: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 i6AGRAQd001736;
	Sat, 10 Jul 2004 09:27: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 i6AGRANg001735;
	Sat, 10 Jul 2004 09:27:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail-relay-2.tiscali.it (mail-relay-2.tiscali.it [212.123.84.92])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6AGR9uJ001727
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 09:27:09 -0700 (PDT)
	(envelope-from danny666@virgilio.it)
Received: from virgilio.it (62.11.121.100) by mail-relay-2.tiscali.it (7.1.021.3)
        id 40E56D3E0032CD91; Sat, 10 Jul 2004 18:26:47 +0200
Message-ID: <40F0184A.20702@virgilio.it>
Date: Sat, 10 Jul 2004 18:24:42 +0200
From: Danny Ayers <danny666@virgilio.it>
Reply-To: danny666@virgilio.it
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Norman Walsh <ndw@nwalsh.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Craeted proposal: PaceProvideSchema
References: <87eknkow28.fsf@nwalsh.com>
In-Reply-To: <87eknkow28.fsf@nwalsh.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


Norman Walsh wrote:

>This Pace supports my comment that a schema should be provided as part
>of the Atom format spec. Concretely, I suggest that both a RELAX NG
>grammar and a W3C XML Schema should be provided.
>  
>

I personally reckon it's almost certainly a good idea, but I don't think 
convincing case has yet been made: what is the purpose of the 
grammar/schema? The rationale in the Pace is that it will "aid readers" 
- how so?

Another obvious question is: should every conformant Atom document be 
valid against the schema?

A perhaps more interesting question is: will every schema-valid document 
be a conformant Atom document?

If the answer to either is "Yes", then there's very good justification 
for a reference to schemas. The latter would mean code generated from 
the schema(s) could be relied on to produce conformant Atom (assuming a 
sensible generator and hiding RFC 3023 in the basement).

A possible scenario which might work with the latter is that the XML 
Schema mandates the element order, but the spec prose doesn't.

Cheers,
Danny.

-- 

Raw
http://dannyayers.com



From owner-atom-syntax@mail.imc.org  Sat Jul 10 12:58:34 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22300
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 12:58: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 i6AGiiCF002884;
	Sat, 10 Jul 2004 09:44: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 i6AGiirU002883;
	Sat, 10 Jul 2004 09:44:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6AGihMk002876
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 09:44:43 -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 1BjKxu-0004Bj-8m; Sat, 10 Jul 2004 16:44:42 +0000
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Sat, 10 Jul 2004 12:44:49 -0400
Subject: Re: What kinds of Atom documents are there?
From: Robert Sayre <mint@franklinmint.fm>
To: Mark Nottingham <mnot@mnot.net>, Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD159541.120A1%mint@franklinmint.fm>
In-Reply-To: <01C0B4EA-D28C-11D8-9A61-000A95BD86C0@mnot.net>
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: <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 7/10/04 12:12 PM, "Mark Nottingham" <mnot@mnot.net> wrote:

> 
> So far, the format spec defines one kind of Atom document, that with
> the atom:feed root element.
> 
> In the -00 draft, a Pace was incorporated that hints that entries might
> be documents on their own; that is, we might have a document whose root
> element is atom:entry.
> 
> Did this slip by without serious consideration by the WG, or does it
> represent consensus?

I think it is the consensus. The protocol spec has always transferred such
documents. 

http://www.imc.org/atom-syntax/mail-archive/msg04381.html

> 
> If it does, we need to add language about what that document is, and
> add a media type registration for it. I'm happy to start working on
> that, but want to make sure that this is the direction we want to go.
> 

Would we need a new media type for it? For example, application/docbook+xml
has more than one possible document element, right?

Robert Sayre



From owner-atom-syntax@mail.imc.org  Sat Jul 10 13:18: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 NAA22835
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 13:18: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 i6AH1lDU004445;
	Sat, 10 Jul 2004 10:01: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 i6AH1l8v004444;
	Sat, 10 Jul 2004 10:01:47 -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 i6AH1kGT004438
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 10:01:47 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.18] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id 649D5727D; Sat, 10 Jul 2004 10:01:50 -0700 (PDT)
In-Reply-To: <40EFE232.6080109@intertwingly.net>
References: <14be96d30407061142441f70ee@mail.gmail.com> <3B72AB44-D235-11D8-9A61-000A95BD86C0@mnot.net> <40EFE232.6080109@intertwingly.net>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <D508BB43-D292-11D8-9A61-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: Atom Syntax <atom-syntax@imc.org>, Mark Pilgrim <pilgrim@gmail.com>
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: PaceMustBeWellFormed
Date: Sat, 10 Jul 2004 10:01:48 -0700
To: Sam Ruby <rubys@intertwingly.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>
Content-Transfer-Encoding: 7bit


The relevant question is where to draw the line. I suspect we're going 
to come up with a lot of other implementation advice, and if we do, 
putting it in the spec is going to make it harder to find the normative 
parts of the spec. This is especially true with an RFC, where the 
format is plain text.

So, I agree with Sam; if we put this information in the spec, it should 
be much more compact, non-normative, and in an appendix or otherwise 
clearly delineated from normative content. However, if we collect more 
than just this, we should create a separate document -- a primer, if 
you like -- and move such content to it.

Cheers,


On Jul 10, 2004, at 5:33 AM, Sam Ruby wrote:

> Mark Nottingham wrote:
>> -1
>> This is great advice, but it restates a number of requirements in 
>> other specifications that are referred to by Atom. That's not good 
>> specification practice, as it very often results in conflicts of 
>> interpretation. Furthermore, this places a large number of 
>> requirements on "clients" that are difficult to test and constrain 
>> their behaviours in frankly unrealistic ways. Finally, many of the 
>> other requirements are made upon "publishers" -- an audience that 
>> almost assuredly will never read the Atom specification.
>> I strongly suggest this be moved to a primer, another non-normative 
>> document, or to WG-external supporting documentation.
>
> Lots of good specifications have informative notes when there are 
> relevant specifications that have specific requirements that need to 
> be aware of.
>
> I'm sure that many of these non-normative notes started out lenghty 
> before being boiled down to their essentials by repeated scrubbing.
>
> I'm quite OK with a non-normative note, and brevity whenever it does 
> not affect clarity is always a virtue, but I am not OK with leaving 
> the effort of finding the relevant specifications as an exercise left 
> for the student.  In producing the feedvalidator I have been 
> continually frustrated by vague specifications and contradictory and 
> non-authoritative clarifications.
>
> So: I strongly encourage that we continue to work towards the 
> placement of SOMETHING that attempts to address the problem this PACE 
> proports to solve in one of the documents produced by this workgroup.
>
> - Sam Ruby
>

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Sat Jul 10 13:18: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 NAA22881
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 13:18: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 i6AH5rWu004720;
	Sat, 10 Jul 2004 10:05:53 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6AH5rsr004719;
	Sat, 10 Jul 2004 10:05:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from 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 i6AH5rwT004712
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 10:05:53 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.18] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id D11FE727D; Sat, 10 Jul 2004 10:05:56 -0700 (PDT)
In-Reply-To: <40EFDCB8.6070902@intertwingly.net>
References: <200407091923.PAA23330@ietf.org> <878ydsubdi.fsf@nwalsh.com> <58709D28-D22E-11D8-9A61-000A95BD86C0@mnot.net> <40EFDCB8.6070902@intertwingly.net>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <685C5FB3-D293-11D8-9A61-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: atom-syntax@imc.org, Norman Walsh <ndw@nwalsh.com>
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: Editorial issues [was: Comments on I-D ACTION:draft-ietf-atompub-format-00.txt]
Date: Sat, 10 Jul 2004 10:05:56 -0700
To: Sam Ruby <rubys@intertwingly.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>
Content-Transfer-Encoding: 7bit


This was beat to death a long, long time ago, but I can't find the 
references. I'm also dissatisfied with the current language; IMHO we 
should just use W3CDateTime and be done with it.


On Jul 10, 2004, at 5:10 AM, Sam Ruby wrote:

> Mark Nottingham wrote:
>
>>> | 4.12  "atom:modified" Element
>>> |
>>> |    The "atom:modified" element is a Date construct that indicates 
>>> the
>>> |    time when the state of the feed was last modified, including any
>>> |    changes to entries therein.  atom:feed elements MUST contain 
>>> exactly
>>> |    one atom:modified element.
>>> |
>>> |    The content of an atom:modified element SHOULD have a time zone 
>>> whose
>>> |    value MUST be "UTC".
>>>
>>> Are "SHOULD" and "MUST" reversed in that sentence?
>> This isn't a mistake; i.e., AFAIK it reflects current consensus 
>> (although personally I don't agree with this approach).
>
> I'm not sure I can assess what the current consensus is, I can comment 
> on the original intent based on what the FeedValidator currently 
> implements:
>
> W3DTFDateNoTimezone is a Warning (will display, but will not cause a 
> feed to be marked as invalid)
>
> W3DTFDateNonUTC is Informational (and therefore by default does not 
> display)
>
> I would be comfortable with reversing the "SHOULD" and "MUST" in that 
> sentence.
>
> - Sam Ruby
>

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Sat Jul 10 13: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 NAA22966
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 13:23: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 i6AHA0cF005101;
	Sat, 10 Jul 2004 10:10: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 i6AHA0Oa005100;
	Sat, 10 Jul 2004 10:10:00 -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 i6AH9xAf005088
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 10:09:59 -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 i6AH9v53003458;
	Sat, 10 Jul 2004 12:09:57 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6AH9ufp003453;
	Sat, 10 Jul 2004 12:09:56 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: atom-syntax@imc.org
Cc: Norman Walsh <ndw@nwalsh.com>
Subject: Re: Embedding non-namespaced elements
References: <200407091923.PAA23330@ietf.org> <878ydsubdi.fsf@nwalsh.com>
	<14be96d3040709185954a33b28@mail.gmail.com>
	<87u0wgrtme.fsf@nwalsh.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 10 Jul 2004 12:09:56 -0500
In-Reply-To: <87u0wgrtme.fsf@nwalsh.com>
Message-ID: <m31xjjrdp7.fsf@bitsko.slc.ut.us>
Lines: 27
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


Norman Walsh <ndw@nwalsh.com> writes:

> By putting it in a container that tells the application it's
> DocBook.  Perhaps:
> 
>   <atom:content type="application/docbook+xml" xmlns="">
>     <para>Like this, for example.</para>
>   </atom:content>

Media types are applied to entity bodies as defined by their
respective specifications.  RFC3023, which DocBook makes reference to
in the encoding considerations of its [proposed?] media type
registration, refers to these as "document entities".

Do you consider the XML text within the atom:content element to be a
"document entity" in the same sense as the entity body of, say, HTTP
or MIME?  If not, what would be a "general profile" for XML fragments
that may appear inline of other document entities?

PaceSimpleContentType attempts to address this problem by removing the
media type indicator for inline XML content and requiring a registered
profile for fragments.  It contains a "general profile" for XML
fragments, but makes its determination based on the XML namespace of
the root element.  Obviously that wouldn't work in this case.
Suggestions?

  -- Ken



From owner-atom-syntax@mail.imc.org  Sat Jul 10 13:25: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 NAA23029
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 13:25: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 i6AH4wBe004652;
	Sat, 10 Jul 2004 10:04: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 i6AH4wka004651;
	Sat, 10 Jul 2004 10:04:58 -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 i6AH4wao004645
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 10:04:58 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.18] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id B0B14727D; Sat, 10 Jul 2004 10:05:01 -0700 (PDT)
In-Reply-To: <BD159541.120A1%mint@franklinmint.fm>
References: <BD159541.120A1%mint@franklinmint.fm>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <471DEDB2-D293-11D8-9A61-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: Atom Syntax <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: Re: What kinds of Atom documents are there?
Date: Sat, 10 Jul 2004 10:05:00 -0700
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>
Content-Transfer-Encoding: 7bit


On Jul 10, 2004, at 9:44 AM, Robert Sayre wrote:

> Would we need a new media type for it? For example, 
> application/docbook+xml
> has more than one possible document element, right?

I'm not aware of the situation of with docbook, but just because one 
format does it doesn't make it good practice.

If a document has a different format, a different syntax, a different 
processing model, and different use cases, and there are situations 
where you might want to negotiate for the different formats (e.g., 
allow people to GET either an entry or a list of entries from the same 
Web resource), it should have a different media type.


--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Sat Jul 10 13:46: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 NAA23523
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 13:46: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 i6AHVQ5x006531;
	Sat, 10 Jul 2004 10: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 i6AHVQ2X006530;
	Sat, 10 Jul 2004 10:31:26 -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 i6AHVP2F006521
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 10:31: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 i6AHVN53003832
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 12:31:24 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6AHVNNo003828;
	Sat, 10 Jul 2004 12:31:23 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: What kinds of Atom documents are there?
References: <01C0B4EA-D28C-11D8-9A61-000A95BD86C0@mnot.net>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 10 Jul 2004 12:31:23 -0500
In-Reply-To: <01C0B4EA-D28C-11D8-9A61-000A95BD86C0@mnot.net>
Message-ID: <m3wu1bpy50.fsf@bitsko.slc.ut.us>
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: <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> writes:

> So far, the format spec defines one kind of Atom document, that with
> the atom:feed root element.
> 
> In the -00 draft, a Pace was incorporated that hints that entries
> might be documents on their own; that is, we might have a document
> whose root element is atom:entry.
> 
> Did this slip by without serious consideration by the WG, or does it
> represent consensus?

PaceEntryTopLevel either borders or encompasses this, it looks like we
got crossed in the mail.

  -- Ken

PS. I'll followup on the "document type" issue to the replies already
in that direction.



From owner-atom-syntax@mail.imc.org  Sat Jul 10 14:11: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 OAA24184
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 14:11: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 i6AHnTWG007992;
	Sat, 10 Jul 2004 10:49:29 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6AHnT1S007991;
	Sat, 10 Jul 2004 10:49: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-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 i6AHnOJt007982
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 10:49:24 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i6AHlM53013379
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 11:47:22 -0600 (MDT)
Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0I0N002GFDIFEE@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sat, 10 Jul 2004 11:49:27 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0N00BC0DI8YS@mail.sun.net> for atom-syntax@imc.org; Sat,
 10 Jul 2004 11:49:27 -0600 (MDT)
Date: Sat, 10 Jul 2004 10:49:19 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: What kinds of Atom documents are there?
In-reply-to: <471DEDB2-D293-11D8-9A61-000A95BD86C0@mnot.net>
To: Mark Nottingham <mnot@mnot.net>
Cc: Atom Syntax <atom-syntax@imc.org>, Robert Sayre <mint@franklinmint.fm>
Message-id: <783A0632-D299-11D8-B2D0-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: <BD159541.120A1%mint@franklinmint.fm>
 <471DEDB2-D293-11D8-9A61-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 Jul 10, 2004, at 9:44 AM, Robert Sayre wrote:
>
>> Would we need a new media type for it? For example, 
>> application/docbook+xml
>> has more than one possible document element, right?

I think one media type is plenty.

On Jul 10, 2004, at 10:05 AM, Mark Nottingham wrote:

> I'm not aware of the situation of with docbook, but just because one 
> format does it doesn't make it good practice.
>
> If a document has a different format, a different syntax, a different 
> processing model, and different use cases, and there are situations 
> where you might want to negotiate for the different formats (e.g., 
> allow people to GET either an entry or a list of entries from the same 
> Web resource), it should have a different media type.

I see the argument, but on balance I still think one media type is 
fine.  The set of scenarios where you're looking for an <atom:feed> are 
quite disjoint from those where you're looking for an <atom:entry> -Tim



From owner-atom-syntax@mail.imc.org  Sat Jul 10 14: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 OAA24240
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 14:13: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 i6AHvnXp008649;
	Sat, 10 Jul 2004 10:57: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 i6AHvnhe008648;
	Sat, 10 Jul 2004 10:57: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 i6AHvmuG008641
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 10:57:48 -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 i6AHtl53014832
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 11:55:47 -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 <0I0N0086QDWFPS@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sat, 10 Jul 2004 11:57:52 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0N00BB7DWEZV@mail.sun.net> for atom-syntax@imc.org; Sat,
 10 Jul 2004 11:57:51 -0600 (MDT)
Date: Sat, 10 Jul 2004 10:57:50 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Craeted proposal: PaceProvideSchema
In-reply-to: <40F0184A.20702@virgilio.it>
To: danny666@virgilio.it
Cc: Atom Syntax <atom-syntax@imc.org>, Norman Walsh <ndw@nwalsh.com>
Message-id: <A8BE07A6-D29A-11D8-B2D0-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: <87eknkow28.fsf@nwalsh.com> <40F0184A.20702@virgilio.it>
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 Jul 10, 2004, at 9:24 AM, Danny Ayers wrote:

> Norman Walsh wrote:
>
>> This Pace supports my comment that a schema should be provided as part
>> of the Atom format spec. Concretely, I suggest that both a RELAX NG
>> grammar and a W3C XML Schema should be provided.
>
> I personally reckon it's almost certainly a good idea, but I don't 
> think convincing case has yet been made: what is the purpose of the 
> grammar/schema? The rationale in the Pace is that it will "aid 
> readers" - how so?

I think one normative schema (but two feels like overkill) would be 
immensely valuable, first of all because writing a schema is helpful in 
shaking out corner cases and making sure the verbal hand-waving 
actually captures clean clear syntax constraints.

> Another obvious question is: should every conformant Atom document be 
> valid against the schema?

Yes, but that doesn't mean you'd normally validate at run-time.  The 
value-add here is that when something breaks (as it will) the schema 
will help the parties sort out where the breakage is.  Exactly in the 
same way that web-page designers routinely validate their HTML when 
sorting out weird rendering breakage, but nobody validates HTML in 
production.

> A perhaps more interesting question is: will every schema-valid 
> document be a conformant Atom document?

Probably not, because there are going to be semantic constraints that a 
schema can say nothing about... e.g. are unique ID's really unique, 
globally?

> A possible scenario which might work with the latter is that the XML 
> Schema mandates the element order, but the spec prose doesn't.

That would be unacceptable, the schema and the prose have to be 
consistent. -Tim



From owner-atom-syntax@mail.imc.org  Sat Jul 10 14: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 OAA24432
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 14: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 i6AHwLwN008673;
	Sat, 10 Jul 2004 10: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 i6AHwLVe008672;
	Sat, 10 Jul 2004 10:58:21 -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 i6AHwLFp008665
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 10:58:21 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.18] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id CD264727D; Sat, 10 Jul 2004 10:58:24 -0700 (PDT)
In-Reply-To: <783A0632-D299-11D8-B2D0-000A95A51C9E@sun.com>
References: <BD159541.120A1%mint@franklinmint.fm> <471DEDB2-D293-11D8-9A61-000A95BD86C0@mnot.net> <783A0632-D299-11D8-B2D0-000A95A51C9E@sun.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <BC78F74C-D29A-11D8-9A61-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: Atom Syntax <atom-syntax@imc.org>, Robert Sayre <mint@franklinmint.fm>
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: What kinds of Atom documents are there?
Date: Sat, 10 Jul 2004 10:58:23 -0700
To: Tim Bray <Tim.Bray@Sun.COM>
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>
Content-Transfer-Encoding: 7bit


What's the cost of having a separate media type? Can we foresee all 
possible uses of the different document types, and be confident that 
there won't be a need to disambiguate between them when doing content 
negotiation, typing links, etc.?


On Jul 10, 2004, at 10:49 AM, Tim Bray wrote:

>
>>
>> On Jul 10, 2004, at 9:44 AM, Robert Sayre wrote:
>>
>>> Would we need a new media type for it? For example, 
>>> application/docbook+xml
>>> has more than one possible document element, right?
>
> I think one media type is plenty.
>
> On Jul 10, 2004, at 10:05 AM, Mark Nottingham wrote:
>
>> I'm not aware of the situation of with docbook, but just because one 
>> format does it doesn't make it good practice.
>>
>> If a document has a different format, a different syntax, a different 
>> processing model, and different use cases, and there are situations 
>> where you might want to negotiate for the different formats (e.g., 
>> allow people to GET either an entry or a list of entries from the 
>> same Web resource), it should have a different media type.
>
> I see the argument, but on balance I still think one media type is 
> fine.  The set of scenarios where you're looking for an <atom:feed> 
> are quite disjoint from those where you're looking for an <atom:entry> 
> -Tim
>

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Sat Jul 10 15:14: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 PAA27659
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 15: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 i6AJ03B1012467;
	Sat, 10 Jul 2004 12:00:03 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6AJ03Dq012466;
	Sat, 10 Jul 2004 12:00:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from 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 i6AJ011N012460
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 12:00: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 i6AJ05il003447
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 13:00:05 -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 <0I0N005LLGS4K7@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sat, 10 Jul 2004 13:00:05 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0N00BEOGS4RW@mail.sun.net> for atom-syntax@imc.org; Sat,
 10 Jul 2004 13:00:04 -0600 (MDT)
Date: Sat, 10 Jul 2004 12:00:04 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Craeted proposal: PaceProvideSchema
In-reply-to: <CBC76314-D2A1-11D8-9A61-000A95BD86C0@mnot.net>
To: Mark Nottingham <mnot@mnot.net>
Cc: Atom Syntax <atom-syntax@imc.org>, danny666@virgilio.it,
        Norman Walsh <ndw@nwalsh.com>
Message-id: <5A12CA80-D2A3-11D8-B2D0-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: <87eknkow28.fsf@nwalsh.com> <40F0184A.20702@virgilio.it>
 <A8BE07A6-D29A-11D8-B2D0-000A95A51C9E@sun.com>
 <CBC76314-D2A1-11D8-9A61-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 Jul 10, 2004, at 11:48 AM, Mark Nottingham wrote:

>> That would be unacceptable, the schema and the prose have to be 
>> consistent. -Tim
>
> In practice, that's tricky to achieve.

I disagree.  The syntax constraints you express in the schema are a 
small, tractable subset of the general constraints that appear in the 
prose.

> In other words, if there are requirements buried in the schema, they 
> have to be reflected in the prose; we can't rely on the schema alone 
> to state them.

Agreed.  But, that's orthogonal to whether the schema is normative. -Tim



From owner-atom-syntax@mail.imc.org  Sat Jul 10 15:20: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 PAA28410
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 15:20:59 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6AImrXs011911;
	Sat, 10 Jul 2004 11: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 i6AImrf5011910;
	Sat, 10 Jul 2004 11:48:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.mnot.net (adsl-67-119-69-242.dsl.sntc01.pacbell.net [67.119.69.242])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6AImq54011904
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 11:48:52 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.18] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id E8831727D; Sat, 10 Jul 2004 11:48:56 -0700 (PDT)
In-Reply-To: <A8BE07A6-D29A-11D8-B2D0-000A95A51C9E@sun.com>
References: <87eknkow28.fsf@nwalsh.com> <40F0184A.20702@virgilio.it> <A8BE07A6-D29A-11D8-B2D0-000A95A51C9E@sun.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <CBC76314-D2A1-11D8-9A61-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: Atom Syntax <atom-syntax@imc.org>, danny666@virgilio.it,
        Norman Walsh <ndw@nwalsh.com>
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: Craeted proposal: PaceProvideSchema
Date: Sat, 10 Jul 2004 11:48:55 -0700
To: Tim Bray <Tim.Bray@Sun.COM>
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>
Content-Transfer-Encoding: 7bit



On Jul 10, 2004, at 10:57 AM, Tim Bray wrote:
> I think one normative schema (but two feels like overkill) would be 
> immensely valuable, first of all because writing a schema is helpful 
> in shaking out corner cases and making sure the verbal hand-waving 
> actually captures clean clear syntax constraints.

What happens when the schema and the prose requirements conflict?

>> A possible scenario which might work with the latter is that the XML 
>> Schema mandates the element order, but the spec prose doesn't.
>
> That would be unacceptable, the schema and the prose have to be 
> consistent. -Tim

In practice, that's tricky to achieve.

My inclination would be to make the schema non-normative. In other 
words, if there are requirements buried in the schema, they have to be 
reflected in the prose; we can't rely on the schema alone to state 
them.

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Sat Jul 10 15:37: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 PAA28884
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 15:37: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 i6AJPjaB014438;
	Sat, 10 Jul 2004 12:25: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 i6AJPjfG014437;
	Sat, 10 Jul 2004 12:25:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mta01-svc.ntlworld.com (mta01-svc.ntlworld.com [62.253.162.41])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6AJPip4014410
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 12:25:45 -0700 (PDT)
	(envelope-from djpowell@djpowell.net)
Received: from cpc2-stke1-5-0-cust190.bagu.cable.ntl.com ([81.111.201.190])
          by mta01-svc.ntlworld.com
          (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP
          id <20040710192511.HLQJ9716.mta01-svc.ntlworld.com@cpc2-stke1-5-0-cust190.bagu.cable.ntl.com>;
          Sat, 10 Jul 2004 20:25:11 +0100
Date: Sat, 10 Jul 2004 20:25:43 +0100
From: David Powell <djpowell@djpowell.net>
X-Mailer: The Bat! (v2.12 Beta/7) Business
Reply-To: David Powell <djpowell@djpowell.net>
X-Priority: 3 (Normal)
Message-ID: <1611181900.20040710202543@djpowell.net>
To: Norman Walsh <ndw@nwalsh.com>
CC: atom-syntax@imc.org
Subject: Re: MUST be UTC?
In-Reply-To: <87smc0qcnk.fsf@nwalsh.com>
References: <87smc0qcnk.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: <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


Saturday, July 10, 2004, 1:17:51 PM, ndw@nwalsh.com wrote:

> On the subject of time zones, is it really necessary to use UTC? How is
> "2004-07-08T07:11:53-04:00" really worse than "2004-07-08T11:11:53Z"?
> I can understand not using forms like "2004-07-08T07:11:53EDT" but I'd
> like the freedom to use the numeric forms.

When you convert a date to UTC you are throwing information away.  It
is no longer possible to convert this back to the publishers local
time.  I assume that the reason for wanting to do this is if this
field is purely for machine/administrative use, and is not normally
displayed to a user.  Saying that the date MUST be in UTC makes it
a lot easier to sort feeds, produce aggregated feeds using XSLT, and
synchronize entries between feeds, because you can just do a string
sort.

If you want to display dates to a user then it is better to store them
in the publisher's local time with a timezone offset. This lets you
keep the time in the publishers local time if you want.


To me the current model seems to assume that atom:created and
atom:modified are for machine use, and that is why UTC is required.
Whereas atom:issued is for human display, and that is why local time
is preferred.

If atom:created and atom:modified are only for machine use, then
atom:issued starts to look a bit weak. If there can only be one
atom:issued, then tools will need to rely on atom:created and
atom:modified to find out about the entry's publishing history. But we
have already weakened these by throwing away their timezone offset...


I would prefer it if:

* There was exactly one atom:created and UTC was a MUST. This would be
the date that an entry was first created, and would not normally be
displayed.

* There was zero or one atom:modified and UTC was a MUST. This would be
the date that an entry was last changed, and would not normally be
displayed.

* There was an ordered list of atom:issued, and localtime + timezone
SHOULD be used. This would be the date that an entry was first posted
and the dates that the entry was updated, so it would be the human
displayable equivalent of the machine optimized atom:created and
atom:modified fields.


If atom:issued doesn't provide a timezone then no timezone should be
assumed. A lot of mobile clients don't know what timezone they are in,
it is wrong for the server to guess randomly, the server should just
display the time without a timezone. I don't see the need to perform
comparison operations on atom:issued - that is what atom:created and
atom:modified are for.



-- 
Dave



From owner-atom-syntax@mail.imc.org  Sat Jul 10 15:40:28 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28975
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 15:40:27 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6AJMJiP014180;
	Sat, 10 Jul 2004 12:22: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 i6AJMJUY014179;
	Sat, 10 Jul 2004 12:22:19 -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 i6AJMI5x014173
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 12:22:18 -0700 (PDT)
	(envelope-from distobj@acm.org)
Received: from mbaker by bork.markbaker.ca with local (Exim 3.35 #1 (Debian))
	id 1BjNQy-0007YH-00
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 15:22:52 -0400
Date: Sat, 10 Jul 2004 15:22:52 -0400
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: What kinds of Atom documents are there?
Message-ID: <20040710192251.GP30868@markbaker.ca>
References: <BD159541.120A1%mint@franklinmint.fm> <471DEDB2-D293-11D8-9A61-000A95BD86C0@mnot.net> <783A0632-D299-11D8-B2D0-000A95A51C9E@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <783A0632-D299-11D8-B2D0-000A95A51C9E@sun.com>
User-Agent: Mutt/1.3.28i
From: Mark Baker <distobj@acm.org>
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 Sat, Jul 10, 2004 at 10:49:19AM -0700, Tim Bray wrote:
> >On Jul 10, 2004, at 9:44 AM, Robert Sayre wrote:
> >
> >>Would we need a new media type for it? For example, 
> >>application/docbook+xml
> >>has more than one possible document element, right?
> 
> I think one media type is plenty.

Mark.
--
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

  Seeking work on large scale application/data integration projects
  and/or the enabling infrastructure for same.



From owner-atom-syntax@mail.imc.org  Sat Jul 10 16:15: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 QAA00023
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 16:15: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 i6AK1WKM016600;
	Sat, 10 Jul 2004 13:01: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 i6AK1Wrs016599;
	Sat, 10 Jul 2004 13:01:32 -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 i6AK1VZZ016593
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 13:01:31 -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 i6AJxU53006977
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 13:59:30 -0600 (MDT)
Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0I0N0053ZJMNK7@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sat, 10 Jul 2004 14:01:35 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0N00BFLJMMYS@mail.sun.net> for atom-syntax@imc.org; Sat,
 10 Jul 2004 14:01:35 -0600 (MDT)
Date: Sat, 10 Jul 2004 13:01:34 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: PaceElementOrder: options
In-reply-to: <87smc0ownv.fsf@nwalsh.com>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <F1AC0C56-D2AB-11D8-B2D0-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: <97774BF0-D096-11D8-B2D0-000A95A51C9E@sun.com>
 <F3C7FAC8-D233-11D8-9A61-000A95BD86C0@mnot.net> <87smc0ownv.fsf@nwalsh.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


So, it seems like we have the following options on this:

1. Do nothing, no rules about ordering
2. Require all the feed-level elements appear before the <atom:entry> 
elements
3. #2, but have an <atom:feed-info> to contain all that stuff.  Thus the
    content-model of <atom:feed> becomes
    atom:feed-info, atom:entry+
4. Require a specific ordering for all the elements.

Until #3 came along, I'd have said that the general leaning was to #2; 
there was no support voiced for #1 and not much for #4.  Now would be a 
good time to prove me wrong by speaking up for #1 or #4, or point out 
why one of #2 or #3 is better than the other.  -Tim



From owner-atom-syntax@mail.imc.org  Sat Jul 10 16:52:30 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01083
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 16:52:29 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6AKYQ9e018229;
	Sat, 10 Jul 2004 13:34: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 i6AKYQnH018228;
	Sat, 10 Jul 2004 13:34:26 -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 i6AKYPVI018215
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 13:34:25 -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 i6AKYO53006742
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 15:34:24 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6AKYOn1006737;
	Sat, 10 Jul 2004 15:34:24 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceElementOrder: options
References: <97774BF0-D096-11D8-B2D0-000A95A51C9E@sun.com>
	<F3C7FAC8-D233-11D8-9A61-000A95BD86C0@mnot.net>
	<87smc0ownv.fsf@nwalsh.com>
	<F1AC0C56-D2AB-11D8-B2D0-000A95A51C9E@sun.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 10 Jul 2004 15:34:24 -0500
In-Reply-To: <F1AC0C56-D2AB-11D8-B2D0-000A95A51C9E@sun.com>
Message-ID: <m3r7rjppnz.fsf@bitsko.slc.ut.us>
Lines: 42
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: <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> writes:

> So, it seems like we have the following options on this:
> 
> 1. Do nothing, no rules about ordering
> 2. Require all the feed-level elements appear before the <atom:entry>
> elements
> 3. #2, but have an <atom:feed-info> to contain all that stuff.  Thus the
>     content-model of <atom:feed> becomes
>     atom:feed-info, atom:entry+
> 4. Require a specific ordering for all the elements.
> 
> Until #3 came along, I'd have said that the general leaning was to
> #2; there was no support voiced for #1 and not much for #4.  Now
> would be a good time to prove me wrong by speaking up for #1 or #4,
> or point out why one of #2 or #3 is better than the other.  -Tim

With #3, see also the suggestion for the <site> element, that also
provides a solution for "replicating" the feed information in
synthetic feeds and indexes,

  http://imc.org/atom-syntax/mail-archive/msg06355.html

Alas, there is still metadata in the "protocol feed" (which is now
different from "a logical feed that is also a site").  Note still that
people using stream parsers would also still like the referenced
elements to come before the referencing elements.

Bob Wyman follows this to its inevitable conclusion in

  http://imc.org/atom-syntax/mail-archive/msg06380.html

Which implies creating new solutions, such as an extension mechanism
that indicates which metadata elements should be replicated (to
prevent server pounding outside of an explicit user action) and which
elements should be hosted at the origin server (because there's lots
more in the origin resource).  PaceSimplifiedFeedFormat does this for
entries, for example.

I'm for exploring #3 and fleshing out its issues.

  -- Ken



From owner-atom-syntax@mail.imc.org  Sat Jul 10 17:24:37 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01811
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 17:24: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 i6AL4vna020489;
	Sat, 10 Jul 2004 14:04: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 i6AL4vB6020488;
	Sat, 10 Jul 2004 14:04: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 i6AL4vNn020473
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 14:04: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 <2004071021045301200hqd0ie>; Sat, 10 Jul 2004 21:04:54 +0000
Date: Sat, 10 Jul 2004 15:04:52 -0600
Subject: Re: MUST be UTC?
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: <1611181900.20040710202543@djpowell.net>
Message-Id: <C9936AC4-D2B4-11D8-A6B6-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, July 10, 2004, at 01:25  PM, David Powell wrote:
> Saying that the date MUST be in UTC makes it
> a lot easier to sort feeds, produce aggregated feeds using XSLT, and
> synchronize entries between feeds, because you can just do a string
> sort.
This is the first argument in favor of requiring (or encouraging) UTC 
that is at all convincing to me.  Still, I would prefer to be able to 
use my local timezone.  If some piece of software wants to have 
everything in the same timezone, it can do the conversion and store the 
data in it's preferred format.  Of course the timezone won't always 
correctly reflect where the author was, but I don't think that's enough 
reason to mandate always converting to UTC.

> To me the current model seems to assume that atom:created and
> atom:modified are for machine use, and that is why UTC is required.
> Whereas atom:issued is for human display, and that is why local time
> is preferred.
Good issues to consider, though I'm not sure I agree.  Let's nail these 
issues down when PaceEntryDates[1] comes up for discussion.  Once we 
know, and agree on, what each of the date elements really means, we'll 
have a basis for deciding requirements for each.

Antone

[1] http://www.intertwingly.net/wiki/pie/PaceEntryDates



From owner-atom-syntax@mail.imc.org  Sat Jul 10 18:01:50 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02601
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 18:01:49 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ALaSq8022296;
	Sat, 10 Jul 2004 14:36: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 i6ALaSsR022295;
	Sat, 10 Jul 2004 14:36:28 -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 i6ALaSxH022287
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 14:36:28 -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 <2004071021362501300j2inve>; Sat, 10 Jul 2004 21:36:25 +0000
Date: Sat, 10 Jul 2004 15:36:24 -0600
Subject: Re: PaceElementOrder: options
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: <m3r7rjppnz.fsf@bitsko.slc.ut.us>
Message-Id: <3120253F-D2B9-11D8-A6B6-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, July 10, 2004, at 02:34  PM, Ken MacLeod wrote:
> Tim Bray <Tim.Bray@Sun.COM> writes:
...
>> 1. Do nothing, no rules about ordering
>> 2. Require all the feed-level elements appear before the <atom:entry>
>> elements
>> 3. #2, but have an <atom:feed-info> to contain all that stuff.  Thus 
>> the
>>     content-model of <atom:feed> becomes
>>     atom:feed-info, atom:entry+
>> 4. Require a specific ordering for all the elements.
-1 on #1 and #4.  I lean towards #2, but a little voice in my head is 
whispering that we might find some real benefits in #3.  I'd be 
interested in exploring what those might be.

> With #3, see also the suggestion for the <site> element, that also
> provides a solution for "replicating" the feed information in
> synthetic feeds and indexes,
>
>   http://imc.org/atom-syntax/mail-archive/msg06355.html
>
> Alas, there is still metadata in the "protocol feed" (which is now
> different from "a logical feed that is also a site").  Note still that
> people using stream parsers would also still like the referenced
> elements to come before the referencing elements.
+1 on ensuring that ordering doesn't cause headaches for stream 
parsers.  I don't think there's any reason NOT to have the minimal 
ordering requirements to help with stream processing.

> Bob Wyman follows this to its inevitable conclusion in
>
>   http://imc.org/atom-syntax/mail-archive/msg06380.html
This message expresses my main concern with #3.  I am very much in 
favor of keeping feeds self-contained to the extent that, for example,  
an HTML representation could be made of the feed without having to 
fetch any external data. Things like images that would be referenced by 
an HTML document, but not actually included inside it, can be external. 
And references by extensions or <link> (or its successors?) to external 
resources are fine. But elements that are part of the Atom 
core--CERTAINLY all required elements, should carry their data in the 
feed itself.

If we can reap benefits from #3 while drawing a firm line against that 
evolving into a situation where feed-level metadata is stored outside 
of the feed, then that sounds good.

Antone



From owner-atom-syntax@mail.imc.org  Sat Jul 10 18: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 SAA03336
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 18: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 i6ALu8lh023987;
	Sat, 10 Jul 2004 14:56: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 i6ALu8x7023986;
	Sat, 10 Jul 2004 14:56:08 -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 i6ALu7FJ023980
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 14:56:07 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.18] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id D71D2727D; Sat, 10 Jul 2004 14:56:12 -0700 (PDT)
In-Reply-To: <F1AC0C56-D2AB-11D8-B2D0-000A95A51C9E@sun.com>
References: <97774BF0-D096-11D8-B2D0-000A95A51C9E@sun.com> <F3C7FAC8-D233-11D8-9A61-000A95BD86C0@mnot.net> <87smc0ownv.fsf@nwalsh.com> <F1AC0C56-D2AB-11D8-B2D0-000A95A51C9E@sun.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <F47D290F-D2BB-11D8-9A61-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: Atom Syntax <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: Disambiguating the subject of feed-level metadata
Date: Sat, 10 Jul 2004 14:56:10 -0700
To: Tim Bray <Tim.Bray@Sun.COM>
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>
Content-Transfer-Encoding: 7bit


This tangentially brings up something that I've been musing on for a 
while.

It seems to me that some feed-level metadata are really "defaults" for 
entries in the feed; that is, they filter down into the feed entries 
unless that entry has more specific information.

Current examples of this are atom:author and atom:contributor.

Another kind of feed-level metadata is about the whole feed itself, not 
the entries in the current Atom document. For example, if I update 
atom:title on a feed, that's the title for the whole feed, including 
all previously seen entries.

Contrast this with the defaulting mechanism, which applies to just the 
entries in the current Atom document, not previously seen ones.

This leads me to believe that there may be some value in separating 
feed-wide metadata with entry defaults, in a manner something like 
this:

<feed>
     <feed-info>
         ...
     </feed-info>
     <entry-defaults>
        ...
     </entry-defaults>
     <entry>
        ...
     </entry>
     ...
</feed>

Another approach would be to specify an attribute that can be used on 
all extensions to clarify this, e.g.:

<feed>
     <author atom:entryDefault="1">
        ...
     </author>
     ...
</feed>

Ideally, such an attribute would be crafted so that it could say that 
the metadata applied just to the feed, just as a default for entries, 
or both.

Either approach would make the separation between these kinds of 
metadata much more specific, and remove the need for entry-level 
metadata to be re-specified at the feed level if it's defaulted.

The acid test for this is whether we can see extensions using such a 
mechanism; if people thought it would prove useful, it would be worth 
the additional
mechanism.

Thoughts?


On Jul 10, 2004, at 1:01 PM, Tim Bray wrote:

>
> So, it seems like we have the following options on this:
>
> 1. Do nothing, no rules about ordering
> 2. Require all the feed-level elements appear before the <atom:entry> 
> elements
> 3. #2, but have an <atom:feed-info> to contain all that stuff.  Thus 
> the
>    content-model of <atom:feed> becomes
>    atom:feed-info, atom:entry+
> 4. Require a specific ordering for all the elements.
>
> Until #3 came along, I'd have said that the general leaning was to #2; 
> there was no support voiced for #1 and not much for #4.  Now would be 
> a good time to prove me wrong by speaking up for #1 or #4, or point 
> out why one of #2 or #3 is better than the other.  -Tim
>

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Sat Jul 10 18:27: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 SAA04536
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 18:27: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 i6AMEoub024653;
	Sat, 10 Jul 2004 15:14: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 i6AMEojf024652;
	Sat, 10 Jul 2004 15:14:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf16.cluster1.charter.net (mxsf16.cluster1.charter.net [209.225.28.216])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6AMEnGa024645
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 15:14:49 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip12.cluster1.charter.net (mxip12a.cluster1.charter.net [209.225.28.142])
	by mxsf16.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6AMHpRq012158
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 18:17:51 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip12.cluster1.charter.net with ESMTP; 10 Jul 2004 18:14:46 -0400
X-Ironport-AV: i="3.81R,160,1083556800"; 
   d="scan'208"; a="108727340:sNHT14426376"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BjQ78-0006GJ-00
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 18:14:34 -0400
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Serialization matters
References: <20040710163330.6078.qmail@web41208.mail.yahoo.com>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Sat, 10 Jul 2004 18:14:32 -0400
In-Reply-To: <20040710163330.6078.qmail@web41208.mail.yahoo.com> (Dare
 Obasanjo's message of "Sat, 10 Jul 2004 09:33:30 -0700 (PDT)")
Message-ID: <873c3zpl13.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: <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-Type: text/plain

/ Dare Obasanjo <kpako@yahoo.com> was heard to say:
| How does Atom prevent Ethopic blogs from being
| syndicated? XML 1.0 can have Ethopic content just
| fine, just not Ethopic element and attribute names.
| Given that an Ethopic blogger will have to use suck it
| up and deal with English element names for the Atom
| namespaced elements and attributes as well as the HTML
| they are using to publish on the Web I'm not sure why
| they are any more disenfranchised by Atom. 

You are absolutely correct. I still think it would be reasonable to
allow XML 1.0 and its successors, but my argument about Ethiopic
dramatically overstated the case. Requiring XML 1.0 serialization
would only forbid the creation of extensions to Atom that used
Ethiopic element or attribute names, not the syndication of Ethiopic
content.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | "Abstraction, abstraction and
http://nwalsh.com/            | abstraction." This is the answer to the
                              | question, "What are the three most
                              | important words in programming?"--Paul
                              | Hudak

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA8GpKOyltUcwYWjsRAu3BAJ0f/9onSxno1V/KJ2evT06/wRSDcwCdFP6S
FNPGtrTKM+O+8MKCtDkp28Y=
=bRxZ
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Sat Jul 10 19:11: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 TAA06280
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 19:11: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 i6AMrWVP026519;
	Sat, 10 Jul 2004 15:53: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 i6AMrW6M026518;
	Sat, 10 Jul 2004 15:53: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 ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6AMrR9F026512
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 15:53: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 E73CB7C117; Sun, 11 Jul 2004 01:51:56 +0200 (CEST)
To: "Mark Nottingham" <mnot@mnot.net>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Proposal: PaceSyntaxGuidelines
References: <opr99igudbuvpchu@quark> <9784AD46-D236-11D8-9A61-000A95BD86C0@mnot.net>
Message-ID: <opsax10rxpuvpchu@quark>
Date: Sun, 11 Jul 2004 00:56:41 +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: <9784AD46-D236-11D8-9A61-000A95BD86C0@mnot.net>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 9 Jul 2004 23:01:31 -0700, Mark Nottingham <mnot@mnot.net> wrote:

> Can we hold off on this one until we've solidified what the format and  
> protocol are first?

No one is refusing anyone from creating a future pace to fix the  
potentially errors in this guideline. It's just the same as with the  
<link> discussion. We can't halt all movement just because we haven't  
figured out if <link rel="something" href="..."> is supposed to be  
<something href="..."> or not. We specify link constructs as being a  
<link> element until that discussion has reached some kind of consensus.

The same goes for this guideline. It fits the current format  
specification, and is bound to change when the format changes. I don't see  
what pausing the guidelines until the format is done would help anything.

> Even then, I'm not sure it's a great idea to put purely stylistic naming
> conventions into the spec...

Is it a problem that the guidelines are purely stylistic? There's nothing  
stopping anyone from creating a non-stylistic section about extending Atom.

-- 
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 Jul 10 19:13:47 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06457
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 19:13: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 i6AMvjXK026690;
	Sat, 10 Jul 2004 15: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 i6AMvjhr026689;
	Sat, 10 Jul 2004 15:57: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 i6AMviBC026678
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 15:57: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 557FA7C117; Sun, 11 Jul 2004 01:56:19 +0200 (CEST)
To: "Norman Walsh" <ndw@nwalsh.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: MUST be UTC?
References: <87smc0qcnk.fsf@nwalsh.com>
Message-ID: <opsax172x5uvpchu@quark>
Date: Sun, 11 Jul 2004 01:01:04 +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: <87smc0qcnk.fsf@nwalsh.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 10 Jul 2004 08:17:51 -0400, Norman Walsh <ndw@nwalsh.com> wrote:

> On the subject of time zones, is it really necessary to use UTC? How is
> "2004-07-08T07:11:53-04:00" really worse than "2004-07-08T11:11:53Z"?

MSDN has a really good article that explains a lot of this, which is not  
only tied to the .NET framework:

<url:  
http://msdn.microsoft.com/library/en-us/dndotnet/html/datetimecode.asp>

-- 
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 Jul 10 19:16:11 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06565
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 19:16:10 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6AN3RCS027037;
	Sat, 10 Jul 2004 16:03: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 i6AN3Ree027036;
	Sat, 10 Jul 2004 16:03: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 i6AN3QAH027029
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 16:03: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 CFB647C117; Sun, 11 Jul 2004 02:02:00 +0200 (CEST)
Date: Sun, 11 Jul 2004 01:06:47 +0200
To: danny666@virgilio.it
Subject: Re: Craeted proposal: PaceProvideSchema
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <87eknkow28.fsf@nwalsh.com> <40F0184A.20702@virgilio.it>
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: <opsax2hlyluvpchu@quark>
In-Reply-To: <40F0184A.20702@virgilio.it>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 10 Jul 2004 18:24:42 +0200, Danny Ayers <danny666@virgilio.it>  
wrote:

> I personally reckon it's almost certainly a good idea, but I don't think  
> convincing case has yet been made: what is the purpose of the  
> grammar/schema? The rationale in the Pace is that it will "aid readers"  
> - how so?

It would make it a thousand times simpler for e.g. me to write my own Atom  
consumer and producer tool. Afaik, there are a lot of home-grown  
syndaction tools out there. A normative schema would help the creators of  
those to make a better tool. That is a big +1 in my humble opinion.

> Another obvious question is: should every conformant Atom document be  
> valid against the schema?

Valid: yes, validated every second: no.

> A perhaps more interesting question is: will every schema-valid document  
> be a conformant Atom document?

Hopefully. But I guess XSD at least isn't powerful enough to express all  
the quirks of Atom. Those quirks will, should I think, be edge cases for  
producers or consumers to wound up in.

-- 
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 Jul 10 19:19: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 TAA06641
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 19:19: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 i6AN1wao026985;
	Sat, 10 Jul 2004 16: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 i6AN1woX026984;
	Sat, 10 Jul 2004 16:01:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail4.edisontel.com (mail4.edisontel.com [62.94.0.37])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6AN1v2w026967
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 16:01:57 -0700 (PDT)
	(envelope-from danny666@virgilio.it)
Received: from virgilio.it (62.94.195.92) by mail4.edisontel.com (7.0.024)
        id 3FB4847C0092C6DD; Sun, 11 Jul 2004 01:01:55 +0200
Message-ID: <40F074E7.9040502@virgilio.it>
Date: Sun, 11 Jul 2004 00:59:51 +0200
From: Danny Ayers <danny666@virgilio.it>
Reply-To: danny666@virgilio.it
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
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: PaceElementOrder: options
References: <97774BF0-D096-11D8-B2D0-000A95A51C9E@sun.com> <F3C7FAC8-D233-11D8-9A61-000A95BD86C0@mnot.net> <87smc0ownv.fsf@nwalsh.com> <F1AC0C56-D2AB-11D8-B2D0-000A95A51C9E@sun.com>
In-Reply-To: <F1AC0C56-D2AB-11D8-B2D0-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


Some questions, starting with the biggy:

Why order the elements?

It may be useful to describe the possible benefits of ordering, and 
seeing how well each option provides those benefits.

Would an order make any significant difference to an application?

How useful is it to have feed-level metadata up front? Are incomplete 
parsing/readings likely?

Would it make any significant difference to the XML processor?

If not, in what respect is the format underconstrained? (That's the only 
rationale given in the Pace).

If there is to be a specific ordering, what should it be?

Tim Bray wrote:

>
> So, it seems like we have the following options on this:
>
> 1. Do nothing, no rules about ordering
> 2. Require all the feed-level elements appear before the <atom:entry> 
> elements
> 3. #2, but have an <atom:feed-info> to contain all that stuff.  Thus the
>    content-model of <atom:feed> becomes
>    atom:feed-info, atom:entry+
> 4. Require a specific ordering for all the elements.
>
> Until #3 came along, I'd have said that the general leaning was to #2; 
> there was no support voiced for #1 and not much for #4.  Now would be 
> a good time to prove me wrong by speaking up for #1 or #4, or point 
> out why one of #2 or #3 is better than the other.  -Tim


A variant on 3. would be an <atom:entries> container. Which is drifting 
towards head/body - a good thing or not?

Cheers,
Danny.

-- 

Raw
http://dannyayers.com



From owner-atom-syntax@mail.imc.org  Sat Jul 10 19:55:13 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07774
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 19:55:12 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ANgA1S030080;
	Sat, 10 Jul 2004 16:42:10 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6ANgApK030079;
	Sat, 10 Jul 2004 16:42: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 i6ANg9WE030073
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 16:42:10 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.18] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id 8D336727D; Sat, 10 Jul 2004 16:42:15 -0700 (PDT)
In-Reply-To: <opsax10rxpuvpchu@quark>
References: <opr99igudbuvpchu@quark> <9784AD46-D236-11D8-9A61-000A95BD86C0@mnot.net> <opsax10rxpuvpchu@quark>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <C4EBE4F8-D2CA-11D8-9A61-000A95BD86C0@mnot.net>
Cc: Atom-Syntax <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: Re: Proposal: PaceSyntaxGuidelines
Date: Sat, 10 Jul 2004 16:42:13 -0700
To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
X-Mailer: Apple Mail (2.618)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6ANgAWE030074
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 Jul 10, 2004, at 3:56 PM, Asbjørn Ulsberg wrote:

> On Fri, 9 Jul 2004 23:01:31 -0700, Mark Nottingham <mnot@mnot.net> 
> wrote:
>
>> Can we hold off on this one until we've solidified what the format 
>> and protocol are first?
>
> No one is refusing anyone from creating a future pace to fix the 
> potentially errors in this guideline. It's just the same as with the 
> <link> discussion. We can't halt all movement just because we haven't 
> figured out if <link rel="something" href="..."> is supposed to be 
> <something href="..."> or not. We specify link constructs as being a 
> <link> element until that discussion has reached some kind of 
> consensus.
>
> The same goes for this guideline. It fits the current format 
> specification, and is bound to change when the format changes. I don't 
> see what pausing the guidelines until the format is done would help 
> anything.

>> Even then, I'm not sure it's a great idea to put purely stylistic 
>> naming
>> conventions into the spec...
>
> Is it a problem that the guidelines are purely stylistic? There's 
> nothing stopping anyone from creating a non-stylistic section about 
> extending Atom.

Let me be clear. I'm not convinced that this is useful material to 
include in the specification. Furthermore,  attempting to improve it to 
sufficient quality will distract from the technical work we're 
undertaking now, and I don't see how this information actually improves 
the specification, the quality of Atom extensions, or the 
interoperability of implementations.

That isn't to say that it doesn't have its uses; it may be perfectly 
suitable material for inclusion in a primer, style guide or 
explanatory, non-WG article. It's just that it's extraneous to the 
specification itself. Does HTTP give style guides for naming new HTTP 
headers? HTML for extension attributes?

--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org  Sat Jul 10 20:04:10 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08128
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 20:04:10 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ANoraX030498;
	Sat, 10 Jul 2004 16:50: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 i6ANorDZ030497;
	Sat, 10 Jul 2004 16:50:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.mnot.net (adsl-67-119-69-242.dsl.sntc01.pacbell.net [67.119.69.242])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ANoqFE030490
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 16:50:52 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.18] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id ED9C5727D; Sat, 10 Jul 2004 16:50:57 -0700 (PDT)
In-Reply-To: <5A12CA80-D2A3-11D8-B2D0-000A95A51C9E@sun.com>
References: <87eknkow28.fsf@nwalsh.com> <40F0184A.20702@virgilio.it> <A8BE07A6-D29A-11D8-B2D0-000A95A51C9E@sun.com> <CBC76314-D2A1-11D8-9A61-000A95BD86C0@mnot.net> <5A12CA80-D2A3-11D8-B2D0-000A95A51C9E@sun.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <FC7F988C-D2CB-11D8-9A61-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: Atom Syntax <atom-syntax@imc.org>, danny666@virgilio.it,
        Norman Walsh <ndw@nwalsh.com>
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: Craeted proposal: PaceProvideSchema
Date: Sat, 10 Jul 2004 16:50:56 -0700
To: Tim Bray <Tim.Bray@Sun.COM>
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>
Content-Transfer-Encoding: 7bit



On Jul 10, 2004, at 12:00 PM, Tim Bray wrote:

> On Jul 10, 2004, at 11:48 AM, Mark Nottingham wrote:
>
>>> That would be unacceptable, the schema and the prose have to be 
>>> consistent. -Tim
>>
>> In practice, that's tricky to achieve.
>
> I disagree.  The syntax constraints you express in the schema are a 
> small, tractable subset of the general constraints that appear in the 
> prose.

I predict that it will be very difficult to have a one-to-one 
relationship between the constraints in an XML Schema and prose, and 
furthermore, that small differences and ambiguities between them will 
conflict despite our best efforts. This will lead to a long period of 
sorting out conflicting normative statements in the prose and schema, 
and errata releases of the specification after we've thought it final.

Specifying something twice is not a good idea; if you give people two 
different readings of a constraint, they'll pick one and ignore the 
other.

Since people seem to feel strongly about making the schema as well as 
the prose normative, let's take a look at them after the next round of 
drafts and see where this approach gets us. If we find ourselves 
sinking significant resources into aligning them, however, I'd ask that 
we reconsider such a decision.

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Sat Jul 10 20:17: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 UAA08465
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 20:17: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 i6B06aJg031809;
	Sat, 10 Jul 2004 17: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 i6B06aoR031808;
	Sat, 10 Jul 2004 17:06:36 -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 i6B06aWK031801
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 17:06:36 -0700 (PDT)
	(envelope-from wkearney@syndic8.com)
Received: (qmail 437 invoked from network); 11 Jul 2004 00:06:39 -0000
Received: from xbox.wkearney.com (HELO media) ([66.92.145.79])
          (envelope-sender <wkearney@syndic8.com>)
          by mail1.speakeasy.net (qmail-ldap-1.03) with SMTP
          for <djpowell@djpowell.net>; 11 Jul 2004 00:06:39 -0000
Message-ID: <02a501c466da$f05d5a50$200ca8c0@wkearney.com>
From: "Bill Kearney" <wkearney@syndic8.com>
To: "David Powell" <djpowell@djpowell.net>, "Norman Walsh" <ndw@nwalsh.com>
Cc: <atom-syntax@imc.org>
References: <87smc0qcnk.fsf@nwalsh.com> <1611181900.20040710202543@djpowell.net>
Subject: Re: MUST be UTC?
Date: Sat, 10 Jul 2004 20:06:33 -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.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
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


> When you convert a date to UTC you are throwing information away.  It
> is no longer possible to convert this back to the publishers local
> time.

The timestamp is indeed the "same instant in time"  You're only throwing away
what "offset" was used to state the time.  But that value is likely to be wrong
in more than a few cases.  If my home base is on the East coast US and I post to
a server in France while on a plane over Tokyo, what time is it?  In UTC it's
one and only one time.  WHERE I was at that instant is a different issue.
Timezones ARE NOT GEO DATA.

> If you want to display dates to a user then it is better to store them
> in the publisher's local time with a timezone offset. This lets you
> keep the time in the publishers local time if you want.

It does raise the question of how do you state "where", in a temporal sense, is
the data located?

> To me the current model seems to assume that atom:created and
> atom:modified are for machine use, and that is why UTC is required.
> Whereas atom:issued is for human display, and that is why local time
> is preferred.

The time will always have to be converted.  Going from local time EDT to UTC and
then to PDT  (-04:00, Z, -07:00) or from UTC directly to PDT.  That it came from
some guy in NYC at 6am "his time" might have some sort of mental relevance
(oooo, he's into work early today!) but it has little machine relevance.

> If atom:created and atom:modified are only for machine use, then
> atom:issued starts to look a bit weak. If there can only be one
> atom:issued, then tools will need to rely on atom:created and
> atom:modified to find out about the entry's publishing history. But we
> have already weakened these by throwing away their timezone offset...

Weakened HOW?  The time is the time is the time, same across all zones.

> I would prefer it if:
>
> * There was exactly one atom:created and UTC was a MUST. This would be
> the date that an entry was first created, and would not normally be
> displayed.
>
> * There was zero or one atom:modified and UTC was a MUST. This would be
> the date that an entry was last changed, and would not normally be
> displayed.
>
> * There was an ordered list of atom:issued, and localtime + timezone
> SHOULD be used. This would be the date that an entry was first posted
> and the dates that the entry was updated, so it would be the human
> displayable equivalent of the machine optimized atom:created and
> atom:modified fields.

Well, that might have some value.  You're suggesting the issuance could be used
to gain some sort of 'local time' relevance.

> If atom:issued doesn't provide a timezone then no timezone should be
> assumed. A lot of mobile clients don't know what timezone they are in,
> it is wrong for the server to guess randomly, the server should just
> display the time without a timezone.

NO, NO, NO.  No times without zones.

>I don't see the need to perform
> comparison operations on atom:issued - that is what atom:created and
> atom:modified are for.

An aggregator might well concern itself with issues.  Especially if
created/modified (the internal times) are not being published.

-Bill Kearney
Syndic8.com



From owner-atom-syntax@mail.imc.org  Sat Jul 10 20:35: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 UAA09079
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 20:35: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 i6B0NVYo032750;
	Sat, 10 Jul 2004 17:23: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 i6B0NVMQ032744;
	Sat, 10 Jul 2004 17:23:31 -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 i6B0NUDu032723
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 17:23:30 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040711002331.70993.qmail@web41208.mail.yahoo.com>
Received: from [67.168.158.64] by web41208.mail.yahoo.com via HTTP; Sat, 10 Jul 2004 17:23:31 PDT
Date: Sat, 10 Jul 2004 17:23:31 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Craeted proposal: PaceProvideSchema
To: Mark Nottingham <mnot@mnot.net>, Tim Bray <Tim.Bray@Sun.COM>
Cc: Atom Syntax <atom-syntax@imc.org>, danny666@virgilio.it,
        Norman Walsh <ndw@nwalsh.com>
In-Reply-To: <FC7F988C-D2CB-11D8-9A61-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: <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> wrote:
> 
> 
> I predict that it will be very difficult to have a
> one-to-one 
> relationship between the constraints in an XML
> Schema and prose, and 
> furthermore, that small differences and ambiguities
> between them will 
> conflict despite our best efforts. This will lead to
> a long period of 
> sorting out conflicting normative statements in the
> prose and schema, 
> and errata releases of the specification after we've
> thought it final.

Based on my experiences with working with W3C XML
Schema and normative schmeas in various specifications
over the past three years I tend to agree with Mark. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
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  Sat Jul 10 20:39: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 UAA09171
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 20:39: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 i6B0I57B032511;
	Sat, 10 Jul 2004 17:18: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 i6B0I5QC032510;
	Sat, 10 Jul 2004 17:18: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 i6B0I5db032503
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 17:18:05 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6B0IAil002515
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 18:18: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 <0I0N006Q7VIAJV@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sat, 10 Jul 2004 18:18:10 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0N00C0AVI9E4@mail.sun.net> for atom-syntax@imc.org; Sat,
 10 Jul 2004 18:18:09 -0600 (MDT)
Date: Sat, 10 Jul 2004 17:18:08 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceElementOrder: options
In-reply-to: <40F074E7.9040502@virgilio.it>
To: danny666@virgilio.it
Cc: Atom Syntax <atom-syntax@imc.org>
Message-id: <C9782020-D2CF-11D8-B2D0-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: <97774BF0-D096-11D8-B2D0-000A95A51C9E@sun.com>
 <F3C7FAC8-D233-11D8-9A61-000A95BD86C0@mnot.net> <87smc0ownv.fsf@nwalsh.com>
 <F1AC0C56-D2AB-11D8-B2D0-000A95A51C9E@sun.com> <40F074E7.9040502@virgilio.it>
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 Jul 10, 2004, at 3:59 PM, Danny Ayers wrote:

> Some questions, starting with the biggy:
>
> Why order the elements?

As I've now stated several times, it may be useful, while processing an 
<atom:entry>, to know what the URI or title or author or copyright of 
the <atom:feed> is.  If you require that the feed-level stuff all 
precede the entries, then you can use a stream parsing API as opposed 
to an in-memory DOM thing.  This feels to me like a significant benefit 
to implementors. -Tim



From owner-atom-syntax@mail.imc.org  Sat Jul 10 21: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 VAA09797
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 21: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 i6B0lfcE034417;
	Sat, 10 Jul 2004 17:47: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 i6B0lfo3034416;
	Sat, 10 Jul 2004 17:47: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 i6B0lf3b034410
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 17:47:41 -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 709124F215;
	Sat, 10 Jul 2004 20:47:44 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040711094406.03c45b78@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Sun, 11 Jul 2004 09:45:10 +0900
To: Antone Roundy <antone@geckotribe.com>, atom-syntax@imc.org
From: Martin Duerst <duerst@w3.org>
Subject: Re: PaceElementOrder: options
In-Reply-To: <3120253F-D2B9-11D8-A6B6-003065EA6144@geckotribe.com>
References: <m3r7rjppnz.fsf@bitsko.slc.ut.us>
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 15:36 04/07/10 -0600, Antone Roundy wrote:

>On Saturday, July 10, 2004, at 02:34  PM, Ken MacLeod wrote:
>>Tim Bray <Tim.Bray@Sun.COM> writes:
>...
>>>1. Do nothing, no rules about ordering
>>>2. Require all the feed-level elements appear before the <atom:entry>
>>>elements
>>>3. #2, but have an <atom:feed-info> to contain all that stuff.  Thus the
>>>     content-model of <atom:feed> becomes
>>>     atom:feed-info, atom:entry+
>>>4. Require a specific ordering for all the elements.
>-1 on #1 and #4.  I lean towards #2, but a little voice in my head is 
>whispering that we might find some real benefits in #3.  I'd be interested 
>in exploring what those might be.

Differentiation of extensions. If an extension is inside feed-info,
it's a new way of providing info about a feed. If it's after, it's
something else than, but similar to, entry.

Regards,    Martin.



From owner-atom-syntax@mail.imc.org  Sat Jul 10 21: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 VAA09886
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 21: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 i6B0pXel034636;
	Sat, 10 Jul 2004 17:51: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 i6B0pXW9034635;
	Sat, 10 Jul 2004 17:51:33 -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 i6B0pWWO034627
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 17:51:32 -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 i6B0qArm016071
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 20:52:10 -0400
Message-ID: <40F08F19.5000204@intertwingly.net>
Date: Sat, 10 Jul 2004 20:51:37 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Craeted proposal: PaceProvideSchema
References: <20040711002331.70993.qmail@web41208.mail.yahoo.com>
In-Reply-To: <20040711002331.70993.qmail@web41208.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:
> 
> Based on my experiences with working with W3C XML
> Schema and normative schmeas in various specifications
> over the past three years I tend to agree with Mark. 

Ditto.

To be clear: presuming that there are adequate volunteers, having one or 
more non-normative schema(s) included in the specification would be a 
very nice thing to have.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Sat Jul 10 21:04: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 VAA09914
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 21:04: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 i6B0ldVB034405;
	Sat, 10 Jul 2004 17:47: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 i6B0ldwc034404;
	Sat, 10 Jul 2004 17:47:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from homer.w3.org (homer.w3.org [18.29.0.30])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6B0lcNY034398
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 17:47:39 -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 6C6004F16F;
	Sat, 10 Jul 2004 20:47:40 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040711092602.05ff3638@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Sun, 11 Jul 2004 09:27:32 +0900
To: Norman Walsh <ndw@nwalsh.com>, atom-syntax@imc.org
From: Martin Duerst <duerst@w3.org>
Subject: Re: Embedding non-namespaced elements
In-Reply-To: <87u0wgrtme.fsf@nwalsh.com>
References: <14be96d3040709185954a33b28@mail.gmail.com>
 <200407091923.PAA23330@ietf.org>
 <878ydsubdi.fsf@nwalsh.com>
 <14be96d3040709185954a33b28@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>


Is the lack of a namespace for DocBook V4.3 considered a feature
(and in that case, why), an oversight, a timing issue, or what?
My assumption was that these days, any halfway serious markup
vocabulary should have a namespace, but maybe I'm wrong.

Regards,    Martin.

At 07:26 04/07/10 -0400, Norman Walsh wrote:
>/ Mark Pilgrim <pilgrim@gmail.com> was heard to say:
>| On Fri, 09 Jul 2004 17:19:37 -0400, Norman Walsh <ndw@nwalsh.com> wrote:
>|> |    All elements and attributes in an Atom document MUST be
>|> |    namespace-qualified.
>|>
>|> Does this apply only to top-level elements in an atom:feed or
>|> atom:entry element? If I want to ship around a content constructor
>|> containing DocBook V4.3 content (which has no namespace), I'm allowed
>|> to, aren't I?
>|
>| Not currently.
>|
>| How is DocBook usually embedded in other formats if it doesn't have a 
>namespace?
>
>By putting it in a container that tells the application it's DocBook.
>Perhaps:
>
>   <atom:content type="application/docbook+xml" xmlns="">
>     <para>Like this, for example.</para>
>   </atom:content>
>
>                                         Be seeing you,
>                                           norm
>
>--
>Norman Walsh <ndw@nwalsh.com> | Perhaps the most valuable result of all
>http://nwalsh.com/            | education is the ability to make
>                               | yourself do the thing you have to do,
>                               | when it ought to be done, whether you
>                               | like it or not.--Thomas H. Huxley



From owner-atom-syntax@mail.imc.org  Sat Jul 10 21:06: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 VAA10022
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 21:06: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 i6B0s7wL034829;
	Sat, 10 Jul 2004 17:54:07 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6B0s73P034828;
	Sat, 10 Jul 2004 17:54:07 -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 i6B0s7dY034816
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 17:54:07 -0700 (PDT)
	(envelope-from antone@geckotribe.com)
Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134])
          by comcast.net (rwcrmhc11) with SMTP
          id <2004071100540801300j0sdje>; Sun, 11 Jul 2004 00:54:08 +0000
Date: Sat, 10 Jul 2004 18:54:06 -0600
Subject: Re: MUST be UTC?
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: <02a501c466da$f05d5a50$200ca8c0@wkearney.com>
Message-Id: <CFE2B52D-D2D4-11D8-A6B6-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, July 10, 2004, at 06:06  PM, Bill Kearney wrote:
> That it came from
> some guy in NYC at 6am "his time" might have some sort of mental 
> relevance
> (oooo, he's into work early today!) but it has little machine 
> relevance.
...
> -Bill Kearney
> Syndic8.com

Naturally, each of us is looking at these issues from the perspective 
most relevant to us.  Machine relevance is going to be more important 
to some, and less to others, as is knowing what time of day it was 
where the author was when (s)he wrote the entry.  It sounds like we may 
have to decide who we're catering to, and whether each of the Date 
Constructs is directed at the same entity or not, in order to decide 
how to make these things work. Here's a list of involved parties, and 
what I'd guess would be preferrable to each:

1) The author: the timezone they're in when they post.
2) The publishing client software: the computer's timezone (probably 
easier to format dates in their own timezone than any other)--note: if 
the server is applying timestamps, the client software is out of the 
loop on those. Also note that if the publishing client software is web 
based, it may be hosted somewhere other than where the author is.
3) The publishing server software: the computer's timezone, or if it's 
simply accepting a timestamp given to it by the client software, then 
it doesn't much matter.
4) Aggregators: UTC--keep it all in the same timezone for easy 
processing.
5) Feed reader software: UTC--same as for aggregators.
6) Readers (people): the timezone the author was in in some cases, 
their own timezone in others (when did this get written in relation to 
the author vs. when did this get written in relation to me).

Is a timezone an accurate geo locator?  Not always, of course.  Is any 
of the content in an entry accurate?  Only as accurate as the author 
makes it.  Any of the data in a feed can be an error, a lie, an 
opinion, or a fact.  We certainly can't mandate the feeds only contain 
accurate facts.  Why not let feeds contain timezones, even though they 
may not be accurate facts?

If a person carries their laptop from one timezone to another, will 
they adjust the clock?  Maybe.  Will they do it by adjusting the 
timezone or the time?  Who knows.  If they do it by adjusting the 
clock, but have the timezone wrong, then mandating that they post in 
UTC isn't going to make the timestamp any more accurate.



From owner-atom-syntax@mail.imc.org  Sat Jul 10 21:47: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 VAA11051
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 21:47: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 i6B1XEPa037141;
	Sat, 10 Jul 2004 18:33: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 i6B1XEBI037140;
	Sat, 10 Jul 2004 18:33:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6B1XCA7037133
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 18:33: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 CAE867C117; Sun, 11 Jul 2004 04:31:46 +0200 (CEST)
Date: Sun, 11 Jul 2004 03:37:07 +0200
To: "Eric Scheid" <eric.scheid@ironclad.net.au>
Subject: Re: Q: modfied vs issued vs created
References: <BD15A8AD.1E6EF%eric.scheid@ironclad.net.au>
Cc: Atom-Syntax <atom-syntax@imc.org>
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: <opsax9f5lkuvpchu@quark>
In-Reply-To: <BD15A8AD.1E6EF%eric.scheid@ironclad.net.au>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 10 Jul 2004 14:07:41 +1000, Eric Scheid  
<eric.scheid@ironclad.net.au> wrote:

>     As of 2pm two days ago,
>     the weather report for today is [blah].
>
>     As of 2pm today,
>     the weather report for today is [not blah]
>
> same entry

No, that's not the same entry. They both talk about different things.  
Someone might find a reason to use the same entry for both events and  
«stories», but that's abuse of the initial entry and not something Atom  
should either support or recommend.

> different issue dates

It should have been different entries as well.

> the latest is more interesting than the earliest.

That is something I can agree with. To take your example a little further:  
«Tomorrow will be a fun day» is _not_ the same entry as «Yesterday was a  
fun day».

-- 
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 Jul 10 22:00: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 WAA11723
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 22: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 i6B1dWBL037561;
	Sat, 10 Jul 2004 18:39:32 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6B1dW47037560;
	Sat, 10 Jul 2004 18:39: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 ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6B1dVTJ037545
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 18:39: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 9CF3B7C117; Sun, 11 Jul 2004 04:38:05 +0200 (CEST)
Date: Sun, 11 Jul 2004 03:43:28 +0200
To: "Mark Nottingham" <mnot@mnot.net>
Subject: Re: What kinds of Atom documents are there?
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <01C0B4EA-D28C-11D8-9A61-000A95BD86C0@mnot.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: <opsax9qq06uvpchu@quark>
In-Reply-To: <01C0B4EA-D28C-11D8-9A61-000A95BD86C0@mnot.net>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 10 Jul 2004 09:12:57 -0700, Mark Nottingham <mnot@mnot.net> wrote:

> Did this slip by without serious consideration by the WG, or does it  
> represent consensus?

It at least represents _my_ consensus. ;)

> If it does, we need to add language about what that document is

PaceEntryTopLevel does a little to fix some of the formal stuff, but we  
need some more language about having <entry> as a document element, yes.  
I, at least, think that section 4.13.2 should say that <link  
rel="alternate" type="application/atom+xml" href="..." /> should point to  
an XML document with atom:entry as the document element.

> and add a media type registration for it.

Why is that needed? <feed><link rel="alternate"  
type="application/atom+xml" href="..." /></feed> should (MUST?) always  
point to an XML document with atom:feed as the document element, while  
<entry><link rel="alternate" type="application/atom+xml" href="..."  
/></entry> should (MUST?) always point to an XML document with atom:entry  
as the document element.

Other cases where you'll find 'application/xhtml+xml' I don't think it's  
very important to know in advanced what document element you'll meet when  
resolving the @href (or whatever).

PS and OT: Is there an HTML representation of the latest format  
specification draft?

____
[1] <url:  
http://www.mnot.net/drafts/draft-nottingham-atom-format-02.html#rfc.section.4.13.2>


-- 
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 Jul 10 22:20: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 WAA12581
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 22:20: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 i6B20cDT039019;
	Sat, 10 Jul 2004 19:00: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 i6B20cdC039018;
	Sat, 10 Jul 2004 19:00:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6B20bmQ038995
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 19:00:37 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 11 Jul 2004 12:05:14 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sun, 11 Jul 2004 12:00:06 +1000
Subject: Re: Q: modfied vs issued vs created
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD16DC46.1EB7A%eric.scheid@ironclad.net.au>
In-Reply-To: <opsax9f5lkuvpchu@quark>
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 i6B20cmQ039013
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 11/7/04 11:37 AM, "Asbjørn Ulsberg" <asbjorn@tigerstaden.no> wrote:
> On Sat, 10 Jul 2004 14:07:41 +1000, Eric Scheid wrote:
>>     As of 2pm two days ago,
>>     the weather report for today is [blah].
>> 
>>     As of 2pm today,
>>     the weather report for today is [not blah]
>> 
> No, that's not the same entry. They both talk about different things.
> Someone might find a reason to use the same entry for both events and
> «stories», but that's abuse of the initial entry and not something Atom
> should either support or recommend.

They are both talking about the same thing: the weather report for Sat, 10
Jul 2004. Typically, when a weather report is issued, it replaces the
previous report for that the date covered -- and I'm talking real-world
(non-atom) here. You thus wouldn't have a feed with two (differing) weather
reports for the same date.

Deleting the old one and inserting the new one will only annoy the user --
if the prognosis hasn't actually changed they will still be presented with a
"new, unread" weather report, and one which they can't compare to the old
(because it's been deleted).

e.




From owner-atom-syntax@mail.imc.org  Sat Jul 10 23:03: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 XAA13909
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 23:03: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 i6B2od0P042907;
	Sat, 10 Jul 2004 19: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 i6B2odnC042906;
	Sat, 10 Jul 2004 19: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.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 i6B2ocv5042900
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 19:50:38 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.18] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id 5CBDE727D; Sat, 10 Jul 2004 19:50:45 -0700 (PDT)
In-Reply-To: <CFE2B52D-D2D4-11D8-A6B6-003065EA6144@geckotribe.com>
References: <CFE2B52D-D2D4-11D8-A6B6-003065EA6144@geckotribe.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <1A0E593A-D2E5-11D8-9A61-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: Re: MUST be UTC?
Date: Sat, 10 Jul 2004 19:50:43 -0700
To: Antone Roundy <antone@geckotribe.com>
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>
Content-Transfer-Encoding: 7bit


Just a thought --

Rather than invent yet another date/time syntax, and thereby make it 
difficult for people to reuse existing software, couldn't we indicate 
that the time zone is unknown by a mechanism external to the date/time 
string?

In other words, instead of allowing a date/time string without a time 
zone, perhaps we could have a new attribute that indicates that the 
time zone isn't to be relied upon?

Something like
    <atom:issued unsureTimeZone="1">2004-02-04T10:23:45Z</atom:issued>
(use your imagination for the attribute name; this is just for colour)

Otherwise, we have to accommodate the special cases in a variety of 
ways (specs, schemas, tools, etc.).


On Jul 10, 2004, at 5:54 PM, Antone Roundy wrote:

>
> On Saturday, July 10, 2004, at 06:06  PM, Bill Kearney wrote:
>> That it came from
>> some guy in NYC at 6am "his time" might have some sort of mental 
>> relevance
>> (oooo, he's into work early today!) but it has little machine 
>> relevance.
> ...
>> -Bill Kearney
>> Syndic8.com
>
> Naturally, each of us is looking at these issues from the perspective 
> most relevant to us.  Machine relevance is going to be more important 
> to some, and less to others, as is knowing what time of day it was 
> where the author was when (s)he wrote the entry.  It sounds like we 
> may have to decide who we're catering to, and whether each of the Date 
> Constructs is directed at the same entity or not, in order to decide 
> how to make these things work. Here's a list of involved parties, and 
> what I'd guess would be preferrable to each:
>
> 1) The author: the timezone they're in when they post.
> 2) The publishing client software: the computer's timezone (probably 
> easier to format dates in their own timezone than any other)--note: if 
> the server is applying timestamps, the client software is out of the 
> loop on those. Also note that if the publishing client software is web 
> based, it may be hosted somewhere other than where the author is.
> 3) The publishing server software: the computer's timezone, or if it's 
> simply accepting a timestamp given to it by the client software, then 
> it doesn't much matter.
> 4) Aggregators: UTC--keep it all in the same timezone for easy 
> processing.
> 5) Feed reader software: UTC--same as for aggregators.
> 6) Readers (people): the timezone the author was in in some cases, 
> their own timezone in others (when did this get written in relation to 
> the author vs. when did this get written in relation to me).
>
> Is a timezone an accurate geo locator?  Not always, of course.  Is any 
> of the content in an entry accurate?  Only as accurate as the author 
> makes it.  Any of the data in a feed can be an error, a lie, an 
> opinion, or a fact.  We certainly can't mandate the feeds only contain 
> accurate facts.  Why not let feeds contain timezones, even though they 
> may not be accurate facts?
>
> If a person carries their laptop from one timezone to another, will 
> they adjust the clock?  Maybe.  Will they do it by adjusting the 
> timezone or the time?  Who knows.  If they do it by adjusting the 
> clock, but have the timezone wrong, then mandating that they post in 
> UTC isn't going to make the timestamp any more accurate.
>

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Sat Jul 10 23: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 XAA13991
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 23:07:25 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6B2spiV043156;
	Sat, 10 Jul 2004 19:54: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 i6B2spGk043155;
	Sat, 10 Jul 2004 19:54: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 i6B2sp10043148
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 19:54:51 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.18] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id E34BD727D; Sat, 10 Jul 2004 19:54:57 -0700 (PDT)
In-Reply-To: <opsax9qq06uvpchu@quark>
References: <01C0B4EA-D28C-11D8-9A61-000A95BD86C0@mnot.net> <opsax9qq06uvpchu@quark>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <B0907389-D2E5-11D8-9A61-000A95BD86C0@mnot.net>
Cc: Atom-Syntax <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: Re: What kinds of Atom documents are there?
Date: Sat, 10 Jul 2004 19:54:55 -0700
To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
X-Mailer: Apple Mail (2.618)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6B2sp10043150
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 Jul 10, 2004, at 6:43 PM, Asbjørn Ulsberg wrote:

>> and add a media type registration for it.
>
> Why is that needed? <feed><link rel="alternate" 
> type="application/atom+xml" href="..." /></feed> should (MUST?) always 
> point to an XML document with atom:feed as the document element, while 
> <entry><link rel="alternate" type="application/atom+xml" href="..." 
> /></entry> should (MUST?) always point to an XML document with 
> atom:entry as the document element.

Are these the ONLY contexts where Atom documents are? Are we absolutely 
sure that there is no reason why anyone would want to disambiguate them 
at the MIME/HTTP layer (e.g., for caching, content negotiation, etc.).

The cost of registering one more media type is very low; I think the 
appropriate question is why it *isn't* needed.


> PS and OT: Is there an HTML representation of the latest format 
> specification draft?

Not yet.


--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org  Sat Jul 10 23:10: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 XAA14113
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 23:10: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 i6B2u03N043216;
	Sat, 10 Jul 2004 19:56: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 i6B2u06M043215;
	Sat, 10 Jul 2004 19:56:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6B2twc2043203
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 19:55:59 -0700 (PDT)
	(envelope-from jasnell@us.ibm.com)
Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32])
	by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i6B2txtf312890;
	Sat, 10 Jul 2004 22:55:59 -0400
Received: from d03nm122.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170])
	by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6B2twjS029882;
	Sat, 10 Jul 2004 20:55:58 -0600
In-Reply-To: <20040711002331.70993.qmail@web41208.mail.yahoo.com>
To: Dare Obasanjo <kpako@yahoo.com>
Cc: Atom Syntax <atom-syntax@imc.org>, danny666@virgilio.it,
        Mark Nottingham <mnot@mnot.net>, Norman Walsh <ndw@nwalsh.com>,
        owner-atom-syntax@mail.imc.org, Tim Bray <Tim.Bray@Sun.COM>
MIME-Version: 1.0
Subject: Re: Craeted proposal: PaceProvideSchema
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
From: James M Snell <jasnell@us.ibm.com>
X-MIMETrack: S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/10/2004 07:51:40 PM,
	Serialize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/10/2004 07:51:40 PM,
	Serialize complete at 07/10/2004 07:51:40 PM,
	Itemize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/10/2004 07:51:40 PM,
	S/MIME Sign complete at 07/10/2004 07:51:40 PM,
	S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/10/2004 07:55:55 PM,
	S/MIME Sign complete at 07/10/2004 07:55:55 PM,
	Serialize by Router on D03NM122/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at
 07/10/2004 20:55:58,
	Serialize complete at 07/10/2004 20:55:59,
	Serialize by Router on D03NM122/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at
 07/10/2004 20:55:59
Message-ID: <OF9967BF62.8C79E246-ON88256ECE.000FA053-88256ECE.00101B2E@us.ibm.com>
Date: Sat, 10 Jul 2004 20:55:55 -0600
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z59447_boundary_sign
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>


This is an S/MIME signed message.

---------z59447_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 000FB77488256ECE_="

This is a multipart message in MIME format.
--=_alternative 000FB77488256ECE_=
Content-Type: text/plain; charset="US-ASCII"

+1 on this.  There will be no way to produce a normative XML Schema, but 
it would be extremely useful to have a non-normative schema that at least 
describes the fundamental elements and attributes.

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



Dare Obasanjo <kpako@yahoo.com> 
Sent by: owner-atom-syntax@mail.imc.org
07/10/2004 05:23 PM

To
Mark Nottingham <mnot@mnot.net>, Tim Bray <Tim.Bray@Sun.COM>
cc
Atom Syntax <atom-syntax@imc.org>, danny666@virgilio.it, Norman Walsh 
<ndw@nwalsh.com>
Subject
Re: Craeted proposal: PaceProvideSchema







--- Mark Nottingham <mnot@mnot.net> wrote:
> 
> 
> I predict that it will be very difficult to have a
> one-to-one 
> relationship between the constraints in an XML
> Schema and prose, and 
> furthermore, that small differences and ambiguities
> between them will 
> conflict despite our best efforts. This will lead to
> a long period of 
> sorting out conflicting normative statements in the
> prose and schema, 
> and errata releases of the specification after we've
> thought it final.

Based on my experiences with working with W3C XML
Schema and normative schmeas in various specifications
over the past three years I tend to agree with Mark. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with 
bodyguards. That way if a prisoner becomes sick and his cellmate tells the 
guard it's an emergency, the guard will fetch a trauma team instead of 
opening up the cell for a look.


 
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo 



--=_alternative 000FB77488256ECE_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">+1 on this. &nbsp;There will be no way
to produce a normative XML Schema, but it would be extremely useful to
have a non-normative schema that at least describes the fundamental elements
and attributes.</font>
<br>
<br><font size=2 face="sans-serif">- James M Snell<br>
 &nbsp;jasnell@us.ibm.com<br>
 &nbsp;http://www.ibm.com<br>
 &nbsp;(877) 511-5082 / Office<br>
 &nbsp;930-1979 / Tie Line</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Dare Obasanjo &lt;kpako@yahoo.com&gt;</b>
</font>
<br><font size=1 face="sans-serif">Sent by: owner-atom-syntax@mail.imc.org</font>
<p><font size=1 face="sans-serif">07/10/2004 05:23 PM</font>
<td width=59%>
<table width=100%>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td valign=top><font size=1 face="sans-serif">Mark Nottingham &lt;mnot@mnot.net&gt;,
Tim Bray &lt;Tim.Bray@Sun.COM&gt;</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td valign=top><font size=1 face="sans-serif">Atom Syntax &lt;atom-syntax@imc.org&gt;,
danny666@virgilio.it, Norman Walsh &lt;ndw@nwalsh.com&gt;</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td valign=top><font size=1 face="sans-serif">Re: Craeted proposal: PaceProvideSchema</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2><tt><br>
--- Mark Nottingham &lt;mnot@mnot.net&gt; wrote:<br>
&gt; <br>
&gt; <br>
&gt; I predict that it will be very difficult to have a<br>
&gt; one-to-one <br>
&gt; relationship between the constraints in an XML<br>
&gt; Schema and prose, and <br>
&gt; furthermore, that small differences and ambiguities<br>
&gt; between them will <br>
&gt; conflict despite our best efforts. This will lead to<br>
&gt; a long period of <br>
&gt; sorting out conflicting normative statements in the<br>
&gt; prose and schema, <br>
&gt; and errata releases of the specification after we've<br>
&gt; thought it final.<br>
<br>
Based on my experiences with working with W3C XML<br>
Schema and normative schmeas in various specifications<br>
over the past three years I tend to agree with Mark. <br>
<br>
=====<br>
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95<br>
My dungeon will have its own qualified medical staff complete with bodyguards.
That way if a prisoner becomes sick and his cellmate tells the guard it's
an emergency, the guard will fetch a trauma team instead of opening up
the cell for a look.<br>
<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<br>
__________________________________<br>
Do you Yahoo!?<br>
Take Yahoo! Mail with you! Get it on your mobile phone.<br>
http://mobile.yahoo.com/maildemo <br>
<br>
</tt></font>
<br>
--=_alternative 000FB77488256ECE_=--

---------z59447_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIIUOAIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIISWDCCAtow
ggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1
aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAy
MDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA629xc49NpAPz
cAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7glzJKgPkPzlTZZfznznGbmAWVnNBQ
lyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnwNclOnnP2sKufuPzbTImQTTi5c8JZNZcM
J0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEEBAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1Ud
DgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAPBgNVHRMBAf8EBTADAQH/MDEGA1UdJQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUH
AwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvu
jQupk2oCScMd3FIHLE7hOfu8YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14ke
McF9ViNdewEoBGiAycUq8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIC2jCCAkOgAwIB
AgIDAxS2MA0GCSqGSIb3DQEBBAUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwMTE0MjIw
NzExWhcNMTExMjMxMjIwNzExWjBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25h
bCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrb3Fzj02kA/NwCy5KFMiY
tFgyTJ6kMSQLVSs9uwVHIAVkqy/enDQwZ9b/7uCXMkqA+Q/OVNll/OfOcZuYBZWc0FCXI9qw60KO
J/rTd65FdF4dwp8cw8si0qjOJtYg8cm46fA1yU6ec/awq5+4/NtMiZBNOLlzwlk1lwwnRgXNNwID
AQABo4GqMIGnMBEGCWCGSAGG+EIBAQQEAwIAhzAOBgNVHQ8BAf8EBAMCAcYwHQYDVR0OBBYEFK5U
DpLqqDOpKyQtx8hvMNze80pAMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMA8GA1Ud
EwEB/wQFMAMBAf8wMQYDVR0lBCowKAYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYB
BQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAMnJ7c2YLyrY/PKlFl+7sm8NENfWtFxqdm+6NC6mTagJJ
wx3cUgcsTuE5+7xh9+/G0tTfLzA1qZAQ5GNMPXvmoB9+vJfKnC2JWMFQpIOUEJDXiR4xwX1WI117
ASgEaIDJxSrxHcuuV/hMIO9bgZ6C41MUVmdLTKBgBOImTuIPK8QwggMgMIICiaADAgECAgQ13vTP
MA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQL
EyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0MTUxWhcN
MTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMk
RXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKKlQRkrPFr
U18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkwrFEeO68r
1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOgYaRfMF0x
CzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBD
ZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAxODA4MjIx
NjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAdBgNV
HQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0HQQAEDTAL
GwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwlMQ0AppJu
f7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn00DbOyZY
sih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMgMIICiaADAgEC
AgQ13vTPMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0
MTUxWhcNMTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsG
A1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKK
lQRkrPFrU18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkw
rFEeO68r1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOg
YaRfMF0xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNl
Y3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAx
ODA4MjIxNjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAdBgNVHQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0H
QQAEDTALGwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwl
MQ0AppJuf7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn
00DbOyZYsih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMmMIIC
j6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIxNjM2NTRaMIGFMQsw
CQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEXMBUGA1UEAxMOSmFt
ZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkqhkiG9w0BCQEWEmph
c25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwKpbDG3zMatEuuOT
FYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSyd+7nwqAvbBfPj+0S
vcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7tBJlLrwDRCMoNlPuQ
Kg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQW
BBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOgFAwSamFzbmVs
bEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pAMCcGA1UdJQQgMB4G
CCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAZMKevB7dFfb9
23OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY8BjwVHxiYgG4xkxf
B1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOIzj3lz3xd+uOzqRFg
/Wsg/VMwggMmMIICj6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAy
BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNV
BAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIx
NjM2NTRaMIGFMQswCQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEX
MBUGA1UEAxMOSmFtZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkq
hkiG9w0BCQEWEmphc25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
wKpbDG3zMatEuuOTFYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSy
d+7nwqAvbBfPj+0SvcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7t
BJlLrwDRCMoNlPuQKg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQD
AgXgMB0GA1UdDgQWBBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcU
AgOgFAwSamFzbmVsbEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA
MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQAD
gYEAZMKevB7dFfb923OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY
8BjwVHxiYgG4xkxfB1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOI
zj3lz3xd+uOzqRFg/Wsg/VMxggG7MIIBtwIBATBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJ
bnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0g
Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwF+kzAJBgUrDgMCGgUAoIGiMBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDcxMTAyNTE0MFowIwYJKoZIhvcNAQkEMRYE
FDubzoUEinH7HatLYH9ZFtFstXAoMEMGCSqGSIb3DQEJDzE2MDQwBwYFKw4DAh0wDgYIKoZIhvcN
AwICAgCAMAoGCCqGSIb3DQMHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAsUELOUEX
VuU7E7YFF545M9ocHvnzDKdeJQWV0AFFHOf9w7uVMFzeD+wC4gOlIOtNk86j2YszO3ff//u9kYrT
19yUw1Q5XsgVU8JiZxsCEQw01Ao8hmhg4muiqm5lgw1tev/Fpw4pA45W/2lyc6Y8IDfRWBDk14nl
LN0wAD9KECYAAAAA

---------z59447_boundary_sign--



From owner-atom-syntax@mail.imc.org  Sat Jul 10 23:25: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 XAA14451
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 23:25:41 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6B36a83043716;
	Sat, 10 Jul 2004 20:06: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 i6B36avU043715;
	Sat, 10 Jul 2004 20:06:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6B36Z9a043708
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 20:06:35 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6B36dil003569
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 21:06:39 -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 <0I0O006A03B3JV@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sat, 10 Jul 2004 21:06:39 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0O00BPE3B2YS@mail.sun.net> for atom-syntax@imc.org; Sat,
 10 Jul 2004 21:06:39 -0600 (MDT)
Date: Sat, 10 Jul 2004 20:06:38 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Craeted proposal: PaceProvideSchema
In-reply-to: <20040711002331.70993.qmail@web41208.mail.yahoo.com>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <53518515-D2E7-11D8-9DBF-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: <20040711002331.70993.qmail@web41208.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 Jul 10, 2004, at 5:23 PM, Dare Obasanjo wrote:

> --- Mark Nottingham <mnot@mnot.net> wrote:
>>
>> I predict that it will be very difficult to have a
>> one-to-one
>> relationship between the constraints in an XML
>> Schema and prose
> Based on my experiences with working with W3C XML
> Schema and normative schmeas in various specifications
> over the past three years I tend to agree with Mark.

Well, if the consensus is against a normative schema I can live with 
that, but I suggest that Dare's problems may be more rooted in the 
specifics of XML Schema than the general notion of a normative schema.

Having said that, I'm inclined to declare rough consensus in favor of 
writing at least one schema, and the jury being out on whether it can 
be made usefully normative.  Anyone disagree?

We seem to have multiple eager volunteers to do the schemas; to them I 
counsel holding on a couple of revs in the draft till things stabilize. 
-Tim



From owner-atom-syntax@mail.imc.org  Sat Jul 10 23:30: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 XAA14555
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 23:30:42 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6B3Ln1d044853;
	Sat, 10 Jul 2004 20: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 i6B3LnNX044852;
	Sat, 10 Jul 2004 20:21:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web41501.mail.yahoo.com (web41501.mail.yahoo.com [66.218.93.84])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6B3LmPC044844
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 20:21:48 -0700 (PDT)
	(envelope-from randymorin@yahoo.com)
Message-ID: <20040711032150.90879.qmail@web41501.mail.yahoo.com>
Received: from [24.43.182.164] by web41501.mail.yahoo.com via HTTP; Sat, 10 Jul 2004 20:21:50 PDT
Date: Sat, 10 Jul 2004 20:21:50 -0700 (PDT)
From: Randy Charles Morin <randymorin@yahoo.com>
Reply-To: randy@kbcafe.com
Subject: Re: Created proposal: PaceProvideSchema 
To: Atomlist <atom-syntax@imc.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1702332778-1089516110=:89115"
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>


--0-1702332778-1089516110=:89115
Content-Type: text/plain; charset=us-ascii


Sample XSD Schema
http://www.kbcafe.com/iBLOGthere4iM/AtomApi.0.3.0.xsd
This is the same XSD that is used by the WSDL 1.1 and 2.0 definitions.

Randy
http://www.kbcafe.com

 

		
---------------------------------
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
--0-1702332778-1089516110=:89115
Content-Type: text/html; charset=us-ascii

<P>Sample XSD Schema<BR><A href="http://www.kbcafe.com/iBLOGthere4iM/AtomApi.0.3.0.xsd">http://www.kbcafe.com/iBLOGthere4iM/AtomApi.0.3.0.xsd</A><BR>This is the same XSD that is used by the WSDL 1.1 and 2.0 definitions.</P>
<P>Randy<BR><A href="http://www.kbcafe.com">http://www.kbcafe.com</A></P>
<P>&nbsp;</P><p>
		<hr size=1>Do you Yahoo!?<br>
Read only the mail you want - <a href="http://us.rd.yahoo.com/mail_us/taglines/spamguard/*http://promotions.yahoo.com/new_mail/static/protection.html">Yahoo! Mail SpamGuard</a>.
--0-1702332778-1089516110=:89115--



From owner-atom-syntax@mail.imc.org  Sat Jul 10 23: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 XAA14879
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 23: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 i6B3ZUGD045981;
	Sat, 10 Jul 2004 20:35: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 i6B3ZUBX045980;
	Sat, 10 Jul 2004 20:35:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web41510.mail.yahoo.com (web41510.mail.yahoo.com [66.218.93.93])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6B3ZU7Y045971
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 20:35:30 -0700 (PDT)
	(envelope-from randymorin@yahoo.com)
Message-ID: <20040711033526.82786.qmail@web41510.mail.yahoo.com>
Received: from [24.43.182.164] by web41510.mail.yahoo.com via HTTP; Sat, 10 Jul 2004 20:35:26 PDT
Date: Sat, 10 Jul 2004 20:35:26 -0700 (PDT)
From: Randy Charles Morin <randymorin@yahoo.com>
Reply-To: randy@kbcafe.com
Subject: Re: Created proposal: PaceProvideSchema 
To: Atomlist <atom-syntax@imc.org>, Tim Bray <tim.bray@sun.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1904365639-1089516926=:80477"
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>


--0-1904365639-1089516926=:80477
Content-Type: text/plain; charset=us-ascii

>That would be unacceptable, the schema and 
>the prose have to be consistent. -Tim
 
Atom would have to be substantially rewritten to make this plausible. 
 
Case #1. You cannot account for cardinality of unordered elements in the feed and entry. This is simply not possible in XSD. There would have to be inconsistency somewhere.
 
Case #2. The content element is not expressible in XSD.
 
Thanks and have a nice day,
 
Randy
http://www.kbcafe.com
 


		
---------------------------------
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
--0-1904365639-1089516926=:80477
Content-Type: text/html; charset=us-ascii

<DIV>
<DIV><FONT face="Courier New">&gt;That would be unacceptable, the schema and </FONT></DIV>
<DIV><FONT face="Courier New">&gt;the prose have to be consistent. -Tim</FONT></DIV>
<DIV><FONT face="Courier New"></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New">Atom would have to be substantially rewritten to make this plausible. </FONT></DIV>
<DIV><FONT face="Courier New"></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New">Case #1. You cannot account for cardinality of unordered elements in the feed and entry. This is simply not possible in XSD. There would have to be inconsistency somewhere.</FONT></DIV>
<DIV><FONT face="Courier New"></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New">Case #2. The content element is not expressible in XSD.</FONT></DIV>
<DIV><FONT face="Courier New"></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New">Thanks and have a nice day,</FONT></DIV>
<DIV><FONT face="Courier New"></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New">Randy</FONT></DIV>
<DIV><FONT face="Courier New"><A href="http://www.kbcafe.com/">http://www.kbcafe.com</A></FONT></DIV>
<DIV><FONT face="Courier New"></FONT>&nbsp;</DIV><!--X-Body-of-Message-End--><!--X-MsgBody-End--><!--X-Follow-Ups--></DIV><p>
		<hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/mail_us/taglines/10/*http://promotions.yahoo.com/new_mail/static/efficiency.html">New and Improved Yahoo! Mail</a> - Send 10MB messages!
--0-1904365639-1089516926=:80477--



From owner-atom-syntax@mail.imc.org  Sat Jul 10 23:44:14 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14904
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 23:44:13 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6B3Z52Y045962;
	Sat, 10 Jul 2004 20:35: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 i6B3Z5JA045961;
	Sat, 10 Jul 2004 20:35: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 i6B3Z4qF045954
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 20:35: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 i6B3ZfmG024641;
	Sat, 10 Jul 2004 23:35:44 -0400
Message-ID: <40F0B56C.90205@intertwingly.net>
Date: Sat, 10 Jul 2004 23:35:08 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <mnot@mnot.net>
CC: atom-syntax@imc.org
Subject: Re: MUST be UTC?
References: <CFE2B52D-D2D4-11D8-A6B6-003065EA6144@geckotribe.com> <1A0E593A-D2E5-11D8-9A61-000A95BD86C0@mnot.net>
In-Reply-To: <1A0E593A-D2E5-11D8-9A61-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: <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:
> 
> Just a thought --
> 
> Rather than invent yet another date/time syntax, and thereby make it 
> difficult for people to reuse existing software, couldn't we indicate 
> that the time zone is unknown by a mechanism external to the date/time 
> string?
> 
> In other words, instead of allowing a date/time string without a time 
> zone, perhaps we could have a new attribute that indicates that the time 
> zone isn't to be relied upon?

We aren't inventing another date/time syntax, take a look at:

   http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dateTime

For more details on ISO 8601, see

   http://www.qsl.net/g1smd/isopdf.htm

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Sat Jul 10 23:45: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 XAA14999
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 23:45: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 i6B3aR5d046053;
	Sat, 10 Jul 2004 20:36: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 i6B3aR0i046052;
	Sat, 10 Jul 2004 20:36:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from dd1516.kasserver.com (dd1516.kasserver.com [81.209.148.207])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6B3aPiY046030
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 20:36:26 -0700 (PDT)
	(envelope-from sc@itst.org)
Received: from [192.168.1.10] (p5081731E.dip0.t-ipconnect.de [80.129.115.30])
	by dd1516.kasserver.com (Postfix) with ESMTP id 870652BE18E
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 05:36:17 +0200 (CEST)
Message-ID: <40F0B613.9020909@itst.org>
Date: Sun, 11 Jul 2004 05:37:55 +0200
From: Sascha Carlin <sc@itst.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707
X-Accept-Language: en, de
MIME-Version: 1.0
To: atom-syntax@imc.org
Subject: Re: MUST be UTC?
References: <87smc0qcnk.fsf@nwalsh.com>
In-Reply-To: <87smc0qcnk.fsf@nwalsh.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


Norman Walsh wrote:
> On the subject of time zones, is it really necessary to use UTC? How
> is "2004-07-08T07:11:53-04:00" really worse than
> "2004-07-08T11:11:53Z"? I can understand not using forms like
> "2004-07-08T07:11:53EDT" but I'd like the freedom to use the numeric
> forms.

As Bill and others already pointed out, we have to make a diffenrence
between machine and human read data.

We need the correct time including the timezone information for display
to humans, and we need the time in a universal format without timezone
information for machine stuff like sorting, analysing, ...

The time for humans is generated from the time plus a timezone information.

So we need to store two pieces of information: the time in UTC and the
timezone. So instead of adding x different tags to the Atom document, we
add a atom:timezone tag and can use atom:created, atom:modified (and
atom:issued, if we need to) and can create all the formats we need.

atom:timezone could have the format [+|-]dddd.dd, for instance.

Just my 2 cents.

Regards, Sascha

-- 
Sascha Carlin * Heinrich-Heine-Str. 1 * 64319 Pfungstadt
http://www.itst.org/         **         +49 6157 157 205



From owner-atom-syntax@mail.imc.org  Sat Jul 10 23:48: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 XAA15062
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 23:48:36 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6B3cV5a046233;
	Sat, 10 Jul 2004 20:38: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 i6B3cVfK046232;
	Sat, 10 Jul 2004 20:38: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 i6B3cUxX046226
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 20:38:30 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.18] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id 9B42C727D; Sat, 10 Jul 2004 20:38:37 -0700 (PDT)
In-Reply-To: <40F0B56C.90205@intertwingly.net>
References: <CFE2B52D-D2D4-11D8-A6B6-003065EA6144@geckotribe.com> <1A0E593A-D2E5-11D8-9A61-000A95BD86C0@mnot.net> <40F0B56C.90205@intertwingly.net>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <CA1CC962-D2EB-11D8-9A61-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: Re: MUST be UTC?
Date: Sat, 10 Jul 2004 20:38:35 -0700
To: Sam Ruby <rubys@intertwingly.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>
Content-Transfer-Encoding: 7bit


Ah - I thought we were still using W3C datetime:
   http://www.w3.org/TR/NOTE-datetime

Never mind this, then. We should update the spec(s) to refer to Schema 
datetimes, however.

Cheers,


On Jul 10, 2004, at 8:35 PM, Sam Ruby wrote:

> Mark Nottingham wrote:
>> Just a thought --
>> Rather than invent yet another date/time syntax, and thereby make it 
>> difficult for people to reuse existing software, couldn't we indicate 
>> that the time zone is unknown by a mechanism external to the 
>> date/time string?
>> In other words, instead of allowing a date/time string without a time 
>> zone, perhaps we could have a new attribute that indicates that the 
>> time zone isn't to be relied upon?
>
> We aren't inventing another date/time syntax, take a look at:
>
>   http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dateTime
>
> For more details on ISO 8601, see
>
>   http://www.qsl.net/g1smd/isopdf.htm
>
> - Sam Ruby
>

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Sat Jul 10 23:53: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 XAA15257
	for <atompub-archive@lists.ietf.org>; Sat, 10 Jul 2004 23:53: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 i6B3ijKG046538;
	Sat, 10 Jul 2004 20: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 i6B3ijdO046537;
	Sat, 10 Jul 2004 20:44:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web41504.mail.yahoo.com (web41504.mail.yahoo.com [66.218.93.87])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6B3ijjn046530
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 20:44:45 -0700 (PDT)
	(envelope-from randymorin@yahoo.com)
Message-ID: <20040711034447.6911.qmail@web41504.mail.yahoo.com>
Received: from [24.43.182.164] by web41504.mail.yahoo.com via HTTP; Sat, 10 Jul 2004 20:44:47 PDT
Date: Sat, 10 Jul 2004 20:44:47 -0700 (PDT)
From: Randy Charles Morin <randymorin@yahoo.com>
Reply-To: randy@kbcafe.com
Subject: Re: PaceElementOrder: options
To: Atomlist <atom-syntax@imc.org>, Danny Ayers <danny666@virgilio.it>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1191727868-1089517487=:6212"
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>


--0-1191727868-1089517487=:6212
Content-Type: text/plain; charset=us-ascii

Previous Wiki and mailing list discussions on order.
http://www.intertwingly.net/wiki/pie/XsdFriendly
Thanks,
 
Randy
http://www.kbcafe.com
 

		
---------------------------------
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
--0-1191727868-1089517487=:6212
Content-Type: text/html; charset=us-ascii

<DIV>Previous Wiki and mailing list discussions on order.</DIV>
<DIV><A href="http://www.intertwingly.net/wiki/pie/XsdFriendly">http://www.intertwingly.net/wiki/pie/XsdFriendly</A></DIV>
<DIV>Thanks,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Randy</DIV>
<DIV><A href="http://www.kbcafe.com">http://www.kbcafe.com</A></DIV>
<DIV>&nbsp;</DIV><p>
		<hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/mail_us/taglines/virus/*http://promotions.yahoo.com/new_mail/static/protection.html">Yahoo! Mail</a> - Helps protect you from nasty viruses.
--0-1191727868-1089517487=:6212--



From owner-atom-syntax@mail.imc.org  Sun Jul 11 00:04: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 AAA15826
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 00:04: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 i6B3sZDr047140;
	Sat, 10 Jul 2004 20: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 i6B3sZuq047139;
	Sat, 10 Jul 2004 20:54:35 -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 i6B3sZRH047133
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 20:54:35 -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 i6B3sg2G021240;
	Sat, 10 Jul 2004 20:54:42 -0700 (PDT)
Received: from [192.168.1.100] (h00080d858303.ne.client2.attbi.com [24.61.1.243])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin01/MantshX 4.0) with ESMTP id i6B3q5kI001517;
	Sat, 10 Jul 2004 20:54:41 -0700 (PDT)
In-Reply-To: <F47D290F-D2BB-11D8-9A61-000A95BD86C0@mnot.net>
References: <97774BF0-D096-11D8-B2D0-000A95A51C9E@sun.com> <F3C7FAC8-D233-11D8-9A61-000A95BD86C0@mnot.net> <87smc0ownv.fsf@nwalsh.com> <F1AC0C56-D2AB-11D8-B2D0-000A95A51C9E@sun.com> <F47D290F-D2BB-11D8-9A61-000A95BD86C0@mnot.net>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-10--458502743; protocol="application/pkcs7-signature"
Message-Id: <7DEA0B24-D2ED-11D8-ACB6-000A95DC3D90@mac.com>
Cc: Atom-Syntax Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: Disambiguating the subject of feed-level metadata
Date: Sat, 10 Jul 2004 23:50:46 -0400
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-10--458502743
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 10 Jul 2004, at 5:56 pm, Mark Nottingham wrote:

> This leads me to believe that there may be some value in separating 
> feed-wide metadata with entry defaults, in a manner something like 
> this:

3rd option for entry defaults:

<feed>
  <author name="person A">
   <entry />
   <entry />
   <entry />
  </author>
</feed>

That would also allow different defaults for different groups of 
entries.

Graham
--Apple-Mail-10--458502743
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
9w0BCQUxDxcNMDQwNzExMDM1MDQ2WjAjBgkqhkiG9w0BCQQxFgQUgVLhHvN4RMFBvYrfYZoBe/WJ
6IoweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAIKknQHF6AE3uAzCy/PP1acH3
IgL1yaNnNCranV/4clMCd0tDMNdiNzNmH8YlmpYPpn9Jq1EkvG5TPUCLmXkS8OF95ipoUq4LXt/G
nSL5bQ7kBewcyp4tHm6SEFa6x3rqyOAtwOieXyl5pw7McaSnEKboh48miCKl7RrRb5qjlNXOc4v/
tczugMEOeKyJULTSKcdxsETFjBO/T0WKGZv4FIyChWzSPO9khuiAIOcSh/pnfO+v3HLtMPfuw0hG
VSpOx8eLQGG53VRHOtKBi/aQAWnLMl9yPT++Qfj50uh9A4cdqXattmYtIzTY4ENjA50A5k9ZT4RP
AGQVnvTtsM2ALQAAAAAAAA==

--Apple-Mail-10--458502743--



From owner-atom-syntax@mail.imc.org  Sun Jul 11 00: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 AAA16904
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 00: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 i6B43v4h047606;
	Sat, 10 Jul 2004 21:03:57 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6B43vcJ047605;
	Sat, 10 Jul 2004 21:03:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web41508.mail.yahoo.com (web41508.mail.yahoo.com [66.218.93.91])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6B43ulX047596
	for <atom-syntax@imc.org>; Sat, 10 Jul 2004 21:03:56 -0700 (PDT)
	(envelope-from randymorin@yahoo.com)
Message-ID: <20040711040358.60865.qmail@web41508.mail.yahoo.com>
Received: from [24.43.182.164] by web41508.mail.yahoo.com via HTTP; Sat, 10 Jul 2004 21:03:58 PDT
Date: Sat, 10 Jul 2004 21:03:58 -0700 (PDT)
From: Randy Charles Morin <randymorin@yahoo.com>
Reply-To: randy@kbcafe.com
Subject: Re: PaceElementOrder 
To: Atomlist <atom-syntax@imc.org>, Tim Bray <tim.bray@sun.com>,
        Mark Nottingham <markn@bea.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-95782644-1089518638=:56329"
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>


--0-95782644-1089518638=:56329
Content-Type: text/plain; charset=us-ascii

Mark Nottingham wrote:
> -1: how would extensions be ordered? 
Tim Bray wrote:
>Urgh, indeed, good catch. [cut] but those both feel kludgy.
 
Other XML Schema based languages like HR-XML don't have a problem w/ this. You just put an xs:any where you want the extension to belong. There's a lot of prior art, so I wouldn't call it a kludge.
Thanks and hope this helps,
 
Randy
http://www.kbcafe.com
 

		
---------------------------------
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
--0-95782644-1089518638=:56329
Content-Type: text/html; charset=us-ascii

<DIV><FONT face="Courier New">Mark Nottingham wrote:</FONT><BR>&gt;&nbsp;<FONT face="Courier New">-1: how would extensions be ordered? </FONT></DIV>
<DIV><FONT face="Courier New">Tim Bray wrote:</FONT></DIV>
<DIV><FONT face="Courier New">&gt;Urgh, indeed, good catch. [cut] but those both feel kludgy.</FONT></DIV>
<DIV><FONT face="Courier New"></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New">Other XML Schema based languages like HR-XML don't have a problem w/ this. You just put an xs:any where you want the extension to belong. There's a lot of prior art, so I wouldn't call it a kludge.</FONT></DIV>
<DIV><FONT face="Courier New">Thanks and hope this helps,</FONT></DIV>
<DIV><FONT face="Courier New"></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New">Randy</FONT></DIV>
<DIV><FONT face="Courier New"><A href="http://www.kbcafe.com">http://www.kbcafe.com</A></FONT></DIV>
<DIV><FONT face="Courier New"></FONT>&nbsp;</DIV><p>
		<hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/mail_us/taglines/10/*http://promotions.yahoo.com/new_mail/static/efficiency.html">New and Improved Yahoo! Mail</a> - Send 10MB messages!
--0-95782644-1089518638=:56329--



From owner-atom-syntax@mail.imc.org  Sun Jul 11 06:47: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 GAA15991
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 06:47: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 i6BAS6h6077037;
	Sun, 11 Jul 2004 03:28: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 i6BAS6tx077036;
	Sun, 11 Jul 2004 03:28:06 -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 i6BAS4iS077009
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 03:28:05 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Received: from mail.online.no (ti132110a080-3373.bb.online.no [80.212.221.45])
	by mail43.fg.online.no (8.12.11/8.12.11) with ESMTP id i6BARmCI011954;
	Sun, 11 Jul 2004 12:27:51 +0200 (CEST)
Date: Sun, 11 Jul 2004 12:27:46 +0200
To: "Mark Nottingham" <mnot@mnot.net>
Subject: Re: MUST be UTC?
Cc: Atom-syntax <atom-syntax@imc.org>
References: <CFE2B52D-D2D4-11D8-A6B6-003065EA6144@geckotribe.com> <1A0E593A-D2E5-11D8-9A61-000A95BD86C0@mnot.net> <40F0B56C.90205@intertwingly.net> <CA1CC962-D2EB-11D8-9A61-000A95BD86C0@mnot.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: <opsayx0klz6dxgxk@mail.online.no>
In-Reply-To: <CA1CC962-D2EB-11D8-9A61-000A95BD86C0@mnot.net>
User-Agent: Opera M2/7.52 (Win32, build 3826)
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, 10 Jul 2004 20:38:35 -0700, Mark Nottingham <mnot@mnot.net> wrote:

>  - I thought we were still using W3C datetime:
>   http://www.w3.org/TR/NOTE-datetime

As did I.

I, for one, don't see the problem with contiued use of W3C Datetime. It is  
easily understood and relatively easy to parse (Even when people use  
timezone offsets).

My fear with mandating UTC _and_ omitting timezone information, is that  
the ViewSourceClan are going to be putting their local time into any/all  
of created/modified/issued without aggregators/feed consumers having any  
way of knowing.

-- 
Arve Bersvendsen

http://www.virtuelvis.com
http://www.bersvendsen.com



From owner-atom-syntax@mail.imc.org  Sun Jul 11 07:53: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 HAA17854
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 07:53: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 i6BBWu5i082240;
	Sun, 11 Jul 2004 04:32: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 i6BBWuBo082239;
	Sun, 11 Jul 2004 04:32:56 -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 i6BBWt11082225;
	Sun, 11 Jul 2004 04:32:55 -0700 (PDT)
	(envelope-from distobj@acm.org)
Received: from mbaker by bork.markbaker.ca with local (Exim 3.35 #1 (Debian))
	id 1BjcaD-0001ZF-00; Sun, 11 Jul 2004 07:33:25 -0400
Date: Sun, 11 Jul 2004 07:33:25 -0400
To: Paul Hoffman / IMC <phoffman@imc.org>
Cc: Atom Syntax <atom-syntax@imc.org>
Subject: Re: IRIs, URIs, and RFC 2396bis
Message-ID: <20040711113325.GQ30868@markbaker.ca>
References: <14be96d3040707103826ba6c34@mail.gmail.com> <20040708031231.GL30868@markbaker.ca> <p06110437bd14cedca63b@[10.71.10.67]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <p06110437bd14cedca63b@[10.71.10.67]>
User-Agent: Mutt/1.3.28i
From: Mark Baker <distobj@acm.org>
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>


Hi,

I've just been chatting with Roy, and he agrees that this issue isn't
as simple as either "successors are implied" or "successors are not
implied".  Luckily, we can avoid that discussion if, as he suggests,
we use a reference to 2396bis only rather than 2396 *and* its
successor.  Directions to the RFC editor in this respect will also
have to be provided.

As you say though Paul, 2396bis' schedule isn't clear.  So perhaps we
can do this for now as what, IMO, seems like the best way forward, but
be prepared to change back to 2396 if it faulters (which I can't
believe will happen, but stranger things have happened).

Mark.

On Fri, Jul 09, 2004 at 03:43:16PM -0700, Paul Hoffman / IMC wrote:
> 
> At 11:12 PM -0400 7/7/04, Mark Baker wrote:
> >On Wed, Jul 07, 2004 at 01:38:50PM -0400, Mark Pilgrim wrote:
> > > Should this be
> >> changed to "whose value MUST be a URI, as defined by RFC2396 or its
> >> successor," so that Atom can benefit from RFC2396bis? [3]
> >
> >It's my understanding that "or its successor" is implied in RFCs.
> >That is, when one RFC obsoletes another, all references to the
> >obsoleted RFC are considered to be updated.
> >
> >2026 doesn't say, but I'm sure I've heard that on at least a couple
> >of occasions.  Paul?
> 
> Sorry for the delay in getting to this. Talking about references to 
> RFCs in general here.
> 
> If we say "or its successor", we get that. If we don't say it, we 
> point *exactly* to the RFC in question. Successors are *not* implied.
> 
> This is very important for many reasons. Successors might change some 
> bits-on-the-wire; that would be Very Bad for us. Successors might 
> change only some unclear parts, but those changes might be things 
> that we as a group thought we understood.
> 
> That is why very few RFCs ever refer to other "and its successors" of an 
> RFC.
> 
> In the specific case, if we point to RFC2396, that's what we get. If 
> we point to the Internet Draft of the successor to RFC 2396, that's 
> what we get. In the latter case, we also cannot finish with Atom 
> until that document is finished. And before you say "oh, but 
> rfc2396bis is far ahead of us", remember that they have been far 
> ahead of us for years and are still not finished.
> 
> This is one of the un-fun things of making standards: guessing which 
> thing that we rely on are going to be out of the oven before us. Tim 
> and I will look at this later in the baking process.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
> 

-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

  Seeking work on large scale application/data integration projects
  and/or the enabling infrastructure for same.



From owner-atom-syntax@mail.imc.org  Sun Jul 11 07:58: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 HAA17961
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 07: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 i6BBVZsG082137;
	Sun, 11 Jul 2004 04:31: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 i6BBVZgT082136;
	Sun, 11 Jul 2004 04:31:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from imo-d20.mx.aol.com (imo-d20.mx.aol.com [205.188.139.136])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BBVYWh082128
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 04:31:34 -0700 (PDT)
	(envelope-from Svgdeveloper@aol.com)
Received: from Svgdeveloper@aol.com
	by imo-d20.mx.aol.com (mail_out_v37_r2.6.) id 7.7e.52e8847b (1320)
	 for <atom-syntax@imc.org>; Sun, 11 Jul 2004 07:31:29 -0400 (EDT)
From: Svgdeveloper@aol.com
Message-ID: <7e.52e8847b.2e227f11@aol.com>
Date: Sun, 11 Jul 2004 07:31:29 EDT
Subject: Re: MUST be UTC?
To: atom-syntax@imc.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_7e.52e8847b.2e227f11_boundary"
X-Mailer: 8.0 for Windows sub 670
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>



--part1_7e.52e8847b.2e227f11_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 7/11/2004 11:31:21 AM GMT Daylight Time, 
arve@virtuelvis.com writes:

> On Sat, 10 Jul 2004 20:38:35 -0700, Mark Nottingham <mnot@mnot.net> wrote:
> 
> > - I thought we were still using W3C datetime:
> >  http://www.w3.org/TR/NOTE-datetime
> 
> As did I.
> 
> I, for one, don't see the problem with contiued use of W3C Datetime. It is  
> easily understood and relatively easy to parse (Even when people use  
> timezone offsets).
> 
> My fear with mandating UTC _and_ omitting timezone information, is that  
> the ViewSourceClan are going to be putting their local time into any/all  
> of created/modified/issued without aggregators/feed consumers having any  
> way of knowing.

Arve,

Some problems with the "W3C datetime" were discussed on list a few weeks 
back. I can't find the thread immediately. Perhaps someone else can?

By the way, there is no such thing as "W3C" datetime. The document is simply 
a NOTE to W3C which, as I understand things, says little more than "W3C has 
received or seen a document displayed at this URL" (my interpretation). 

To quote the NOTE, "This indicates no endorsement of its content" (text of 
the NOTE).

Andrew Watt

--part1_7e.52e8847b.2e227f11_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML><FONT FACE=3Darial,helvetica><HTML><FONT  SIZE=3D2 PTSIZE=3D10 FAMILY=
=3D"SANSSERIF" FACE=3D"Arial" LANG=3D"0">In a message dated 7/11/2004 11:31:=
21 AM GMT Daylight Time, arve@virtuelvis.com writes:<BR>
<BR>
<BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT=
: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">On Sat, 10 Jul 2004 20:38:35 -0=
700, Mark Nottingham &lt;mnot@mnot.net&gt; wrote:<BR>
<BR>
&gt; - I thought we were still using W3C datetime:<BR>
&gt;&nbsp; http://www.w3.org/TR/NOTE-datetime<BR>
<BR>
As did I.<BR>
<BR>
I, for one, don't see the problem with contiued use of W3C Datetime. It is&n=
bsp; <BR>
easily understood and relatively easy to parse (Even when people use&nbsp; <=
BR>
timezone offsets).<BR>
<BR>
My fear with mandating UTC _and_ omitting timezone information, is that&nbsp=
; <BR>
the ViewSourceClan are going to be putting their local time into any/all&nbs=
p; <BR>
of created/modified/issued without aggregators/feed consumers having any&nbs=
p; <BR>
way of knowing.</BLOCKQUOTE><BR>
<BR>
Arve,<BR>
<BR>
Some problems with the "W3C datetime" were discussed on list a few weeks bac=
k. I can't find the thread immediately. Perhaps someone else can?<BR>
<BR>
By the way, there is no such thing as "W3C" datetime. The document is simply=
 a NOTE to W3C which, as I understand things, says little more than "W3C has=
 received or seen a document displayed at this URL" (my interpretation). <BR=
>
<BR>
To quote the NOTE, "This indicates no endorsement of its content" (text of t=
he NOTE).<BR>
<BR>
Andrew Watt</FONT></HTML>

--part1_7e.52e8847b.2e227f11_boundary--



From owner-atom-syntax@mail.imc.org  Sun Jul 11 08:00: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 IAA18055
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 08:00: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 i6BBYKOf082290;
	Sun, 11 Jul 2004 04:34: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 i6BBYKol082289;
	Sun, 11 Jul 2004 04:34:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from imo-m14.mx.aol.com (imo-m14.mx.aol.com [64.12.138.204])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BBXnQ7082265
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 04:34:19 -0700 (PDT)
	(envelope-from Svgdeveloper@aol.com)
Received: from Svgdeveloper@aol.com
	by imo-m14.mx.aol.com (mail_out_v37_r2.6.) id 7.1e2.2516e92b (1320)
	 for <atom-syntax@imc.org>; Sun, 11 Jul 2004 07:33:41 -0400 (EDT)
From: Svgdeveloper@aol.com
Message-ID: <1e2.2516e92b.2e227f94@aol.com>
Date: Sun, 11 Jul 2004 07:33:40 EDT
Subject: [ADMIN] Can we make the default "Reply to list"?
To: atom-syntax@imc.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_1e2.2516e92b.2e227f94_boundary"
X-Mailer: 8.0 for Windows sub 670
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>



--part1_1e2.2516e92b.2e227f94_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

I wonder whether we can make the default for this list "Reply to list"?

Shouldn't the norm be to continue discussion of substantive points on list?

Andrew Watt

--part1_1e2.2516e92b.2e227f94_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML><FONT FACE=3Darial,helvetica><HTML><FONT  SIZE=3D2 PTSIZE=3D10 FAMILY=
=3D"SANSSERIF" FACE=3D"Arial" LANG=3D"0">I wonder whether we can make the de=
fault for this list "Reply to list"?<BR>
<BR>
Shouldn't the norm be to continue discussion of substantive points on list?<=
BR>
<BR>
Andrew Watt</FONT></HTML>

--part1_1e2.2516e92b.2e227f94_boundary--



From owner-atom-syntax@mail.imc.org  Sun Jul 11 09:13: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 JAA20894
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 09:13: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 i6BD2ec9090180;
	Sun, 11 Jul 2004 06:02: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 i6BD2eQf090179;
	Sun, 11 Jul 2004 06:02:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf25.cluster1.charter.net (mxsf25.cluster1.charter.net [209.225.28.225])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BD2dck090170
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 06:02:39 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip07.cluster1.charter.net (mxip07a.cluster1.charter.net [209.225.28.137])
	by mxsf25.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6BD6EEG006537
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 09:06:15 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip07.cluster1.charter.net with ESMTP; 11 Jul 2004 09:02:31 -0400
X-Ironport-AV: i="3.81R,160,1083556800"; 
   d="scan'208"; a="107898444:sNHT15321206"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BjdyG-0004kL-00; Sun, 11 Jul 2004 09:02:20 -0400
To: Martin Duerst <duerst@w3.org>
Cc: atom-syntax@imc.org
Subject: Re: Embedding non-namespaced elements
References: <14be96d3040709185954a33b28@mail.gmail.com>
	<200407091923.PAA23330@ietf.org> <878ydsubdi.fsf@nwalsh.com>
	<14be96d3040709185954a33b28@mail.gmail.com>
	<4.2.0.58.J.20040711092602.05ff3638@localhost>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Sun, 11 Jul 2004 09:02:17 -0400
In-Reply-To: <4.2.0.58.J.20040711092602.05ff3638@localhost> (Martin Duerst's
 message of "Sun, 11 Jul 2004 09:27:32 +0900")
Message-ID: <87smbyofxi.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: <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-Type: text/plain

/ Martin Duerst <duerst@w3.org> was heard to say:
| Is the lack of a namespace for DocBook V4.3 considered a feature
| (and in that case, why), an oversight, a timing issue, or what?
| My assumption was that these days, any halfway serious markup
| vocabulary should have a namespace, but maybe I'm wrong.

DocBook predates namespaces by, uhm, almost a decade. Also, we still
publish an SGML version, where namespaces don't exist at all.

DocBook V5.0 will be in a namespace, but there are tens of thousands,
probably hundreds of thousands, of DocBook documents out there in no
namespace and that's not going to change very quickly.

Anyway, I think treating documents that happen to be in a vocabulary
with no namespace like second class citizens is unnecessary in this
case.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Wisdom is only a comparative quality,
http://nwalsh.com/            | it will not bear a single
                              | definition.--Marquess of Halifax

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA8TpcOyltUcwYWjsRAgabAJsH8GPuWYKfhT9+6WYsc7RnlrDdhACZAcxQ
+yk9gCMm/3gLWMOBbkdNzdE=
=nM34
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Sun Jul 11 10:11: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 KAA23161
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 10: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 i6BDkFYV093192;
	Sun, 11 Jul 2004 06:46: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 i6BDkFHw093191;
	Sun, 11 Jul 2004 06:46:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf23.cluster1.charter.net (mxsf23.cluster1.charter.net [209.225.28.223])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BDk8A5093177
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 06:46:15 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip12.cluster1.charter.net (mxip12a.cluster1.charter.net [209.225.28.142])
	by mxsf23.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6BDoWqL023045
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 09:50:32 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip12.cluster1.charter.net with ESMTP; 11 Jul 2004 09:46:04 -0400
X-Ironport-AV: i="3.81R,160,1083556800"; 
   d="scan'208"; a="110815319:sNHT14256056"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BjeeK-00050H-00
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 09:45:48 -0400
To: Atom Syntax <atom-syntax@imc.org>
Subject: Are foreign attributes allowed?
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Sun, 11 Jul 2004 09:45:48 -0400
Message-ID: <87hdseodwz.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: <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-Type: text/plain

Assuming that ex: is bound to http://example.org/

Is this allowed:

  <atom:entry ex:foo="bar" ...>

Is this

  <atom:entry foobar="test" ...>

Assuming that either of those are allowed, are they only allowed on
content constructs, or are they allowed anywhere?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Klein bottle for rent; enquire within.
http://nwalsh.com/            | 

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA8USMOyltUcwYWjsRAim4AJ9lQslNbItH69MPEgBxGnF+gM7lgwCdEG3Q
pSDwiT/EEUULA0nSrtNRqOE=
=LeXm
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Sun Jul 11 10:22: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 KAA24081
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 10:22: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 i6BE5xP6094337;
	Sun, 11 Jul 2004 07:05: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 i6BE5xUK094336;
	Sun, 11 Jul 2004 07:05: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 i6BE5vuI094324
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 07:05: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 99B937C117; Sun, 11 Jul 2004 17:04:18 +0200 (CEST)
Date: Sun, 11 Jul 2004 16:09:14 +0200
To: "Mark Nottingham" <mnot@mnot.net>
Subject: Re: What kinds of Atom documents are there?
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <01C0B4EA-D28C-11D8-9A61-000A95BD86C0@mnot.net> <opsax9qq06uvpchu@quark> <B0907389-D2E5-11D8-9A61-000A95BD86C0@mnot.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: <opsay79ox5uvpchu@quark>
In-Reply-To: <B0907389-D2E5-11D8-9A61-000A95BD86C0@mnot.net>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 10 Jul 2004 19:54:55 -0700, Mark Nottingham <mnot@mnot.net> wrote:

> Are these the ONLY contexts where Atom documents are?

Probably not.

> Are we absolutely sure that there is no reason why anyone would want
> to disambiguate them at the MIME/HTTP layer (e.g., for caching, content
> negotiation, etc.).

Probably not, but there's imho no problem with going with  
'application/atom+xml' for both feeds and entries in the beginning, and  
rather add 'application/atom-feed+xml' and 'application/atom-entry+xml'  
(or something) when we find it necessary. I don't think it's necessary  
just yet, and not even sure it ever will be.

> The cost of registering one more media type is very low; I think the  
> appropriate question is why it *isn't* needed.

I don't really care whether Atom has one or ten MIME types. So if you  
manage to gather consensus about registering two separate for feeds and  
entries, I at least, won't stop you. ;-)

>> PS and OT: Is there an HTML representation of the latest format  
>> specification draft?
>
> Not yet.

Please let the list know when it's done. :-)

-- 
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 Jul 11 10: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 KAA24108
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 10: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 i6BE8HVm094483;
	Sun, 11 Jul 2004 07:08: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 i6BE8Hn5094482;
	Sun, 11 Jul 2004 07:08:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf28.cluster1.charter.net (mxsf28.cluster1.charter.net [209.225.28.228])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BE8G5l094474
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 07:08:16 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip06.cluster1.charter.net (mxip06a.cluster1.charter.net [209.225.28.136])
	by mxsf28.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6BEBHx9000763
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 10:11:17 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip06.cluster1.charter.net with ESMTP; 11 Jul 2004 10:08:11 -0400
X-Ironport-AV: i="3.81R,160,1083556800"; 
   d="scan'208"; a="107777758:sNHT14733968"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1Bjezk-0005AY-00
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 10:07:56 -0400
To: Atom Syntax <atom-syntax@imc.org>
Subject: Editorial proposal to replace "MAY contain any namespace-qualified
 elements as children"
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Sun, 11 Jul 2004 10:07:51 -0400
Message-ID: <87d632ocw8.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: <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-Type: text/plain

I imagine that this phrase is intended to exclude random elements from
the atom: namespace. In other words, I don't think that phrase is
intended to allow

  <atom:entry ...>
    <atom:myNewElement/>
  </atom:entry>

If that's the case, I think it would be better described along these
lines:

The children of the (feed|entry) element MAY contain:

 1. White space characters, but no other characters.
 2. Any namespace-qualified [W3C.REC-xml-names-19990114] elements with
    a namespace name other than
    http://purl.org/atom/ns#draft-ietf-atompub-format-00
 3. Or those elements in the atom namespace explicitly called out in
    this specification.

Ordering of the element children of atom:entry element MUST NOT be
considered significant.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | The belief in a supernatural source of
http://nwalsh.com/            | evil is not necessary; men alone are
                              | quite capable of every
                              | wickedness.--Joseph Conrad

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA8Um3OyltUcwYWjsRAu5CAKCr/08vxOfghMsyQgcrab6+lvX+vQCfaHbE
ngCPJYhr6+aGGeyVmvfn9Z4=
=Lxkg
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Sun Jul 11 10:31: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 KAA24355
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 10:31: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 i6BEDbwv095331;
	Sun, 11 Jul 2004 07:13: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 i6BEDbjo095330;
	Sun, 11 Jul 2004 07:13: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 ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BEDamu095265
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 07:13: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 52E237C117; Sun, 11 Jul 2004 17:12:02 +0200 (CEST)
To: "Eric Scheid" <eric.scheid@ironclad.net.au>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Q: modfied vs issued vs created
References: <BD16DC46.1EB7A%eric.scheid@ironclad.net.au>
Message-ID: <opsay8mlqcuvpchu@quark>
Date: Sun, 11 Jul 2004 16:16:59 +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: <BD16DC46.1EB7A%eric.scheid@ironclad.net.au>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 11 Jul 2004 12:00:06 +1000, Eric Scheid  
<eric.scheid@ironclad.net.au> wrote:

> They are both talking about the same thing: the weather report for Sat,  
> 10 Jul 2004.

They have the same topic; yes, but they are two different stories. If you  
don't see that, I don't think we can ever reach any agreement on this  
matter.

> Typically, when a weather report is issued, it replaces the previous
> report for that the date covered -- and I'm talking real-world (non-atom)
> here.

I know that's how it seems like for the audience. But having worked with  
The Meteorological Institute in Norway (my company is a big client of  
their services) I know that their internal data model stores each of these  
events seperately (for how long, I'm not sure, but they do for at least a  
couple of days). A new forecast doesn't overwrite an old one, even if  
they're reporting the same weather at the same time at the same place.

> You thus wouldn't have a feed with two (differing) weather reports for
> the same date.

I agree that having two entries saying different things in the feed at the  
same time is confusing and shouldn't happen, but there's absolutely no  
fuzz with just removing the old weather report and inserting the new one  
-- effectively replacing it in the feed. The entry will have a new ID  
though, and it will have different dates.

> Deleting the old one and inserting the new one will only annoy the user

Why? Do you really think a user cares whether the ID has changed or not?  
If anything, the entries should be related (<link rel="related"> or  
something), but they are, and never will be, the same 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  Sun Jul 11 10: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 KAA24850
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 10: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 i6BEKUmU095759;
	Sun, 11 Jul 2004 07:20: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 i6BEKU8X095758;
	Sun, 11 Jul 2004 07:20:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf25.cluster1.charter.net (mxsf25.cluster1.charter.net [209.225.28.225])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BEK14T095723
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 07:20:29 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip11.cluster1.charter.net (mxip11a.cluster1.charter.net [209.225.28.141])
	by mxsf25.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6BENeNX012360
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 10:23:40 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip11.cluster1.charter.net with ESMTP; 11 Jul 2004 10:19:58 -0400
X-Ironport-AV: i="3.81R,160,1083556800"; 
   d="scan'208"; a="111289610:sNHT14622744"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BjfB3-0005Gr-00
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 10:19:37 -0400
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceElementOrder: options
References: <m3r7rjppnz.fsf@bitsko.slc.ut.us>
	<4.2.0.58.J.20040711094406.03c45b78@localhost>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Sun, 11 Jul 2004 10:19:36 -0400
In-Reply-To: <4.2.0.58.J.20040711094406.03c45b78@localhost> (Martin Duerst's
 message of "Sun, 11 Jul 2004 09:45:10 +0900")
Message-ID: <878ydqoccn.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: <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-Type: text/plain

/ Martin Duerst <duerst@w3.org> was heard to say:
[...]
| Differentiation of extensions. If an extension is inside feed-info,
| it's a new way of providing info about a feed. If it's after, it's
| something else than, but similar to, entry.

Yes, that's one. A few more:

1. Differentiation of extensions.
2. Ability to easily identify/grab/transform the whole set of feed metadata
3. Provides an easy mechanism to group all the feed metadata up front
   without requiring an explicit order
4. Provides a mechanism for accomplishing 3 that can easily be tested by
   a grammar-based schema language
5. Uses a common idiom (HTML "head", TEI/GCA "front", DocBook "info) that
   users will find familiar

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Wink at small faults; for thou has
http://nwalsh.com/            | great ones.--Thomas Fuller (II)

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA8Ux5OyltUcwYWjsRAuNZAKCm/ZT8aMpWmxsxXLKFoHdY+v4YkwCfSrEw
4+DcT4aJQrceICn+pw3JG4g=
=mPt8
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Sun Jul 11 10: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 KAA24884
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 10:39: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 i6BEModb095853;
	Sun, 11 Jul 2004 07:22: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 i6BEMoqg095852;
	Sun, 11 Jul 2004 07:22: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 i6BEMn0c095841
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 07:22: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 EB8927C117; Sun, 11 Jul 2004 17:21:14 +0200 (CEST)
Date: Sun, 11 Jul 2004 16:26:14 +0200
To: "Mark Nottingham" <mnot@mnot.net>
Subject: Re: MUST be UTC?
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <CFE2B52D-D2D4-11D8-A6B6-003065EA6144@geckotribe.com> <1A0E593A-D2E5-11D8-9A61-000A95BD86C0@mnot.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: <opsay810jeuvpchu@quark>
In-Reply-To: <1A0E593A-D2E5-11D8-9A61-000A95BD86C0@mnot.net>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 10 Jul 2004 19:50:43 -0700, Mark Nottingham <mnot@mnot.net> wrote:

> Rather than invent yet another date/time syntax, and thereby make it  
> difficult for people to reuse existing software, couldn't we indicate  
> that the time zone is unknown by a mechanism external to the date/time  
> string?

In what cases would the timezone be unknown, exactly? Just wondering.

> In other words, instead of allowing a date/time string without a time  
> zone, perhaps we could have a new attribute that indicates that the time  
> zone isn't to be relied upon?

Perhaps. I don't like the current state of affairs, at least, where we  
seem to be inventing our own datetime format, and violating the format we  
say we're using; W3CDTF.

> <atom:issued unsureTimeZone="1">2004-02-04T10:23:45Z</atom:issued>

Looks like a suggestion as good as any, but I just wonder what the usecase  
for not having timezone is, and why it'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  Sun Jul 11 10:48: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 KAA25162
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 10:48: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 i6BEYd55096479;
	Sun, 11 Jul 2004 07:34: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 i6BEYdgU096478;
	Sun, 11 Jul 2004 07:34: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 i6BEYc0A096471
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 07:34: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 941E47C117; Sun, 11 Jul 2004 17:33:03 +0200 (CEST)
To: randy@kbcafe.com
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Created proposal: PaceProvideSchema 
References: <20040711033526.82786.qmail@web41510.mail.yahoo.com>
Message-ID: <opsay9lsx5uvpchu@quark>
Date: Sun, 11 Jul 2004 16:38:06 +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: <20040711033526.82786.qmail@web41510.mail.yahoo.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 10 Jul 2004 20:35:26 -0700 (PDT), Randy Charles Morin  
<randymorin@yahoo.com> wrote:

> Case #1. You cannot account for cardinality of unordered elements in the  
> feed and entry. This is simply not possible in XSD. There would have to  
> be inconsistency somewhere.

That's understandable. This is imho a flaw in XSD, though.

> Case #2. The content element is not expressible in XSD.

What do you mean, «not expressible»? Isn't it possible to say 'xs:anyType'  
with any namespace to be the the child of atom:content, or is it something  
else that is impossible to express?

-- 
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 Jul 11 10: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 KAA25371
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 10: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 i6BEWJle096371;
	Sun, 11 Jul 2004 07: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 i6BEWJfu096370;
	Sun, 11 Jul 2004 07:32: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 i6BEWIqU096363
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 07:32: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 7570F7C117; Sun, 11 Jul 2004 17:30:44 +0200 (CEST)
Date: Sun, 11 Jul 2004 16:35:46 +0200
To: "Arve Bersvendsen" <arve@virtuelvis.com>
Subject: Re: MUST be UTC?
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <CFE2B52D-D2D4-11D8-A6B6-003065EA6144@geckotribe.com> <1A0E593A-D2E5-11D8-9A61-000A95BD86C0@mnot.net> <40F0B56C.90205@intertwingly.net> <CA1CC962-D2EB-11D8-9A61-000A95BD86C0@mnot.net> <opsayx0klz6dxgxk@mail.online.no>
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: <opsay9hwg8uvpchu@quark>
In-Reply-To: <opsayx0klz6dxgxk@mail.online.no>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 11 Jul 2004 12:27:46 +0200, Arve Bersvendsen <arve@virtuelvis.com>  
wrote:

>>  - I thought we were still using W3C datetime:
>
> As did I.

And I.

> I, for one, don't see the problem with contiued use of W3C Datetime.

Me either. It's an order of magnitude simpler than ISO 8601 (or the XML  
Schema dateTime) to understand, parse and produce correctly.

> My fear with mandating UTC _and_ omitting timezone information, is that  
> the ViewSourceClan are going to be putting their local time into any/all  
> of created/modified/issued without aggregators/feed consumers having any  
> way of knowing.

A big +1 on that one. I think we make the situation absolutely no better  
than the current state of affairs in RSS world if we don't try to be a  
little more strict and explicit on datetime usage in Atom.

-- 
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 Jul 11 10: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 KAA25515
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 10: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 i6BEZ1c5096503;
	Sun, 11 Jul 2004 07:35: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 i6BEZ17x096502;
	Sun, 11 Jul 2004 07:35:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf11.cluster1.charter.net (mxsf11.cluster1.charter.net [209.225.28.211])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BEZ0V2096493
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 07:35:00 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip11.cluster1.charter.net (mxip11a.cluster1.charter.net [209.225.28.141])
	by mxsf11.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6BEcgQG028332
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 10:38:42 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip11.cluster1.charter.net with ESMTP; 11 Jul 2004 10:34:56 -0400
X-Ironport-AV: i="3.81R,160,1083556800"; 
   d="scan'208"; a="111323598:sNHT20836866"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BjfPc-0005Ly-00
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 10:34:40 -0400
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Craeted proposal: PaceProvideSchema
References: <20040711002331.70993.qmail@web41208.mail.yahoo.com>
	<53518515-D2E7-11D8-9DBF-000A95A51C9E@sun.com>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Sun, 11 Jul 2004 10:34:39 -0400
In-Reply-To: <53518515-D2E7-11D8-9DBF-000A95A51C9E@sun.com> (Tim Bray's
 message of "Sat, 10 Jul 2004 20:06:38 -0700")
Message-ID: <874qoeobnk.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: <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-Type: text/plain

/ Tim Bray <Tim.Bray@Sun.COM> was heard to say:
| Having said that, I'm inclined to declare rough consensus in favor of
| writing at least one schema, and the jury being out on whether it can
| be made usefully normative.  Anyone disagree?

For the record, I'm completely comfortable with a non-normative
schema. Two normative descriptions of something is bound to lead to
trouble and the prose has to be normative.

| We seem to have multiple eager volunteers to do the schemas; to them I
| counsel holding on a couple of revs in the draft till things
| stabilize. -Tim

I agree, except that tinkering with the schema this morning has
already pointed me to a couple of places where the spec is less than
clear. So I think I'll finish the exercise, even if it gets thrown
away it will have added value, I think.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | The fact of having been born is bad
http://nwalsh.com/            | augury for immortality.-- Santayana

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA8U//OyltUcwYWjsRAox1AJ42FxSrvfX4Qg7FHvkO9OC0lIAadwCfZ/vt
BZ0oozOAJnY95gaf6OLcKWU=
=fOIX
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Sun Jul 11 10:57:40 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25646
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 10:57:39 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BEetrS096923;
	Sun, 11 Jul 2004 07:40:55 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6BEetvE096922;
	Sun, 11 Jul 2004 07:40:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf26.cluster1.charter.net (mxsf26.cluster1.charter.net [209.225.28.226])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BEekNG096907
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 07:40:54 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip10.cluster1.charter.net (mxip10a.cluster1.charter.net [209.225.28.140])
	by mxsf26.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6BEiJVo026222
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 10:44:19 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip10.cluster1.charter.net with ESMTP; 11 Jul 2004 10:40:42 -0400
X-Ironport-AV: i="3.81R,160,1083556800"; 
   d="scan'208"; a="106658825:sNHT14150844"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BjfV7-0005Qd-00
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 10:40:21 -0400
To: Atom Syntax <atom-syntax@imc.org>
Subject: atom:summary or atom:content required?
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Sun, 11 Jul 2004 10:40:20 -0400
Message-ID: <87wu1amwtn.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: <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-Type: text/plain

Is an entry required to have at least one of atom:summary or
atom:content?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Unless one is a genius, it is best to
http://nwalsh.com/            | aim at being intelligible.--Anthony Hope

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA8VFUOyltUcwYWjsRAmSXAKCRgf3hukDMHFN/3jAKR9VjAr9JBgCeJjiN
dGYt6hUTLLpabjTGGVx7EZc=
=m/Oo
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Sun Jul 11 11:01: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 LAA25744
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 11:01: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 i6BElq1n097771;
	Sun, 11 Jul 2004 07:47: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 i6BElqGo097769;
	Sun, 11 Jul 2004 07:47:52 -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 i6BElpG7097763
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 07:47:51 -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 i6BEmRqf031841;
	Sun, 11 Jul 2004 10:48:27 -0400
Message-ID: <40F15319.9050703@intertwingly.net>
Date: Sun, 11 Jul 2004 10:47:53 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Norman Walsh <ndw@nwalsh.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Are foreign attributes allowed?
References: <87hdseodwz.fsf@nwalsh.com>
In-Reply-To: <87hdseodwz.fsf@nwalsh.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


Norman Walsh wrote:

> Assuming that ex: is bound to http://example.org/
> 
> Is this allowed:
> 
>   <atom:entry ex:foo="bar" ...>
> 
> Is this
> 
>   <atom:entry foobar="test" ...>
> 
> Assuming that either of those are allowed, are they only allowed on
> content constructs, or are they allowed anywhere?

The feedvalidator currently flags both.  I can see an argument for 
allowing the former, but I would strongly prefer that the not allow the 
latter.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Sun Jul 11 11:06: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 LAA25892
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 11:06: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 i6BEkbcq097692;
	Sun, 11 Jul 2004 07:46: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 i6BEkbo6097691;
	Sun, 11 Jul 2004 07:46:37 -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 i6BEka5H097683
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 07:46: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 i6BEl8Im031787;
	Sun, 11 Jul 2004 10:47:11 -0400
Message-ID: <40F152CA.5000000@intertwingly.net>
Date: Sun, 11 Jul 2004 10:46:34 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: MUST be UTC?
References: <CFE2B52D-D2D4-11D8-A6B6-003065EA6144@geckotribe.com> <1A0E593A-D2E5-11D8-9A61-000A95BD86C0@mnot.net> <opsay810jeuvpchu@quark>
In-Reply-To: <opsay810jeuvpchu@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, 10 Jul 2004 19:50:43 -0700, Mark Nottingham <mnot@mnot.net> wrote:
> 
>> Rather than invent yet another date/time syntax, and thereby make it  
>> difficult for people to reuse existing software, couldn't we indicate  
>> that the time zone is unknown by a mechanism external to the 
>> date/time  string?
> 
> In what cases would the timezone be unknown, exactly? Just wondering.

LiveJournal.  See http://www.livejournal.com/update.bml?mode=full

In addition to newly entered dates and times, LiveJournal has a database 
full of existing dates and times with unknown timezones.

>> In other words, instead of allowing a date/time string without a time  
>> zone, perhaps we could have a new attribute that indicates that the 
>> time  zone isn't to be relied upon?
> 
> Perhaps. I don't like the current state of affairs, at least, where we  
> seem to be inventing our own datetime format, and violating the format 
> we  say we're using; W3CDTF.

W3CDTF is merely a profile of ISO-8601.  ISO-8601 permits dates without 
a time zone.

>> <atom:issued unsureTimeZone="1">2004-02-04T10:23:45Z</atom:issued>
> 
> Looks like a suggestion as good as any, but I just wonder what the 
> usecase  for not having timezone is, and why it's missing?

See above.

- Sam Ruby




From owner-atom-syntax@mail.imc.org  Sun Jul 11 11:16: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 LAA26241
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 11:16: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 i6BEoXcn098026;
	Sun, 11 Jul 2004 07: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 i6BEoXCM098025;
	Sun, 11 Jul 2004 07: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 i6BEoXsj098017
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 07:50:33 -0700 (PDT)
	(envelope-from asbjorn@tigerstaden.no)
Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19])
	by smtpgateway.itweb.no (Postfix) with ESMTP
	id 86EF87C117; Sun, 11 Jul 2004 17:48:58 +0200 (CEST)
Date: Sun, 11 Jul 2004 16:54:05 +0200
To: "Sascha Carlin" <sc@itst.org>
Subject: Re: MUST be UTC?
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <87smc0qcnk.fsf@nwalsh.com> <40F0B613.9020909@itst.org>
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: <opsazacflzuvpchu@quark>
In-Reply-To: <40F0B613.9020909@itst.org>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 11 Jul 2004 05:37:55 +0200, Sascha Carlin <sc@itst.org> wrote:

> atom:timezone could have the format [+|-]dddd.dd, for instance.

If it's a way to make the content of atom:timezone a valid format in  
respect to e.g. ISO 8601, then this is imho a good proposal. Authors and  
readers get what they want from having the local timezone specified, we  
don't have to create quirky date constructs or specification text, and  
aggregator writers get datetimes that's a lot nicer to work with.

A +1 to this one. Sascha; could you maybe write up a pace, so we get this  
down «on paper»?

-- 
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 Jul 11 11:18: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 LAA26331
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 11:18: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 i6BFBX0d000135;
	Sun, 11 Jul 2004 08: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 i6BFBXTl000134;
	Sun, 11 Jul 2004 08:11:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf20.cluster1.charter.net (mxsf20.cluster1.charter.net [209.225.28.220])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BFBWlP000122
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 08:11:32 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip15.cluster1.charter.net (mxip15a.cluster1.charter.net [209.225.28.145])
	by mxsf20.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6BFFWat002868
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 11:15:32 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip15.cluster1.charter.net with ESMTP; 11 Jul 2004 11:11:28 -0400
X-Ironport-AV: i="3.81R,160,1083556800"; 
   d="scan'208"; a="106686849:sNHT15021076"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1Bjfz4-0005on-00
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 11:11:18 -0400
To: Atom Syntax <atom-syntax@imc.org>
Subject: Version attribute on atom:entry
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Sun, 11 Jul 2004 11:11:16 -0400
Message-ID: <87smbymve3.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: <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-Type: text/plain

The spec says

  If used alone, atom:entry elements MUST have a "version" attribute
  whose content indicates the version of the Atom specification that
  the construct conforms to.

Is version allowed on atom:entry if the element is not used alone, if
it occurs in a feed?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Do not try to live forever. You will
http://nwalsh.com/            | not succeed.--George Bernard Shaw

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA8ViWOyltUcwYWjsRAoazAJ9384jHhXkVA4UEMo9CNmIwRjRLwgCeIbpZ
gNZItj+wtDMheaoov7euswo=
=iiAs
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Sun Jul 11 11: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 LAA26410
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 11:21: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 i6BF6gqi099505;
	Sun, 11 Jul 2004 08:06: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 i6BF6gK4099504;
	Sun, 11 Jul 2004 08:06: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 (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BF6fb9099495
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 08:06: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 0C5DC7C125; Sun, 11 Jul 2004 18:05:07 +0200 (CEST)
Date: Sun, 11 Jul 2004 17:10:17 +0200
To: "Sam Ruby" <rubys@intertwingly.net>
Subject: Re: MUST be UTC?
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <CFE2B52D-D2D4-11D8-A6B6-003065EA6144@geckotribe.com> <1A0E593A-D2E5-11D8-9A61-000A95BD86C0@mnot.net> <opsay810jeuvpchu@quark> <40F152CA.5000000@intertwingly.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: <opsaza3fttuvpchu@quark>
In-Reply-To: <40F152CA.5000000@intertwingly.net>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 11 Jul 2004 10:46:34 -0400, Sam Ruby <rubys@intertwingly.net>  
wrote:

>>  In what cases would the timezone be unknown, exactly? Just wondering.
>
> LiveJournal.  See http://www.livejournal.com/update.bml?mode=full

Oh, okay.

> In addition to newly entered dates and times, LiveJournal has a database  
> full of existing dates and times with unknown timezones.

The times in those dates is rather meaningless, aren't they? If an author  
lives in the timezone +10:00, the time '08:00' don't really mean anything.  
Therefore; would it be a solution to either:

   1) Have all users enter their timezone one place in the system, to
      change all times (and possibly dates) that user has entered?

   2) Append 'UTC' to all timezone-less dates in the database?

2) would imho not make the dates less useful than they currently are, but  
1) seems like the best solution. I think we can agree on that not storing  
timezones in LiveJournal is b0rked from the very beginning. I also hope we  
can agree on that Atom shouldn't adapt itself to b0rked implementations,  
if those implementations can be fixed.

> W3CDTF is merely a profile of ISO-8601.

Yes, but it's a neat and extremely simple profile that I think fits Atom  
pretty much like a hand in a glove.

> ISO-8601 permits dates without a time zone.

I know, but imho Atom shouldn't. There are cases where one would want to  
conform to ISO-8601 and not store timezone, e.g. in an publishing system  
only intended for local customers. But whenever you're talking about  
exchanging information across borders, the timezone informatin is not only  
important, but vital to the date stored with the information.

-- 
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 Jul 11 11:22:58 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26464
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 11:22:58 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BFEGna000469;
	Sun, 11 Jul 2004 08:14: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 i6BFEGbc000468;
	Sun, 11 Jul 2004 08:14:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web41507.mail.yahoo.com (web41507.mail.yahoo.com [66.218.93.90])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6BFEFA5000436
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 08:14:15 -0700 (PDT)
	(envelope-from randymorin@yahoo.com)
Message-ID: <20040711151411.58345.qmail@web41507.mail.yahoo.com>
Received: from [24.43.182.164] by web41507.mail.yahoo.com via HTTP; Sun, 11 Jul 2004 08:14:11 PDT
Date: Sun, 11 Jul 2004 08:14:11 -0700 (PDT)
From: Randy Charles Morin <randymorin@yahoo.com>
Reply-To: randy@kbcafe.com
Subject: Re: Created proposal: PaceProvideSchema 
To: "Asbjørn_Ulsberg" <asbjorn@tigerstaden.no>, randy@kbcafe.com
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <opsay9lsx5uvpchu@quark>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1726090577-1089558851=:57868"
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>


--0-1726090577-1089558851=:57868
Content-Type: text/plain; charset=us-ascii

Asbjørn_Ulsberg <asbjorn@tigerstaden.no> wrote:
>That's understandable. This is imho a flaw in XSD, though.
 
No, it is a feature. Writing a validator that accounts for cardinality of ordered elements is substantially more difficult.

>What do you mean, «not expressible»? Isn't it possible to say 'xs:anyType' 
>with any namespace to be the the child of atom:content, or is it something 
>else that is impossible to express?
 
Correct. Let me rephrase. You cannot accurately express contentType such that tools like XSD.exe can generate the corresponding data model, without some loss of type definition.
Thanks,
 
Randy
http://www.kbcafe.com
 

		
---------------------------------
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
--0-1726090577-1089558851=:57868
Content-Type: text/html; charset=us-ascii

<DIV><STRONG><EM>Asbjørn_Ulsberg &lt;asbjorn@tigerstaden.no&gt;</EM></STRONG> wrote:</DIV>
<DIV>&gt;That's understandable. This is imho a flaw in XSD, though.</DIV>
<DIV>&nbsp;</DIV>
<DIV>No,&nbsp;it&nbsp;is a feature. Writing a validator that accounts for cardinality of ordered elements is substantially more difficult.<BR><BR>&gt;What do you mean, «not expressible»? Isn't it possible to say 'xs:anyType' </DIV>
<DIV>&gt;with any namespace to be the the child of atom:content, or is it something </DIV>
<DIV>&gt;else that is impossible to express?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Correct. Let me rephrase. You cannot accurately express contentType such that tools like XSD.exe can generate the corresponding data model, without some loss of type definition.</DIV>
<DIV>Thanks,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Randy</DIV>
<DIV><A href="http://www.kbcafe.com">http://www.kbcafe.com</A></DIV>
<DIV>&nbsp;</DIV><p>
		<hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/mail_us/taglines/50x/*http://promotions.yahoo.com/new_mail/static/efficiency.html">Yahoo! Mail</a> - 50x more storage than other providers!
--0-1726090577-1089558851=:57868--



From owner-atom-syntax@mail.imc.org  Sun Jul 11 11:31: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 LAA26690
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 11:31: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 i6BFNHfG001083;
	Sun, 11 Jul 2004 08:23:17 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6BFNHYP001082;
	Sun, 11 Jul 2004 08:23:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.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 i6BFNHUs001076
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 08:23:17 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.19] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP id 2044D727D
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 08:23:20 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v618)
In-Reply-To: <874qoeobnk.fsf@nwalsh.com>
References: <20040711002331.70993.qmail@web41208.mail.yahoo.com> <53518515-D2E7-11D8-9DBF-000A95A51C9E@sun.com> <874qoeobnk.fsf@nwalsh.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <3C8A053C-D34E-11D8-9A61-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: Craeted proposal: PaceProvideSchema
Date: Sun, 11 Jul 2004 08:23:18 -0700
To: Atom Syntax <atom-syntax@imc.org>
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>
Content-Transfer-Encoding: 7bit



On Jul 11, 2004, at 7:34 AM, Norman Walsh wrote:
> For the record, I'm completely comfortable with a non-normative
> schema.

+1


--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Sun Jul 11 11: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 LAA26711
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 11:32: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 i6BFL6EZ000950;
	Sun, 11 Jul 2004 08:21: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 i6BFL6eE000949;
	Sun, 11 Jul 2004 08:21:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf14.cluster1.charter.net (mxsf14.cluster1.charter.net [209.225.28.214])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BFL5ni000934
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 08:21:05 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip15.cluster1.charter.net (mxip15a.cluster1.charter.net [209.225.28.145])
	by mxsf14.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6BFOP3k013136
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 11:24:25 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip15.cluster1.charter.net with ESMTP; 11 Jul 2004 11:21:02 -0400
X-Ironport-AV: i="3.81R,160,1083556800"; 
   d="scan'208"; a="106714290:sNHT14673982"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1Bjg8J-0005r6-00
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 11:20:51 -0400
To: Atom Syntax <atom-syntax@imc.org>
Subject: atom:author in feed and entry
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Sun, 11 Jul 2004 11:20:50 -0400
Message-ID: <87oemmmuy5.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: <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-Type: text/plain

The draft 00 spec says "atom:feed elements MUST contain exactly one
atom:author element, UNLESS all of the atom:feed element's child
atom:entry elements contain an atom:author element".

May the atom:feed element contain an atom:author if all of the
relevant atom:entry elements ALSO contain an atom:author?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | What are the thoughts of the canvas on
http://nwalsh.com/            | which a masterpiece is being created?
                              | "I am being soiled, brutally treated
                              | and concealed from view." Thus men
                              | grumble at their destiny, however
                              | fair.--Jean Cocteau

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA8VrSOyltUcwYWjsRAhr7AKCJiPE8juviK55gmTkZ2nVikaMdAACgjX1v
VkzsI4a4A53doZrLWm7rDR8=
=r6E9
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Sun Jul 11 11:39: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 LAA26931
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 11:39: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 i6BFOT4u001142;
	Sun, 11 Jul 2004 08:24: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 i6BFOTUK001141;
	Sun, 11 Jul 2004 08:24:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web41501.mail.yahoo.com (web41501.mail.yahoo.com [66.218.93.84])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6BFOSds001124
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 08:24:28 -0700 (PDT)
	(envelope-from randymorin@yahoo.com)
Message-ID: <20040711152426.7536.qmail@web41501.mail.yahoo.com>
Received: from [24.43.182.164] by web41501.mail.yahoo.com via HTTP; Sun, 11 Jul 2004 08:24:26 PDT
Date: Sun, 11 Jul 2004 08:24:26 -0700 (PDT)
From: Randy Charles Morin <randymorin@yahoo.com>
Reply-To: randy@kbcafe.com
Subject: Re: Created proposal: PaceProvideSchema 
To: randy@kbcafe.com, "Asbjørn_Ulsberg" <asbjorn@tigerstaden.no>
Cc: Atom-Syntax <atom-syntax@imc.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-638961226-1089559466=:7486"
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>


--0-638961226-1089559466=:7486
Content-Type: text/plain; charset=us-ascii

Randy Charles Morin <randymorin@yahoo.com> wrote:
>Writing a validator that accounts for cardinality of ordered 
>elements is substantially more difficult.
 
That should have been "cardinality of unordered elements".
Thanks,
 
Randy
http://www.kbcafe.com
 


		
---------------------------------
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
--0-638961226-1089559466=:7486
Content-Type: text/html; charset=us-ascii

<DIV><B><I>Randy Charles Morin &lt;randymorin@yahoo.com&gt;</I></B> wrote:</DIV>
<DIV>
<DIV>&gt;Writing a validator that accounts for cardinality of ordered </DIV>
<DIV>&gt;elements is substantially more difficult.</DIV>
<DIV>&nbsp;</DIV>
<DIV>That should have been "cardinality of unordered elements".</DIV>
<DIV>Thanks,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Randy</DIV>
<DIV><A href="http://www.kbcafe.com">http://www.kbcafe.com</A></DIV>
<DIV>&nbsp;</DIV></DIV><p>
		<hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/mail_us/taglines/aac/*http://promotions.yahoo.com/new_mail/static/ease.html">Yahoo! Mail Address AutoComplete</a> - You start. We finish.
--0-638961226-1089559466=:7486--



From owner-atom-syntax@mail.imc.org  Sun Jul 11 11:43:23 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27035
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 11:43:22 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BFSaxV001494;
	Sun, 11 Jul 2004 08:28: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 i6BFSa7V001493;
	Sun, 11 Jul 2004 08:28:36 -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 SMTP id i6BFSZLT001487
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 08:28:36 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d15so223625rng
        for <atom-syntax@imc.org>; Sun, 11 Jul 2004 08:28:36 -0700 (PDT)
Received: by 10.38.71.13 with SMTP id t13mr79127rna;
        Sun, 11 Jul 2004 08:28:36 -0700 (PDT)
Message-ID: <14be96d304071108284f50396@mail.gmail.com>
Date: Sun, 11 Jul 2004 11:28:36 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Norman Walsh <ndw@nwalsh.com>
Subject: Re: atom:summary or atom:content required?
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <87wu1amwtn.fsf@nwalsh.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <87wu1amwtn.fsf@nwalsh.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, 11 Jul 2004 10:40:20 -0400, Norman Walsh <ndw@nwalsh.com> wrote:
> Is an entry required to have at least one of atom:summary or
> atom:content?

Not currently.

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Sun Jul 11 11: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 LAA27173
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 11:47: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 i6BFXK90001750;
	Sun, 11 Jul 2004 08:33: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 i6BFXKAI001749;
	Sun, 11 Jul 2004 08:33: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 i6BFXJlT001743
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 08:33:19 -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 i6BFXuTv001717;
	Sun, 11 Jul 2004 11:33:56 -0400
Message-ID: <40F15DC2.3060307@intertwingly.net>
Date: Sun, 11 Jul 2004 11:33:22 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: MUST be UTC?
References: <CFE2B52D-D2D4-11D8-A6B6-003065EA6144@geckotribe.com> <1A0E593A-D2E5-11D8-9A61-000A95BD86C0@mnot.net> <opsay810jeuvpchu@quark> <40F152CA.5000000@intertwingly.net> <opsaza3fttuvpchu@quark>
In-Reply-To: <opsaza3fttuvpchu@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:

> I 
> also hope we  can agree on that Atom shouldn't adapt itself to b0rked 
> implementations,  if those implementations can be fixed.

Let's try to avoid terms like b0rked, and if you would like people to be 
respectful of limitations that affect you (example: 
<http://www.imc.org/atom-syntax/mail-archive/msg05239.html>), then 
perhaps taking the time to understand the perspective of others.

LiveJournal has a large customer base, who to date have seen value in 
expressing time in relative and personal terms.  To live journal users, 
knowing that an entry was penned at 2am in the subjective frame of 
reference of the author is much more significant piece of information 
than knowing what this time corresponds to in a canonical time 
corresponding to a place in a country that they may never visit.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Sun Jul 11 11: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 LAA27256
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 11:48: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 i6BFeADn002169;
	Sun, 11 Jul 2004 08:40: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 i6BFeAbI002168;
	Sun, 11 Jul 2004 08:40: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 i6BFe9fu002162
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 08:40: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 i6BFejIg002040;
	Sun, 11 Jul 2004 11:40:46 -0400
Message-ID: <40F15F5C.1080102@intertwingly.net>
Date: Sun, 11 Jul 2004 11:40:12 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Norman Walsh <ndw@nwalsh.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Version attribute on atom:entry
References: <87smbymve3.fsf@nwalsh.com>
In-Reply-To: <87smbymve3.fsf@nwalsh.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


Norman Walsh wrote:

> The spec says
> 
>   If used alone, atom:entry elements MUST have a "version" attribute
>   whose content indicates the version of the Atom specification that
>   the construct conforms to.
> 
> Is version allowed on atom:entry if the element is not used alone, if
> it occurs in a feed?

I would prefer that version attributes be limited to root elements of 
XML documents.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Sun Jul 11 11:59: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 LAA27870
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 11:59: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 i6BFoEu2002786;
	Sun, 11 Jul 2004 08:50: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 i6BFoEZP002785;
	Sun, 11 Jul 2004 08:50:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BFoDcB002777
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 08:50:14 -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 32BAC7C117; Sun, 11 Jul 2004 18:48:39 +0200 (CEST)
Date: Sun, 11 Jul 2004 17:53:58 +0200
To: "Sam Ruby" <rubys@intertwingly.net>
Subject: Re: MUST be UTC?
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <CFE2B52D-D2D4-11D8-A6B6-003065EA6144@geckotribe.com> <1A0E593A-D2E5-11D8-9A61-000A95BD86C0@mnot.net> <opsay810jeuvpchu@quark> <40F152CA.5000000@intertwingly.net> <opsaza3fttuvpchu@quark> <40F15DC2.3060307@intertwingly.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: <opsazc38qcuvpchu@quark>
In-Reply-To: <40F15DC2.3060307@intertwingly.net>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 11 Jul 2004 11:33:22 -0400, Sam Ruby <rubys@intertwingly.net>  
wrote:

> Let's try to avoid terms like b0rked

Very true. Sorry about that.

> then perhaps taking the time to understand the perspective of others.

Agreed, although I hope someone would agree that the situation of  
LiveJournal is easier to «fix» than the situation for the unpriviledged  
users[1]. To make the entries in LiveJournal work with a stricter datetime  
format in Atom, we «just» need the users to enter their timezone offset,  
and all their entries can be served with the offset information as  
supplied, or converted to UTC.

> LiveJournal has a large customer base, who to date have seen value in  
> expressing time in relative and personal terms.

Though this perspective is incomprehensible to me, I accept that this is  
the current situation, but I hope that it can be worked on to make it  
better and easier for other tools to work with LiveJournal's entry dates.

> To live journal users, knowing that an entry was penned at 2am in the
> subjective frame of reference of the author is much more significant
> piece of information than knowing what this time corresponds to in a
> canonical time corresponding to a place in a country that they may
> never visit.

And that's something I can understand, but outside the author's very  
narrow worlds, the timezone is very important. While '08:00' means «08:00  
where I live» for the author and some of its audience, it doesn't mean  
diddlysquat to everyone else. Therefore, I think we need timezone in the  
entries. Either as '+10:00' in the date constructs, or as Sascha Carlin  
proposed; in a separate element.

This way, the authors can still express what time of the day in their  
local time the entry was written, as well as providing useful information  
to aggregator tools trying to (automatically) do something fun with their  
entries.

____
[1] <url: http://intertwingly.net/wiki/pie/UnprivilegedUsers>

-- 
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 Jul 11 12:06: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 MAA28168
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 12:06:09 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BFvsld004357;
	Sun, 11 Jul 2004 08:57: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 i6BFvsa1004356;
	Sun, 11 Jul 2004 08:57: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 (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BFvqVm004345
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 08:57: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 60B507C117; Sun, 11 Jul 2004 18:56:18 +0200 (CEST)
To: randy@kbcafe.com
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Created proposal: PaceProvideSchema 
References: <20040711151411.58345.qmail@web41507.mail.yahoo.com>
Message-ID: <opsazdg2vzuvpchu@quark>
Date: Sun, 11 Jul 2004 18:01:40 +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: <20040711151411.58345.qmail@web41507.mail.yahoo.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 11 Jul 2004 08:14:11 -0700 (PDT), Randy Charles Morin  
<randymorin@yahoo.com> wrote:

>> That's understandable. This is imho a flaw in XSD, though.
>
> No, it is a feature. Writing a validator that accounts for cardinality  
> of unordered elements is substantially more difficult.

Does RNG have this restrictive «feature» as well?

> You cannot accurately express contentType such that tools like XSD.exe
> can generate the corresponding data model, without some loss of type
> definition.

What is «loss of type definition», then? How serious is it? What's lost,  
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  Sun Jul 11 12:13:38 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28423
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 12:13: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 i6BFvcHO004335;
	Sun, 11 Jul 2004 08:57: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 i6BFvcfh004334;
	Sun, 11 Jul 2004 08:57:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BFvc7B004325
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 08:57:38 -0700 (PDT)
	(envelope-from NED+atom@mauve.mrochek.com)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243)
 id <01LCAZF4LPVK0061HF@mauve.mrochek.com> for atom-syntax@imc.org; Sun,
 11 Jul 2004 08:57:31 -0700 (PDT)
Date: Sun, 11 Jul 2004 08:55:34 -0700 (PDT)
From: NED+atom@mauve.mrochek.com
Subject: Re: MUST be UTC?
In-reply-to: "Your message dated Sun, 11 Jul 2004 11:33:22 -0400"
 <40F15DC2.3060307@intertwingly.net>
To: Sam Ruby <rubys@intertwingly.net>
Cc: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>,
        Atom-Syntax <atom-syntax@imc.org>
Message-id: <01LCBVDE4EQ20061HF@mauve.mrochek.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <CFE2B52D-D2D4-11D8-A6B6-003065EA6144@geckotribe.com>
 <1A0E593A-D2E5-11D8-9A61-000A95BD86C0@mnot.net> <opsay810jeuvpchu@quark>
 <40F152CA.5000000@intertwingly.net> <opsaza3fttuvpchu@quark>
 <40F15DC2.3060307@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


> LiveJournal has a large customer base, who to date have seen value in
> expressing time in relative and personal terms.  To live journal users,
> knowing that an entry was penned at 2am in the subjective frame of
> reference of the author is much more significant piece of information
> than knowing what this time corresponds to in a canonical time
> corresponding to a place in a country that they may never visit.

I agree 100% with this sentiment. Knowing that something was written at 3:00AM
local can be just as important as knowing exactly when something was written.

				Ned



From owner-atom-syntax@mail.imc.org  Sun Jul 11 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 MAA28512
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 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 i6BG5F01004866;
	Sun, 11 Jul 2004 09:05: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 i6BG5FEX004865;
	Sun, 11 Jul 2004 09:05:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BG5Edd004843
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 09:05:14 -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 B90647C125; Sun, 11 Jul 2004 19:03:39 +0200 (CEST)
Date: Sun, 11 Jul 2004 18:09:03 +0200
To: "Norman Walsh" <ndw@nwalsh.com>
Subject: Re: Version attribute on atom:entry
Cc: "Atom Syntax" <atom-syntax@imc.org>
References: <87smbymve3.fsf@nwalsh.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: <opsazdtdcguvpchu@quark>
In-Reply-To: <87smbymve3.fsf@nwalsh.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 11 Jul 2004 11:11:16 -0400, Norman Walsh <ndw@nwalsh.com> wrote:

> Is version allowed on atom:entry if the element is not used alone, if
> it occurs in a feed?

I hope not! This should probably be noted in the specification, though, no  
matter what's allowed and not. I would say +1 to «The version attribute is  
only allowed on document level elements».

However, it is a valid use case that feeds may contain entries with  
different versions (synthetical feeds). In such situations, it would  
probably be best (although not easiest) to «downgrade» the feed to the  
lowest //entry/@version.

-- 
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 Jul 11 12: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 MAA28530
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 12: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 i6BG5DKE004856;
	Sun, 11 Jul 2004 09: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 i6BG5Da3004855;
	Sun, 11 Jul 2004 09:05:13 -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 i6BG5Dxc004844
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 09:05:13 -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 esmtp (Exim 4.34)
	id 1BjgpB-0006JC-Ah; Sun, 11 Jul 2004 16:05:09 +0000
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Sun, 11 Jul 2004 12:05:15 -0400
Subject: Re: MUST be UTC?
From: Robert Sayre <mint@franklinmint.fm>
To: Sam Ruby <rubys@intertwingly.net>,
        Asbj=?ISO-8859-1?B?+A==?=rn Ulsberg <asbjorn@tigerstaden.no>
CC: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD16DD7B.12D45%mint@franklinmint.fm>
In-Reply-To: <40F15DC2.3060307@intertwingly.net>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
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
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6BG5Dxc004849
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 7/11/04 11:33 AM, "Sam Ruby" <rubys@intertwingly.net> wrote:

> 
> Asbjørn Ulsberg wrote:
> 
>> I 
>> also hope we  can agree on that Atom shouldn't adapt itself to b0rked
>> implementations,  if those implementations can be fixed.
> 
> Let's try to avoid terms like b0rked, and if you would like people to be
> respectful of limitations that affect you (example:
> <http://www.imc.org/atom-syntax/mail-archive/msg05239.html>), then
> perhaps taking the time to understand the perspective of others.
> 
> LiveJournal has a large customer base, who to date have seen value in
> expressing time in relative and personal terms.  To live journal users,
> knowing that an entry was penned at 2am in the subjective frame of
> reference of the author is much more significant piece of information
> than knowing what this time corresponds to in a canonical time
> corresponding to a place in a country that they may never visit.

http://diveintomark.org/archives/

If Atom doesn't have subjective dates, Mark will have to tweak time stamps
to move entries around in the archives. Instead of changing a subjective
field, people will falsify "objective" ones. Now that's b0rked.

Robert Sayre




From owner-atom-syntax@mail.imc.org  Sun Jul 11 12:18:23 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28605
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 12:18: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 i6BG7WbI005240;
	Sun, 11 Jul 2004 09:07: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 i6BG7Wp7005239;
	Sun, 11 Jul 2004 09:07: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 ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BG7V5i005227
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 09:07: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 8F7487C125; Sun, 11 Jul 2004 19:05:52 +0200 (CEST)
To: Ned <NED+atom@mauve.mrochek.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: MUST be UTC?
References: <CFE2B52D-D2D4-11D8-A6B6-003065EA6144@geckotribe.com> <1A0E593A-D2E5-11D8-9A61-000A95BD86C0@mnot.net> <opsay810jeuvpchu@quark> <40F152CA.5000000@intertwingly.net> <opsaza3fttuvpchu@quark> <40F15DC2.3060307@intertwingly.net> <01LCBVDE4EQ20061HF@mauve.mrochek.com>
Message-ID: <opsazdw2rnuvpchu@quark>
Date: Sun, 11 Jul 2004 18:11:16 +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: <01LCBVDE4EQ20061HF@mauve.mrochek.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 11 Jul 2004 08:55:34 -0700 (PDT), <NED+atom@mauve.mrochek.com>  
wrote:

> I agree 100% with this sentiment. Knowing that something was written at  
> 3:00AM local can be just as important as knowing exactly when something
> was written.

Okay, I see the use case, but does it matter to the author if it the time  
is expressed as '03:00+10:00' or '03:00'?

-- 
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 Jul 11 12: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 MAA28726
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 12:20: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 i6BGA0sH005398;
	Sun, 11 Jul 2004 09:10: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 i6BGA0EI005396;
	Sun, 11 Jul 2004 09:10:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf05.cluster1.charter.net (mxsf05.cluster1.charter.net [209.225.28.205])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BG9xBL005382
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 09:10:00 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip11.cluster1.charter.net (mxip11a.cluster1.charter.net [209.225.28.141])
	by mxsf05.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6BGCd9E012982
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 12:12:40 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip11.cluster1.charter.net with ESMTP; 11 Jul 2004 12:09:56 -0400
X-Ironport-AV: i="3.81R,160,1083556800"; 
   d="scan'208"; a="111634596:sNHT15560552"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BjgtW-0006PP-00
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 12:09:38 -0400
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Created proposal: PaceProvideSchema
References: <20040711033526.82786.qmail@web41510.mail.yahoo.com>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Sun, 11 Jul 2004 12:09:35 -0400
In-Reply-To: <20040711033526.82786.qmail@web41510.mail.yahoo.com> (Randy
 Charles Morin's message of "Sat, 10 Jul 2004 20:35:26 -0700 (PDT)")
Message-ID: <87hdsemsow.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: <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-Type: text/plain

/ Randy Charles Morin <randymorin@yahoo.com> was heard to say:
|>That would be unacceptable, the schema and 
|>the prose have to be consistent. -Tim
|
| Atom would have to be substantially rewritten to make this plausible. 
|
| Case #1. You cannot account for cardinality of unordered elements in the feed and entry. This is simply not possible in XSD. There would have to be inconsistency somewhere.
|
| Case #2. The content element is not expressible in XSD.

Uhm. So don't use XSD?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Man is the only animal who causes pain
http://nwalsh.com/            | to others with no other object than
                              | wanting to do so.-- Schopenhauer

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA8WZCOyltUcwYWjsRAmtyAJ46xVt0UrL3gnQZfxcw/jFn1sx/3QCfS5KC
gGp9GCjLhfdug2IKogRiWwM=
=rcle
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Sun Jul 11 12:31: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 MAA29383
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 12:31: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 i6BGEKKT005746;
	Sun, 11 Jul 2004 09:14: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 i6BGEKio005745;
	Sun, 11 Jul 2004 09:14:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BGEIja005737
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 09:14:19 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Mon, 12 Jul 2004 02:19:28 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Mon, 12 Jul 2004 02:14:19 +1000
Subject: Re: Version attribute on atom:entry
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD17A47B.1EDB8%eric.scheid@ironclad.net.au>
In-Reply-To: <40F15F5C.1080102@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: <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 12/7/04 1:40 AM, "Sam Ruby" <rubys@intertwingly.net> wrote:

> I would prefer that version attributes be limited to root elements of
> XML documents.


+1

that's the making of some nice spec text there too.

e.



From owner-atom-syntax@mail.imc.org  Sun Jul 11 12: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 MAA29447
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 12:32: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 i6BGEDpN005733;
	Sun, 11 Jul 2004 09:14: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 i6BGEDGs005732;
	Sun, 11 Jul 2004 09:14:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BGEBMP005726
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 09:14:12 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Mon, 12 Jul 2004 02:19:20 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Mon, 12 Jul 2004 02:14:11 +1000
Subject: Re: Q: modfied vs issued vs created
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD17A473.1EDB8%eric.scheid@ironclad.net.au>
In-Reply-To: <opsay8mlqcuvpchu@quark>
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 i6BGEDMP005727
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 12/7/04 12:16 AM, "Asbjørn Ulsberg" <asbjorn@tigerstaden.no> wrote:
>> They are both talking about the same thing: the weather report for Sat,
>> 10 Jul 2004.

> I know that's how it seems like for the audience. But having worked with
> The Meteorological Institute in Norway (my company is a big client of
> their services) I know that their internal data model stores each of these
> events seperately (for how long, I'm not sure, but they do for at least a
> couple of days). A new forecast doesn't overwrite an old one, even if
> they're reporting the same weather at the same time at the same place.

(1) I did my uni time on VAX/VMS, complete with a versioning file system
(handy for all that COBOL programming I did ... saints preserve me!). A
database that retains a multiple number of older versions is not that
different. Consider too your typical wiki -- any given page can have
multiple versions held. In each of those three cases, we're talking about
the same "thing", they just happen to have multiple versions.

(2) "I know that's how it seems like for the audience". Isn't that what we
should be modelling for? The technical arcana inside the guts of the
publishers' system is of zero interest to most users, surely?

>> Deleting the old one and inserting the new one will only annoy the user
> 
> Why? Do you really think a user cares whether the ID has changed or not?
> If anything, the entries should be related (<link rel="related"> or
> something), but they are, and never will be, the same entry.

They would be annoyed because they would see a "new" entry (because it has a
new ID), even though it is actually a weather report for the same node in
4-space. Right now my aggregator of choice advises me of modifications to a
given entry in the same way it would of a new entry - the entry title
appears in blue and bold. I'm hanging out for a future version that
differentiates modifications of old entries from completely new entries.

e.




From owner-atom-syntax@mail.imc.org  Sun Jul 11 12:32: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 MAA29478
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 12:32:54 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BGHld1006115;
	Sun, 11 Jul 2004 09:17: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 i6BGHl7r006114;
	Sun, 11 Jul 2004 09:17:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BGHk0e006108
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 09:17:46 -0700 (PDT)
	(envelope-from NED+atom@mauve.mrochek.com)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243)
 id <01LCAZF4LPVK0061HF@mauve.mrochek.com> for atom-syntax@imc.org; Sun,
 11 Jul 2004 09:17:48 -0700 (PDT)
Date: Sun, 11 Jul 2004 09:13:10 -0700 (PDT)
From: NED+atom@mauve.mrochek.com
Subject: Re: MUST be UTC?
In-reply-to: "Your message dated Sun, 11 Jul 2004 18:11:16 +0200"
 <opsazdw2rnuvpchu@quark>
To: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
Cc: Atom-Syntax <atom-syntax@imc.org>
Message-id: <01LCBW3J0GY00061HF@mauve.mrochek.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed; delsp=yes; charset=iso-8859-1
Content-transfer-encoding: 7BIT
References: <CFE2B52D-D2D4-11D8-A6B6-003065EA6144@geckotribe.com>
 <1A0E593A-D2E5-11D8-9A61-000A95BD86C0@mnot.net> <opsay810jeuvpchu@quark>
 <40F152CA.5000000@intertwingly.net> <opsaza3fttuvpchu@quark>
 <40F15DC2.3060307@intertwingly.net> <01LCBVDE4EQ20061HF@mauve.mrochek.com>
 <opsazdw2rnuvpchu@quark>
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, 11 Jul 2004 08:55:34 -0700 (PDT), <NED+atom@mauve.mrochek.com>
> wrote:

> > I agree 100% with this sentiment. Knowing that something was written at
> > 3:00AM local can be just as important as knowing exactly when something
> > was written.

> Okay, I see the use case, but does it matter to the author if it the time
> is expressed as '03:00+10:00' or '03:00'?

Presumably the author knows what time zone they're in when the write the
message, so no, it doesn't matter to the author at the time. OTOH, since
computer systems not infrequently botch time zone settings  showing the author
the time zone that's in effect isn't a bad thing to do. I've caught config
problems this way more than once. (Although for J Random User to catch config
errors they may need to see PDT/PST/whatever and not +/-nn:nn.)

				Ned



From owner-atom-syntax@mail.imc.org  Sun Jul 11 12:36: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 MAA29732
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 12:36: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 i6BGJ46V006207;
	Sun, 11 Jul 2004 09:19:04 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6BGJ41e006206;
	Sun, 11 Jul 2004 09:19: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 i6BGJ36e006199
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 09:19: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 i6BGH253023110
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 10:17:02 -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 <0I0P00M753ZU5F@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sun, 11 Jul 2004 10:19:06 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0P00C1B3ZTE4@mail.sun.net> for atom-syntax@imc.org; Sun,
 11 Jul 2004 10:19:06 -0600 (MDT)
Date: Sun, 11 Jul 2004 09:19:07 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: atom:summary or atom:content required?
In-reply-to: <14be96d304071108284f50396@mail.gmail.com>
To: Mark Pilgrim <pilgrim@gmail.com>
Cc: Atom Syntax <atom-syntax@imc.org>, Norman Walsh <ndw@nwalsh.com>
Message-id: <08D5430A-D356-11D8-9DBF-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: <87wu1amwtn.fsf@nwalsh.com>
 <14be96d304071108284f50396@mail.gmail.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 Jul 11, 2004, at 8:28 AM, Mark Pilgrim wrote:

>
> On Sun, 11 Jul 2004 10:40:20 -0400, Norman Walsh <ndw@nwalsh.com> 
> wrote:
>> Is an entry required to have at least one of atom:summary or
>> atom:content?
>
> Not currently.

Should it be? -Tim



From owner-atom-syntax@mail.imc.org  Sun Jul 11 12:37: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 MAA29773
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 12:37: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 i6BGOJkv006776;
	Sun, 11 Jul 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 i6BGOJQP006775;
	Sun, 11 Jul 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 mxsf01.cluster1.charter.net (mxsf01.cluster1.charter.net [209.225.28.201])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BGOIlD006765
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 09:24:19 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip06.cluster1.charter.net (mxip06a.cluster1.charter.net [209.225.28.136])
	by mxsf01.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6BGRG8H009562
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 12:27:16 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip06.cluster1.charter.net with ESMTP; 11 Jul 2004 12:24:16 -0400
X-Ironport-AV: i="3.81R,160,1083556800"; 
   d="scan'208"; a="108221785:sNHT15159364"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1Bjh7V-0006a0-00
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 12:24:05 -0400
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: RELAX NG Grammar for draft-...-00.txt
References: <87eknkow28.fsf@nwalsh.com> <877jtaldla.fsf@nwalsh.com>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Sun, 11 Jul 2004 12:24:05 -0400
In-Reply-To: <877jtaldla.fsf@nwalsh.com> (Norman Walsh's message of "Sun, 11
 Jul 2004 12:21:05 -0400")
Message-ID: <873c3yldga.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: <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-Type: text/plain

/ Norman Walsh <ndw@nwalsh.com> was heard to say:
[...]
| atomDateConstruct =
|    atomCommonAttributes,
|    (xsd:date | xsd:dateTime | xsd:gYearMonth | xsd:gYear)

Urk. This is a cut-and-paste bug. I think we mean xsd:dateTime *only* here.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Everything should be made as simple as
http://nwalsh.com/            | possible, but no simpler.

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA8WmlOyltUcwYWjsRAsoUAKCFTMmCFUU2P5ajs8aPT69H3YXwYwCeJ8lg
vSSuMZ6g9BzweohexvBw0yE=
=7u1q
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Sun Jul 11 12:39:49 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29882
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 12:39:48 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BGSKR3007181;
	Sun, 11 Jul 2004 09:28:20 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6BGSK2C007180;
	Sun, 11 Jul 2004 09:28:20 -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 i6BGSJ0E007170
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 09:28: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 BFD137C117; Sun, 11 Jul 2004 19:26:44 +0200 (CEST)
Date: Sun, 11 Jul 2004 18:32:13 +0200
To: Ned <NED+atom@mauve.mrochek.com>
Subject: Re: MUST be UTC?
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <CFE2B52D-D2D4-11D8-A6B6-003065EA6144@geckotribe.com> <1A0E593A-D2E5-11D8-9A61-000A95BD86C0@mnot.net> <opsay810jeuvpchu@quark> <40F152CA.5000000@intertwingly.net> <opsaza3fttuvpchu@quark> <40F15DC2.3060307@intertwingly.net> <01LCBVDE4EQ20061HF@mauve.mrochek.com> <opsazdw2rnuvpchu@quark> <01LCBW3J0GY00061HF@mauve.mrochek.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: <opsazevziiuvpchu@quark>
In-Reply-To: <01LCBW3J0GY00061HF@mauve.mrochek.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 11 Jul 2004 09:13:10 -0700 (PDT), <NED+atom@mauve.mrochek.com>  
wrote:

>> Okay, I see the use case, but does it matter to the author if it the  
>> time is expressed as '03:00+10:00' or '03:00'?
>
> Presumably the author knows what time zone they're in when the write the
> message, so no, it doesn't matter to the author at the time.

Right. Would it be too much to ask of LiveJournal to have their users  
enter their timezone once, to have the LiveJournal entry's dates conform  
to a stricter specified date construct (requiring timezone) in Atom? I  
don't think that's asking for much.

> OTOH, since computer systems not infrequently botch time zone settings
> showing the author the time zone that's in effect isn't a bad thing to
> do.

True. That would indeed be useful information to a lot of authors.

-- 
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 Jul 11 12:42: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 MAA00005
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 12:42: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 i6BGLQOo006418;
	Sun, 11 Jul 2004 09:21: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 i6BGLQJf006417;
	Sun, 11 Jul 2004 09:21:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf06.cluster1.charter.net (mxsf06.cluster1.charter.net [209.225.28.206])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BGLPOR006405
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 09:21:25 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip06.cluster1.charter.net (mxip06a.cluster1.charter.net [209.225.28.136])
	by mxsf06.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6BGOAA6008620
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 12:24:10 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip06.cluster1.charter.net with ESMTP; 11 Jul 2004 12:21:22 -0400
X-Ironport-AV: i="3.81R,160,1083556800"; 
   d="scan'208"; a="108210167:sNHT16290440"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1Bjh4e-0006W5-00; Sun, 11 Jul 2004 12:21:08 -0400
To: Atom Syntax <atom-syntax@imc.org>, David Pawson <dpawson@nildram.co.uk>
Subject: RELAX NG Grammar for draft-...-00.txt
References: <87eknkow28.fsf@nwalsh.com>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Sun, 11 Jul 2004 12:21:05 -0400
In-Reply-To: <87eknkow28.fsf@nwalsh.com> (Norman Walsh's message of "Sat, 10
 Jul 2004 09:01:35 -0400")
Message-ID: <877jtaldla.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: <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-Type: text/plain

/ Norman Walsh <ndw@nwalsh.com> was heard to say:
| This Pace supports my comment that a schema should be provided as part
| of the Atom format spec. Concretely, I suggest that both a RELAX NG
| grammar and a W3C XML Schema should be provided.

Ok, I started with the draft-...-00.txt spec and (re)built a RELAX NG
Grammar for it. That exercise led to several questions that I've
posted today. Dave and I have agreed offline to work together on
building the grammar and I said I'd take another stab at it.

A few notes:

1. I tried hard to implement exactly what the spec currently says

2. I intentionally structured the grammar like the spec. This may or
may not be a good thing in the long run. I expect the whole thing
could be made to fit on a single page with a little condensing.

3. I created patterns from some types that we might eventually
consider trying to constrain (like media types and language tags), but
I've made no effort to define the constraints.

4. I've added Schematron rules in a few places to test for things that
a grammar based schema can't practically test.

5. The schema can be converted to XSD with some approximation as XSD
is inherently less capable of expressing some kinds of constraints.

Here it is.

# -*- Relax NG -*-

namespace local = ""
namespace atom = "http://purl.org/atom/ns#"
namespace s = "http://www.ascc.net/xml/schematron"

start = atomFeed | atomEntry

# Attribute definitions

atomCommonAttributes =
   attribute xml:base { atomUri }?,
   attribute xml:lang { atomLanguageTag }?

atomVersionAttribute = attribute version { text }

# Common Atom Constructs

atomContentConstruct =
   atomCommonAttributes,
   attribute type { atomRegisteredMediaType }?,
   attribute mode { "xml" | "escaped" | "base64" }?,
   (text|anyElement)*

atomPersonConstruct =
   atomCommonAttributes,
   (element atom:name { text }
    & element atom:url { atomUri }?
    & element atom:email { atomEmailAddress }?)

atomDateConstruct =
   atomCommonAttributes,
   (xsd:date | xsd:dateTime | xsd:gYearMonth | xsd:gYear)

atomLinkConstruct =
   atomCommonAttributes,
   attribute rel {
      "alternate"
    | "start"
    | "next"
    | "prev"
    | "service.edit"
    | "service.post"
    | "service.feed" },
   attribute type { atomMediaType },
   attribute href { atomUri },
   attribute hreflang { atomLanguageTag }?,
   attribute title { text }?,
   empty

# atom:feed
# TODO: Test for multiple atom:link/@rel='alternate' with the same @type
# The following tests are simple to do, but my validator is giving me trouble.
# TODO: Debug and add them back
#       Test for at least one atom:link/@rel='alternate'
#       Test for atom:author or all atom:entry have atom:author

atomFeed =
   element atom:feed {
   atomCommonAttributes,
   atomVersionAttribute,
   (atomTitle
    & atomLink+
    & atomAuthor?
    & atomContributor*
    & atomTagline?
    & atomId?
    & atomGenerator?
    & atomCopyright?
    & atomInfo?
    & atomModified
    & atomEntry*
    & anyElement*)
}

# atom:title

atomTitle = element atom:title { atomContentConstruct }

# atom:link

atomLink = element atom:link { atomLinkConstruct }

# atom:author

atomAuthor = element atom:author { atomPersonConstruct }

# atom:contributor

atomContributor = element atom:contributor { atomPersonConstruct }

# atom:tagline

atomTagline = element atom:tagline { atomContentConstruct }

# atom:id

atomId = element atom:id { atomUri }

# atom:generator

atomGenerator = element atom:generator {
   atomCommonAttributes,
   atomVersionAttribute?,
   attribute url { atomUri }?,
   text
}

# atom:copyright

atomCopyright = element atom:copyright { atomContentConstruct }

# atom:info

atomInfo = element atom:info { atomContentConstruct }

# atom:modified
# TODO: Test for a timezone that SHOULD be UTC

atomModified = element atom:modified { atomDateConstruct }

# atom:entry
# TODO: Test for multiple atom:link @rel='alternate' with the same @type

atomEntry =
   [
      s:rule [
         context = "/atom:entry"
         s:assert [
            test = "@version"
            "The version attribute is required on standalone atom:entry elements."
         ]
      ]
      s:rule [
         context = "atom:entry"
         s:assert [
            test = "atom:link[@rel='alternate']"
            "An atom:entry must have at least one link element with a rel attribute of 'alternate'."
         ]
      ]
      s:rule [
         context = "atom:entry"
         s:assert [
            test = "atom:author or ../atom:author"
            "An atom:entry must have an atom:author if the parent atom:feed does not."
         ]
      ]
   ]
   element atom:entry {
      atomCommonAttributes,
      atomVersionAttribute?,
      (atomTitle
       & atomLink+
       & atomAuthor?
       & atomContributor*
       & atomId?
       & atomModified
       & atomIssued?
       & atomCreated?
       & atomSummary?
       & atomContent?
       & atomCopyright?
       & anyElement*)
   }

# atom:issued

atomIssued = element atom:issued { atomDateConstruct }

# atom:created
# TODO: Test for a timezone that SHOULD be UTC

atomCreated = element atom:created { atomDateConstruct }

# atom:summary

atomSummary = element atom:summary { atomContentConstruct }

# atom:content

atomContent =
   [
      s:rule [
         context = "atom:content"
         s:assert [
            test = "@type != 'multipart/alternative' or not(@mode)"
            "Multipart/alternative content cannot have a mode attribute."
         ]
      ]
      s:rule [
         context = "atom:content"
         s:assert [
            test = "@type = 'multipart/alternative' and *[@type = 'multipart/alternative']"
            "Multipart/alternative content cannot have multipart/alternative children."
         ]
      ]
      s:rule [
         context = "atom:content"
         s:assert [
            test = "@type != 'multipart/alternative' or child::*"
            "Multipart/alternative content must have children content elements."
         ]
      ]
   ]
   element atom:content { atomContentConstruct }

# Low-level simple types

# TODO: can anything more specific be said about these types?

atomMediaType = text
atomRegisteredMediaType = text
atomLanguageTag = text
atomUri = text
atomEmailAddress = text

# Extensibility

anyForeignElement =
   element * - (atom:* | local:*)
   {
      (attribute * { text }
       | text
       | anyForeignElement)*
   }

anyForeignAttribute =
   attribute * - (atom:* | local:* | xml:*) { text }

anyElement =
   element * - local:*
   {
      (attribute * { text }
       | text
       | anyElement)*
   }

# EOF

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Everything should be made as simple as
http://nwalsh.com/            | possible, but no simpler.

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA8Wj0OyltUcwYWjsRAv/gAKCduO1BX/n9D/lxFN+2wMADzSokJwCfc+3F
FUgflzjBqMdlYhGw0y5S4k0=
=Ze34
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Sun Jul 11 12: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 MAA00247
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 12: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 i6BGa7b7008077;
	Sun, 11 Jul 2004 09:36:07 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6BGa7v6008076;
	Sun, 11 Jul 2004 09:36:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf18.cluster1.charter.net (mxsf18.cluster1.charter.net [209.225.28.218])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BGa6Ai008065
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 09:36:06 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip12.cluster1.charter.net (mxip12a.cluster1.charter.net [209.225.28.142])
	by mxsf18.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6BGdqxs022881
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 12:39:52 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip12.cluster1.charter.net with ESMTP; 11 Jul 2004 12:36:02 -0400
X-Ironport-AV: i="3.81R,160,1083556800"; 
   d="scan'208"; a="111329852:sNHT15861546"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BjhIt-0006h9-00
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 12:35:51 -0400
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Version vs. Namespace
References: <87smbymve3.fsf@nwalsh.com>
	<B40394C3-D356-11D8-9A61-000A95BD86C0@mnot.net>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Sun, 11 Jul 2004 12:35:48 -0400
In-Reply-To: <B40394C3-D356-11D8-9A61-000A95BD86C0@mnot.net> (Mark
 Nottingham's message of "Sun, 11 Jul 2004 09:23:54 -0700")
Message-ID: <87llhqjycb.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: <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-Type: text/plain

/ Mark Nottingham <mnot@mnot.net> was heard to say:
| I'd phrase the question in a slightly different manner;
|
| Why do we have a version attribute at all? Why not rely upon the XML
| namespace to identify the version of the Atom document?

Because changing namespace names is about the most traumatic thing you
can do to a document. It breaks every single tool that is doing a
proper namespace-based comparison of element names. All the XSLT
stylesheets stop functioning, all the DOM tools that use the ...NS()
accessors stop working, etc.

A version attribute lets us make small changes and corrections to the
spec over time without breaking everything.

It strikes me that we need to specify the rules for processing Atom
documents that have a version that isn't recognized. We may also want
to add an atom:mustUnderstand attribute globally.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Do not try to live forever. You will
http://nwalsh.com/            | not succeed.--George Bernard Shaw

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA8WxnOyltUcwYWjsRAtkEAJ9iagzG6lKfrPuh3FZgLNKTRYvrzQCghkyT
79+WxjzRMMTNJ55/WNy14jc=
=/hok
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Sun Jul 11 12:50:37 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00347
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 12: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 i6BGNrfW006733;
	Sun, 11 Jul 2004 09:23: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 i6BGNr0n006732;
	Sun, 11 Jul 2004 09:23:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.mnot.net (adsl-67-119-69-242.dsl.sntc01.pacbell.net [67.119.69.242])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BGNr4a006726
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 09:23:53 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.19] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id 654D5727D; Sun, 11 Jul 2004 09:23:56 -0700 (PDT)
In-Reply-To: <87smbymve3.fsf@nwalsh.com>
References: <87smbymve3.fsf@nwalsh.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <B40394C3-D356-11D8-9A61-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: Atom Syntax <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: Version vs. Namespace
Date: Sun, 11 Jul 2004 09:23:54 -0700
To: Norman Walsh <ndw@nwalsh.com>
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>
Content-Transfer-Encoding: 7bit


I'd phrase the question in a slightly different manner;

Why do we have a version attribute at all? Why not rely upon the XML 
namespace to identify the version of the Atom document?


On Jul 11, 2004, at 8:11 AM, Norman Walsh wrote:

> The spec says
>
>   If used alone, atom:entry elements MUST have a "version" attribute
>   whose content indicates the version of the Atom specification that
>   the construct conforms to.
>
> Is version allowed on atom:entry if the element is not used alone, if
> it occurs in a feed?
>
>                                         Be seeing you,
>                                           norm
>
> -- 
> Norman Walsh <ndw@nwalsh.com> | Do not try to live forever. You will
> http://nwalsh.com/            | not succeed.--George Bernard Shaw
>

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Sun Jul 11 13: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 NAA01157
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 13:09: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 i6BGlYko009240;
	Sun, 11 Jul 2004 09: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 i6BGlYdq009239;
	Sun, 11 Jul 2004 09:47:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web41501.mail.yahoo.com (web41501.mail.yahoo.com [66.218.93.84])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6BGlYoD009227
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 09:47:34 -0700 (PDT)
	(envelope-from randymorin@yahoo.com)
Message-ID: <20040711164732.22973.qmail@web41501.mail.yahoo.com>
Received: from [24.43.182.164] by web41501.mail.yahoo.com via HTTP; Sun, 11 Jul 2004 09:47:32 PDT
Date: Sun, 11 Jul 2004 09:47:32 -0700 (PDT)
From: Randy Charles Morin <randymorin@yahoo.com>
Reply-To: randy@kbcafe.com
Subject: Re: Created proposal: PaceProvideSchema 
To: "Asbjørn_Ulsberg" <asbjorn@tigerstaden.no>, randy@kbcafe.com
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <opsazdg2vzuvpchu@quark>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1888875369-1089564452=:22437"
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>


--0-1888875369-1089564452=:22437
Content-Type: text/plain; charset=us-ascii

Asbjørn_Ulsberg <asbjorn@tigerstaden.no> wrote:
>Does RNG have this restrictive «feature» as well?
 
Good question. Anybody know the answer? Regardless, RNG is not supported by many developer tools [1]. 

>What is «loss of type definition», then? 
>How serious is it? What's lost, exactly?

I'll describe two losses present in my Atom XSD [2].
 
#1 - The schema, run thru XSD.exe [3] or WSDL.exe [4] to generate C#, does not limit the amount of title elements present within a feed or entry element. This is because of the limitation above.
 
#2 - In my attempt to describe the content multipart/alternative construct in XSD, the XSD.exe tool complained saying that the XSD is not deterministic. That's because the content element has two possible parents, one of which is itself.
Thanks and hope this helps,
 
Randy
http://www.kbcafe.com
 
[1] - http://www.relaxng.org/#code-generators
[2] - http://www.kbcafe.com/rss/?guid=20040710135750
[3] - http://msdn.microsoft.com/library/en-us/cptools/html/cpconXMLSchemaDefinitionToolXsdexe.asp
[4] - http://msdn.microsoft.com/library/en-us/cptools/html/cpgrfWebServicesDescriptionLanguageToolWsdlexe.asp
 

		
---------------------------------
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
--0-1888875369-1089564452=:22437
Content-Type: text/html; charset=us-ascii

<DIV><STRONG><EM>Asbjørn_Ulsberg &lt;asbjorn@tigerstaden.no&gt;</EM></STRONG> wrote:</DIV>
<DIV>&gt;Does RNG have this restrictive «feature» as well?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Good question. Anybody know the answer? Regardless, RNG is not supported by many developer tools [1]. <BR></DIV>
<DIV>&gt;What is «loss of type definition», then? </DIV>
<DIV>&gt;How serious is it? What's lost, exactly?<BR><BR>I'll describe two losses present in my Atom XSD [2].</DIV>
<DIV>&nbsp;</DIV>
<DIV>#1 - The schema, run thru XSD.exe [3] or WSDL.exe [4] to generate C#, does not limit the amount of title elements present within a feed or entry element. This is because of the limitation above.</DIV>
<DIV>&nbsp;</DIV>
<DIV>#2 -&nbsp;In my&nbsp;attempt to describe the content multipart/alternative construct in XSD, the XSD.exe&nbsp;tool complained saying that the XSD is not deterministic. That's because the content element has two possible parents, one of which is itself.</DIV>
<DIV>Thanks and hope this helps,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Randy</DIV>
<DIV><A href="http://www.kbcafe.com">http://www.kbcafe.com</A></DIV>
<DIV>&nbsp;</DIV>
<DIV>[1] - <A href="http://www.relaxng.org/#code-generators">http://www.relaxng.org/#code-generators</A></DIV>
<DIV>[2] - <A href="http://www.kbcafe.com/rss/?guid=20040710135750">http://www.kbcafe.com/rss/?guid=20040710135750</A></DIV>
<DIV>[3] - <A href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cptools/html/cpconXMLSchemaDefinitionToolXsdexe.asp">http://msdn.microsoft.com/library/en-us/cptools/html/cpconXMLSchemaDefinitionToolXsdexe.asp</A></DIV>
<DIV>[4] - <A href="http://msdn.microsoft.com/library/en-us/cptools/html/cpgrfWebServicesDescriptionLanguageToolWsdlexe.asp">http://msdn.microsoft.com/library/en-us/cptools/html/cpgrfWebServicesDescriptionLanguageToolWsdlexe.asp</A></DIV>
<DIV>&nbsp;</DIV><p>
		<hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/mail_us/taglines/50x/*http://promotions.yahoo.com/new_mail/static/efficiency.html">Yahoo! Mail</a> - 50x more storage than other providers!
--0-1888875369-1089564452=:22437--



From owner-atom-syntax@mail.imc.org  Sun Jul 11 13: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 NAA01367
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 13:14:12 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BGwNSj010184;
	Sun, 11 Jul 2004 09:58: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 i6BGwNAJ010183;
	Sun, 11 Jul 2004 09:58: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 i6BGw5he010146
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 09:58: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 i6BGwgja005728;
	Sun, 11 Jul 2004 12:58:42 -0400
Message-ID: <40F171A0.5080801@intertwingly.net>
Date: Sun, 11 Jul 2004 12:58:08 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <Tim.Bray@Sun.COM>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: atom:summary or atom:content required?
References: <87wu1amwtn.fsf@nwalsh.com> <14be96d304071108284f50396@mail.gmail.com> <08D5430A-D356-11D8-9DBF-000A95A51C9E@sun.com>
In-Reply-To: <08D5430A-D356-11D8-9DBF-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:
> 
> On Jul 11, 2004, at 8:28 AM, Mark Pilgrim wrote:
> 
>> On Sun, 11 Jul 2004 10:40:20 -0400, Norman Walsh <ndw@nwalsh.com> wrote:
>>
>>> Is an entry required to have at least one of atom:summary or
>>> atom:content?
>>
>> Not currently.
> 
> Should it be? -Tim

For a historical perspective, neither RSS 1.0 nor RSS 2.0 require 
titles. (*)

If you do a current search on «"title only" feed», you will find that 
such feeds are(1) still being produced, and (2) widely disliked by 
consumers.

- Sam Ruby

(*) More history:
   - In 0.91, title is required, description is optional
   - In 0.92, neither title nor description is required.
   - In 2.0, at least one of title or description is required.




From owner-atom-syntax@mail.imc.org  Sun Jul 11 13:23: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 NAA01753
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 13:23: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 i6BH4S2D010817;
	Sun, 11 Jul 2004 10:04: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 i6BH4SMe010816;
	Sun, 11 Jul 2004 10:04: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 i6BH4RgB010809
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 10:04:27 -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 i6BH54oH006026;
	Sun, 11 Jul 2004 13:05:04 -0400
Message-ID: <40F1731D.5000103@intertwingly.net>
Date: Sun, 11 Jul 2004 13:04:29 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Norman Walsh <ndw@nwalsh.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Version vs. Namespace
References: <87smbymve3.fsf@nwalsh.com>	<B40394C3-D356-11D8-9A61-000A95BD86C0@mnot.net> <87llhqjycb.fsf@nwalsh.com>
In-Reply-To: <87llhqjycb.fsf@nwalsh.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


Norman Walsh wrote:

> / Mark Nottingham <mnot@mnot.net> was heard to say:
> | I'd phrase the question in a slightly different manner;
> |
> | Why do we have a version attribute at all? Why not rely upon the XML
> | namespace to identify the version of the Atom document?
> 
> Because changing namespace names is about the most traumatic thing you
> can do to a document. It breaks every single tool that is doing a
> proper namespace-based comparison of element names. All the XSLT
> stylesheets stop functioning, all the DOM tools that use the ...NS()
> accessors stop working, etc.

<joke>
     Actually, with current tools, the most traumatic thing you can do
     to a document is to change the version number from "1.0" to "1.1"
     - in the XML prolog.
</joke>

> A version attribute lets us make small changes and corrections to the
> spec over time without breaking everything.

Sometimes.  ;-)

> It strikes me that we need to specify the rules for processing Atom
> documents that have a version that isn't recognized. We may also want
> to add an atom:mustUnderstand attribute globally.

It has been alleged that David Orchard is working on such a proposal.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Sun Jul 11 13:37: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 NAA02310
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 13:37: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 i6BHIA86012098;
	Sun, 11 Jul 2004 10:18: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 i6BHIAFO012097;
	Sun, 11 Jul 2004 10:18:10 -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 i6BHIA5N012091
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 10:18:10 -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 i6BHID9L001998
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 10:18:13 -0700 (PDT)
Received: from [192.168.1.100] (h00080d858303.ne.client2.attbi.com [24.61.1.243])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id i6BHICVM012563
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 10:18:13 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v618)
In-Reply-To: <40F171A0.5080801@intertwingly.net>
References: <87wu1amwtn.fsf@nwalsh.com> <14be96d304071108284f50396@mail.gmail.com> <08D5430A-D356-11D8-9DBF-000A95A51C9E@sun.com> <40F171A0.5080801@intertwingly.net>
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-12--410033805; protocol="application/pkcs7-signature"
Message-Id: <57A70284-D35E-11D8-ACB6-000A95DC3D90@mac.com>
From: Graham <dtcd@mac.com>
Subject: Re: atom:summary or atom:content required?
Date: Sun, 11 Jul 2004 13:18:35 -0400
To: Atom-Syntax Syntax <atom-syntax@imc.org>
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-12--410033805
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 11 Jul 2004, at 12:58 pm, Sam Ruby wrote:

> (*) More history:
>   - In 0.91, title is required, description is optional
>   - In 0.92, neither title nor description is required.
>   - In 2.0, at least one of title or description is required.

2.0 has it right. Not all content systems include a title field, only a 
body, so requiring titles requires synthetic titles, which are 
impossible to display in a non-sucky way, since they're always the 
wrong length. Therefore one of the 3 should be required.

(I've said this before and got booed by the XSLT crowd)

Graham
--Apple-Mail-12--410033805
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
9w0BCQUxDxcNMDQwNzExMTcxODM2WjAjBgkqhkiG9w0BCQQxFgQUk1Ns4hjAbnWlVupE31aR5kdy
MyQweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAMgTfUPo1EPOYohyIWYLfEmrx
md71kIcbdw3tG16fJqhQoAO9RjmJ5lB6UB+kxzWJRlITMcYx0fPU51DAm70ds0mOFpHoSzAyFslU
qpDx4gAe3TGNTlBvg8VadNsZl+khFM06ppEZ7FCo5HRCWDjGAxibxB5bRxJS9PoMcC1HQ+RhAOxv
4mi1Tp4jJfROlZhKOAyxCBlHQ6o5uIr07SJaMXxboHf+hudR+X44AkcNyLrXet8XpczbZpA8tIPi
Kg0/drVZoXXh7FPPaL859tVys1gIxhcaIYc34YCyZgtWv/cOmsAO012Y6Qrzrg9Cqj+LUldH1u+f
/1QgOYJ5gNjG+wAAAAAAAA==

--Apple-Mail-12--410033805--



From owner-atom-syntax@mail.imc.org  Sun Jul 11 13:46: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 NAA02744
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 13:46:18 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BGVBEG007371;
	Sun, 11 Jul 2004 09:31: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 i6BGVBor007370;
	Sun, 11 Jul 2004 09:31:11 -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 i6BGVAI2007364
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 09:31:10 -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 i6BGVlev004533;
	Sun, 11 Jul 2004 12:31:47 -0400
Message-ID: <40F16B51.3000602@intertwingly.net>
Date: Sun, 11 Jul 2004 12:31:13 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: MUST be UTC?
References: <CFE2B52D-D2D4-11D8-A6B6-003065EA6144@geckotribe.com> <1A0E593A-D2E5-11D8-9A61-000A95BD86C0@mnot.net> <opsay810jeuvpchu@quark> <40F152CA.5000000@intertwingly.net> <opsaza3fttuvpchu@quark> <40F15DC2.3060307@intertwingly.net> <opsazc38qcuvpchu@quark>
In-Reply-To: <opsazc38qcuvpchu@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, 11 Jul 2004 11:33:22 -0400, Sam Ruby <rubys@intertwingly.net>  
> wrote:
> 
>> Let's try to avoid terms like b0rked
> 
> Very true. Sorry about that.
> 
>> then perhaps taking the time to understand the perspective of others.
> 
> Agreed, although I hope someone would agree that the situation of  
> LiveJournal is easier to «fix» than the situation for the unpriviledged  
> users[1]. To make the entries in LiveJournal work with a stricter 
> datetime  format in Atom, we «just» need the users to enter their 
> timezone offset,  and all their entries can be served with the offset 
> information as  supplied, or converted to UTC.

Fixing a server is always possible.  Fixing a historical database may 
not be.

>> LiveJournal has a large customer base, who to date have seen value in  
>> expressing time in relative and personal terms.
> 
> Though this perspective is incomprehensible to me, I accept that this 
> is  the current situation, but I hope that it can be worked on to make 
> it  better and easier for other tools to work with LiveJournal's entry 
> dates.

We need to better define what we expect people who "work with" these 
dates can expect.  I explored this in

http://www.intertwingly.net/blog/2003/07/01/Subjective-and-objective-dates

And I suspect that the opening paragraph in that blog entry applies here:

     In TimestampVsCreationDateTime there are a number of votes for each
     of the 'alternatives'.  In cases like this, I suspect that what is
     really going on is that people are talking about multiple distinct
     things.

There is no question in my mind that <modified> dates should be strictly 
ordered, so either an indication of timezone or canonicalization to UTC 
would be required.  Doing so would allow aggregator authors to order 
entries across all weblogs, if they chose to do so.

What Bloggers calls Post Date and Time [1], and what LiveJournal simply 
calls Date and Local Time of an entry is different.  Qualitatively 
different.  It is subjective.  It's primary purpose is for display.  For 
human consumption.

Note that in both Blogger and LiveJournal, this latter field is 
something that the user can control.  In Blogger, this field can even be 
changed after the fact.

The most you can assume about this particular date is that it is the 
date that the author wants associated with the entry, nothing more, 
nothing less.

Like the August issue of Sports Illustrated that may be on your 
newsstands now, or that blog entry that you may have written up 
yesterday - about events that took place yesterday - but somehow didn't 
get posted to your site until this morning.

One date is objective, intended to be processed by cold hard machines. 
One date is subjective, intended to be processed by warm squishy humans.

I don't know if these two concepts have exact equivalents in Dublin 
Core.  I know that these concepts are not well explained in the current 
drafts.  I doubt that any of the current Paces adequately captures this.

But I do know that a number of blog vendors model things this way.  And 
don't view it a bug.

- Sam Ruby

[1] http://help.blogger.com/bin/answer.py?answer=139&topic=17



From owner-atom-syntax@mail.imc.org  Sun Jul 11 14:00: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 OAA03756
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 14:00: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 i6BHfccI013865;
	Sun, 11 Jul 2004 10:41: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 i6BHfcTq013864;
	Sun, 11 Jul 2004 10:41:38 -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 i6BHfbZn013849
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 10:41:38 -0700 (PDT)
	(envelope-from roger@agincourtmedia.com)
Received: from biggreen ([216.63.148.42]) by journurl.com with MailEnable ESMTP; Sun, 11 Jul 2004 12:32:28 -0500
From: "Roger B." <roger@agincourtmedia.com>
To: "'Sam Ruby'" <rubys@intertwingly.net>
Cc: "'Atom Syntax'" <atom-syntax@imc.org>
Subject: RE: atom:summary or atom:content required?
Date: Sun, 11 Jul 2004 12:33:48 -0500
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: <40F171A0.5080801@intertwingly.net>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Thread-Index: AcRnaINHTGQXNW0YS8ePfIfPQ9otawAA6ccw
Message-ID: <9F8E6F4CC33B4E7F907112BD3F832C.MAI@journurl.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


> If you do a current search on <"title only" feed>, you will find that
> such feeds are(1) still being produced, and (2) widely disliked by
> consumers.

Sam: I'm a producer of a whole batch of feeds like that. The Macromedia
support and Fusebox methodology forums don't currently produce native feeds,
so I've got a scraper set up that pulls down thread titles/links and dumps
'em into RSS.

People who use them would certainly _prefer_ content in those feeds, but
when the alternative is no feed at all, folks get real appreciative, real
fast. So dislike is a relative thing, IMX. 

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/ 







From owner-atom-syntax@mail.imc.org  Sun Jul 11 14:18: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 OAA04957
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 14:18: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 i6BHsARQ014752;
	Sun, 11 Jul 2004 10:54: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 i6BHsA9L014751;
	Sun, 11 Jul 2004 10:54: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 i6BHs9Cw014745
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 10:54: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 i6BHskeH008420;
	Sun, 11 Jul 2004 13:54:47 -0400
Message-ID: <40F17EC4.4020403@intertwingly.net>
Date: Sun, 11 Jul 2004 13:54:12 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <dtcd@mac.com>
CC: Atom-Syntax Syntax <atom-syntax@imc.org>
Subject: Re: atom:summary or atom:content required?
References: <87wu1amwtn.fsf@nwalsh.com> <14be96d304071108284f50396@mail.gmail.com> <08D5430A-D356-11D8-9DBF-000A95A51C9E@sun.com> <40F171A0.5080801@intertwingly.net> <57A70284-D35E-11D8-ACB6-000A95DC3D90@mac.com>
In-Reply-To: <57A70284-D35E-11D8-ACB6-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: <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:

> so requiring titles requires synthetic titles

 From the Atom Protocol description of titles in POSTs [1]:

     MUST be present. The element may be empty, to explicitly indicate
     "no title". Servers SHOULD NOT try to generate a title if one is not
     provided. The type attribute MAY be present, and if not it defaults
     to "text/plain". If present, it MUST represent a MIME type that the
     server supports.

- Sam Ruby

[1]<http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-00.html#rfc.section.3.5.3>



From owner-atom-syntax@mail.imc.org  Sun Jul 11 14: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 OAA05114
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 14: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 i6BHBrv3011498;
	Sun, 11 Jul 2004 10:11: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 i6BHBrxx011497;
	Sun, 11 Jul 2004 10:11:53 -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 i6BHBrYc011491
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 10:11:53 -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 i6BHBu2G022948
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 10:11:56 -0700 (PDT)
Received: from [192.168.1.100] (h00080d858303.ne.client2.attbi.com [24.61.1.243])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id i6BHBs0t012718
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 10:11:55 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v618)
In-Reply-To: <opsazdtdcguvpchu@quark>
References: <87smbymve3.fsf@nwalsh.com> <opsazdtdcguvpchu@quark>
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-11--410411264; protocol="application/pkcs7-signature"
Message-Id: <76AB645A-D35D-11D8-ACB6-000A95DC3D90@mac.com>
From: Graham <dtcd@mac.com>
Subject: Re: Version attribute on atom:entry
Date: Sun, 11 Jul 2004 13:12:17 -0400
To: Atom-Syntax Syntax <atom-syntax@imc.org>
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-11--410411264
Content-Type: text/plain;
	charset=ISO-8859-1;
	format=flowed
Content-Transfer-Encoding: quoted-printable

On 11 Jul 2004, at 12:09 pm, Asbj=F8rn Ulsberg wrote:

> However, it is a valid use case that feeds may contain entries with=20
> different versions (synthetical feeds). In such situations, it would=20=

> probably be best (although not easiest) to =ABdowngrade=BB the feed to =
the=20
> lowest //entry/@version.

Do synthetic feeds normally contain cut-and-pasted XML*? Wouldn't it be=20=

normal for incoming entries to be normalized on the way in (eg=20
converted to an internal data format, or a specific version of Atom),=20
such that they could all be output in the same format? I don't see this=20=

as an issue.

Graham

(* apart from the perennially sucky Feedster, which at least used to)=

--Apple-Mail-11--410411264
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
9w0BCQUxDxcNMDQwNzExMTcxMjE4WjAjBgkqhkiG9w0BCQQxFgQU+9qF788wxdD4dn5xbWeZgmNM
qqgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEASN+TDa3y39Vev47sJ9BBiPKM
/foZrAQ6YaHVD9e1AEX2i6ZISrZdhOXYjAEhmxRK1jaucSTGPpifS4RbyBg0YAM15sQ3ecLgPsse
QiXJMoJXDv4FDXsbpdSe3+h9XiRJyEex5f/7n4qpAkv8Ox/Vz6x/ZP6E3mhiqnQHUioG/LsNROE/
+kYQLTtrvnFb7/Eq86d75KC2spWgSgGbcfuYhyQ9ZcupKGt9is0mA6wa1PR2f95fCgyrlc5UowrV
dFUVzl1+GYZa2LGMVRg/G+V46AkD5C0W3vDbhpxJQMGyTb2+cUslmo+ynZ9dpOSPekMPw+1L7wqn
sHIa5xqY6GPLkQAAAAAAAA==

--Apple-Mail-11--410411264--



From owner-atom-syntax@mail.imc.org  Sun Jul 11 14: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 OAA05152
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 14: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 i6BIBD0p016696;
	Sun, 11 Jul 2004 11:11: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 i6BIBDQu016695;
	Sun, 11 Jul 2004 11:11: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.89])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BIBC4v016681
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 11:11:12 -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 i6BIBG2G023421;
	Sun, 11 Jul 2004 11:11:16 -0700 (PDT)
Received: from [192.168.1.100] (h00080d858303.ne.client2.attbi.com [24.61.1.243])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id i6BIBF0t023725;
	Sun, 11 Jul 2004 11:11:16 -0700 (PDT)
In-Reply-To: <40F17EC4.4020403@intertwingly.net>
References: <87wu1amwtn.fsf@nwalsh.com> <14be96d304071108284f50396@mail.gmail.com> <08D5430A-D356-11D8-9DBF-000A95A51C9E@sun.com> <40F171A0.5080801@intertwingly.net> <57A70284-D35E-11D8-ACB6-000A95DC3D90@mac.com> <40F17EC4.4020403@intertwingly.net>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-13--406853940; protocol="application/pkcs7-signature"
Message-Id: <BEFFF1C3-D365-11D8-ACB6-000A95DC3D90@mac.com>
Cc: atom-syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: atom:summary or atom:content required?
Date: Sun, 11 Jul 2004 14:11:35 -0400
To: Sam Ruby <rubys@intertwingly.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-13--406853940
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 11 Jul 2004, at 1:54 pm, Sam Ruby wrote:

> Graham wrote:
>
>> so requiring titles requires synthetic titles
>
> From the Atom Protocol description of titles in POSTs [1]:
>
>     MUST be present. The element may be empty, to explicitly indicate
>     "no title". Servers SHOULD NOT try to generate a title if one is 
> not
>     provided. The type attribute MAY be present, and if not it defaults
>     to "text/plain". If present, it MUST represent a MIME type that the
>     server supports.

Firstly: What?!? How is an empty element a more explicit way of saying 
there isn't one than omitting it completely? This is nonsense.

Secondly, I was referring to the format spec:

   atom:entry elements MUST have exactly one "atom:title" element.

How does that square with the protocol spec?

Graham
--Apple-Mail-13--406853940
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
9w0BCQUxDxcNMDQwNzExMTgxMTM1WjAjBgkqhkiG9w0BCQQxFgQU1u6KJ93ZCbKMkXuPX/c8z4fD
Y9YweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAiTfxBY1bXK4u0BYoDIQdMFn3
WrjcyaeWMbP8qu3/YKYASyUGt3tGfXKgVmOSEIVMZUsIxUYwvYcDlVH9UeSDtfxANSjk5WP04+6n
pgMRmFDBBtcCU5Zh5jjDW5ToLDCS8g9c6DF91m9RhFyJwSFE/xnYsgmtuU8hF27JHuAtWd/EY/c/
b1SG04qRk047VQvQHm/DFmvRLAqv4FdSeOnXezj3v94tanee2TEl8CoprjIxorfbw/+e/0SpJf4z
/iHGla+M+j9qDU94DpNiTxQSpIwy83kjWTY8CSUS+U+D4SeKdmoDz2za11HM4vytfjy8ecDTFUra
t5FIHI7hholCyQAAAAAAAA==

--Apple-Mail-13--406853940--



From owner-atom-syntax@mail.imc.org  Sun Jul 11 14:34: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 OAA05845
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 14:34: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 i6BISJ1J018254;
	Sun, 11 Jul 2004 11:28: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 i6BISJhV018253;
	Sun, 11 Jul 2004 11:28: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 i6BISIVG018237
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 11:28: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 1C8807C117; Sun, 11 Jul 2004 21:26:43 +0200 (CEST)
To: Graham <dtcd@mac.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Version attribute on atom:entry
References: <87smbymve3.fsf@nwalsh.com> <opsazdtdcguvpchu@quark> <76AB645A-D35D-11D8-ACB6-000A95DC3D90@mac.com>
Message-ID: <opsazkesu4uvpchu@quark>
Date: Sun, 11 Jul 2004 20:31:30 +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: <76AB645A-D35D-11D8-ACB6-000A95DC3D90@mac.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 11 Jul 2004 13:12:17 -0400, Graham <dtcd@mac.com> wrote:

> Do synthetic feeds normally contain cut-and-pasted XML*?

I have no idea, but you shouldn't bet much money on people _not_ doing  
things like this:

   <xsl:copy-of  
select="document('http://example.com/feed.atom')//atom:entry" />

> Wouldn't it be normal for incoming entries to be normalized on the way
> in (eg converted to an internal data format, or a specific version of
> Atom), such that they could all be output in the same format?

That should be recommended, yes.

> I don't see this as an issue.

Maybe it's not. I still think we need to be explicit about what elements  
@version can occur on, and in what situations.

-- 
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 Jul 11 14: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 OAA06027
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 14: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 i6BIQsjH018155;
	Sun, 11 Jul 2004 11:26: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 i6BIQs2I018154;
	Sun, 11 Jul 2004 11:26:54 -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 i6BIQpuV018146
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 11:26:53 -0700 (PDT)
	(envelope-from wkearney@syndic8.com)
Received: (qmail 26703 invoked from network); 11 Jul 2004 18:26:53 -0000
Received: from xbox.wkearney.com (HELO media) ([66.92.145.79])
          (envelope-sender <wkearney@syndic8.com>)
          by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP
          for <atom-syntax@imc.org>; 11 Jul 2004 18:26:53 -0000
Message-ID: <03c901c46774$a38e0f40$200ca8c0@wkearney.com>
From: "Bill Kearney" <wkearney@syndic8.com>
Cc: "Atom-Syntax" <atom-syntax@imc.org>
References: <CFE2B52D-D2D4-11D8-A6B6-003065EA6144@geckotribe.com> <1A0E593A-D2E5-11D8-9A61-000A95BD86C0@mnot.net> <opsay810jeuvpchu@quark> <40F152CA.5000000@intertwingly.net> <opsaza3fttuvpchu@quark> <40F15DC2.3060307@intertwingly.net> <01LCBVDE4EQ20061HF@mauve.mrochek.com> <opsazdw2rnuvpchu@quark> <01LCBW3J0GY00061HF@mauve.mrochek.com>
Subject: Re: MUST be UTC?
Date: Sun, 11 Jul 2004 14:26:43 -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.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
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


> (Although for J Random User to catch config
> errors they may need to see PDT/PST/whatever and not +/-nn:nn.)

And as long as the developers understand that PDT/PST mean -07:00/-08:00.  It
varies based on the /date/ involved.

Take, for example, Noon in LA:

07/01/2004 12:00PDT is 07/01/2004 19:00Z
(seven hours off UTC during DST)
but
12/01/2004 12:00PST is 07/01/2004 20:00Z
(eight hours off during standard time)

This is also why it's often a better idea all around to store in UTC.  Doing
'date math' across ranges when you cross daylight savings periods can often have
unexpected results.  As in, converting a timestamp from outside your current
shift (May during December, and vice versa).

Oh, and to make matters worse, not all areas/countries observe DST
"consistently".  Thus flipping the date to UTC as quickly as possible in the
collection process makes a whooooole lot of sense.

-Bill Kearney



From owner-atom-syntax@mail.imc.org  Sun Jul 11 14:36:58 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06045
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 14:36: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 i6BIRIRn018180;
	Sun, 11 Jul 2004 11:27: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 i6BIRIe5018178;
	Sun, 11 Jul 2004 11:27: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 i6BIRHGA018171
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 11:27:18 -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 i6BIRsGr009790;
	Sun, 11 Jul 2004 14:27:55 -0400
Message-ID: <40F18688.6030805@intertwingly.net>
Date: Sun, 11 Jul 2004 14:27:20 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: "Roger B." <roger@agincourtmedia.com>
CC: "'Atom Syntax'" <atom-syntax@imc.org>
Subject: Re: atom:summary or atom:content required?
References: <9F8E6F4CC33B4E7F907112BD3F832C.MAI@journurl.com>
In-Reply-To: <9F8E6F4CC33B4E7F907112BD3F832C.MAI@journurl.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


Roger B. wrote:

>>If you do a current search on <"title only" feed>, you will find that
>>such feeds are(1) still being produced, and (2) widely disliked by
>>consumers.
> 
> Sam: I'm a producer of a whole batch of feeds like that. The Macromedia
> support and Fusebox methodology forums don't currently produce native feeds,
> so I've got a scraper set up that pulls down thread titles/links and dumps
> 'em into RSS.
> 
> People who use them would certainly _prefer_ content in those feeds, but
> when the alternative is no feed at all, folks get real appreciative, real
> fast. So dislike is a relative thing, IMX. 

Thank you for coming forward.  I was looking for such an example.

Note that there are slippery slope arguments on both sides of this.  If 
you have a format where everything is optional and everything is 
extensible, then interoperability and user experience suffers.

If, on the other hand, you require so much that only a few tools can 
produce valid contents, then either people start ignoring the validity 
constraints or stop producing the content.  Either way, something 
important suffers.

My personal leanings for Atom are towards being more restrictive and 
predictable, particularly as there clearly are viable alternatives which 
are less restrictive and predictable.

Roger, as somebody who has been following Atom since before it was 
called Echo, and as a producer of feeds for which there are neither a 
summary or a content (and therefore, a recipient of complaints), do you 
think it is important for Atom to support feeds which have neither?

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Sun Jul 11 14: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 OAA06221
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 14:39: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 i6BIUr6u018512;
	Sun, 11 Jul 2004 11: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 i6BIUrrt018511;
	Sun, 11 Jul 2004 11:30:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from dd1516.kasserver.com (dd1516.kasserver.com [81.209.148.207])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BIUqua018500
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 11:30:53 -0700 (PDT)
	(envelope-from sc@itst.org)
Received: from [192.168.1.10] (p5081731E.dip0.t-ipconnect.de [80.129.115.30])
	by dd1516.kasserver.com (Postfix) with ESMTP id 751182BF3FE
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 20:30:48 +0200 (CEST)
Message-ID: <40F187BC.3060801@itst.org>
Date: Sun, 11 Jul 2004 20:32:28 +0200
From: Sascha Carlin <sc@itst.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707
X-Accept-Language: en, de
MIME-Version: 1.0
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: MUST be UTC?
References: <87smc0qcnk.fsf@nwalsh.com> <40F0B613.9020909@itst.org> <opsazacflzuvpchu@quark>
In-Reply-To: <opsazacflzuvpchu@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:

> A +1 to this one. Sascha; could you maybe write up a pace, so we get 
> this  down «on paper»?

Sorry, I only follow this mailinglist, well, very roughly ;) Please do 
whatever you want or tell me what to do.

Regards, Sascha

-- 
Sascha Carlin * Heinrich-Heine-Str. 1 * 64319 Pfungstadt
http://www.itst.org/         **         +49 6157 157 205



From owner-atom-syntax@mail.imc.org  Sun Jul 11 14:55:34 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06903
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 14: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 i6BIkVMB019873;
	Sun, 11 Jul 2004 11:46: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 i6BIkVCL019872;
	Sun, 11 Jul 2004 11:46: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 i6BIkUAv019866
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 11:46: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 i6BIl8hU010730;
	Sun, 11 Jul 2004 14:47:08 -0400
Message-ID: <40F18B09.4080304@intertwingly.net>
Date: Sun, 11 Jul 2004 14:46:33 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <dtcd@mac.com>
CC: atom-syntax <atom-syntax@imc.org>
Subject: Re: atom:summary or atom:content required?
References: <87wu1amwtn.fsf@nwalsh.com> <14be96d304071108284f50396@mail.gmail.com> <08D5430A-D356-11D8-9DBF-000A95A51C9E@sun.com> <40F171A0.5080801@intertwingly.net> <57A70284-D35E-11D8-ACB6-000A95DC3D90@mac.com> <40F17EC4.4020403@intertwingly.net> <BEFFF1C3-D365-11D8-ACB6-000A95DC3D90@mac.com>
In-Reply-To: <BEFFF1C3-D365-11D8-ACB6-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: <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 11 Jul 2004, at 1:54 pm, Sam Ruby wrote:
> 
>> Graham wrote:
>>
>>> so requiring titles requires synthetic titles
>>
>> From the Atom Protocol description of titles in POSTs [1]:
>>
>>     MUST be present. The element may be empty, to explicitly indicate
>>     "no title". Servers SHOULD NOT try to generate a title if one is not
>>     provided. The type attribute MAY be present, and if not it defaults
>>     to "text/plain". If present, it MUST represent a MIME type that the
>>     server supports.
> 
> Firstly: What?!? How is an empty element a more explicit way of saying 
> there isn't one than omitting it completely? This is nonsense.

Counter-example: I can point to RSS feeds where the absense of a <link> 
element merely means that the permalink is to be found elsewhere.

My preference for Atom is that both the format and protocol discourage 
the synthetic generation of titles and have a clear an unambiguous way 
of expressing that no title was provided.

> Secondly, I was referring to the format spec:
> 
>   atom:entry elements MUST have exactly one "atom:title" element.
> 
> How does that square with the protocol spec?

The protocol spec clearly provides more guidance and informative at the 
moment.  However this is resolved, the protocol and format specs should 
be made more consistent.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Sun Jul 11 15:06:00 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07510
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 15:06: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 i6BIsAD0020836;
	Sun, 11 Jul 2004 11:54: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 i6BIsA1u020835;
	Sun, 11 Jul 2004 11:54:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mta03-svc.ntlworld.com (mta03-svc.ntlworld.com [62.253.162.43])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BIs94B020824
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 11:54:09 -0700 (PDT)
	(envelope-from djpowell@djpowell.net)
Received: from cpc2-stke1-5-0-cust190.bagu.cable.ntl.com ([81.111.201.190])
          by mta03-svc.ntlworld.com
          (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP
          id <20040711185120.CXBB15264.mta03-svc.ntlworld.com@cpc2-stke1-5-0-cust190.bagu.cable.ntl.com>
          for <atom-syntax@imc.org>; Sun, 11 Jul 2004 19:51:20 +0100
Date: Sun, 11 Jul 2004 19:52:19 +0100
From: David Powell <djpowell@djpowell.net>
X-Mailer: The Bat! (v2.12 Beta/7) Business
Reply-To: David Powell <djpowell@djpowell.net>
X-Priority: 3 (Normal)
Message-ID: <1901598504.20040711195219@djpowell.net>
To: atom-syntax@imc.org
Subject: HTML fragments in content constructs
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



It is a very common use-case that HTML content in an Atom entry will
be embedded amongst some other HTML and a bunch of other Atom entries.

So is there any restriction on the type of HTML tags that are allowed
in a content construct?

It is usual for entry content to be labeled as @type="text/html", but
really contain HTML fragments - not full HTML.


Should both of these be allowed:

a)

<atom:content mode="xml" type="application/xhtml+xml">
some <b>mixed</b> content
</atom:content>


b)

<atom:content mode="xml" type="application/xhtml+xml">
<html>
<head><title>Title</title></head>
<body><p>A complete file</p></body>
</html>
</atom:content>


Should we define what is expected in terms of the XHTML DTD [1] so
that people know how to frame the content - Eg: %Flow or %Block or
%Inline ?

Or is this out of our scope?


A few possible proposals:

  i) Just add a note to the spec to say that content constructs MAY
     contain fragments of the media type that they are declared to
     contain.

 ii) Say that HTML content SHOULD comply to a particular element set
     such as %Flow

iii) Add an attribute such as @framing="full|fragment" to the content
     construct.

or all of the above?


[1] http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd
 or http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd

-- 
Dave



From owner-atom-syntax@mail.imc.org  Sun Jul 11 15:22: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 PAA08898
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 15:22: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 i6BJAvit022109;
	Sun, 11 Jul 2004 12:10:57 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6BJAvoA022108;
	Sun, 11 Jul 2004 12:10:57 -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 i6BJAu7s022101
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 12:10:57 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Received: from mail.online.no (ti132110a080-3373.bb.online.no [80.212.221.45])
	by mail43.fg.online.no (8.12.11/8.12.11) with ESMTP id i6BJAvqk006437
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 21:10:58 +0200 (CEST)
In-Reply-To: <40F16B51.3000602@intertwingly.net>
References: <CFE2B52D-D2D4-11D8-A6B6-003065EA6144@geckotribe.com> <1A0E593A-D2E5-11D8-9A61-000A95BD86C0@mnot.net> <opsay810jeuvpchu@quark> <40F152CA.5000000@intertwingly.net> <opsaza3fttuvpchu@quark> <40F15DC2.3060307@intertwingly.net> <opsazc38qcuvpchu@quark> <40F16B51.3000602@intertwingly.net>
Subject: Re: MUST be UTC?
To: Atom-syntax <atom-syntax@imc.org>
Message-ID: <opsazl8i1e6dxgxk@mail.online.no>
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
Date: Sun, 11 Jul 2004 21:10:56 +0200
User-Agent: Opera M2/7.52 (Win32, build 3826)
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, 11 Jul 2004 12:31:13 -0400, Sam Ruby <rubys@intertwingly.net>
wrote:

> Fixing a server is always possible.  Fixing a historical database may  
> not be.

My hunch is that if Livejournal asks their users once about providing
correct time zone information, and correct the dates on their entries
accordingly, 99% of LiveJournal dates will be "reasonably valid".

Without disrespecting LiveJournal, I think omitting timezone info for the
sake of one vendor is going to keep us in all sorts of trouble for years
to come.

(Besides: How likely are the old entries to reappear in any feed?)

-- 
Arve Bersvendsen

http://www.virtuelvis.com
http://www.bersvendsen.com



From owner-atom-syntax@mail.imc.org  Sun Jul 11 15:23:35 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08925
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 15:23:34 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BJENPX022427;
	Sun, 11 Jul 2004 12:14: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 i6BJEN14022426;
	Sun, 11 Jul 2004 12:14:23 -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 i6BJEJkP022413
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 12:14:21 -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 i6BJEE53029140
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 14:14:16 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6BJECqG029136;
	Sun, 11 Jul 2004 14:14:12 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: atom-syntax@imc.org
Subject: Re: HTML fragments in content constructs
References: <1901598504.20040711195219@djpowell.net>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 11 Jul 2004 14:14:12 -0500
In-Reply-To: <1901598504.20040711195219@djpowell.net>
Message-ID: <m3n026pda3.fsf@bitsko.slc.ut.us>
Lines: 10
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


David Powell <djpowell@djpowell.net> writes:

> It is usual for entry content to be labeled as @type="text/html",
> but really contain HTML fragments - not full HTML.

Dave, take a look at PaceSimpleContentType, particularly the "Content
Profiles" section, and see if you agree with that.  That Pace was
written to address this issue, among a couple others.

  -- Ken



From owner-atom-syntax@mail.imc.org  Sun Jul 11 15:28: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 PAA09112
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 15:28:44 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BJLvj3022858;
	Sun, 11 Jul 2004 12:21:57 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6BJLv1x022856;
	Sun, 11 Jul 2004 12:21:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from 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 i6BJLsPt022842
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 12:21: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 i6BJLn53029258
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 14:21:51 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6BJLk8S029254;
	Sun, 11 Jul 2004 14:21:46 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom-syntax <atom-syntax@imc.org>
Subject: Re: MUST be UTC?
References: <CFE2B52D-D2D4-11D8-A6B6-003065EA6144@geckotribe.com>
	<1A0E593A-D2E5-11D8-9A61-000A95BD86C0@mnot.net>
	<opsay810jeuvpchu@quark> <40F152CA.5000000@intertwingly.net>
	<opsaza3fttuvpchu@quark> <40F15DC2.3060307@intertwingly.net>
	<opsazc38qcuvpchu@quark> <40F16B51.3000602@intertwingly.net>
	<opsazl8i1e6dxgxk@mail.online.no>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 11 Jul 2004 14:21:46 -0500
In-Reply-To: <opsazl8i1e6dxgxk@mail.online.no>
Message-ID: <m3iscupcxh.fsf@bitsko.slc.ut.us>
Lines: 8
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


"Arve Bersvendsen" <arve@virtuelvis.com> writes:

> (Besides: How likely are the old entries to reappear in any feed?)

Atom is an archiving format as well as a feed format, even if we
haven't addressed some of the archiving issues yet.

  -- Ken



From owner-atom-syntax@mail.imc.org  Sun Jul 11 15:35: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 PAA09305
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 15:35: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 i6BJM85N022910;
	Sun, 11 Jul 2004 12:22:08 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6BJM8YJ022909;
	Sun, 11 Jul 2004 12:22:08 -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 i6BJM7vr022862
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 12:22:07 -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 MAA10988
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 12:22:04 -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 MAA18391
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 12:22:03 -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, 11 Jul 2004 12:22:03 -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 <0I0P008QGCGP45@shazam.verity.com> for atom-syntax@imc.org; Sun,
 11 Jul 2004 12:22:02 -0700 (PDT)
Date: Sun, 11 Jul 2004 12:22:03 -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: PaceElementOrder: options
In-reply-to: <C9782020-D2CF-11D8-B2D0-000A95A51C9E@sun.com>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: 
 <90E71832A421D850D3152670@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
MIME-version: 1.0
X-Mailer: Mulberry/3.1.5 (Mac OS X)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <97774BF0-D096-11D8-B2D0-000A95A51C9E@sun.com>
 <F3C7FAC8-D233-11D8-9A61-000A95BD86C0@mnot.net> <87smc0ownv.fsf@nwalsh.com>
 <F1AC0C56-D2AB-11D8-B2D0-000A95A51C9E@sun.com> <40F074E7.9040502@virgilio.it>
 <C9782020-D2CF-11D8-B2D0-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 Saturday, July 10, 2004 5:18 PM -0700 Tim Bray <Tim.Bray@Sun.COM> wrote:
>
> If you require that the feed-level stuff all precede the entries, then
> you can use a stream parsing API as opposed to an in-memory DOM thing.
> This feels to me like a significant benefit to implementors.

Strongly agree. Ultraseek uses a stream parser for XML indexing.

Very large feeds are certainly plausible, which causes problem
for DOM/in-memory approaches. Perhaps the Congressional Record
would be a feed.

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Sun Jul 11 16: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 QAA10629
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 16: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 i6BJuhUW024945;
	Sun, 11 Jul 2004 12:56:45 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6BJuhVY024944;
	Sun, 11 Jul 2004 12:56:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from lakermmtao07.cox.net (lakermmtao07.cox.net [68.230.240.32])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BJu4fs024915
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 12:56:42 -0700 (PDT)
	(envelope-from sah@428cobrajet.net)
Received: from A31P ([68.100.55.187]) by lakermmtao07.cox.net
          (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with ESMTP
          id <20040711195602.SOBL27959.lakermmtao07.cox.net@A31P>
          for <atom-syntax@imc.org>; Sun, 11 Jul 2004 15:56:02 -0400
From: "Scott Hollenbeck" <sah@428cobrajet.net>
To: "'Atom-syntax'" <atom-syntax@imc.org>
Subject: RE: MUST be UTC?
Date: Sun, 11 Jul 2004 15:58: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
Thread-Index: AcRnfHWc7x8XBkDoSVyeD0jXUZa1MAABHClg
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
In-Reply-To: <m3iscupcxh.fsf@bitsko.slc.ut.us>
Message-Id: <20040711195602.SOBL27959.lakermmtao07.cox.net@A31P>
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


There's something else to consider when trying to decide upon a date-time
format for use in IETF protocols, and that's re-use of earlier IETF work.  I
know that you're all considering earlier W3C work, so please check this out
as well:

ftp://ftp.rfc-editor.org/in-notes/rfc3339.txt

I can guarantee that your AD will eventually ask why an existing format
wasn't referenced if you all decide to do something new.

-Scott-



From owner-atom-syntax@mail.imc.org  Sun Jul 11 16: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 QAA11619
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 16: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 i6BKTM7n026714;
	Sun, 11 Jul 2004 13:29: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 i6BKTM0U026713;
	Sun, 11 Jul 2004 13:29:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf21.cluster1.charter.net (mxsf21.cluster1.charter.net [209.225.28.221])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BKTLMI026702
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 13:29:21 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip20.cluster1.charter.net (mxip20a.cluster1.charter.net [209.225.28.150])
	by mxsf21.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6BKVa9t013042
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 16:31:37 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip20.cluster1.charter.net with ESMTP; 11 Jul 2004 16:29:17 -0400
X-Ironport-AV: i="3.81R,160,1083556800"; 
   d="scan'208"; a="38706387:sNHT14577692"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BjkwY-0000hO-00
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 16:29:02 -0400
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: MUST be UTC?
References: <20040711195602.SOBL27959.lakermmtao07.cox.net@A31P>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Sun, 11 Jul 2004 16:28:59 -0400
In-Reply-To: <20040711195602.SOBL27959.lakermmtao07.cox.net@A31P> (Scott
 Hollenbeck's message of "Sun, 11 Jul 2004 15:58:03 -0400")
Message-ID: <87vfgui8z8.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: <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-Type: text/plain

/ "Scott Hollenbeck" <sah@428cobrajet.net> was heard to say:
| There's something else to consider when trying to decide upon a date-time
| format for use in IETF protocols, and that's re-use of earlier IETF work.  I
| know that you're all considering earlier W3C work, so please check this out
| as well:
|
| ftp://ftp.rfc-editor.org/in-notes/rfc3339.txt
|
| I can guarantee that your AD will eventually ask why an existing format
| wasn't referenced if you all decide to do something new.

I would support a normative reference to this RFC for specifying all
of the date/time values in Atom.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Until death, it is all life.-- Cervantes
http://nwalsh.com/            | 

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA8aMNOyltUcwYWjsRAtXnAJ0UkGxXavB8MfyvmceGig6psrydAwCfbJlA
L9pjNeQlwkD3Dvv4UcYGVBk=
=1V9p
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Sun Jul 11 16:47: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 QAA11824
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 16:47: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 i6BKYUVc027033;
	Sun, 11 Jul 2004 13: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 i6BKYUF8027032;
	Sun, 11 Jul 2004 13:34: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 i6BKYTWk027020
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 13:34:29 -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 i6BKZ6jM015562;
	Sun, 11 Jul 2004 16:35:07 -0400
Message-ID: <40F1A458.8020200@intertwingly.net>
Date: Sun, 11 Jul 2004 16:34:32 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Scott Hollenbeck <sah@428cobrajet.net>
CC: "'Atom-syntax'" <atom-syntax@imc.org>
Subject: Re: MUST be UTC?
References: <20040711195602.SOBL27959.lakermmtao07.cox.net@A31P>
In-Reply-To: <20040711195602.SOBL27959.lakermmtao07.cox.net@A31P>
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


Scott Hollenbeck wrote:
> There's something else to consider when trying to decide upon a date-time
> format for use in IETF protocols, and that's re-use of earlier IETF work.  I
> know that you're all considering earlier W3C work, so please check this out
> as well:
> 
> ftp://ftp.rfc-editor.org/in-notes/rfc3339.txt
> 
> I can guarantee that your AD will eventually ask why an existing format
> wasn't referenced if you all decide to do something new.

Thanks!  That is *very* helpful.  What I have gathered from a quick scan:

This document essentially indicates that the IETF now feels (as of 2002) 
that ISO 8601 is a better base than RFC 822/2822 for date formats in new 
protocols (feel free to correct me if I am overstating this).

For interoperability reasons, the IETF defined a profile of ISO 8601. 
This profile is *much* more restrictive than the one in W3CDTF.  As an 
example, here is a valid W3CDTF date-time:

   1997

In rfc 3339 dates, everything is mandatory except fractions of seconds, 
and the only option is the use of "Z" in place of a time-numoffset.

The wording in section 4.4 against unqualified local times is fairly strong.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Sun Jul 11 17:15: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 RAA13489
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 17:15: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 i6BKwFZD028935;
	Sun, 11 Jul 2004 13:58: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 i6BKwFq3028934;
	Sun, 11 Jul 2004 13:58:15 -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 i6BKwEUe028924
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 13:58:14 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Received: from mail.online.no (ti132110a080-3373.bb.online.no [80.212.221.45])
	by mail43.fg.online.no (8.12.11/8.12.11) with ESMTP id i6BKw0Sa002070;
	Sun, 11 Jul 2004 22:58:06 +0200 (CEST)
To: "Sam Ruby" <rubys@intertwingly.net>
Cc: Atom-syntax <atom-syntax@imc.org>
Subject: Re: MUST be UTC?
References: <20040711195602.SOBL27959.lakermmtao07.cox.net@A31P> <40F1A458.8020200@intertwingly.net>
Message-ID: <opsazq6so96dxgxk@mail.online.no>
Date: Sun, 11 Jul 2004 22:57:54 +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: <40F1A458.8020200@intertwingly.net>
User-Agent: Opera M2/7.52 (Win32, build 3826)
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, 11 Jul 2004 16:34:32 -0400, Sam Ruby <rubys@intertwingly.net>  
wrote:

> In rfc 3339 dates, everything is mandatory except fractions of seconds,  
> and the only option is the use of "Z" in place of a time-numoffset.
>  The wording in section 4.4 against unqualified local times is fairly  
> strong.

Also, in section 4.3:

    If the time in UTC is known, but the offset to local time is
    unknown, this can be represented with an offset of "-00:00".

Will this be able to (partly) solve LiveJournal's archive problems?

-- 
Arve Bersvendsen

http://www.virtuelvis.com
http://www.bersvendsen.com



From owner-atom-syntax@mail.imc.org  Sun Jul 11 17: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 RAA13509
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 17: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 i6BL1uNR029274;
	Sun, 11 Jul 2004 14:01: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 i6BL1uEt029273;
	Sun, 11 Jul 2004 14:01:56 -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 i6BL1pLU029261
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 14:01:55 -0700 (PDT)
	(envelope-from wkearney@syndic8.com)
Received: (qmail 8128 invoked from network); 11 Jul 2004 21:01:53 -0000
Received: from xbox.wkearney.com (HELO media) ([66.92.145.79])
          (envelope-sender <wkearney@syndic8.com>)
          by mail3.speakeasy.net (qmail-ldap-1.03) with SMTP
          for <atom-syntax@imc.org>; 11 Jul 2004 21:01:53 -0000
Message-ID: <03e201c4678a$4af6c2d0$200ca8c0@wkearney.com>
From: "Bill Kearney" <wkearney@syndic8.com>
To: "Atom-syntax" <atom-syntax@imc.org>, "Ken MacLeod" <ken@bitsko.slc.ut.us>
References: <CFE2B52D-D2D4-11D8-A6B6-003065EA6144@geckotribe.com><1A0E593A-D2E5-11D8-9A61-000A95BD86C0@mnot.net><opsay810jeuvpchu@quark> <40F152CA.5000000@intertwingly.net><opsaza3fttuvpchu@quark> <40F15DC2.3060307@intertwingly.net><opsazc38qcuvpchu@quark> <40F16B51.3000602@intertwingly.net><opsazl8i1e6dxgxk@mail.online.no> <m3iscupcxh.fsf@bitsko.slc.ut.us>
Subject: Re: MUST be UTC?
Date: Sun, 11 Jul 2004 17:01:52 -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.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
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


> Atom is an archiving format as well as a feed format,

Since when?

> even if we haven't addressed some of the archiving issues yet.

Indeed, works from the folks at NARA [1] would well be worth consulting before
rampant wheel reinventing get underway.

-Bill Kearney

[1] http://www.archives.gov/



From owner-atom-syntax@mail.imc.org  Sun Jul 11 17:16: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 RAA13593
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 17:16: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 i6BL4jfr029443;
	Sun, 11 Jul 2004 14:04: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 i6BL4jPD029442;
	Sun, 11 Jul 2004 14:04:45 -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 i6BL4i7s029436
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 14:04:44 -0700 (PDT)
	(envelope-from wkearney@syndic8.com)
Received: (qmail 7821 invoked from network); 11 Jul 2004 21:04:49 -0000
Received: from xbox.wkearney.com (HELO media) ([66.92.145.79])
          (envelope-sender <wkearney@syndic8.com>)
          by mail1.speakeasy.net (qmail-ldap-1.03) with SMTP
          for <atom-syntax@imc.org>; 11 Jul 2004 21:04:49 -0000
Message-ID: <03f601c4678a$b3a68900$200ca8c0@wkearney.com>
From: "Bill Kearney" <wkearney@syndic8.com>
To: <atom-syntax@imc.org>
References: <CFE2B52D-D2D4-11D8-A6B6-003065EA6144@geckotribe.com> <1A0E593A-D2E5-11D8-9A61-000A95BD86C0@mnot.net> <opsay810jeuvpchu@quark> <40F152CA.5000000@intertwingly.net> <opsaza3fttuvpchu@quark> <40F15DC2.3060307@intertwingly.net> <opsazc38qcuvpchu@quark> <40F16B51.3000602@intertwingly.net> <opsazl8i1e6dxgxk@mail.online.no>
Subject: Re: MUST be UTC?
Date: Sun, 11 Jul 2004 17:04:48 -0400
Organization: http://www.ideaspace.net/users/wkearney/foaf.xrdf
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
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


> Without disrespecting LiveJournal, I think omitting timezone info for the
> sake of one vendor is going to keep us in all sorts of trouble for years
> to come.
>
> (Besides: How likely are the old entries to reappear in any feed?)

I second both comments.  Also, LJ is 'relatively' centrialized, is it not?  Much
like blogger it's therefor likely that a small set of fixes could be implemented
that eliminate and so-called legacy issue.

Sure, the "LJ community" is likely to express certain amounts of "opinion" about
it but probably nowhere near the hand-wringing cited around here.

Let's not be too hasty to beat /anyone/ up about it though.  The timezone stuff
is enough to give anyone a migraine.  If something 'got it wrong' then let's
help them 'get it right'.

-Bill Kearney
Syndic8.com



From owner-atom-syntax@mail.imc.org  Sun Jul 11 17:18: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 RAA13712
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 17:18: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 i6BL4MMh029422;
	Sun, 11 Jul 2004 14:04:22 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6BL4MY7029421;
	Sun, 11 Jul 2004 14:04:22 -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 i6BL4L8M029414
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 14:04:22 -0700 (PDT)
	(envelope-from wkearney@syndic8.com)
Received: (qmail 10666 invoked from network); 11 Jul 2004 21:04:26 -0000
Received: from xbox.wkearney.com (HELO media) ([66.92.145.79])
          (envelope-sender <wkearney@syndic8.com>)
          by mail3.speakeasy.net (qmail-ldap-1.03) with SMTP
          for <rubys@intertwingly.net>; 11 Jul 2004 21:04:26 -0000
Message-ID: <03f501c4678a$a6242170$200ca8c0@wkearney.com>
From: "Bill Kearney" <wkearney@syndic8.com>
To: "Sam Ruby" <rubys@intertwingly.net>,
        "Scott Hollenbeck" <sah@428cobrajet.net>
Cc: "'Atom-syntax'" <atom-syntax@imc.org>
References: <20040711195602.SOBL27959.lakermmtao07.cox.net@A31P> <40F1A458.8020200@intertwingly.net>
Subject: Re: MUST be UTC?
Date: Sun, 11 Jul 2004 17:04:25 -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.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
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


> For interoperability reasons, the IETF defined a profile of ISO 8601.
> This profile is *much* more restrictive than the one in W3CDTF.  As an
> example, here is a valid W3CDTF date-time:
>
>    1997
>
> In rfc 3339 dates, everything is mandatory except fractions of seconds,
> and the only option is the use of "Z" in place of a time-numoffset.

Yes, I think most folks, when referencing 'w3cdtf' were talking about that which
parallels the 8601 profile.

-Bill
(who hopes this drives a final stake in the heart of x822 format)



From owner-atom-syntax@mail.imc.org  Sun Jul 11 17:27: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 RAA14077
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 17: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 i6BLDS5J030045;
	Sun, 11 Jul 2004 14:13:28 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6BLDSVB030044;
	Sun, 11 Jul 2004 14:13:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from dd1516.kasserver.com (dd1516.kasserver.com [81.209.148.207])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BLDRbI030028
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 14:13:27 -0700 (PDT)
	(envelope-from sc@itst.org)
Received: from [192.168.1.10] (p5081731E.dip0.t-ipconnect.de [80.129.115.30])
	by dd1516.kasserver.com (Postfix) with ESMTP id 50E602BF4F2
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 23:09:08 +0200 (CEST)
Message-ID: <40F1ACD8.5060506@itst.org>
Date: Sun, 11 Jul 2004 23:10:48 +0200
From: Sascha Carlin <sc@itst.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707
X-Accept-Language: en, de
MIME-Version: 1.0
To: "'Atom-syntax'" <atom-syntax@imc.org>
Subject: Re: MUST be UTC?
References: <20040711195602.SOBL27959.lakermmtao07.cox.net@A31P> <40F1A458.8020200@intertwingly.net>
In-Reply-To: <40F1A458.8020200@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:

> The wording in section 4.4 against unqualified local times is fairly 
> strong.

Sorry: what exactly are 'unqualified local times'? Times without correct 
timezone information?

Seconding my last post 
(http://www.imc.org/atom-syntax/mail-archive/msg06542.html): From a 
software author's/machine's point of view, having time and timezone 
information readily seperated would be a great thing. Otherwise you 
would have to do a lot of wugga wugga to generate all needed formats.

Regards, Sascha

-- 
Sascha Carlin * Heinrich-Heine-Str. 1 * 64319 Pfungstadt
http://www.itst.org/         **         +49 6157 157 205



From owner-atom-syntax@mail.imc.org  Sun Jul 11 17: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 RAA14402
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 17: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 i6BLOZGl030948;
	Sun, 11 Jul 2004 14: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 i6BLOZhH030947;
	Sun, 11 Jul 2004 14:24:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.84])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BLOZqL030940
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 14:24:35 -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 i6BLOe97022694
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 14:24:40 -0700 (PDT)
Received: from [192.168.1.100] (h00080d858303.ne.client2.attbi.com [24.61.1.243])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id i6BLOaZt018219
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 14:24:39 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v618)
In-Reply-To: <opsazq6so96dxgxk@mail.online.no>
References: <20040711195602.SOBL27959.lakermmtao07.cox.net@A31P> <40F1A458.8020200@intertwingly.net> <opsazq6so96dxgxk@mail.online.no>
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1--395276008; protocol="application/pkcs7-signature"
Message-Id: <B3FC2720-D380-11D8-84E9-000A95DC3D90@mac.com>
From: Graham <dtcd@mac.com>
Subject: Re: MUST be UTC?
Date: Sun, 11 Jul 2004 17:24:33 -0400
To: atom-syntax Syntax <atom-syntax@imc.org>
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--395276008
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 11 Jul 2004, at 4:57 pm, Arve Bersvendsen wrote:

>
> On Sun, 11 Jul 2004 16:34:32 -0400, Sam Ruby <rubys@intertwingly.net> 
> wrote:
>
>> In rfc 3339 dates, everything is mandatory except fractions of 
>> seconds, and the only option is the use of "Z" in place of a 
>> time-numoffset.
>>  The wording in section 4.4 against unqualified local times is fairly 
>> strong.
>
> Also, in section 4.3:
>
>    If the time in UTC is known, but the offset to local time is
>    unknown, this can be represented with an offset of "-00:00".
>
> Will this be able to (partly) solve LiveJournal's archive problems?

No, since the time is not known in UTC, only in an unknown local 
timezone.

Graham


--Apple-Mail-1--395276008
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
9w0BCQUxDxcNMDQwNzExMjEyNDMzWjAjBgkqhkiG9w0BCQQxFgQUeeG0UrsUn9i3TkCuiEBEOeN3
CToweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAdeIPPnxGeAV0lnPO50aIl1RR
XODpaoJ3Nec5p0NLv7HzLJ9Mg+Gx+dpO7MqNIAV9htyEjGceQ7qnzUBJuWyXfMAibCoICeL2l8nm
86TVyvWlkdZ/iioDjC8rZ7PV0HcvSkW2ilxv0FtPoctHVBPxOkdVIIt38PUtjvVHnb9qznlc8XJH
WizmyMU/CywLmJfbs2+RVReUrsxPCrnlyI3VCvC9qQhN37zPNZJON/md2ggr+w5xZf7vAHan1ofv
zS0NHUw5BwC6wdQ6D8WCkRidQ0nyp84UqCXUDOtIDXp/ZgQagU3tXp/L9WnwstjcChYXZIEaQ7oc
A501bH6I/lCLugAAAAAAAA==

--Apple-Mail-1--395276008--



From owner-atom-syntax@mail.imc.org  Sun Jul 11 17:38: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 RAA14507
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 17:38: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 i6BLOj0G031060;
	Sun, 11 Jul 2004 14:24: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 i6BLOjv5031059;
	Sun, 11 Jul 2004 14:24: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 i6BLOiau030953
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 14:24:44 -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 OAA18303
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 14:24:44 -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 OAA02051
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 14:24:43 -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, 11 Jul 2004 14:24:42 -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 <0I0P008MLI5445@shazam.verity.com> for atom-syntax@imc.org; Sun,
 11 Jul 2004 14:24:42 -0700 (PDT)
Date: Sun, 11 Jul 2004 14:24:40 -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: Q: modfied vs issued vs created
In-reply-to: <opsay8mlqcuvpchu@quark>
To: Atom-Syntax <atom-syntax@imc.org>
Message-id: 
 <027F8A821108A49C79D94109@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
MIME-version: 1.0
X-Mailer: Mulberry/3.1.5 (Mac OS X)
Content-type: text/plain; charset=iso-8859-1; format=flowed
Content-disposition: inline
References: <BD16DC46.1EB7A%eric.scheid@ironclad.net.au>
 <opsay8mlqcuvpchu@quark>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6BLOiau031042
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 Sunday, July 11, 2004 4:16 PM +0200 Asbjørn Ulsberg <asbjorn@tigerstaden.no> wrote:
> On Sun, 11 Jul 2004 12:00:06 +1000, Eric Scheid  <eric.scheid@ironclad.net.au> wrote:
>
>> They are both talking about the same thing: the weather report for Sat,
>> 10 Jul 2004.
>
> They have the same topic; yes, but they are two different stories.
> If you  don't see that, I don't think we can ever reach any agreement
> on this  matter.

"Current weather" is a valid web resource. It might change every
second.

Whether that web resource is a good Atom entry is a different
question.

We still need to work on what kind of web resource an Atom entry is.

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Sun Jul 11 17: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 RAA14526
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 17: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 i6BLVO1a032514;
	Sun, 11 Jul 2004 14:31: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 i6BLVOjd032513;
	Sun, 11 Jul 2004 14:31:24 -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 i6BLVNMW032501
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 14:31:23 -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 i6BLVM53031029
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 16:31:23 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6BLVMrR031025;
	Sun, 11 Jul 2004 16:31:22 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: "Atom-syntax" <atom-syntax@imc.org>
Subject: Re: MUST be UTC?
References: <CFE2B52D-D2D4-11D8-A6B6-003065EA6144@geckotribe.com>
	<1A0E593A-D2E5-11D8-9A61-000A95BD86C0@mnot.net>
	<opsay810jeuvpchu@quark> <40F152CA.5000000@intertwingly.net>
	<opsaza3fttuvpchu@quark> <40F15DC2.3060307@intertwingly.net>
	<opsazc38qcuvpchu@quark> <40F16B51.3000602@intertwingly.net>
	<opsazl8i1e6dxgxk@mail.online.no> <m3iscupcxh.fsf@bitsko.slc.ut.us>
	<03e201c4678a$4af6c2d0$200ca8c0@wkearney.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 11 Jul 2004 16:31:22 -0500
In-Reply-To: <03e201c4678a$4af6c2d0$200ca8c0@wkearney.com>
Message-ID: <m3eknip6xh.fsf@bitsko.slc.ut.us>
Lines: 36
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: <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 Kearney" <wkearney@syndic8.com> writes:

> > Atom is an archiving format as well as a feed format,
> 
> Since when?

Since inception,

  http://intertwingly.net/wiki/pie/RoadMap

and it's in our charter,

  http://ietf.org/html.charters/atompub-charter.html

> > even if we haven't addressed some of the archiving issues yet.
> 
> Indeed, works from the folks at NARA [1] would well be worth
> consulting before rampant wheel reinventing get underway.

I'm not seeing any particular specs there to learn from, pointers?

The use-case for the archive format is to export/import a site.  The
back-of-the-envelope current solution is one big <feed>.  Another
use-case is back-history for a site, by using an organization of
mostly static <feed> resources as an index to all entries, with
prev/next and side links.

There are issues in the index and "big" archive feed that, for
example, may be helped by recent discussion on separating "site" or
"feed" information from the "physical" feed structure.  The issue of
storing non-entry resources in an archive is a biggy, for the archive
profile we most likely will have to use a MIME container.

  -- Ken

> [1] http://www.archives.gov/



From owner-atom-syntax@mail.imc.org  Sun Jul 11 17: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 RAA15048
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 17: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 i6BLhFde033601;
	Sun, 11 Jul 2004 14:43: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 i6BLhFdM033600;
	Sun, 11 Jul 2004 14:43:15 -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 i6BLhEDl033578
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 14:43: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 i6BLhE53031197
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 16:43:14 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6BLhEh8031193;
	Sun, 11 Jul 2004 16:43:14 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Q: modfied vs issued vs created
References: <BD16DC46.1EB7A%eric.scheid@ironclad.net.au>
	<opsay8mlqcuvpchu@quark>
	<027F8A821108A49C79D94109@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 11 Jul 2004 16:43:13 -0500
In-Reply-To:  <027F8A821108A49C79D94109@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
Message-ID: <m3acy6p6dq.fsf@bitsko.slc.ut.us>
Lines: 36
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


Walter Underwood <wunder@verity.com> writes:

> "Current weather" is a valid web resource. It might change every
> second.
> 
> Whether that web resource is a good Atom entry is a different
> question.
> 
> We still need to work on what kind of web resource an Atom entry is.

There's been some work in that area in AtomTerminology,

    http://intertwingly.net/wiki/pie/AtomTerminology

The current definition (sans Atom implementation) of Entry reads,

     A principal published resource that is part of a set or series,
     such as would appear in a front page "news", a digest,
     hierarchical sitemap or index, or news box.

Please note well: I am *not* against having Atom <entry> elements, or
feeds for that matter, being used for things that work well in
aggregators.  I'm not particularly against using feeds/entries for
some things that don't work well in aggregators specifically, as long
as they're well marked.

The only thing I'm against is making feeds and entries completely
generic resource records, there are far better ways of doing that.

The definition above can be matched by similar definitions of other
things that can also be mapped to atom:entry, or maybe we can change
the above term for "entry" into, say, "Syndication entry" to indicate
the above usage, and reserve the unqualified "entry" for whatever we
determine atom:entry is.

  -- Ken



From owner-atom-syntax@mail.imc.org  Sun Jul 11 17:57: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 RAA15068
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 17:57:23 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BLmHDn033917;
	Sun, 11 Jul 2004 14:48: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 i6BLmHxV033916;
	Sun, 11 Jul 2004 14:48: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 i6BLmG7K033909
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 14:48:17 -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 i6BLmtAN019470;
	Sun, 11 Jul 2004 17:48:56 -0400
Message-ID: <40F1B5A5.2020707@intertwingly.net>
Date: Sun, 11 Jul 2004 17:48:21 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <dtcd@mac.com>
CC: atom-syntax Syntax <atom-syntax@imc.org>
Subject: Re: MUST be UTC?
References: <20040711195602.SOBL27959.lakermmtao07.cox.net@A31P> <40F1A458.8020200@intertwingly.net> <opsazq6so96dxgxk@mail.online.no> <B3FC2720-D380-11D8-84E9-000A95DC3D90@mac.com>
In-Reply-To: <B3FC2720-D380-11D8-84E9-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: <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 11 Jul 2004, at 4:57 pm, Arve Bersvendsen wrote:
> 
>> On Sun, 11 Jul 2004 16:34:32 -0400, Sam Ruby <rubys@intertwingly.net> 
>> wrote:
>>
>>> In rfc 3339 dates, everything is mandatory except fractions of 
>>> seconds, and the only option is the use of "Z" in place of a 
>>> time-numoffset.
>>>  The wording in section 4.4 against unqualified local times is fairly 
>>> strong.
>>
>> Also, in section 4.3:
>>
>>    If the time in UTC is known, but the offset to local time is
>>    unknown, this can be represented with an offset of "-00:00".
>>
>> Will this be able to (partly) solve LiveJournal's archive problems?
> 
> No, since the time is not known in UTC, only in an unknown local timezone.

My read of section 4.3 is that RFC 3339 defines "+00:00" and "-00:00" to 
have different semantic meanings: the former equating to "UTC", the 
latter equating to "Unknown Local Offset".

Undoubtably software which can not deal with the concept of dates 
without timesones will read such dates and assume UTC.  All things 
considered, this is not the worst assumption that can be made.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Sun Jul 11 18:08: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 SAA15916
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 18: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 i6BM0uQx035558;
	Sun, 11 Jul 2004 15:00:56 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6BM0u08035557;
	Sun, 11 Jul 2004 15:00: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.89])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BM0tZ1035551
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 15:00:55 -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 i6BM102G006529;
	Sun, 11 Jul 2004 15:01:01 -0700 (PDT)
Received: from [192.168.1.100] (h00080d858303.ne.client2.attbi.com [24.61.1.243])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id i6BM0vVM013069;
	Sun, 11 Jul 2004 15:00:58 -0700 (PDT)
In-Reply-To: <40F1B5A5.2020707@intertwingly.net>
References: <20040711195602.SOBL27959.lakermmtao07.cox.net@A31P> <40F1A458.8020200@intertwingly.net> <opsazq6so96dxgxk@mail.online.no> <B3FC2720-D380-11D8-84E9-000A95DC3D90@mac.com> <40F1B5A5.2020707@intertwingly.net>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--393096468; protocol="application/pkcs7-signature"
Message-Id: <C7179283-D385-11D8-84E9-000A95DC3D90@mac.com>
Cc: atom-syntax Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: MUST be UTC?
Date: Sun, 11 Jul 2004 18:00:52 -0400
To: Sam Ruby <rubys@intertwingly.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-2--393096468
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 11 Jul 2004, at 5:48 pm, Sam Ruby wrote:

> My read of section 4.3 is that RFC 3339 defines "+00:00" and "-00:00" 
> to have different semantic meanings: the former equating to "UTC", the 
> latter equating to "Unknown Local Offset".

But to use either you still need to know the correct time in UTC - 
"+00:00" implies the author is located near the Greenwich Meridian, 
"-00:00" doesn't. It's different from the Livejournal problem.

Graham
--Apple-Mail-2--393096468
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
9w0BCQUxDxcNMDQwNzExMjIwMDUzWjAjBgkqhkiG9w0BCQQxFgQUIWFR4/yp3ue4gFRZuiZFGBO7
Y5EweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAjyf1DSw/hq76dBd1MHXDRp8Y
llOm3Fe3+L+tI3gn4JXJlHK+0DzJPKCP7E8O9KZ60JfbNmM60JoZs8pSz2aYf8mCCNRGyVQxIu5a
Jenbf6EHj9AdN2iMs16vH+7D4oPyUjdReVskvkwelwF6T+LPxrfDQVcgZQb4haJ1ERu7+9MmsYAg
MS3fqqsBrsFin/kJXKjzl0BuVKF4Ku0ANwqXCqEzL9wt5nr6FJL/ZEFFF682C9/2ulOKZ2zd927m
GMBLXMWW4DCMRi8th0OJsP2cfC0Y2LDJAvQltmJQLXuhcJlJnSnKAuWhrUqhEtr9THM7w154jWSU
eoGGlNKdgIhLVQAAAAAAAA==

--Apple-Mail-2--393096468--



From owner-atom-syntax@mail.imc.org  Sun Jul 11 18:20: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 SAA16934
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 18:20: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 i6BMAb4b036621;
	Sun, 11 Jul 2004 15:10: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 i6BMAbmJ036620;
	Sun, 11 Jul 2004 15:10:37 -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 i6BMAa7d036614
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 15:10:37 -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 CA5204F033;
	Sun, 11 Jul 2004 18:10:39 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040712070748.0622d848@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Mon, 12 Jul 2004 07:10:33 +0900
To: randy@kbcafe.com,
        =?ISO-2022-JP?B?IkFzYmobJEJ4chsoQm5fVWxzYmVyZyI=?= <asbjorn@tigerstaden.no>
From: Martin Duerst <duerst@w3.org>
Subject: Re: Created proposal: PaceProvideSchema 
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <20040711152426.7536.qmail@web41501.mail.yahoo.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 08:24 04/07/11 -0700, Randy Charles Morin wrote:
>Randy Charles Morin <randymorin@yahoo.com> wrote:
> >Writing a validator that accounts for cardinality of ordered
> >elements is substantially more difficult.
>
>That should have been "cardinality of unordered elements".

It is maybe slightly more difficult. It of course depends
on the internal structures of your validator that you already
have. When this was discussed in the XML Schema WG and with
others who commented on it, it even turned out that one
of the prototype implementations allowed it because that
seemed easier to implement than not allowing it.

But for us, of course, that's all rather irrelevant.
We have to take XSD the way it is.

Regards,    Martin.



From owner-atom-syntax@mail.imc.org  Sun Jul 11 18:26:23 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17098
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 18:26: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 i6BMDK3g036846;
	Sun, 11 Jul 2004 15: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 i6BMDKap036845;
	Sun, 11 Jul 2004 15:13: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 i6BMDJNV036839
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 15:13:20 -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 i6BMDxNO020658;
	Sun, 11 Jul 2004 18:13:59 -0400
Message-ID: <40F1BB84.1070205@intertwingly.net>
Date: Sun, 11 Jul 2004 18:13:24 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <dtcd@mac.com>
CC: atom-syntax Syntax <atom-syntax@imc.org>
Subject: Re: MUST be UTC?
References: <20040711195602.SOBL27959.lakermmtao07.cox.net@A31P> <40F1A458.8020200@intertwingly.net> <opsazq6so96dxgxk@mail.online.no> <B3FC2720-D380-11D8-84E9-000A95DC3D90@mac.com> <40F1B5A5.2020707@intertwingly.net> <C7179283-D385-11D8-84E9-000A95DC3D90@mac.com>
In-Reply-To: <C7179283-D385-11D8-84E9-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: <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 11 Jul 2004, at 5:48 pm, Sam Ruby wrote:
> 
>> My read of section 4.3 is that RFC 3339 defines "+00:00" and "-00:00" 
>> to have different semantic meanings: the former equating to "UTC", the 
>> latter equating to "Unknown Local Offset".
> 
> But to use either you still need to know the correct time in UTC - 
> "+00:00" implies the author is located near the Greenwich Meridian, 
> "-00:00" doesn't. It's different from the Livejournal problem.

I agree with everything but the last sentence.

+00:00 implies the author is located near the Greenwich Meridian.

-00:00 does not imply where the author is located.

LiveJournal has recorded some dates where they don't know where the 
author is located.

An example livejournal feed can be found at

http://www.livejournal.com/users/brad/data/atom

Note that value of <issued> in (what is now) the first entry is 
"2004-07-10T16:47:00".  My read of RFC 3339 is that this information 
would need to be represented as "2004-07-10T16:47:00-00:00" in order to 
express the concept that this time is in an unknown local timezone offset.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Sun Jul 11 18: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 SAA17207
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 18: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 i6BMKFTg037606;
	Sun, 11 Jul 2004 15:20: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 i6BMKFFn037605;
	Sun, 11 Jul 2004 15:20:15 -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 i6BMKFPE037598
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 15:20:15 -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 i6BMKKkN028174;
	Sun, 11 Jul 2004 15:20:20 -0700 (PDT)
Received: from [192.168.1.100] (h00080d858303.ne.client2.attbi.com [24.61.1.243])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id i6BMKC0t012357;
	Sun, 11 Jul 2004 15:20:19 -0700 (PDT)
In-Reply-To: <40F1BB84.1070205@intertwingly.net>
References: <20040711195602.SOBL27959.lakermmtao07.cox.net@A31P> <40F1A458.8020200@intertwingly.net> <opsazq6so96dxgxk@mail.online.no> <B3FC2720-D380-11D8-84E9-000A95DC3D90@mac.com> <40F1B5A5.2020707@intertwingly.net> <C7179283-D385-11D8-84E9-000A95DC3D90@mac.com> <40F1BB84.1070205@intertwingly.net>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3--391940404; protocol="application/pkcs7-signature"
Message-Id: <7828E4BA-D388-11D8-84E9-000A95DC3D90@mac.com>
Cc: atom-syntax Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: MUST be UTC?
Date: Sun, 11 Jul 2004 18:20:09 -0400
To: Sam Ruby <rubys@intertwingly.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-3--391940404
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 11 Jul 2004, at 6:13 pm, Sam Ruby wrote:

> LiveJournal has recorded some dates where they don't know where the 
> author is located.

But they don't know how to correctly convert them to UTC (do they?), 
which is a requirement of using "-00:00". I think LiveJournal falls 
under section 4.4 "Unqualified Local Time".

> Note that value of <issued> in (what is now) the first entry is 
> "2004-07-10T16:47:00".  My read of RFC 3339 is that this information 
> would need to be represented as "2004-07-10T16:47:00-00:00" in order 
> to express the concept that this time is in an unknown local timezone 
> offset.

I don't think that does represent 16:47 UTC +/- up to 12 hours. It 
represents 16:47 UTC exactly - the location is the only thing unknown.

Graham
--Apple-Mail-3--391940404
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
9w0BCQUxDxcNMDQwNzExMjIyMDA5WjAjBgkqhkiG9w0BCQQxFgQUEX0xmEHMHRSzOV38PZTQXZM3
3McweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAW0zGElR6D8TvHazx39CJ+TIQ
3eO6BI1zj1ZRv8LK6vyq/kIiLu0OnNIRBe7gu3MTdyS4Y+rl2wuaQK2n0u6I9mT7Vob0qZaN4M1v
rEYq9b4oL3gWQuMt3PviKiYJe03RK+embsVJlWlzZAW/J6uUs1uk1kwLHHBc11ib8eAXv8mJgJTe
WnZsUw8ZLzkGahtByeZhD3niZPw/pc2e+l0g2MOHzm1jrSW0RtVMWF4nfY3kWC2qGKTCXG6zmC9z
YWPCX0oZ9cQPQ1T3JHJCYdguOcM8Ys9ZzrSv/7GPb8UxTaYkdNebuQjck8BY34uibq9pQIYlOcmU
qJUVNZDUApNhawAAAAAAAA==

--Apple-Mail-3--391940404--



From owner-atom-syntax@mail.imc.org  Sun Jul 11 18:28:13 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17226
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 18:28:12 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BMJMNC037539;
	Sun, 11 Jul 2004 15:19: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 i6BMJMUg037538;
	Sun, 11 Jul 2004 15:19:22 -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 i6BMJL6R037529
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 15:19:21 -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 i6BMJK53031700
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 17:19:21 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6BMJJWK031696;
	Sun, 11 Jul 2004 17:19:19 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom-Syntax Syntax <atom-syntax@imc.org>
Subject: Re: Disambiguating the subject of feed-level metadata
References: <97774BF0-D096-11D8-B2D0-000A95A51C9E@sun.com>
	<F3C7FAC8-D233-11D8-9A61-000A95BD86C0@mnot.net>
	<87smc0ownv.fsf@nwalsh.com>
	<F1AC0C56-D2AB-11D8-B2D0-000A95A51C9E@sun.com>
	<F47D290F-D2BB-11D8-9A61-000A95BD86C0@mnot.net>
	<7DEA0B24-D2ED-11D8-ACB6-000A95DC3D90@mac.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 11 Jul 2004 17:19:19 -0500
In-Reply-To: <7DEA0B24-D2ED-11D8-ACB6-000A95DC3D90@mac.com>
Message-ID: <m3658up4pk.fsf@bitsko.slc.ut.us>
Lines: 56
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


Graham <dtcd@mac.com> writes:

> <feed>
>   <author name="person A">
>    <entry />
>    <entry />
>    <entry />
>   </author>
> </feed>
> 
> That would also allow different defaults for different groups of
> entries.

So with an author and a contributor it might look like this?

<feed>
  <author name="person A">
    <contributor name="person B">
      <entry />
      <entry />
    </contributor>
  </author>
  <author name="person B">
    <contributor name="person C">
      <entry />
    </contributor>
  </author>
</feed>

With all the use-cases for multiple feeds, synthetic feeds,
independent entries, I'm leaning heavily towards -1 on inheritance or
defaults in any manner.  Making entries as independent as possible
would be a good "core Atom" goal, and then explicit references for
"more info".  I'm still good with "hard local references", such as
<site> and <author> with known required-to-be-copied elements:

<feed>
  <site id="site1" />
  <person id="person A" />
  <person id="person B" />
  <entry>
    <site ref="site1" />
    <author ref="person A" />
  </entry>
  <entry>
    <site ref="site1" />
    <author ref="person B" />
    <contributor ref="person A" />
  </entry>
</feed>

In this scenario, the "redundantly replicated" @ref elements in, yes,
every entry are acting like foreign keys in a database table.
Absolutely no inheritance of any kind -- it's all explicit.

  -- Ken



From owner-atom-syntax@mail.imc.org  Sun Jul 11 18: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 SAA17912
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 18:51: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 i6BMYJfg038969;
	Sun, 11 Jul 2004 15:34: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 i6BMYJD1038968;
	Sun, 11 Jul 2004 15:34: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 i6BMYI4X038955
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 15:34: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 2BC1B7C117; Mon, 12 Jul 2004 01:32:37 +0200 (CEST)
To: "Walter Underwood" <wunder@verity.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Q: modfied vs issued vs created
References: <BD16DC46.1EB7A%eric.scheid@ironclad.net.au> <opsay8mlqcuvpchu@quark> <027F8A821108A49C79D94109@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
Message-ID: <opsazvtdgsuvpchu@quark>
Date: Mon, 12 Jul 2004 00:37:51 +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: <027F8A821108A49C79D94109@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 11 Jul 2004 14:24:40 -0700, Walter Underwood <wunder@verity.com>  
wrote:

> "Current weather" is a valid web resource. It might change every
> second.

Yes.

> Whether that web resource is a good Atom entry is a different
> question.

Each update of the resource is a valid and good Atom entry, but it's not  
the _same_ entry for each update.

> We still need to work on what kind of web resource an Atom entry is.

Feel free to edit AtomTerminology with what you think an Atom entry is or  
should be, but please tell the list if the changes you make are major.

-- 
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 Jul 11 18:52: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 SAA17942
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 18:52:53 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BMdwZ5039563;
	Sun, 11 Jul 2004 15:39: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 i6BMdwLj039562;
	Sun, 11 Jul 2004 15:39:58 -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 i6BMdrew039553
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 15:39:58 -0700 (PDT)
	(envelope-from wkearney@syndic8.com)
Received: (qmail 6361 invoked from network); 11 Jul 2004 22:39:57 -0000
Received: from xbox.wkearney.com (HELO media) ([66.92.145.79])
          (envelope-sender <wkearney@syndic8.com>)
          by mail1.speakeasy.net (qmail-ldap-1.03) with SMTP
          for <atom-syntax@imc.org>; 11 Jul 2004 22:39:56 -0000
Message-ID: <041601c46797$fdd3df20$200ca8c0@wkearney.com>
From: "Bill Kearney" <wkearney@syndic8.com>
To: <atom-syntax@imc.org>
References: <20040711195602.SOBL27959.lakermmtao07.cox.net@A31P> <40F1A458.8020200@intertwingly.net> <opsazq6so96dxgxk@mail.online.no> <B3FC2720-D380-11D8-84E9-000A95DC3D90@mac.com> <40F1B5A5.2020707@intertwingly.net> <C7179283-D385-11D8-84E9-000A95DC3D90@mac.com> <40F1BB84.1070205@intertwingly.net> <7828E4BA-D388-11D8-84E9-000A95DC3D90@mac.com>
Subject: Re: MUST be UTC?
Date: Sun, 11 Jul 2004 18:39:08 -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.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
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 don't think that does represent 16:47 UTC +/- up to 12 hours. It
> represents 16:47 UTC exactly - the location is the only thing unknown.

NO, timezones are NOT geographic data.  They don't denote "where" something is
located.  Let's just get off that line of thinking right away.  If location info
is desired it's a whole other can of worms.

It does NOT represent 16:47 at UTC.  It represents 4:47 pm in some unknown
timezone and cannot be expressed as a timestamp.

-Bill Kearney



From owner-atom-syntax@mail.imc.org  Sun Jul 11 18: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 SAA18165
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 18:59: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 i6BMfe5G039660;
	Sun, 11 Jul 2004 15:41: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 i6BMfeUj039659;
	Sun, 11 Jul 2004 15:41:40 -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 i6BMfd4n039651
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 15:41:39 -0700 (PDT)
	(envelope-from wkearney@syndic8.com)
Received: (qmail 7930 invoked from network); 11 Jul 2004 22:41:44 -0000
Received: from xbox.wkearney.com (HELO media) ([66.92.145.79])
          (envelope-sender <wkearney@syndic8.com>)
          by mail1.speakeasy.net (qmail-ldap-1.03) with SMTP
          for <atom-syntax@imc.org>; 11 Jul 2004 22:41:44 -0000
Message-ID: <041801c46798$3dfcbcc0$200ca8c0@wkearney.com>
From: "Bill Kearney" <wkearney@syndic8.com>
To: <atom-syntax@imc.org>
References: <CFE2B52D-D2D4-11D8-A6B6-003065EA6144@geckotribe.com> <1A0E593A-D2E5-11D8-9A61-000A95BD86C0@mnot.net> <opsay810jeuvpchu@quark> <40F152CA.5000000@intertwingly.net> <opsaza3fttuvpchu@quark> <40F15DC2.3060307@intertwingly.net> <opsazc38qcuvpchu@quark>
Subject: Re: MUST be UTC?
Date: Sun, 11 Jul 2004 18:41:11 -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.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
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 way, the authors can still express what time of the day in their
> local time the entry was written, as well as providing useful information
> to aggregator tools trying to (automatically) do something fun with their
> entries.

The arguments against using timestamps with or without zone suffiixes is the
root of much confusion.

If an implementation can't make a timezone assertion then it has no hope, and
workarounds are a hopeless quagmire.

Yes, it's useful to see that an item has a timestamp of "the middle of the
night, local time".  It often adds a bit of subjectivity to the process that
might be lacking otherwise.  As in, middle of the night Friday might explain
someone being drunk off their ass when they posted something.  Of course knowing
the poster's a boozehound 24x7 might be the edge case against it however.
Regardless, if consistency and ACCURATE understanding of timezones is encouraged
then this is all largely a non-issue.  This is something the developers can
spend a trivial amount of time coding and forever be DONE with it.

But if the nonsense of coddling un-zoned timestamps is tolerated then the chaos
will continue.  It's really NOT that hard folks, fix the code and MOVE ON.

-Bill Kearney
Syndic8.com



From owner-atom-syntax@mail.imc.org  Sun Jul 11 19: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 TAA18236
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 19:01: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 i6BMl5cQ040003;
	Sun, 11 Jul 2004 15: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 i6BMl5xL040002;
	Sun, 11 Jul 2004 15:47: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 (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BMl4Pv039992
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 15:47: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 8D8687C117; Mon, 12 Jul 2004 01:45:27 +0200 (CEST)
Date: Mon, 12 Jul 2004 00:50:44 +0200
To: "Sascha Carlin" <sc@itst.org>
Subject: Re: MUST be UTC?
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <87smc0qcnk.fsf@nwalsh.com> <40F0B613.9020909@itst.org> <opsazacflzuvpchu@quark> <40F187BC.3060801@itst.org>
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: <opsazweudbuvpchu@quark>
In-Reply-To: <40F187BC.3060801@itst.org>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 11 Jul 2004 20:32:28 +0200, Sascha Carlin <sc@itst.org> wrote:

>> A +1 to this one. Sascha; could you maybe write up a pace, so we get  
>> this  down «on paper»?
>
> Sorry, I only follow this mailinglist, well, very roughly ;) Please do  
> whatever you want or tell me what to do.

Recent discussions on #atom has lead to PaceDates[1] which bases the Date  
Construct in Atom on RFC 3339, which requires timezone on all dates.  
Therefore, a separate element for the timezone is not required anymore. At  
least not if the Pace is accepted.

____
[1] <url: http://intertwingly.net/wiki/pie/PaceDates>

-- 
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 Jul 11 19:23:18 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18831
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 19:23:17 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BN6Bb9041771;
	Sun, 11 Jul 2004 16:06: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 i6BN6BMR041770;
	Sun, 11 Jul 2004 16:06:11 -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 i6BN692K041748
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 16:06:11 -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 QAA23955
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 16:06:09 -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 QAA13225
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 16:06:08 -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, 11 Jul 2004 16:06:07 -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 <0I0P008H8MU545@shazam.verity.com> for atom-syntax@imc.org; Sun,
 11 Jul 2004 16:06:07 -0700 (PDT)
Date: Sun, 11 Jul 2004 16:06:03 -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: MUST be UTC?
In-reply-to: <1A0E593A-D2E5-11D8-9A61-000A95BD86C0@mnot.net>
To: atom-syntax@imc.org
Message-id: 
 <F30E2D99C5CC4893F2858B19@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
MIME-version: 1.0
X-Mailer: Mulberry/3.1.5 (Mac OS X)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <CFE2B52D-D2D4-11D8-A6B6-003065EA6144@geckotribe.com>
 <1A0E593A-D2E5-11D8-9A61-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 Saturday, July 10, 2004 7:50 PM -0700 Mark Nottingham <mnot@mnot.net> wrote:
>
> Rather than invent yet another date/time syntax, and thereby make it
> difficult for people to reuse existing software, couldn't we indicate
> that the time zone is unknown by a mechanism external to the date/time
> string?
>
> Something like
>     <atom:issued unsureTimeZone="1">2004-02-04T10:23:45Z</atom:issued>
> (use your imagination for the attribute name; this is just for colour)

Excellent idea.

We do want to use these untrustworthy times to order the entries
in one blog and to display times, but we can't trust them for
inter-blog ordering. The maximum uncertainty is +/-24 hours.
Maybe +-26 with worst-case summer/daylight time.

I really like the idea of a display timezone. UTC is for computers,
timezones are for people. So Atom must communicate dates in UTC
and should provide timezone prettyfication hints.

Funny, this is just like an undated entry in a paper diary. The order
is certain, but the exact time isn't.

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Sun Jul 11 20: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 UAA20488
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 20:06: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 i6BNkQG6045963;
	Sun, 11 Jul 2004 16:46: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 i6BNkQoM045962;
	Sun, 11 Jul 2004 16:46: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 i6BNkJrj045951
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 16:46: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 A5DC87C117; Mon, 12 Jul 2004 02:44:41 +0200 (CEST)
To: "Walter Underwood" <wunder@verity.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: MUST be UTC?
References: <CFE2B52D-D2D4-11D8-A6B6-003065EA6144@geckotribe.com> <1A0E593A-D2E5-11D8-9A61-000A95BD86C0@mnot.net> <F30E2D99C5CC4893F2858B19@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
Message-ID: <opsazy5wy0uvpchu@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: Mon, 12 Jul 2004 01:50:10 +0200
In-Reply-To: <F30E2D99C5CC4893F2858B19@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 11 Jul 2004 16:06:03 -0700, Walter Underwood <wunder@verity.com>  
wrote:

>>     <atom:issued unsureTimeZone="1">2004-02-04T10:23:45Z</atom:issued>
>
> Excellent idea.

Although much better expressed as '2004-02-04T10:23:45-00:00' as stated in  
RFC 3339 section 4.4.

-- 
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 Jul 11 20:16: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 UAA20761
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 20:16: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 i6BNpnPd046381;
	Sun, 11 Jul 2004 16:51: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 i6BNpnjF046380;
	Sun, 11 Jul 2004 16:51:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6BNpmSi046374
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 16:51: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 i6BNqS4H025063;
	Sun, 11 Jul 2004 19:52:28 -0400
Message-ID: <40F1D299.9030101@intertwingly.net>
Date: Sun, 11 Jul 2004 19:51:53 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <dtcd@mac.com>
CC: atom-syntax Syntax <atom-syntax@imc.org>
Subject: Re: MUST be UTC?
References: <20040711195602.SOBL27959.lakermmtao07.cox.net@A31P> <40F1A458.8020200@intertwingly.net> <opsazq6so96dxgxk@mail.online.no> <B3FC2720-D380-11D8-84E9-000A95DC3D90@mac.com> <40F1B5A5.2020707@intertwingly.net> <C7179283-D385-11D8-84E9-000A95DC3D90@mac.com> <40F1BB84.1070205@intertwingly.net> <7828E4BA-D388-11D8-84E9-000A95DC3D90@mac.com>
In-Reply-To: <7828E4BA-D388-11D8-84E9-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: <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 11 Jul 2004, at 6:13 pm, Sam Ruby wrote:
> 
>> LiveJournal has recorded some dates where they don't know where the 
>> author is located.
> 
> But they don't know how to correctly convert them to UTC (do they?), 
> which is a requirement of using "-00:00". I think LiveJournal falls 
> under section 4.4 "Unqualified Local Time".

I've gone back and reread this section more carefully, and now concur 
with your interpretation.

Oddly, this is 180 degrees off of where the threat indicated by this 
subject line started.  The premise of this RFC seems to be that time 
zones are useful information and should be included whenever possible. 
"-00:00" seems to be a way to indicate that this information is lost.

In any case, I now agree that this does not address LiveJournal's needs.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Sun Jul 11 20: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 UAA20794
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 20: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 i6C00XZl046927;
	Sun, 11 Jul 2004 17:00: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 i6C00XHi046926;
	Sun, 11 Jul 2004 17:00:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from beta.verity.com (beta.verity.com [192.187.143.12])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6C00WMp046917
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 17:00: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 RAA26466
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 17:00:33 -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 RAA18217
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 17:00:32 -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, 11 Jul 2004 17:00:32 -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 <0I0P008EAJSU45@shazam.verity.com> for atom-syntax@imc.org; Sun,
 11 Jul 2004 15:00:31 -0700 (PDT)
Date: Sun, 11 Jul 2004 15:00:29 -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: MUST be UTC?
In-reply-to: <m3eknip6xh.fsf@bitsko.slc.ut.us>
To: Atom-syntax <atom-syntax@imc.org>
Message-id: 
 <A6E856285FC050BE6B85AA07@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
MIME-version: 1.0
X-Mailer: Mulberry/3.1.5 (Mac OS X)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <CFE2B52D-D2D4-11D8-A6B6-003065EA6144@geckotribe.com>
 <1A0E593A-D2E5-11D8-9A61-000A95BD86C0@mnot.net> <opsay810jeuvpchu@quark>
 <40F152CA.5000000@intertwingly.net> <opsaza3fttuvpchu@quark>
 <40F15DC2.3060307@intertwingly.net> <opsazc38qcuvpchu@quark>
 <40F16B51.3000602@intertwingly.net> <opsazl8i1e6dxgxk@mail.online.no>
 <m3iscupcxh.fsf@bitsko.slc.ut.us>
 <03e201c4678a$4af6c2d0$200ca8c0@wkearney.com> <m3eknip6xh.fsf@bitsko.slc.ut.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 Sunday, July 11, 2004 4:31 PM -0500 Ken MacLeod <ken@bitsko.slc.ut.us> wrote:
>> Indeed, works from the folks at NARA [1] would well be worth
>> consulting before rampant wheel reinventing get underway.
>
> I'm not seeing any particular specs there to learn from, pointers?

Encoded Archival Desciription (EAD) is where I would start:
<http://www.loc.gov/ead/>

But archives have a much, much more difficult problem than Atom
is addressing. Dates may be uncertain, with a wide range, months,
decades, or even centuries. They need to deal with local calendars,
like the French Revolutionary calendar. What about magazines where
the release date is months apart from the cover date?

Still, library technology and practice is very effective, and we
need to learn from it.

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Sun Jul 11 20:22:17 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20941
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 20:22:17 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6C0EdQI048515;
	Sun, 11 Jul 2004 17:14: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 i6C0Edlx048514;
	Sun, 11 Jul 2004 17:14:39 -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 i6C0Ecra048507
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 17:14:38 -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 RAA27091
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 17:14:39 -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 RAA19645
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 17:14:39 -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, 11 Jul 2004 17:14:38 -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 <0I0P008JFQ0C45@shazam.verity.com> for atom-syntax@imc.org; Sun,
 11 Jul 2004 17:14:38 -0700 (PDT)
Date: Sun, 11 Jul 2004 17:14:34 -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: HTTP header/content precedence
To: atom-syntax@imc.org
Message-id: 
 <9CBF6789BA4872152EE9DAD7@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
MIME-version: 1.0
X-Mailer: Mulberry/3.1.5 (Mac OS X)
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


I'm quoting a message, but modifying this to a new issue.

--On Friday, July 9, 2004 10:06 PM -0400 Mark Pilgrim <pilgrim@gmail.com> wrote:
>
> Also note that the XML specification does specifically state that
> xml:lang (if present) overrides the external language identification.
> This is notable in that it is different in some cases from the
> precedence rules for character encoding (RFC 3023), of which we are
> all now painfully aware.

We have hit a few situations where Atom needs to resolve conflicts
between HTTP headers, content, and even the XML spec. It would be
nice to resolve all of these the same way, but that might not be
possible. Regardless, we should list them all in the spec. Here is
what I have so far.

Language: xml:lang overrides HTTP content-language

Media type and character encoding: use application/atom+xml so we
can let the XML spec rules handle it and bypass HTTP rules (override
within the rules)

Expires/refresh-rate: no decision, need to resolve HTTP caching
mechanism and historical rate-oriented RSS hints

Did I miss any? In general, it looks like content overrides
headers, which is opposite to the HTTP transmogrifying gateway
assumption. HTTP is designed for gateways which can transform
content on the fly and modify the headers to mark that decision.
These seem to be quite rare in practice, probably because they
mess with the end-to-end design principle which underlies much
of the internet design [1].

wunder

[1] <http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf>
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Sun Jul 11 20: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 UAA21480
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 20:36: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 i6C0QSwc049558;
	Sun, 11 Jul 2004 17:26: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 i6C0QSKv049557;
	Sun, 11 Jul 2004 17:26:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from beta.verity.com (beta.verity.com [192.187.143.12])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6C0QRB7049548
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 17:26:27 -0700 (PDT)
	(envelope-from wunder@verity.com)
Received: from mx-rr.verity.com ([10.3.100.59])
	by beta.verity.com (8.9.3/8.9.3) with ESMTP id RAA27954
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 17:26: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 RAA21114
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 17:26:27 -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, 11 Jul 2004 17:26:27 -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 <0I0P008Q7QK145@shazam.verity.com> for atom-syntax@imc.org; Sun,
 11 Jul 2004 17:26:27 -0700 (PDT)
Date: Sun, 11 Jul 2004 17:26:23 -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: MUST be UTC?
In-reply-to: <opsazy5wy0uvpchu@quark>
To: Atom-Syntax <atom-syntax@imc.org>
Message-id: 
 <73F7D1BDB5229F9107F33EE8@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
MIME-version: 1.0
X-Mailer: Mulberry/3.1.5 (Mac OS X)
Content-type: text/plain; charset=iso-8859-1; format=flowed
Content-disposition: inline
References: <CFE2B52D-D2D4-11D8-A6B6-003065EA6144@geckotribe.com>
 <1A0E593A-D2E5-11D8-9A61-000A95BD86C0@mnot.net>
 <F30E2D99C5CC4893F2858B19@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
 <opsazy5wy0uvpchu@quark>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6C0QRB7049552
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 Monday, July 12, 2004 1:50 AM +0200 Asbjørn Ulsberg <asbjorn@tigerstaden.no> wrote:
>
> On Sun, 11 Jul 2004 16:06:03 -0700, Walter Underwood <wunder@verity.com>  wrote:
>
>>>     <atom:issued unsureTimeZone="1">2004-02-04T10:23:45Z</atom:issued>
>>
>> Excellent idea.
>
> Although much better expressed as '2004-02-04T10:23:45-00:00' as stated
> in  RFC 3339 section 4.4.

Treating negative zero differently raises the hairs on the back of
my neck, but since it is standard, I guess it is OK. I must be having
some vicarious flashback to sign-magnitude machine architectures,
even though I've never done acid or integer sign bits.

We will have to rewrite some code to discard timestamps with
-00:00 timezone offsets, but it is minor. My instinct is that
when the indexer sees one of those, it will discard it and choose
the next most reliable source. It isn't feasible to modify the
whole search engine to handle date+certainty.

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Sun Jul 11 20: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 UAA21513
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 20: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 i6C0Lsdb049054;
	Sun, 11 Jul 2004 17:21:54 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6C0LsG3049053;
	Sun, 11 Jul 2004 17:21:54 -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 i6C0Lrmi049045
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 17:21:53 -0700 (PDT)
	(envelope-from roger@agincourtmedia.com)
Received: from biggreen ([216.63.148.42]) by journurl.com with MailEnable ESMTP; Sun, 11 Jul 2004 19:20:18 -0500
From: "Roger B." <roger@agincourtmedia.com>
To: "'Arve Bersvendsen'" <arve@virtuelvis.com>,
        "'Atom-syntax'" <atom-syntax@imc.org>
Subject: RE: MUST be UTC?
Date: Sun, 11 Jul 2004 19:21:13 -0500
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: <opsazl8i1e6dxgxk@mail.online.no>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Thread-Index: AcRnesh1ozSnbbuyTxef09o31ci3UgAJnaTA
Message-ID: <E9BB11FC984E48A8827C788BA11BF7.MAI@journurl.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


> (Besides: How likely are the old entries to reappear in any feed?)

Arve: I'm not LiveJournal, but:

Standard feed:
http://admin.support.journurl.com/?template=rss

Feed for July 2003:
http://admin.support.journurl.com/?month=07-31-2003&template=rss

Search feed for term "blogs":
http://admin.support.journurl.com/?mode=search&s=blogs&template=rss

The latter two return old entries galore.

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/ 







From owner-atom-syntax@mail.imc.org  Sun Jul 11 20:41: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 UAA21615
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 20:41: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 i6C0N8iV049231;
	Sun, 11 Jul 2004 17:23:08 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6C0N8Qb049230;
	Sun, 11 Jul 2004 17:23:08 -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 i6C0N7bf049223
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 17:23:07 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net ([66.57.27.65])
	(authenticated bits=0)
	by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i6C0NlTX026462
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 20:23:47 -0400
Message-ID: <40F1D9F0.2070409@intertwingly.net>
Date: Sun, 11 Jul 2004 20:23:12 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 Syntax <atom-syntax@imc.org>
Subject: Re: MUST be UTC?
References: <20040711195602.SOBL27959.lakermmtao07.cox.net@A31P> <40F1A458.8020200@intertwingly.net> <opsazq6so96dxgxk@mail.online.no> <B3FC2720-D380-11D8-84E9-000A95DC3D90@mac.com> <40F1B5A5.2020707@intertwingly.net> <C7179283-D385-11D8-84E9-000A95DC3D90@mac.com> <40F1BB84.1070205@intertwingly.net> <7828E4BA-D388-11D8-84E9-000A95DC3D90@mac.com> <40F1D299.9030101@intertwingly.net>
In-Reply-To: <40F1D299.9030101@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:
> 
> Oddly, this is 180 degrees off of where the threat indicated by this 
> subject line started.

Oopsie.  s/threat/thread/.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Sun Jul 11 20:55:50 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22167
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 20:55:49 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6C0jsfO051566;
	Sun, 11 Jul 2004 17:45:54 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6C0jsBl051565;
	Sun, 11 Jul 2004 17:45:54 -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 i6C0jscK051558
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 17:45:54 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.19] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id 2B107727D; Sun, 11 Jul 2004 17:46:00 -0700 (PDT)
In-Reply-To: <87hdsemsow.fsf@nwalsh.com>
References: <20040711033526.82786.qmail@web41510.mail.yahoo.com> <87hdsemsow.fsf@nwalsh.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <D7251B7F-D39C-11D8-9A61-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: Atom Syntax <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: Re: Created proposal: PaceProvideSchema
Date: Sun, 11 Jul 2004 17:45:58 -0700
To: Norman Walsh <ndw@nwalsh.com>
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>
Content-Transfer-Encoding: 7bit



On Jul 11, 2004, at 9:09 AM, Norman Walsh wrote:
> Uhm. So don't use XSD?

Big +1


Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Sun Jul 11 20: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 UAA22220
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 20: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 i6C0fSSr050732;
	Sun, 11 Jul 2004 17:41: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 i6C0fSMK050731;
	Sun, 11 Jul 2004 17:41:28 -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 i6C0fSBn050725
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 17:41:28 -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 i6C0fY9L004078;
	Sun, 11 Jul 2004 17:41:34 -0700 (PDT)
Received: from [192.168.1.100] (h00080d858303.ne.client2.attbi.com [24.61.1.243])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id i6C0fVVM017248;
	Sun, 11 Jul 2004 17:41:33 -0700 (PDT)
In-Reply-To: <73F7D1BDB5229F9107F33EE8@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
References: <CFE2B52D-D2D4-11D8-A6B6-003065EA6144@geckotribe.com> <1A0E593A-D2E5-11D8-9A61-000A95BD86C0@mnot.net> <F30E2D99C5CC4893F2858B19@adsl-64-166-133-244.dsl.snfc21.pacbell.net> <opsazy5wy0uvpchu@quark> <73F7D1BDB5229F9107F33EE8@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1--383460411; protocol="application/pkcs7-signature"
Message-Id: <36A13D4C-D39C-11D8-82B1-000A95DC3D90@mac.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: MUST be UTC?
Date: Sun, 11 Jul 2004 20:41:28 -0400
To: Walter Underwood <wunder@verity.com>
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--383460411
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 11 Jul 2004, at 8:26 pm, Walter Underwood wrote:

> Treating negative zero differently raises the hairs on the back of
> my neck, but since it is standard, I guess it is OK. I must be having
> some vicarious flashback to sign-magnitude machine architectures,
> even though I've never done acid or integer sign bits.
>
> We will have to rewrite some code to discard timestamps with
> -00:00 timezone offsets, but it is minor. My instinct is that
> when the indexer sees one of those, it will discard it and choose
> the next most reliable source. It isn't feasible to modify the
> whole search engine to handle date+certainty.

Erm, why? Maybe Sam and Bill have confused you. -00:00 means the point 
in time the event happened is known, but the timezone it happened in 
isn't (ie The UTC time is known, the local time isn't). There's no need 
to discard it unless you're desperate for the local time of the event.

Graham

--Apple-Mail-1--383460411
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
9w0BCQUxDxcNMDQwNzEyMDA0MTI5WjAjBgkqhkiG9w0BCQQxFgQUEpqbOV1PdL4z+GXuJcdQiyBh
U9IweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEANHmn2T1I88WgWSUaKxbcm2lA
4hiSeUb2MEGVdNhHdrrdsDYUEso78msLZCb1xxUPan8qQB0b3TqTGzAtVTBSeRpBAJbpwRHfVZHF
Y8aHJdL+4TcBCOoAav9Ocru8Nj8ow5p5iRQyflYnvmTB2btCFRaEiUEFdgLV7MeHuwzASXQNREjF
06YEe0MTVZO/GR9QOQFaT5WcxxGfV3reoY/dtXYoD3/wBC0GgB7XCF1OvrZ1d4S3qOyIwUT/nvsC
4Dj0WqMu4sI+iknAQO4Ytl+6wo+sLJtrQCsbAm0vSFqW3+HIGTdLjayCsIcdKEShDxgtKgMT03+M
Un0H2uVPd4WY7wAAAAAAAA==

--Apple-Mail-1--383460411--



From owner-atom-syntax@mail.imc.org  Sun Jul 11 20:57: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 UAA22238
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 20:57: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 i6C0hfBE050917;
	Sun, 11 Jul 2004 17:43: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 i6C0hfvu050916;
	Sun, 11 Jul 2004 17:43:41 -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 i6C0he0K050910
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 17:43:40 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.19] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id 79091727D; Sun, 11 Jul 2004 17:43:46 -0700 (PDT)
In-Reply-To: <87llhqjycb.fsf@nwalsh.com>
References: <87smbymve3.fsf@nwalsh.com> <B40394C3-D356-11D8-9A61-000A95BD86C0@mnot.net> <87llhqjycb.fsf@nwalsh.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <8725AB57-D39C-11D8-9A61-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: Atom Syntax <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: Re: Version vs. Namespace
Date: Sun, 11 Jul 2004 17:43:44 -0700
To: Norman Walsh <ndw@nwalsh.com>
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>
Content-Transfer-Encoding: 7bit


Atom is less a document and more a container format for metadata; any 
changes to the semantics or syntax of atom:feed and atom:entry will be 
a traumatic change anyway. So, the version doesn't give us anything new 
for changes to the feed and entry themselves, as containers.

Another thing that the version might apply to is the semantics and 
syntax of individual pieces of metadata in the atom namespace; e.g., 
atom:title and atom:content. This doesn't seem like a good use of such 
an attribute, because the version attribute is coarse-grained; if we 
change the content model of "title," it doesn't seem like a good thing 
to change the entire Atom version. Additionally, versioning for 
"built-in" and extension metadata should happen in the same manner. So, 
version probably won't apply to the syntax and semantics of atom 
metadata; if we need to change existing metadata's syntax or semantics, 
we'll need to introduce a new, separate metadata (i.e., new namespace 
and/or new local name) and have a transition story between them.

There's one thing left that the version attribute can describe; the 
vocabulary of metadata used in a particular Atom feed; i.e., the feed 
MUST contain a title, MUST NOT contain more than one foo:blah in an 
entry, etc. This is something that the namespace is NOT good for 
describing, because the syntax and semantics of the individual elements 
have not changed at all. What has changed is the allowable and required 
combinations of those elements; this is what I think the version is 
good for.

However, I don't think "version" is a good name for it, because people 
tend to read the first two use cases into it. It would be much more 
appropriate to call it something like "profile", somewhat like HTML 
has.

In other words, I'm proposing that we refine our approach to versioning 
to three separate things:

1) Atom container constructs (e.g., atom:feed, atom:entry) are 
identified by their namespace URI; if we change the containment 
semantics, processing model, etc. we have to change that namespace.

2) Atom and extension metadata are likewise identified by their 
namespace; if their syntax or semantics change, they need a differnent 
Qname. This means that the metadata in our final release of Atom had 
better be well-understood and stable, because they'll be baked in (I 
think that's OK because it's true no matter what we do, and we're 
chartered to be conservative about the metadata we bake in).

3) The "package" of metadata used in a feed is described by a "profile" 
or "version" attribute, e.g.,
   <atom:feed profile="http://.../..."> ... </atom:feed>
   Atom would ship with a "default" profile that says there MUST be an 
atom:title, etc. -- just as the spec currently does -- and that 
extensions are allowed on top of that. More specialised vertical uses 
of Atom can likewise describe their own profiles; if they can get tool 
support for them, good on them.

Thoughts? There may be some interaction with atom:mustUnderstand here; 
I could see such a profile mechanism either replacing mU or being 
augmented by it. No matter what we do, I think we need to be a lot more 
precise about what a version attribute identifies; this is my 
straw-man, I'm more than open to other approaches, as long as they 
cover all of the bases.




On Jul 11, 2004, at 9:35 AM, Norman Walsh wrote:
> Because changing namespace names is about the most traumatic thing you
> can do to a document. It breaks every single tool that is doing a
> proper namespace-based comparison of element names. All the XSLT
> stylesheets stop functioning, all the DOM tools that use the ...NS()
> accessors stop working, etc.
>
> A version attribute lets us make small changes and corrections to the
> spec over time without breaking everything.
>
> It strikes me that we need to specify the rules for processing Atom
> documents that have a version that isn't recognized. We may also want
> to add an atom:mustUnderstand attribute globally.
>
>                                         Be seeing you,
>                                           norm
>
> -- 
> Norman Walsh <ndw@nwalsh.com> | Do not try to live forever. You will
> http://nwalsh.com/            | not succeed.--George Bernard Shaw
>

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Sun Jul 11 20:58: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 UAA22256
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 20:58: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 i6C0n01i051764;
	Sun, 11 Jul 2004 17: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 i6C0n0Yc051763;
	Sun, 11 Jul 2004 17:49: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 i6C0mxk1051755
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 17:48:59 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.19] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id BBC21727D; Sun, 11 Jul 2004 17:49:05 -0700 (PDT)
In-Reply-To: <m3658up4pk.fsf@bitsko.slc.ut.us>
References: <97774BF0-D096-11D8-B2D0-000A95A51C9E@sun.com> <F3C7FAC8-D233-11D8-9A61-000A95BD86C0@mnot.net> <87smc0ownv.fsf@nwalsh.com> <F1AC0C56-D2AB-11D8-B2D0-000A95A51C9E@sun.com> <F47D290F-D2BB-11D8-9A61-000A95BD86C0@mnot.net> <7DEA0B24-D2ED-11D8-ACB6-000A95DC3D90@mac.com> <m3658up4pk.fsf@bitsko.slc.ut.us>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <45B81C71-D39D-11D8-9A61-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: Atom-Syntax Syntax <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: Re: Disambiguating the subject of feed-level metadata
Date: Sun, 11 Jul 2004 17:49:04 -0700
To: Ken MacLeod <ken@bitsko.slc.ut.us>
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>
Content-Transfer-Encoding: 7bit


+1

This has the implication of taking the defaulting mechanism OUT of 
feed-level author, copyright, etc. -- I'm all for that, but wanted to 
make sure you meant that too.



On Jul 11, 2004, at 3:19 PM, Ken MacLeod wrote:

>
> Graham <dtcd@mac.com> writes:
>
>> <feed>
>>   <author name="person A">
>>    <entry />
>>    <entry />
>>    <entry />
>>   </author>
>> </feed>
>>
>> That would also allow different defaults for different groups of
>> entries.
>
> So with an author and a contributor it might look like this?
>
> <feed>
>   <author name="person A">
>     <contributor name="person B">
>       <entry />
>       <entry />
>     </contributor>
>   </author>
>   <author name="person B">
>     <contributor name="person C">
>       <entry />
>     </contributor>
>   </author>
> </feed>
>
> With all the use-cases for multiple feeds, synthetic feeds,
> independent entries, I'm leaning heavily towards -1 on inheritance or
> defaults in any manner.  Making entries as independent as possible
> would be a good "core Atom" goal, and then explicit references for
> "more info".  I'm still good with "hard local references", such as
> <site> and <author> with known required-to-be-copied elements:
>
> <feed>
>   <site id="site1" />
>   <person id="person A" />
>   <person id="person B" />
>   <entry>
>     <site ref="site1" />
>     <author ref="person A" />
>   </entry>
>   <entry>
>     <site ref="site1" />
>     <author ref="person B" />
>     <contributor ref="person A" />
>   </entry>
> </feed>
>
> In this scenario, the "redundantly replicated" @ref elements in, yes,
> every entry are acting like foreign keys in a database table.
> Absolutely no inheritance of any kind -- it's all explicit.
>
>   -- Ken
>

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Sun Jul 11 20:59: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 UAA22319
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 20:59: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 i6C0lrU7051692;
	Sun, 11 Jul 2004 17: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 i6C0lrce051691;
	Sun, 11 Jul 2004 17:47:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.20.30.249] (user-2injafg.dialup.mindspring.com [165.121.169.240])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6C0lo2d051684
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 17:47:51 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p0611040fbd1778e7d515@[10.20.30.249]>
Date: Sun, 11 Jul 2004 17:48:15 -0700
To: Atom WG <atom-syntax@imc.org>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: On MUST and SHOULD
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>


Greetings again. I am now speaking with my working group co-chair hat on.

Everyone who is commenting on the list should go read RFC 2119 as 
soon as possible. Really. It's amazingly short document but very, 
very useful for some of the threads that have been started recently. 
Be sure to read section 6. Then go back and read the whole thing 
again.

If enough folks do this, the traffic on the mailing list about MUST 
and SHOULD will go way down.

<http://www.ietf.org/rfc/rfc2119.txt>

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Sun Jul 11 21:02: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 VAA22378
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 21:02: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 i6C0qK0d052071;
	Sun, 11 Jul 2004 17: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 i6C0qKkt052070;
	Sun, 11 Jul 2004 17:52:20 -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 i6C0qKhu052060
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 17:52: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 RAA00042
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 17:52: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 RAA24890
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 17:52:20 -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, 11 Jul 2004 17:52:19 -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 <0I0P008BYRR545@shazam.verity.com> for atom-syntax@imc.org; Sun,
 11 Jul 2004 17:52:19 -0700 (PDT)
Date: Sun, 11 Jul 2004 17:52:15 -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: MUST be UTC?
In-reply-to: <36A13D4C-D39C-11D8-82B1-000A95DC3D90@mac.com>
To: Atom-Syntax <atom-syntax@imc.org>
Message-id: 
 <9C895A5189754D5C0C88D461@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
MIME-version: 1.0
X-Mailer: Mulberry/3.1.5 (Mac OS X)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <CFE2B52D-D2D4-11D8-A6B6-003065EA6144@geckotribe.com>
 <1A0E593A-D2E5-11D8-9A61-000A95BD86C0@mnot.net>
 <F30E2D99C5CC4893F2858B19@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
 <opsazy5wy0uvpchu@quark>
 <73F7D1BDB5229F9107F33EE8@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
 <36A13D4C-D39C-11D8-82B1-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 Sunday, July 11, 2004 8:41 PM -0400 Graham <dtcd@mac.com> wrote:
>
> Erm, why? Maybe Sam and Bill have confused you. -00:00 means the point
> in time the event happened is known, but the timezone it happened in
> isn't (ie The UTC time is known, the local time isn't). There's no need
> to discard it unless you're desperate for the local time of the event.

First, the application -- I expect to use Atom feeds to: 1) direct the
search engine spider to interesting content, and 2) provide quality
metadata for those targets.

The -00:00 timestamps have a large error. Either I change the software
to carry around error estimates for all timestamps and choose the best,
or we throw away the bad ones early on. HTTP timestamps are implicitly
exact, so they always win. Thus, we throw away all -00:00 timestamps
from Atom.

I'm quite familiar with timezone issues. We provide search for
worldwide companies, so queries for "changed in the last day"
need to work regardless of timezone. Timezones are a tar pit.

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Sun Jul 11 21:06: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 VAA22552
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 21:06: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 i6C0vI13052369;
	Sun, 11 Jul 2004 17:57:18 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6C0vIr8052368;
	Sun, 11 Jul 2004 17:57:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from homer.w3.org (homer.w3.org [18.29.0.30])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6C0vIcR052361
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 17:57:18 -0700 (PDT)
	(envelope-from danbri@w3.org)
Received: by homer.w3.org (Postfix, from userid 13522)
	id D876A4F16F; Sun, 11 Jul 2004 20:57:23 -0400 (EDT)
Date: Sun, 11 Jul 2004 20:57:23 -0400
From: Dan Brickley <danbri@w3.org>
To: Walter Underwood <wunder@verity.com>
Cc: Atom-syntax <atom-syntax@imc.org>
Subject: Re: MUST be UTC?
Message-ID: <20040712005723.GA12483@homer.w3.org>
References: <40F152CA.5000000@intertwingly.net> <opsaza3fttuvpchu@quark> <40F15DC2.3060307@intertwingly.net> <opsazc38qcuvpchu@quark> <40F16B51.3000602@intertwingly.net> <opsazl8i1e6dxgxk@mail.online.no> <m3iscupcxh.fsf@bitsko.slc.ut.us> <03e201c4678a$4af6c2d0$200ca8c0@wkearney.com> <m3eknip6xh.fsf@bitsko.slc.ut.us> <A6E856285FC050BE6B85AA07@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <A6E856285FC050BE6B85AA07@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
User-Agent: Mutt/1.5.6+20040523i
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>


* Walter Underwood <wunder@verity.com> [2004-07-11 15:00-0700]
> 
> --On Sunday, July 11, 2004 4:31 PM -0500 Ken MacLeod <ken@bitsko.slc.ut.us> 
> wrote:
> >>Indeed, works from the folks at NARA [1] would well be worth
> >>consulting before rampant wheel reinventing get underway.
> >
> >I'm not seeing any particular specs there to learn from, pointers?
> 
> Encoded Archival Desciription (EAD) is where I would start:
> <http://www.loc.gov/ead/>
> 
> But archives have a much, much more difficult problem than Atom
> is addressing. Dates may be uncertain, with a wide range, months,
> decades, or even centuries. They need to deal with local calendars,
> like the French Revolutionary calendar. 

It isn't clear to me that Atom/RSS/etc should avoid this issue. There
are 1000s of Iranian blogs whose dates are published and consumed in
terms of the Persian calendar. I'd hope at least for non-gregorian dates 
to be expressible using extensions in another namespace; when Atom's 
namespace extension policy is nailed down, perhaps we might revisit this
topic?

>					What about magazines where
> the release date is months apart from the cover date?
> 
> Still, library technology and practice is very effective, and we
> need to learn from it.

Most certainly...

Dan



From owner-atom-syntax@mail.imc.org  Sun Jul 11 21:13: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 VAA22800
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 21: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 i6C12FHj052800;
	Sun, 11 Jul 2004 18:02: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 i6C12FYs052799;
	Sun, 11 Jul 2004 18:02:15 -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 i6C12EE5052787
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 18:02:14 -0700 (PDT)
	(envelope-from wunder@verity.com)
Received: from mx-rr.verity.com ([10.3.100.59])
	by beta.verity.com (8.9.3/8.9.3) with ESMTP id SAA00809
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 18:02:15 -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 SAA26550
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 18:02: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); Sun, 11 Jul 2004 18:02: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 <0I0P008Q7S7O45@shazam.verity.com> for atom-syntax@imc.org; Sun,
 11 Jul 2004 18:02:13 -0700 (PDT)
Date: Sun, 11 Jul 2004 18:02:09 -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: MUST be UTC?
In-reply-to: <20040712005723.GA12483@homer.w3.org>
To: Atom-syntax <atom-syntax@imc.org>
Message-id: 
 <A3A1DF40B89EC92DB56C3C7F@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
MIME-version: 1.0
X-Mailer: Mulberry/3.1.5 (Mac OS X)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <40F152CA.5000000@intertwingly.net> <opsaza3fttuvpchu@quark>
 <40F15DC2.3060307@intertwingly.net> <opsazc38qcuvpchu@quark>
 <40F16B51.3000602@intertwingly.net> <opsazl8i1e6dxgxk@mail.online.no>
 <m3iscupcxh.fsf@bitsko.slc.ut.us>
 <03e201c4678a$4af6c2d0$200ca8c0@wkearney.com>
 <m3eknip6xh.fsf@bitsko.slc.ut.us>
 <A6E856285FC050BE6B85AA07@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
 <20040712005723.GA12483@homer.w3.org>
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 Sunday, July 11, 2004 8:57 PM -0400 Dan Brickley <danbri@w3.org> wrote:
>
> It isn't clear to me that Atom/RSS/etc should avoid this issue. There
> are 1000s of Iranian blogs whose dates are published and consumed in
> terms of the Persian calendar. I'd hope at least for non-gregorian dates
> to be expressible using extensions in another namespace; when Atom's
> namespace extension policy is nailed down, perhaps we might revisit this
> topic?

Good point. Perhaps a utc-date and optional display-date for each value?
They MUST be equivalent, of course.

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Sun Jul 11 21:16: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 VAA22865
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 21:16:28 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6C1A0Nr053513;
	Sun, 11 Jul 2004 18:10: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 i6C1A0Jo053512;
	Sun, 11 Jul 2004 18:10:00 -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 i6C19x5v053497
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 18:10:00 -0700 (PDT)
	(envelope-from roger@agincourtmedia.com)
Received: from biggreen ([216.63.148.42]) by journurl.com with MailEnable ESMTP; Sun, 11 Jul 2004 20:06:11 -0500
From: "Roger B." <roger@agincourtmedia.com>
To: "'Sam Ruby'" <rubys@intertwingly.net>
Cc: "'Atom Syntax'" <atom-syntax@imc.org>
Subject: RE: atom:summary or atom:content required?
Date: Sun, 11 Jul 2004 20:07:25 -0500
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: <40F18688.6030805@intertwingly.net>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Thread-Index: AcRndJzv6kuMYPcqTJK0wTzGiOLZIgAM/+MA
Message-ID: <3AE4F0E1DA564FF08A26361ECF6928.MAI@journurl.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


> Note that there are slippery slope arguments on both sides of this.  

Sam: Agreed. I just wanted to point out a practical example of a feed that
_can't_ have content, and one that many people in the relevant community
depend upon.  

It's funny... I produce thousands of individual feeds, but of them all, that
relative handful of crippled, scraped snippets have generated more "thank
you"s and ongoing good vibes than all the rest combined. 

> Roger, as somebody who has been following Atom since before it was
> called Echo, and as a producer of feeds for which there are neither a
> summary or a content (and therefore, a recipient of complaints), do you
> think it is important for Atom to support feeds which have neither?

For my purposes? No. My no-content feeds are distributing such limited info
that there's really no need for anything more than RSS. Trying to force that
kind of thing to work with Atom nets the user nothing (the RSS and Atom
versions would be effectively identical), and blunts Atom's purpose (clearer
specification) in the process. 

And if I'm absolutely determined to use Atom anyway, what's stopping me from
just inserting an empty atom:content or atom:summary element? It might be
tacky, but it's also an edge-case... I'm sure most aggregators would
compensate by doing what they're already doing with description-less RSS.

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/ 







From owner-atom-syntax@mail.imc.org  Sun Jul 11 21: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 VAA23474
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 21:32: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 i6C1IGkQ054739;
	Sun, 11 Jul 2004 18: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 i6C1IGUU054738;
	Sun, 11 Jul 2004 18:18:16 -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 i6C1IGCM054732
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 18:18:16 -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 i6C1IMOo017383;
	Sun, 11 Jul 2004 18:18:22 -0700 (PDT)
Received: from [192.168.1.100] (h00080d858303.ne.client2.attbi.com [24.61.1.243])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id i6C1IL0t016860;
	Sun, 11 Jul 2004 18:18:22 -0700 (PDT)
In-Reply-To: <9C895A5189754D5C0C88D461@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
References: <CFE2B52D-D2D4-11D8-A6B6-003065EA6144@geckotribe.com> <1A0E593A-D2E5-11D8-9A61-000A95BD86C0@mnot.net> <F30E2D99C5CC4893F2858B19@adsl-64-166-133-244.dsl.snfc21.pacbell.net> <opsazy5wy0uvpchu@quark> <73F7D1BDB5229F9107F33EE8@adsl-64-166-133-244.dsl.snfc21.pacbell.net> <36A13D4C-D39C-11D8-82B1-000A95DC3D90@mac.com> <9C895A5189754D5C0C88D461@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--381249133; protocol="application/pkcs7-signature"
Message-Id: <5CA75B0F-D3A1-11D8-82B1-000A95DC3D90@mac.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: MUST be UTC?
Date: Sun, 11 Jul 2004 21:18:20 -0400
To: Walter Underwood <wunder@verity.com>
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--381249133
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 11 Jul 2004, at 8:52 pm, Walter Underwood wrote:

>
> --On Sunday, July 11, 2004 8:41 PM -0400 Graham <dtcd@mac.com> wrote:
>>
>> Erm, why? Maybe Sam and Bill have confused you. -00:00 means the point
>> in time the event happened is known, but the timezone it happened in
>> isn't (ie The UTC time is known, the local time isn't). There's no 
>> need
>> to discard it unless you're desperate for the local time of the event.
>
> First, the application -- I expect to use Atom feeds to: 1) direct the
> search engine spider to interesting content, and 2) provide quality
> metadata for those targets.
>
> The -00:00 timestamps have a large error.

No they do not. A -00:00 timestamp is as accurate as one with +00:00. 
The difference is that the *originating* timezone is unknown. 
12:00-00:00 could really be 08:00-4:00 or 17:00+5:00, but whatever, 
it's still noon UTC. When normalizing for a search engine, you don't 
have a problem.

Graham
--Apple-Mail-2--381249133
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
9w0BCQUxDxcNMDQwNzEyMDExODIwWjAjBgkqhkiG9w0BCQQxFgQUCcohNA/6QRvbYzvz1qjaSexS
2AYweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAInqXKlIW0kr3dVQaX+k8QVJu
WsRhP3ejid1emj98RCrYXEIksnLIwbpkhW8D2mozrx07FLVHaGMicL0mI4uDlHsSMMVO/7TURyn+
xrhGsxItMN08/nlrVCJACHqOwhD8VkPMjV49+OCr3DD5NnO9QNt30JrSIcog85LbRgODsJ5qWUXx
GKbhNKUe7olOvc0hnGyMWk4fIUcAe0IL8lOA3uTz6I5MrKTjv7cyKEEB8W06XkGE5qvQRplYlfHh
TRLqwcjV8uDxf+pgn7AUe00iJZ6J8j3gThl3RQX4ofzS5NnEdAQ+Cw3PjiY/S35b5AdwYw2/Cg8D
xv18CillRnhLHQAAAAAAAA==

--Apple-Mail-2--381249133--



From owner-atom-syntax@mail.imc.org  Sun Jul 11 21:50:06 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24094
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 21:50:06 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6C1bGmn056121;
	Sun, 11 Jul 2004 18:37: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 i6C1bGxN056120;
	Sun, 11 Jul 2004 18:37:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web41501.mail.yahoo.com (web41501.mail.yahoo.com [66.218.93.84])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6C1bGHZ056112
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 18:37:16 -0700 (PDT)
	(envelope-from randymorin@yahoo.com)
Message-ID: <20040712013717.19749.qmail@web41501.mail.yahoo.com>
Received: from [24.43.182.164] by web41501.mail.yahoo.com via HTTP; Sun, 11 Jul 2004 18:37:17 PDT
Date: Sun, 11 Jul 2004 18:37:17 -0700 (PDT)
From: Randy Charles Morin <randymorin@yahoo.com>
Reply-To: randy@kbcafe.com
Subject: Re: Created proposal: PaceProvideSchema 
To: Atomlist <atom-syntax@imc.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1591195384-1089596237=:18583"
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>


--0-1591195384-1089596237=:18583
Content-Type: text/plain; charset=us-ascii

Norman Walsh wrote:
>Uhm. So don't use XSD?

So, we shouldn't use the schema language that is most supported by vendors. Don't use the schema language language which Microsoft and Apache/IBM have created countless tools from. Let's start from scratch. Clean slate.
Thanks,
 
Randy
http://www.kbcafe.com
 

		
---------------------------------
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
--0-1591195384-1089596237=:18583
Content-Type: text/html; charset=us-ascii

<DIV>Norman Walsh wrote:</DIV>
<DIV>&gt;Uhm. So don't use XSD?<BR></DIV>
<DIV>So, we shouldn't use the schema language that is most supported by vendors. Don't use the schema language language which Microsoft and Apache/IBM&nbsp;have created countless tools from. Let's start from scratch. Clean slate.</DIV>
<DIV>Thanks,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Randy</DIV>
<DIV><A href="http://www.kbcafe.com">http://www.kbcafe.com</A></DIV>
<DIV>&nbsp;</DIV><p>
		<hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/mail_us/taglines/10/*http://promotions.yahoo.com/new_mail/static/efficiency.html">New and Improved Yahoo! Mail</a> - Send 10MB messages!
--0-1591195384-1089596237=:18583--



From owner-atom-syntax@mail.imc.org  Sun Jul 11 22: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 WAA25717
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 22:37: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 i6C2HxPD060681;
	Sun, 11 Jul 2004 19: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 i6C2HxTa060680;
	Sun, 11 Jul 2004 19: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 i6C2Hxvj060671
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 19:17:59 -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 TAA05448
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 19:18: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 TAA04695
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 19:18:00 -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, 11 Jul 2004 19:17:59 -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 <0I0P008FEVPX45@shazam.verity.com> for atom-syntax@imc.org; Sun,
 11 Jul 2004 19:17:59 -0700 (PDT)
Date: Sun, 11 Jul 2004 19:17:57 -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: MUST be UTC?
In-reply-to: <5CA75B0F-D3A1-11D8-82B1-000A95DC3D90@mac.com>
To: Atom-Syntax <atom-syntax@imc.org>
Message-id: 
 <1143567D29087196AEBD57C9@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
MIME-version: 1.0
X-Mailer: Mulberry/3.1.5 (Mac OS X)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <CFE2B52D-D2D4-11D8-A6B6-003065EA6144@geckotribe.com>
 <1A0E593A-D2E5-11D8-9A61-000A95BD86C0@mnot.net>
 <F30E2D99C5CC4893F2858B19@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
 <opsazy5wy0uvpchu@quark>
 <73F7D1BDB5229F9107F33EE8@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
 <36A13D4C-D39C-11D8-82B1-000A95DC3D90@mac.com>
 <9C895A5189754D5C0C88D461@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
 <5CA75B0F-D3A1-11D8-82B1-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 Sunday, July 11, 2004 9:18 PM -0400 Graham <dtcd@mac.com> wrote:
>> The -00:00 timestamps have a large error.
>
> No they do not. A -00:00 timestamp is as accurate as one with +00:00.
> The difference is that the *originating* timezone is unknown. 12:00-00:00
> could really be 08:00-4:00 or 17:00+5:00, but whatever, it's still noon
> UTC. When normalizing for a search engine, you don't have a problem.

You are right. I didn't read RFC 3339 closely. Sorry. I was catching
up on 275 new messages.

Local clock time with an unknown timezone cannot be represented in
RFC 3339 formats. So old LiveJournal timestamps cannot be sent in
Atom if we require RFC 3339.

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Sun Jul 11 22:39:49 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25800
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 22:39: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 i6C2QuZk061343;
	Sun, 11 Jul 2004 19: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 i6C2Quvf061342;
	Sun, 11 Jul 2004 19:26:56 -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 i6C2Qtfe061333
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 19:26: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 i6C2Qu53002061
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 21:26:56 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6C2QuuW002057;
	Sun, 11 Jul 2004 21:26:56 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom-syntax <atom-syntax@imc.org>
Subject: Re: MUST be UTC?
References: <CFE2B52D-D2D4-11D8-A6B6-003065EA6144@geckotribe.com>
	<1A0E593A-D2E5-11D8-9A61-000A95BD86C0@mnot.net>
	<opsay810jeuvpchu@quark> <40F152CA.5000000@intertwingly.net>
	<opsaza3fttuvpchu@quark> <40F15DC2.3060307@intertwingly.net>
	<opsazc38qcuvpchu@quark> <40F16B51.3000602@intertwingly.net>
	<opsazl8i1e6dxgxk@mail.online.no> <m3iscupcxh.fsf@bitsko.slc.ut.us>
	<03e201c4678a$4af6c2d0$200ca8c0@wkearney.com>
	<m3eknip6xh.fsf@bitsko.slc.ut.us>
	<A6E856285FC050BE6B85AA07@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 11 Jul 2004 21:26:55 -0500
In-Reply-To:  <A6E856285FC050BE6B85AA07@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
Message-ID: <m31xjiot8w.fsf@bitsko.slc.ut.us>
Lines: 34
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


Walter Underwood <wunder@verity.com> writes:

> Encoded Archival Desciription (EAD) is where I would start:
> <http://www.loc.gov/ead/>
> 
> But archives have a much, much more difficult problem than Atom is
> addressing. Dates may be uncertain, with a wide range, months,
> decades, or even centuries. They need to deal with local calendars,
> like the French Revolutionary calendar. What about magazines where
> the release date is months apart from the cover date?
> 
> Still, library technology and practice is very effective, and we
> need to learn from it.

I may be misunderstanding the scope of this suggestion.

The scope I'm describing is the "export" of an Atom publishing system,
either of the whole system (an "archive" of the Atom publishing
system), or an "index" structure (as described in "Catching up on
missed news"[1]).

Within this scope, the "archive" or "index" contain the same <entry>
resources as appear in feeds (possibly with additional information,
like source formatted content).

If these other archiving technologies are more appropriate for that
purpose, it's likely that they are more appropriate model for <entry>s
that we use in feeds, too.

Please advise,

  -- Ken

[1] http://www.xml.com/pub/a/2004/06/16/dive.html



From owner-atom-syntax@mail.imc.org  Sun Jul 11 23:04: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 XAA26782
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 23:04: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 i6C2lTjG062610;
	Sun, 11 Jul 2004 19:47: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 i6C2lTvr062609;
	Sun, 11 Jul 2004 19:47:29 -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 i6C2lMlD062584
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 19:47:28 -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 i6C2lN53002257
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 21:47:23 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6C2lNnu002253;
	Sun, 11 Jul 2004 21:47:23 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom-Syntax Syntax <atom-syntax@imc.org>
Subject: Re: Disambiguating the subject of feed-level metadata
References: <97774BF0-D096-11D8-B2D0-000A95A51C9E@sun.com>
	<F3C7FAC8-D233-11D8-9A61-000A95BD86C0@mnot.net>
	<87smc0ownv.fsf@nwalsh.com>
	<F1AC0C56-D2AB-11D8-B2D0-000A95A51C9E@sun.com>
	<F47D290F-D2BB-11D8-9A61-000A95BD86C0@mnot.net>
	<7DEA0B24-D2ED-11D8-ACB6-000A95DC3D90@mac.com>
	<m3658up4pk.fsf@bitsko.slc.ut.us>
	<45B81C71-D39D-11D8-9A61-000A95BD86C0@mnot.net>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 11 Jul 2004 21:47:23 -0500
In-Reply-To: <45B81C71-D39D-11D8-9A61-000A95BD86C0@mnot.net>
Message-ID: <m3wu1andqc.fsf@bitsko.slc.ut.us>
Lines: 25
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: <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> writes:

> +1
> 
> This has the implication of taking the defaulting mechanism OUT of
> feed-level author, copyright, etc. -- I'm all for that, but wanted
> to make sure you meant that too.

Yes, that's what I meant.

Feed-level site information moves into a child element of the feed
called <site>.  <person> elements could be in <site> or move
seperately as element children of the <feed> also, but are still
referenced explicitly from <entry>s.

Extensions to <site> would go in <site>, extensions to <person> would
go in <person>.  New entity constructs could be child elements of
<feed> as well.  Two examples are <category> and <section>.

My term for these "major" independent elements in the original Syntax
document on the wiki was "Entity" elements, which in current style now
be "Entity constructs", basically a small or micro-content resource
that has an <id>.

  -- Ken



From owner-atom-syntax@mail.imc.org  Sun Jul 11 23:12: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 XAA27006
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 23:12: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 i6C2sSek063106;
	Sun, 11 Jul 2004 19:54: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 i6C2sSWj063105;
	Sun, 11 Jul 2004 19:54: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 i6C2sRci063095
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 19:54: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 E32B97C117; Mon, 12 Jul 2004 05:52:51 +0200 (CEST)
To: "Walter Underwood" <wunder@verity.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: MUST be UTC?
References: <CFE2B52D-D2D4-11D8-A6B6-003065EA6144@geckotribe.com> <1A0E593A-D2E5-11D8-9A61-000A95BD86C0@mnot.net> <F30E2D99C5CC4893F2858B19@adsl-64-166-133-244.dsl.snfc21.pacbell.net> <opsazy5wy0uvpchu@quark> <73F7D1BDB5229F9107F33EE8@adsl-64-166-133-244.dsl.snfc21.pacbell.net> <36A13D4C-D39C-11D8-82B1-000A95DC3D90@mac.com> <9C895A5189754D5C0C88D461@adsl-64-166-133-244.dsl.snfc21.pacbell.net> <5CA75B0F-D3A1-11D8-82B1-000A95DC3D90@mac.com> <1143567D29087196AEBD57C9@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
Message-ID: <opsaz7un0ruvpchu@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: Mon, 12 Jul 2004 04:57:49 +0200
In-Reply-To: <1143567D29087196AEBD57C9@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 11 Jul 2004 19:17:57 -0700, Walter Underwood <wunder@verity.com>  
wrote:

> So old LiveJournal timestamps cannot be sent in Atom if we require
> RFC 3339.

Correct. Old LiveJournal timestamps should therefore be fixed.

-- 
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 Jul 11 23:20: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 XAA27145
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 23:20: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 i6C37DRC064053;
	Sun, 11 Jul 2004 20:07: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 i6C37DVr064052;
	Sun, 11 Jul 2004 20:07:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.mnot.net (adsl-67-119-69-242.dsl.sntc01.pacbell.net [67.119.69.242])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6C37AEU064042
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 20:07:12 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.19] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id BD092727D; Sun, 11 Jul 2004 20:07:16 -0700 (PDT)
In-Reply-To: <87oemmmuy5.fsf@nwalsh.com>
References: <87oemmmuy5.fsf@nwalsh.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <9340AD71-D3B0-11D8-9A61-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: Atom Syntax <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: Re: atom:author in feed and entry
Date: Sun, 11 Jul 2004 20:07:14 -0700
To: Norman Walsh <ndw@nwalsh.com>
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>
Content-Transfer-Encoding: 7bit


I think this is the crux of the defaulting discussion going on in the 
PaceElementOrder thread; see those messages titled "Disambiguating the 
subject of feed-level metadata." Once we figure that out, this should 
follow...


On Jul 11, 2004, at 8:20 AM, Norman Walsh wrote:

> The draft 00 spec says "atom:feed elements MUST contain exactly one
> atom:author element, UNLESS all of the atom:feed element's child
> atom:entry elements contain an atom:author element".
>
> May the atom:feed element contain an atom:author if all of the
> relevant atom:entry elements ALSO contain an atom:author?
>
>                                         Be seeing you,
>                                           norm
>
> -- 
> Norman Walsh <ndw@nwalsh.com> | What are the thoughts of the canvas on
> http://nwalsh.com/            | which a masterpiece is being created?
>                               | "I am being soiled, brutally treated
>                               | and concealed from view." Thus men
>                               | grumble at their destiny, however
>                               | fair.--Jean Cocteau
>

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Sun Jul 11 23:30:51 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27505
	for <atompub-archive@lists.ietf.org>; Sun, 11 Jul 2004 23:30: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 i6C3C8dw064502;
	Sun, 11 Jul 2004 20:12: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 i6C3C83q064501;
	Sun, 11 Jul 2004 20:12:08 -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 i6C3C8DD064494
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 20:12:08 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.19] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id E72D1727D; Sun, 11 Jul 2004 20:12:14 -0700 (PDT)
In-Reply-To: <20040712013717.19749.qmail@web41501.mail.yahoo.com>
References: <20040712013717.19749.qmail@web41501.mail.yahoo.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <45249A2E-D3B1-11D8-9A61-000A95BD86C0@mnot.net>
Cc: Atomlist <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: Re: Created proposal: PaceProvideSchema 
Date: Sun, 11 Jul 2004 20:12:13 -0700
To: randy@kbcafe.com
X-Mailer: Apple Mail (2.618)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6C3C8DD064495
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 Jul 11, 2004, at 6:37 PM, Randy Charles Morin wrote:

> So, we shouldn't use the schema language that is most supported by 
> vendors.
> Don't use the schema language language which Microsoft and 
> Apache/IBM have created countless tools from. Let's start from 
> scratch. Clean slate.

Sounds sensible to me. Seriously. Just because MSFT and IBM have thrown 
resources at it doesn't mean that it'll magically work, thanks to their 
pixie dust; both have made mistakes, of which there are numerous 
examples. I'm not just picking on them, of course, but they were the 
only vendors you mention.

Consider this - WSDL isn't specified in terms of XML Schema; it defines 
a "component model." Neither does SOAP; that's right, the Schema isn't 
normative, just informational.

--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org  Mon Jul 12 00: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 AAA28740
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 00: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 i6C3utSK067745;
	Sun, 11 Jul 2004 20: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 i6C3usBc067732;
	Sun, 11 Jul 2004 20:56:54 -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 i6C3uqdh067640;
	Sun, 11 Jul 2004 20:56:52 -0700 (PDT)
	(envelope-from jasnell@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.2) with ESMTP id i6C3uquc588190;
	Sun, 11 Jul 2004 23:56:52 -0400
Received: from d03nm122.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170])
	by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6C3uqnf393172;
	Sun, 11 Jul 2004 21:56:52 -0600
In-Reply-To: <45249A2E-D3B1-11D8-9A61-000A95BD86C0@mnot.net>
To: Mark Nottingham <mnot@mnot.net>
Cc: Atomlist <atom-syntax@imc.org>, owner-atom-syntax@mail.imc.org,
        randy@kbcafe.com
MIME-Version: 1.0
Subject: Re: Created proposal: PaceProvideSchema
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
From: James M Snell <jasnell@us.ibm.com>
X-MIMETrack: S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/11/2004 08:53:22 PM,
	Serialize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/11/2004 08:53:22 PM,
	Serialize complete at 07/11/2004 08:53:22 PM,
	Itemize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/11/2004 08:53:22 PM,
	S/MIME Sign complete at 07/11/2004 08:53:22 PM,
	S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/11/2004 08:56:49 PM,
	S/MIME Sign complete at 07/11/2004 08:56:49 PM,
	Serialize by Router on D03NM122/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at
 07/11/2004 21:56:52,
	Serialize complete at 07/11/2004 21:56:52
Message-ID: <OFA17BD725.9FB45E49-ON88256ECF.00154080-88256ECF.0015AE5D@us.ibm.com>
Date: Sun, 11 Jul 2004 21:56:49 -0600
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z32150_boundary_sign
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>


This is an S/MIME signed message.

---------z32150_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 00155DB488256ECF_="

This is a multipart message in MIME format.
--=_alternative 00155DB488256ECF_=
Content-Type: text/plain; charset="US-ASCII"

IMHO, like WSDL and SOAP, Atom should also provide an *informational* XML 
Schema.  It may be something put together "unofficially" by those of us 
who care about such things, but something should be made available.

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



Mark Nottingham <mnot@mnot.net> 
Sent by: owner-atom-syntax@mail.imc.org
07/11/2004 08:12 PM

To
randy@kbcafe.com
cc
Atomlist <atom-syntax@imc.org>
Subject
Re: Created proposal: PaceProvideSchema








On Jul 11, 2004, at 6:37 PM, Randy Charles Morin wrote:

> So, we shouldn't use the schema language that is most supported by 
> vendors.
> Don't use the schema language language which Microsoft and 
> Apache/IBM have created countless tools from. Let's start from 
> scratch. Clean slate.

Sounds sensible to me. Seriously. Just because MSFT and IBM have thrown 
resources at it doesn't mean that it'll magically work, thanks to their 
pixie dust; both have made mistakes, of which there are numerous 
examples. I'm not just picking on them, of course, but they were the 
only vendors you mention.

Consider this - WSDL isn't specified in terms of XML Schema; it defines 
a "component model." Neither does SOAP; that's right, the Schema isn't 
normative, just informational.

--
Mark Nottingham     http://www.mnot.net/




--=_alternative 00155DB488256ECF_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">IMHO, like WSDL and SOAP, Atom should
also provide an *informational* XML Schema. &nbsp;It may be something put
together &quot;unofficially&quot; by those of us who care about such things,
but something should be made available.</font>
<br>
<br><font size=2 face="sans-serif">- James M Snell<br>
 &nbsp;jasnell@us.ibm.com<br>
 &nbsp;http://www.ibm.com<br>
 &nbsp;(877) 511-5082 / Office<br>
 &nbsp;930-1979 / Tie Line</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Mark Nottingham &lt;mnot@mnot.net&gt;</b>
</font>
<br><font size=1 face="sans-serif">Sent by: owner-atom-syntax@mail.imc.org</font>
<p><font size=1 face="sans-serif">07/11/2004 08:12 PM</font>
<td width=59%>
<table width=100%>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td valign=top><font size=1 face="sans-serif">randy@kbcafe.com</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td valign=top><font size=1 face="sans-serif">Atomlist &lt;atom-syntax@imc.org&gt;</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td valign=top><font size=1 face="sans-serif">Re: Created proposal: PaceProvideSchema</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2><tt><br>
<br>
On Jul 11, 2004, at 6:37 PM, Randy Charles Morin wrote:<br>
<br>
&gt; So, we shouldn't use the schema language that is most supported by
<br>
&gt; vendors.<br>
&gt; Don't use the schema language language which Microsoft and <br>
&gt; Apache/IBM&nbsp;have created countless tools from. Let's start from
<br>
&gt; scratch. Clean slate.<br>
<br>
Sounds sensible to me. Seriously. Just because MSFT and IBM have thrown
<br>
resources at it doesn't mean that it'll magically work, thanks to their
<br>
pixie dust; both have made mistakes, of which there are numerous <br>
examples. I'm not just picking on them, of course, but they were the <br>
only vendors you mention.<br>
<br>
Consider this - WSDL isn't specified in terms of XML Schema; it defines
<br>
a &quot;component model.&quot; Neither does SOAP; that's right, the Schema
isn't <br>
normative, just informational.<br>
<br>
--<br>
Mark Nottingham &nbsp; &nbsp; http://www.mnot.net/<br>
<br>
<br>
</tt></font>
<br>
--=_alternative 00155DB488256ECF_=--

---------z32150_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIIUOAIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIISWDCCAtow
ggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1
aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAy
MDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA629xc49NpAPz
cAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7glzJKgPkPzlTZZfznznGbmAWVnNBQ
lyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnwNclOnnP2sKufuPzbTImQTTi5c8JZNZcM
J0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEEBAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1Ud
DgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAPBgNVHRMBAf8EBTADAQH/MDEGA1UdJQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUH
AwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvu
jQupk2oCScMd3FIHLE7hOfu8YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14ke
McF9ViNdewEoBGiAycUq8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIC2jCCAkOgAwIB
AgIDAxS2MA0GCSqGSIb3DQEBBAUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwMTE0MjIw
NzExWhcNMTExMjMxMjIwNzExWjBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25h
bCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrb3Fzj02kA/NwCy5KFMiY
tFgyTJ6kMSQLVSs9uwVHIAVkqy/enDQwZ9b/7uCXMkqA+Q/OVNll/OfOcZuYBZWc0FCXI9qw60KO
J/rTd65FdF4dwp8cw8si0qjOJtYg8cm46fA1yU6ec/awq5+4/NtMiZBNOLlzwlk1lwwnRgXNNwID
AQABo4GqMIGnMBEGCWCGSAGG+EIBAQQEAwIAhzAOBgNVHQ8BAf8EBAMCAcYwHQYDVR0OBBYEFK5U
DpLqqDOpKyQtx8hvMNze80pAMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMA8GA1Ud
EwEB/wQFMAMBAf8wMQYDVR0lBCowKAYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYB
BQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAMnJ7c2YLyrY/PKlFl+7sm8NENfWtFxqdm+6NC6mTagJJ
wx3cUgcsTuE5+7xh9+/G0tTfLzA1qZAQ5GNMPXvmoB9+vJfKnC2JWMFQpIOUEJDXiR4xwX1WI117
ASgEaIDJxSrxHcuuV/hMIO9bgZ6C41MUVmdLTKBgBOImTuIPK8QwggMgMIICiaADAgECAgQ13vTP
MA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQL
EyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0MTUxWhcN
MTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMk
RXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKKlQRkrPFr
U18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkwrFEeO68r
1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOgYaRfMF0x
CzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBD
ZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAxODA4MjIx
NjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAdBgNV
HQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0HQQAEDTAL
GwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwlMQ0AppJu
f7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn00DbOyZY
sih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMgMIICiaADAgEC
AgQ13vTPMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0
MTUxWhcNMTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsG
A1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKK
lQRkrPFrU18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkw
rFEeO68r1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOg
YaRfMF0xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNl
Y3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAx
ODA4MjIxNjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAdBgNVHQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0H
QQAEDTALGwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwl
MQ0AppJuf7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn
00DbOyZYsih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMmMIIC
j6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIxNjM2NTRaMIGFMQsw
CQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEXMBUGA1UEAxMOSmFt
ZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkqhkiG9w0BCQEWEmph
c25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwKpbDG3zMatEuuOT
FYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSyd+7nwqAvbBfPj+0S
vcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7tBJlLrwDRCMoNlPuQ
Kg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQW
BBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOgFAwSamFzbmVs
bEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pAMCcGA1UdJQQgMB4G
CCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAZMKevB7dFfb9
23OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY8BjwVHxiYgG4xkxf
B1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOIzj3lz3xd+uOzqRFg
/Wsg/VMwggMmMIICj6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAy
BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNV
BAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIx
NjM2NTRaMIGFMQswCQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEX
MBUGA1UEAxMOSmFtZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkq
hkiG9w0BCQEWEmphc25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
wKpbDG3zMatEuuOTFYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSy
d+7nwqAvbBfPj+0SvcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7t
BJlLrwDRCMoNlPuQKg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQD
AgXgMB0GA1UdDgQWBBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcU
AgOgFAwSamFzbmVsbEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA
MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQAD
gYEAZMKevB7dFfb923OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY
8BjwVHxiYgG4xkxfB1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOI
zj3lz3xd+uOzqRFg/Wsg/VMxggG7MIIBtwIBATBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJ
bnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0g
Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwF+kzAJBgUrDgMCGgUAoIGiMBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDcxMjAzNTMyMlowIwYJKoZIhvcNAQkEMRYE
FGoJ6/vdQLuJX1Rq6t/pA64jz6UeMEMGCSqGSIb3DQEJDzE2MDQwBwYFKw4DAh0wDgYIKoZIhvcN
AwICAgCAMAoGCCqGSIb3DQMHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAdXm7yXXW
Lja+vsx12l/Qy1AmOD0dC3gZlLHPILOYreGgCfVcOxexbixnIN8eFB4gLHyGZY/kcvnd0yKjqgIw
ksMPVXFK15No3pX6PNVLcxG8JzkfS+/5l9zMK5Xyt32s2clIu0fBlc/YL7j3dzc/iflR3lMBmYQy
PgBBh+HiK8IAAAAA

---------z32150_boundary_sign--



From owner-atom-syntax@mail.imc.org  Mon Jul 12 00: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 AAA28832
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 00: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 i6C3ur0b067714;
	Sun, 11 Jul 2004 20:56: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 i6C3urbf067712;
	Sun, 11 Jul 2004 20:56:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6C3uqg4067641;
	Sun, 11 Jul 2004 20:56:52 -0700 (PDT)
	(envelope-from jasnell@us.ibm.com)
Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32])
	by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i6C3urko791984;
	Sun, 11 Jul 2004 23:56:53 -0400
Received: from d03nm122.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170])
	by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6C3urVk206426;
	Sun, 11 Jul 2004 21:56:53 -0600
In-Reply-To: <D7251B7F-D39C-11D8-9A61-000A95BD86C0@mnot.net>
To: Mark Nottingham <mnot@mnot.net>
Cc: Atom Syntax <atom-syntax@imc.org>, Norman Walsh <ndw@nwalsh.com>,
        owner-atom-syntax@mail.imc.org
MIME-Version: 1.0
Subject: Re: Created proposal: PaceProvideSchema
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
From: James M Snell <jasnell@us.ibm.com>
X-MIMETrack: S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/11/2004 08:55:48 PM,
	Serialize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/11/2004 08:55:48 PM,
	Serialize complete at 07/11/2004 08:55:48 PM,
	Itemize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/11/2004 08:55:48 PM,
	S/MIME Sign complete at 07/11/2004 08:55:48 PM,
	S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/11/2004 08:56:50 PM,
	S/MIME Sign complete at 07/11/2004 08:56:50 PM,
	Serialize by Router on D03NM122/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at
 07/11/2004 21:56:53,
	Serialize complete at 07/11/2004 21:56:53
Message-ID: <OF082EA495.E5B00BA7-ON88256ECF.00156336-88256ECF.0015AEC0@us.ibm.com>
Date: Sun, 11 Jul 2004 21:56:50 -0600
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z39330_boundary_sign
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>


This is an S/MIME signed message.

---------z39330_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 0015969188256ECF_="

This is a multipart message in MIME format.
--=_alternative 0015969188256ECF_=
Content-Type: text/plain; charset="US-ASCII"

-1 on this.  Those of us who care about XML Schema should provide an XML 
Schema... not for normative purposes, however.  Those who care about Relax 
should provide a Relax thing.  Let's not rule such things out simply 
because of our personal feelings about various technologies or the 
companies who promote them.  There are sound technical reasons why some 
folks may want an XSD.  I am not saying it should be codified as part of 
the Atom specification, but something could and should be made available.

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



Mark Nottingham <mnot@mnot.net> 
Sent by: owner-atom-syntax@mail.imc.org
07/11/2004 05:45 PM

To
Norman Walsh <ndw@nwalsh.com>
cc
Atom Syntax <atom-syntax@imc.org>
Subject
Re: Created proposal: PaceProvideSchema








On Jul 11, 2004, at 9:09 AM, Norman Walsh wrote:
> Uhm. So don't use XSD?

Big +1


Mark Nottingham     http://www.mnot.net/



--=_alternative 0015969188256ECF_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">-1 on this. &nbsp;Those of us who care
about XML Schema should provide an XML Schema... not for normative purposes,
however. &nbsp;Those who care about Relax should provide a Relax thing.
&nbsp;Let's not rule such things out simply because of our personal feelings
about various technologies or the companies who promote them. &nbsp;There
are sound technical reasons why some folks may want an XSD. &nbsp;I am
not saying it should be codified as part of the Atom specification, but
something could and should be made available.</font>
<br>
<br><font size=2 face="sans-serif">- James M Snell<br>
 &nbsp;jasnell@us.ibm.com<br>
 &nbsp;http://www.ibm.com<br>
 &nbsp;(877) 511-5082 / Office<br>
 &nbsp;930-1979 / Tie Line</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Mark Nottingham &lt;mnot@mnot.net&gt;</b>
</font>
<br><font size=1 face="sans-serif">Sent by: owner-atom-syntax@mail.imc.org</font>
<p><font size=1 face="sans-serif">07/11/2004 05:45 PM</font>
<td width=59%>
<table width=100%>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td valign=top><font size=1 face="sans-serif">Norman Walsh &lt;ndw@nwalsh.com&gt;</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td valign=top><font size=1 face="sans-serif">Atom Syntax &lt;atom-syntax@imc.org&gt;</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td valign=top><font size=1 face="sans-serif">Re: Created proposal: PaceProvideSchema</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2><tt><br>
<br>
On Jul 11, 2004, at 9:09 AM, Norman Walsh wrote:<br>
&gt; Uhm. So don't use XSD?<br>
<br>
Big +1<br>
<br>
<br>
Mark Nottingham &nbsp; &nbsp; http://www.mnot.net/<br>
<br>
</tt></font>
<br>
--=_alternative 0015969188256ECF_=--

---------z39330_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIIUOAIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIISWDCCAtow
ggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1
aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAy
MDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA629xc49NpAPz
cAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7glzJKgPkPzlTZZfznznGbmAWVnNBQ
lyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnwNclOnnP2sKufuPzbTImQTTi5c8JZNZcM
J0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEEBAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1Ud
DgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAPBgNVHRMBAf8EBTADAQH/MDEGA1UdJQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUH
AwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvu
jQupk2oCScMd3FIHLE7hOfu8YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14ke
McF9ViNdewEoBGiAycUq8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIC2jCCAkOgAwIB
AgIDAxS2MA0GCSqGSIb3DQEBBAUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwMTE0MjIw
NzExWhcNMTExMjMxMjIwNzExWjBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25h
bCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrb3Fzj02kA/NwCy5KFMiY
tFgyTJ6kMSQLVSs9uwVHIAVkqy/enDQwZ9b/7uCXMkqA+Q/OVNll/OfOcZuYBZWc0FCXI9qw60KO
J/rTd65FdF4dwp8cw8si0qjOJtYg8cm46fA1yU6ec/awq5+4/NtMiZBNOLlzwlk1lwwnRgXNNwID
AQABo4GqMIGnMBEGCWCGSAGG+EIBAQQEAwIAhzAOBgNVHQ8BAf8EBAMCAcYwHQYDVR0OBBYEFK5U
DpLqqDOpKyQtx8hvMNze80pAMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMA8GA1Ud
EwEB/wQFMAMBAf8wMQYDVR0lBCowKAYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYB
BQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAMnJ7c2YLyrY/PKlFl+7sm8NENfWtFxqdm+6NC6mTagJJ
wx3cUgcsTuE5+7xh9+/G0tTfLzA1qZAQ5GNMPXvmoB9+vJfKnC2JWMFQpIOUEJDXiR4xwX1WI117
ASgEaIDJxSrxHcuuV/hMIO9bgZ6C41MUVmdLTKBgBOImTuIPK8QwggMgMIICiaADAgECAgQ13vTP
MA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQL
EyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0MTUxWhcN
MTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMk
RXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKKlQRkrPFr
U18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkwrFEeO68r
1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOgYaRfMF0x
CzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBD
ZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAxODA4MjIx
NjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAdBgNV
HQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0HQQAEDTAL
GwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwlMQ0AppJu
f7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn00DbOyZY
sih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMgMIICiaADAgEC
AgQ13vTPMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0
MTUxWhcNMTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsG
A1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKK
lQRkrPFrU18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkw
rFEeO68r1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOg
YaRfMF0xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNl
Y3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAx
ODA4MjIxNjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAdBgNVHQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0H
QQAEDTALGwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwl
MQ0AppJuf7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn
00DbOyZYsih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMmMIIC
j6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIxNjM2NTRaMIGFMQsw
CQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEXMBUGA1UEAxMOSmFt
ZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkqhkiG9w0BCQEWEmph
c25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwKpbDG3zMatEuuOT
FYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSyd+7nwqAvbBfPj+0S
vcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7tBJlLrwDRCMoNlPuQ
Kg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQW
BBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOgFAwSamFzbmVs
bEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pAMCcGA1UdJQQgMB4G
CCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAZMKevB7dFfb9
23OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY8BjwVHxiYgG4xkxf
B1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOIzj3lz3xd+uOzqRFg
/Wsg/VMwggMmMIICj6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAy
BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNV
BAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIx
NjM2NTRaMIGFMQswCQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEX
MBUGA1UEAxMOSmFtZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkq
hkiG9w0BCQEWEmphc25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
wKpbDG3zMatEuuOTFYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSy
d+7nwqAvbBfPj+0SvcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7t
BJlLrwDRCMoNlPuQKg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQD
AgXgMB0GA1UdDgQWBBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcU
AgOgFAwSamFzbmVsbEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA
MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQAD
gYEAZMKevB7dFfb923OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY
8BjwVHxiYgG4xkxfB1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOI
zj3lz3xd+uOzqRFg/Wsg/VMxggG7MIIBtwIBATBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJ
bnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0g
Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwF+kzAJBgUrDgMCGgUAoIGiMBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDcxMjAzNTU0OFowIwYJKoZIhvcNAQkEMRYE
FCYIsDD4Mf+B9YchKPP3ksI3PAqNMEMGCSqGSIb3DQEJDzE2MDQwBwYFKw4DAh0wDgYIKoZIhvcN
AwICAgCAMAoGCCqGSIb3DQMHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAdMp+klxU
NueOD+F7j/e0gq/4Uk2FuZAIUDhcJ0sIWqUjQ3dzqxE+Amg2IdCzPV4bj1nDDDOWMwRUJncxASV/
4N8pMzWepHPTUn12vDoFO6oN2YzhtCiZmNp042KD5hRkimjgaJnmy40PuL3/7UydZMbvzrhkGEHq
gLbCkdTvIdMAAAAA

---------z39330_boundary_sign--



From owner-atom-syntax@mail.imc.org  Mon Jul 12 00:21: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 AAA29213
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 00:21: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 i6C49Wqm068786;
	Sun, 11 Jul 2004 21:09:32 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6C49WqK068785;
	Sun, 11 Jul 2004 21:09:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web41502.mail.yahoo.com (web41502.mail.yahoo.com [66.218.93.85])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6C49VR7068768
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 21:09:31 -0700 (PDT)
	(envelope-from randymorin@yahoo.com)
Message-ID: <20040712040933.33059.qmail@web41502.mail.yahoo.com>
Received: from [24.43.182.164] by web41502.mail.yahoo.com via HTTP; Sun, 11 Jul 2004 21:09:33 PDT
Date: Sun, 11 Jul 2004 21:09:33 -0700 (PDT)
From: Randy Charles Morin <randymorin@yahoo.com>
Reply-To: randy@kbcafe.com
Subject: Re: Created proposal: PaceProvideSchema
To: James M Snell <jasnell@us.ibm.com>, Mark Nottingham <mnot@mnot.net>
Cc: Atomlist <atom-syntax@imc.org>, owner-atom-syntax@mail.imc.org,
        randy@kbcafe.com
In-Reply-To: <OFA17BD725.9FB45E49-ON88256ECF.00154080-88256ECF.0015AE5D@us.ibm.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1800845876-1089605373=:31946"
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>


--0-1800845876-1089605373=:31946
Content-Type: text/plain; charset=us-ascii

Don't worry James, I will always make my XML Schema available to those that case. Regardless of whether Atom has an official XSD, I will always have an unofficial one.
http://www.kbcafe.com/rss/?guid=20040710135750
 
I use to write Java for Solaris. I use to write Java for Weblogic. I guess I've been told that they are not going to support standards enough times. Now I write for .NET and Apache Axis. They actually support XSD better. 
Thanks IBM and M$FT,
 
Randy
http://www.kbcafe.com

James M Snell <jasnell@us.ibm.com> wrote:

IMHO, like WSDL and SOAP, Atom should also provide an *informational* XML Schema.  It may be something put together "unofficially" by those of us who care about such things, but something should be made available. 

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


Mark Nottingham <mnot@mnot.net> 
Sent by: owner-atom-syntax@mail.imc.org 
07/11/2004 08:12 PM 
To
randy@kbcafe.com cc
Atomlist <atom-syntax@imc.org> Subject
Re: Created proposal: PaceProvideSchema






On Jul 11, 2004, at 6:37 PM, Randy Charles Morin wrote:

> So, we shouldn't use the schema language that is most supported by 
> vendors.
> Don't use the schema language language which Microsoft and 
> Apache/IBM have created countless tools from. Let's start from 
> scratch. Clean slate.

Sounds sensible to me. Seriously. Just because MSFT and IBM have thrown 
resources at it doesn't mean that it'll magically work, thanks to their 
pixie dust; both have made mistakes, of which there are numerous 
examples. I'm not just picking on them, of course, but they were the 
only vendors you mention.

Consider this - WSDL isn't specified in terms of XML Schema; it defines 
a "component model." Neither does SOAP; that's right, the Schema isn't 
normative, just informational.

--
Mark Nottingham     http://www.mnot.net/





> ATTACHMENT part 2 application/x-pkcs7-signature name=smime.p7s

		
---------------------------------
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
--0-1800845876-1089605373=:31946
Content-Type: text/html; charset=us-ascii

<DIV>Don't worry James, I will always make my XML Schema available to those that case. Regardless of whether Atom has an official XSD, I will always have an unofficial one.</DIV>
<DIV><A href="http://www.kbcafe.com/rss/?guid=20040710135750">http://www.kbcafe.com/rss/?guid=20040710135750</A></DIV>
<DIV>&nbsp;</DIV>
<DIV>I use to write Java for Solaris. I use to write Java for Weblogic. I guess I've been told that they are not going to support standards enough times. Now I write for .NET and Apache Axis. They actually support XSD better. </DIV>
<DIV>Thanks IBM and M$FT,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Randy</DIV>
<DIV><A href="http://www.kbcafe.com">http://www.kbcafe.com</A></DIV>
<DIV><BR><B><I>James M Snell &lt;jasnell@us.ibm.com&gt;</I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid"><BR><FONT face=sans-serif size=2>IMHO, like WSDL and SOAP, Atom should also provide an *informational* XML Schema. &nbsp;It may be something put together "unofficially" by those of us who care about such things, but something should be made available.</FONT> <BR><BR><FONT face=sans-serif size=2>- James M Snell<BR>&nbsp;jasnell@us.ibm.com<BR>&nbsp;http://www.ibm.com<BR>&nbsp;(877) 511-5082 / Office<BR>&nbsp;930-1979 / Tie Line</FONT> <BR><BR><BR>
<TABLE width="100%">
<TBODY>
<TR vAlign=top>
<TD width="40%"><FONT face=sans-serif size=1><B>Mark Nottingham &lt;mnot@mnot.net&gt;</B> </FONT><BR><FONT face=sans-serif size=1>Sent by: owner-atom-syntax@mail.imc.org</FONT> 
<P><FONT face=sans-serif size=1>07/11/2004 08:12 PM</FONT> </P>
<TD width="59%">
<TABLE width="100%">
<TBODY>
<TR>
<TD>
<DIV align=right><FONT face=sans-serif size=1>To</FONT></DIV>
<TD vAlign=top><FONT face=sans-serif size=1>randy@kbcafe.com</FONT> 
<TR>
<TD>
<DIV align=right><FONT face=sans-serif size=1>cc</FONT></DIV>
<TD vAlign=top><FONT face=sans-serif size=1>Atomlist &lt;atom-syntax@imc.org&gt;</FONT> 
<TR>
<TD>
<DIV align=right><FONT face=sans-serif size=1>Subject</FONT></DIV>
<TD vAlign=top><FONT face=sans-serif size=1>Re: Created proposal: PaceProvideSchema</FONT></TR></TBODY></TABLE><BR>
<TABLE>
<TBODY>
<TR vAlign=top>
<TD>
<TD></TR></TBODY></TABLE><BR></TR></TBODY></TABLE><BR><BR><BR><FONT size=2><TT><BR><BR>On Jul 11, 2004, at 6:37 PM, Randy Charles Morin wrote:<BR><BR>&gt; So, we shouldn't use the schema language that is most supported by <BR>&gt; vendors.<BR>&gt; Don't use the schema language language which Microsoft and <BR>&gt; Apache/IBM&nbsp;have created countless tools from. Let's start from <BR>&gt; scratch. Clean slate.<BR><BR>Sounds sensible to me. Seriously. Just because MSFT and IBM have thrown <BR>resources at it doesn't mean that it'll magically work, thanks to their <BR>pixie dust; both have made mistakes, of which there are numerous <BR>examples. I'm not just picking on them, of course, but they were the <BR>only vendors you mention.<BR><BR>Consider this - WSDL isn't specified in terms of XML Schema; it defines <BR>a "component model." Neither does SOAP; that's right, the Schema isn't <BR>normative, just informational.<BR><BR>--<BR>Mark Nottingham &nbsp; &nbsp;
 http://www.mnot.net/<BR><BR><BR></TT></FONT><BR><BR><BR>&gt; ATTACHMENT part 2 application/x-pkcs7-signature name=smime.p7s<BR></BLOCKQUOTE><p>
		<hr size=1>Do you Yahoo!?<br>
Yahoo! Mail is new and improved - <a href="http://us.rd.yahoo.com/mail_us/taglines/new/*http://promotions.yahoo.com/new_mail">Check it out!</a>
--0-1800845876-1089605373=:31946--



From owner-atom-syntax@mail.imc.org  Mon Jul 12 00:27: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 AAA29458
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 00:27: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 i6C4HZqv069494;
	Sun, 11 Jul 2004 21:17:35 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6C4HZ4p069493;
	Sun, 11 Jul 2004 21:17:35 -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 i6C4HYav069479
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 21:17:34 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.19] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id 08E7C7288; Sun, 11 Jul 2004 21:17:42 -0700 (PDT)
In-Reply-To: <OF082EA495.E5B00BA7-ON88256ECF.00156336-88256ECF.0015AEC0@us.ibm.com>
References: <OF082EA495.E5B00BA7-ON88256ECF.00156336-88256ECF.0015AEC0@us.ibm.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <69D21DD5-D3BA-11D8-9A61-000A95BD86C0@mnot.net>
Cc: Atom Syntax <atom-syntax@imc.org>, owner-atom-syntax@mail.imc.org,
        Norman Walsh <ndw@nwalsh.com>
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: Created proposal: PaceProvideSchema
Date: Sun, 11 Jul 2004 21:17:40 -0700
To: James M Snell <jasnell@us.ibm.com>
X-Mailer: Apple Mail (2.618)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6C4HZav069482
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


To be clear -

I have no problem with providing an XML Schema; it is a genuinely 
useful thing to provide for some people. In fact, I'd be disappointed 
if we didn't provide one.

However, it shouldn't be normative, for reasons described before, and 
the design of Atom shouldn't be subjugated by the needs of Schema; if 
there's contention between real-world requirements and the contortions 
that Schema makes you go through, Schema should lose (i.e., the schema 
should be less expressive).

That's what I meant by +1'ing "not using XML Schema" -- apologies if 
that wasn't clear.

Cheers,


On Jul 11, 2004, at 8:56 PM, James M Snell wrote:

> -1 on this.  Those of us who care about XML Schema should provide an 
> XML Schema... not for normative purposes, however.  Those who care 
> about Relax should provide a Relax thing.  Let's not rule such things 
> out simply because of our personal feelings about various technologies 
> or the companies who promote them.  There are sound technical reasons 
> why some folks may want an XSD.  I am not saying it should be codified 
> as part of the Atom specification, but something could and should be 
> made available.



--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org  Mon Jul 12 00:36: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 AAA29781
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 00: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 i6C4MvV0070015;
	Sun, 11 Jul 2004 21:22: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 i6C4MvV5070014;
	Sun, 11 Jul 2004 21:22: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 i6C4MuDr070003
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 21:22: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 D7DF37C117; Mon, 12 Jul 2004 07:21:20 +0200 (CEST)
Date: Mon, 12 Jul 2004 06:26:37 +0200
To: "Eric Scheid" <eric.scheid@ironclad.net.au>
Subject: Re: Q: modfied vs issued vs created
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <BD17A473.1EDB8%eric.scheid@ironclad.net.au>
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: <opsa0bynaauvpchu@quark>
In-Reply-To: <BD17A473.1EDB8%eric.scheid@ironclad.net.au>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Mon, 12 Jul 2004 02:14:11 +1000, Eric Scheid  
<eric.scheid@ironclad.net.au> wrote:

> (2) "I know that's how it seems like for the audience". Isn't that what  
> we should be modelling for? The technical arcana inside the guts of the
> publishers' system is of zero interest to most users, surely?

I don't know what other people's agenda is, but my goal is to influence  
Atom to be usable in some EU projects I, through my company, am involved  
in, as well as for the needs my company and myself have in regard to  
syndication of news. I'm also a notorious non-pragmatist and a Draconian  
bastard, and try to aim as high as possible and rather end on the second  
top shelf, instead of aiming at the middle and ending at the second  
lowest. :-)

PaceSupersede[1] has been created to accommodate some of my and other's  
needs in this regard.

> They would be annoyed because they would see a "new" entry (because it  
> has a new ID)

The new entry would supersede the old one, and thus leaving it up to the  
client what to do with this information. Also, I wouldn't be annoyed to  
get an update when the weather forecast changed from saying «at 18:00,  
there will be sun and great weather» to «at 18:00, there will be a deadly  
storm annihilating everything in its path».

> I'm hanging out for a future version that differentiates modifications
> of old entries from completely new entries.

Wouldn't it be better to differentiate between minor and major updates?  
You mostly don't care about typographical erratas, but if the entry has  
been completely rewritten, has become six sections longer and so on, you'd  
probably want to be notified.

Atom currently doesn't support «minor» and «major» changes; everything is  
just «changes» and all changes will (or at least should) update the  
'atom:modified' date.

____
[1] <url: http://intertwingly.net/wiki/pie/PaceSupersede>

-- 
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 Jul 12 01:08: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 BAA01544
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 01:08: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 i6C4kQQj073497;
	Sun, 11 Jul 2004 21:46: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 i6C4kQ9d073496;
	Sun, 11 Jul 2004 21:46: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.84])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6C4kQjh073489
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 21:46:26 -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 i6C4kX97004318;
	Sun, 11 Jul 2004 21:46:33 -0700 (PDT)
Received: from [192.168.1.100] (h00080d858303.ne.client2.attbi.com [24.61.1.243])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id i6C4kWC5013953;
	Sun, 11 Jul 2004 21:46:33 -0700 (PDT)
In-Reply-To: <opsa0bynaauvpchu@quark>
References: <BD17A473.1EDB8%eric.scheid@ironclad.net.au> <opsa0bynaauvpchu@quark>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4--368757970; protocol="application/pkcs7-signature"
Message-Id: <71F7A31B-D3BE-11D8-82B1-000A95DC3D90@mac.com>
Cc: Atom-Syntax Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: Q: modfied vs issued vs created
Date: Mon, 12 Jul 2004 00:46:31 -0400
To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
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-4--368757970
Content-Type: text/plain;
	charset=ISO-8859-1;
	format=flowed
Content-Transfer-Encoding: quoted-printable

On 12 Jul 2004, at 12:26 am, Asbj=F8rn Ulsberg wrote:

> PaceSupersede[1] has been created to accommodate some of my and=20
> other's needs in this regard.

I agree with the idea of the Pace, but completely disagree with=20
changing the atom:id of the entry. What is the point of the id if not=20
to link different versions of the same entry? There's a 1:1=20
relationship here. A major change should result in a new atom:issued=20
under PaceEntryDates.

Secondly, the atom:supercedes element itself appears to point to only=20
the previous version. What if two major changes happen between polls?=20
The aggregator can't follow the thread. The solution here is to... have=20=

a single id that appears in all versions of the entry.

-1

Graham=

--Apple-Mail-4--368757970
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
9w0BCQUxDxcNMDQwNzEyMDQ0NjMyWjAjBgkqhkiG9w0BCQQxFgQUHRZ4BK4lhRnmUj+GspuJ8g2t
rTQweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEA1FjGguTj0Iy7sNRBz7s98zqd
0cCd+JI/FKkT65enpfEFThyxGuU9IgXHGx4bdi6W+jjBZbUzJxiiZ+MOKqK1Jz8CJIbZmthTqApm
FmMpmBnnEujvy05qpkoaEht61B3Kub+YclqtIuu1DlRZa+caBIB1dEhuujId6XjPssgk7kDl2mxP
ezD2tM9V1JdeoxOjYFMoKZf3ueXT6AXUFKT+GZ86VrSht6OUdDtEkA2tSAbtzyQnu4ug+3VTgPRF
CpNW1PzepEL2meASU+xrgGnoPC8ilSfnLWshXXN1q7ilnBer3XIYA/+UWCDfo1rcPTNQIkpZ6Fk2
5HlSB+Vqvo5gPgAAAAAAAA==

--Apple-Mail-4--368757970--



From owner-atom-syntax@mail.imc.org  Mon Jul 12 01:17: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 BAA01835
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 01:17: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 i6C4xvug075432;
	Sun, 11 Jul 2004 21:59: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 i6C4xvi3075431;
	Sun, 11 Jul 2004 21:59: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 i6C4xplq075404
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 21:59: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 DDBD67C117; Mon, 12 Jul 2004 07:58:15 +0200 (CEST)
To: Graham <dtcd@mac.com>
Cc: "Atom-Syntax Syntax" <atom-syntax@imc.org>
Subject: Re: Q: modfied vs issued vs created
References: <BD17A473.1EDB8%eric.scheid@ironclad.net.au> <opsa0bynaauvpchu@quark> <71F7A31B-D3BE-11D8-82B1-000A95DC3D90@mac.com>
Message-ID: <opsa0doeb0uvpchu@quark>
Date: Mon, 12 Jul 2004 07:03:40 +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: <71F7A31B-D3BE-11D8-82B1-000A95DC3D90@mac.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Mon, 12 Jul 2004 00:46:31 -0400, Graham <dtcd@mac.com> wrote:

> I agree with the idea of the Pace, but completely disagree with
> changing the atom:id of the entry.

You're not changing the ID of the entry. You're issuing a _new_ entry,  
with of course, a new ID.

> What is the point of the id if not to link different versions of
> the same entry?

Being able to identify an entry by its ID is totally orthogonal to being  
able to see different versions of the entry at the exact same ID. With  
PaceSupersede, entries will be related through the atom:supersedes  
element, and a superseding entry could be abstractly considered to be the  
same entry, in some sense.

> A major change should result in a new atom:issued under PaceEntryDates.

Oh god, no!

> Secondly, the atom:supercedes element itself appears to point to only
> the previous version. What if two major changes happen between polls?

Good question which I should look into.

-- 
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 Jul 12 01:21: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 BAA01964
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 01:21:19 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6C53HpP075725;
	Sun, 11 Jul 2004 22:03: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 i6C53HQJ075723;
	Sun, 11 Jul 2004 22:03:17 -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 i6C52r4u075675
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 22:03:16 -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 00EC04EFC3;
	Mon, 12 Jul 2004 01:02:58 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040712135322.03c31618@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Mon, 12 Jul 2004 14:02:48 +0900
To: Dan Brickley <danbri@w3.org>, Walter Underwood <wunder@verity.com>
From: Martin Duerst <duerst@w3.org>
Subject: Re: MUST be UTC?
Cc: Atom-syntax <atom-syntax@imc.org>
In-Reply-To: <20040712005723.GA12483@homer.w3.org>
References: <A6E856285FC050BE6B85AA07@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
 <40F152CA.5000000@intertwingly.net>
 <opsaza3fttuvpchu@quark>
 <40F15DC2.3060307@intertwingly.net>
 <opsazc38qcuvpchu@quark>
 <40F16B51.3000602@intertwingly.net>
 <opsazl8i1e6dxgxk@mail.online.no>
 <m3iscupcxh.fsf@bitsko.slc.ut.us>
 <03e201c4678a$4af6c2d0$200ca8c0@wkearney.com>
 <m3eknip6xh.fsf@bitsko.slc.ut.us>
 <A6E856285FC050BE6B85AA07@adsl-64-166-133-244.dsl.snfc21.pacbell.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: <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 20:57 04/07/11 -0400, Dan Brickley wrote:

>* Walter Underwood <wunder@verity.com> [2004-07-11 15:00-0700]

> > But archives have a much, much more difficult problem than Atom
> > is addressing. Dates may be uncertain, with a wide range, months,
> > decades, or even centuries. They need to deal with local calendars,
> > like the French Revolutionary calendar.
>
>It isn't clear to me that Atom/RSS/etc should avoid this issue. There
>are 1000s of Iranian blogs whose dates are published and consumed in
>terms of the Persian calendar. I'd hope at least for non-gregorian dates
>to be expressible using extensions in another namespace; when Atom's
>namespace extension policy is nailed down, perhaps we might revisit this
>topic?

I doubt that's actually necessary. What should be possible is for
end users preferring non-gregorian calendars to input their dates in
their calendar of preference, and to see all the dates in a calendar
format of their preference.

Data interchange is much better limited to a very limited
ISO 8601-based W3C/XSD/IETF/... format. What we might think
about are extensions to define ranges rather than timestamps,...


Regards,    Martin.



From owner-atom-syntax@mail.imc.org  Mon Jul 12 01:21: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 BAA01983
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 01:21: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 i6C58bx4076319;
	Sun, 11 Jul 2004 22:08: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 i6C58bRt076318;
	Sun, 11 Jul 2004 22:08: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.85])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6C58bJW076312
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 22:08:37 -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 i6C58i3n000383;
	Sun, 11 Jul 2004 22:08:44 -0700 (PDT)
Received: from [192.168.1.100] (h00080d858303.ne.client2.attbi.com [24.61.1.243])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id i6C58h0t004516;
	Sun, 11 Jul 2004 22:08:44 -0700 (PDT)
In-Reply-To: <opsa0doeb0uvpchu@quark>
References: <BD17A473.1EDB8%eric.scheid@ironclad.net.au> <opsa0bynaauvpchu@quark> <71F7A31B-D3BE-11D8-82B1-000A95DC3D90@mac.com> <opsa0doeb0uvpchu@quark>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-6--367446498; protocol="application/pkcs7-signature"
Message-Id: <7FAA6B42-D3C1-11D8-82B1-000A95DC3D90@mac.com>
Cc: Atom-Syntax Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: Q: modfied vs issued vs created
Date: Mon, 12 Jul 2004 01:08:22 -0400
To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
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-6--367446498
Content-Type: text/plain;
	charset=ISO-8859-1;
	format=flowed
Content-Transfer-Encoding: quoted-printable

On 12 Jul 2004, at 1:03 am, Asbj=F8rn Ulsberg wrote:

> Being able to identify an entry by its ID is totally orthogonal to=20
> being able to see different versions of the entry at the exact same=20
> ID. With PaceSupersede, entries will be related through the=20
> atom:supersedes element, and a superseding entry could be abstractly=20=

> considered to be the same entry, in some sense.

What does supercedes offer that linking all major and minor versions by=20=

the same atom:id doesn't? Wouldn't a more direct approach to versioning=20=

be better - version ids or version numbers?

Graham=

--Apple-Mail-6--367446498
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
9w0BCQUxDxcNMDQwNzEyMDUwODIzWjAjBgkqhkiG9w0BCQQxFgQUdE95obpJKSnDiHoQkM7vM2RF
+YQweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAlmqZAEnupfqX4RJfH+AVnTjc
YlBJN7y/M1RoKfV+Y0bT+Ohsy5bWARU/RnUe5UFoCW+TSkDGhNshhSPiW9Oalfu+7owpDcL3aWGz
z1AFY9UKoNEfeCnq3oXo36i8ZdnQvCdDQfoWzzRKIIuSJqij/6dHxTh0o4L9gk0pkPGX8niOwWXt
M79bCXQ0/APjUyXF5an8R6vF96pcCbtFpaF63FhDQwYEMkRzoD8hNN4u/JTxYYw783Z89Ci2n/AJ
HsLTPI26/pDaCDu+Bgejbjesc/RY4GfqDHMMSD0Ieu4rheV9j3QQNFkjabbhvswmL8/s29wnwfE+
AtTjAUeLJnvUOQAAAAAAAA==

--Apple-Mail-6--367446498--



From owner-atom-syntax@mail.imc.org  Mon Jul 12 01:26: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 BAA02293
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 01:26: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 i6C53HCX075724;
	Sun, 11 Jul 2004 22:03: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 i6C53H7C075722;
	Sun, 11 Jul 2004 22:03:17 -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 i6C52opP075663
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 22:03:16 -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 A1DE74F158;
	Mon, 12 Jul 2004 01:02:55 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040712132500.03c5d398@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Mon, 12 Jul 2004 13:49:19 +0900
To: Walter Underwood <wunder@verity.com>, atom-syntax@imc.org
From: Martin Duerst <duerst@w3.org>
Subject: Re: HTTP header/content precedence
In-Reply-To: <9CBF6789BA4872152EE9DAD7@adsl-64-166-133-244.dsl.snfc21.pa
 cbell.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: <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 17:14 04/07/11 -0700, Walter Underwood wrote:

>I'm quoting a message, but modifying this to a new issue.
>
>--On Friday, July 9, 2004 10:06 PM -0400 Mark Pilgrim <pilgrim@gmail.com> 
>wrote:
>>
>>Also note that the XML specification does specifically state that
>>xml:lang (if present) overrides the external language identification.
>>This is notable in that it is different in some cases from the
>>precedence rules for character encoding (RFC 3023), of which we are
>>all now painfully aware.
>
>We have hit a few situations where Atom needs to resolve conflicts
>between HTTP headers, content, and even the XML spec. It would be
>nice to resolve all of these the same way, but that might not be
>possible.

Yes, it would be nice. But the situation may be very different in
each case.



>Regardless, we should list them all in the spec. Here is
>what I have so far.
>
>Language: xml:lang overrides HTTP content-language

It's very clear that this has to work that way, because
any xml:lang on any child element can overwrite the
information on an ancestor element. If Content-Language
would then overwrite xml:lang, we would get a real mess.
The core reason for doing it that way is that language
doesn't have to be the same for the whole document.
Also, there are no simple transformations that change
language.

>Media type and character encoding: use application/atom+xml so we
>can let the XML spec rules handle it and bypass HTTP rules (override
>within the rules)

For charset, HTTP overwrites what's in the document because:
- There is only one charset per external entity
- Ideally, the charset is known before looking at the document,
   to be able to start parsing quickly.
- There are scripting solutions and there is transcoding,
   both don't look inside the document.
- It is relatively easy to change the charset of an external
   entity without.

Regards,    Martin.

>Expires/refresh-rate: no decision, need to resolve HTTP caching
>mechanism and historical rate-oriented RSS hints
>
>Did I miss any? In general, it looks like content overrides
>headers, which is opposite to the HTTP transmogrifying gateway
>assumption. HTTP is designed for gateways which can transform
>content on the fly and modify the headers to mark that decision.
>These seem to be quite rare in practice, probably because they
>mess with the end-to-end design principle which underlies much
>of the internet design [1].
>
>wunder
>
>[1] <http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf>
>--
>Walter Underwood
>Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Mon Jul 12 01: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 BAA02478
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 01:30:28 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6C5Ah66076468;
	Sun, 11 Jul 2004 22:10: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 i6C5AhhS076467;
	Sun, 11 Jul 2004 22:10:43 -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 i6C5Agj3076459
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 22:10:42 -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 i6C58e53023990
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 23:08:40 -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 <0I0Q00MSC3PZ5F@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sun, 11 Jul 2004 23:10:47 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0Q00KVN3PYC1@mail.sun.net> for atom-syntax@imc.org; Sun,
 11 Jul 2004 23:10:46 -0600 (MDT)
Date: Sun, 11 Jul 2004 22:10:47 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Version vs. Namespace
In-reply-to: <8725AB57-D39C-11D8-9A61-000A95BD86C0@mnot.net>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <D5C4C862-D3C1-11D8-9DBF-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: <87smbymve3.fsf@nwalsh.com>
 <B40394C3-D356-11D8-9A61-000A95BD86C0@mnot.net> <87llhqjycb.fsf@nwalsh.com>
 <8725AB57-D39C-11D8-9A61-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 Jul 11, 2004, at 5:43 PM, Mark Nottingham wrote:

> In other words, I'm proposing that we refine our approach to 
> versioning to three separate things:

I'm massively unconvinced that this added complexity has noticeable 
benefit.  I want to see a single namespace that means "this is Atom", 
and I don't expect the semantics of atom:title to change for a long 
time so I don't think its name should change, and I do want a 
root-level "version" attribute.  Going down the path of solving the 
versioning problem in the general case reliably leads to convulsions 
and hairy palms.  Let's do the simplest thing that could possibly work: 
a fixed namespace and a root version attribute. -Tim



From owner-atom-syntax@mail.imc.org  Mon Jul 12 01:30: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 BAA02496
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 01:30: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 i6C5HEg8077333;
	Sun, 11 Jul 2004 22: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 i6C5HEUs077332;
	Sun, 11 Jul 2004 22:17: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 i6C5HDGS077324
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 22:17:14 -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 i6C5HLil007750
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 23:17:21 -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 <0I0Q00G6J40WD5@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sun, 11 Jul 2004 23:17:21 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0Q00KX340Q4P@mail.sun.net> for atom-syntax@imc.org; Sun,
 11 Jul 2004 23:17:20 -0600 (MDT)
Date: Sun, 11 Jul 2004 22:17:15 -0700
From: Tim Bray <tbray@textuality.com>
Subject: A note on process
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <BD3257E3-D3C2-11D8-9DBF-000A95A51C9E@textuality.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.618)
Content-type: multipart/signed; micalg=sha1; boundary=Apple-Mail-11--366913769;
 protocol="application/pkcs7-signature"
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-11--366913769
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

The volume here is too high for me to stay on top of all the threads.  
Given that doing this one of the things I'm paid for, I imagine that 
others are feeling similar stress.  Despite all this, I think it's 
perfectly OK for people to discuss atom-related stuff here to their 
heart's content.

However, in my capacity as chair, I am only making a determined effort 
to stay on top of emerging consensus (or its lack) in the issues that 
are currently officially queued for discussion.  That would be the ones 
marked "Recommended to Proceed" in the Public Issues List at 
http://www.intertwingly.net/wiki/pie/AtomPubIssuesList.

So, those who care about some issue and who think they spot a consensus 
position, please make sure it's nicely encapsulated somewhere in a Pace 
or an email whose address you remember, to help refresh your co-chairs' 
memory when those issues are get to the front of the queue.   -Tim
--Apple-Mail-11--366913769
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
hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDcxMjA1MTcxNlowIwYJKoZIhvcNAQkEMRYEFK77
N68qwt4CjQFrghIKf6KPzbrJMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV
BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLirkwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT
AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3
dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDC4q5MA0GCSqGSIb3DQEBAQUABIIBACq2
JjbXurSMFHD6bXN5SAuAuw8JRUrxMb+6HsZhe9CjdgUeHYvC0nJEu+x1MxFgdZZFpolnZWG4XNX8
kP4sTxCrCTrlL+O01gdOYj6kg2vCxgQHpQ0fZgcSd+OTcLGBDucKzB7utFf/NAwIyoOfQ24mWvtb
4swnOYx3hnxrwhx5FFDhWn7LJJziAhkMQgaOiSVXfaxQHaXr0pfK9YCnUsYyOQUpnQsBZqDgC83y
4AflZjvkdW9mcS3Bse2dlHprdzPUgejcddsCAxENGBJ3BgqyT0h5bC2eupP4V3+iHXaQQF7PJueI
KvaIWmch5KguSvM8Rydvjjr5ilyhbdLJpb0AAAAAAAA=

--Apple-Mail-11--366913769--



From owner-atom-syntax@mail.imc.org  Mon Jul 12 02:33: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 CAA18682
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 02: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 i6C6KSPJ084010;
	Sun, 11 Jul 2004 23: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 i6C6KSkH084009;
	Sun, 11 Jul 2004 23:20:28 -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 i6C6KRS1084003
	for <atom-syntax@imc.org>; Sun, 11 Jul 2004 23:20:27 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.19] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id 810AC727D; Sun, 11 Jul 2004 23:20:27 -0700 (PDT)
In-Reply-To: <D5C4C862-D3C1-11D8-9DBF-000A95A51C9E@sun.com>
References: <87smbymve3.fsf@nwalsh.com> <B40394C3-D356-11D8-9A61-000A95BD86C0@mnot.net> <87llhqjycb.fsf@nwalsh.com> <8725AB57-D39C-11D8-9A61-000A95BD86C0@mnot.net> <D5C4C862-D3C1-11D8-9DBF-000A95A51C9E@sun.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <90382C73-D3CB-11D8-9A61-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: Atom Syntax <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: Re: Version vs. Namespace
Date: Sun, 11 Jul 2004 23:20:25 -0700
To: Tim Bray <Tim.Bray@Sun.COM>
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>
Content-Transfer-Encoding: 7bit


>> In other words, I'm proposing that we refine our approach to 
>> versioning to three separate things:
>
> I'm massively unconvinced that this added complexity has noticeable 
> benefit.  I want to see a single namespace that means "this is Atom", 
> and I don't expect the semantics of atom:title to change for a long 
> time so I don't think its name should change, and I do want a 
> root-level "version" attribute.  Going down the path of solving the 
> versioning problem in the general case reliably leads to convulsions 
> and hairy palms.  Let's do the simplest thing that could possibly 
> work: a fixed namespace and a root version attribute. -Tim

Tim, you've completely failed to convince me that this is the right 
thing to do; you've effectively said "trust me, this'll work," 
justified the particular approach by saying "because I want it," and 
forstalled others by saying "you don't want to do that, it's hard."

Why do we need both a fixed namespace and a root version attribute?

When should the version attribute be changed?

How should the three scenarios I highlight be handled?

What, if any, is the interaction between versioning and profiling?

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Mon Jul 12 04: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 EAA22563
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 04: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 i6C7skN5092622;
	Mon, 12 Jul 2004 00:55: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 i6C7skZ4092621;
	Mon, 12 Jul 2004 00:54: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 i6C7sUrv092569
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 00:54:46 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Mon, 12 Jul 2004 17:59:01 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Mon, 12 Jul 2004 17:49:50 +1000
Subject: Re: Q: modfied vs issued vs created
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD187FBE.1F041%eric.scheid@ironclad.net.au>
In-Reply-To: <opsa0bynaauvpchu@quark>
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 i6C7skrv092616
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 12/7/04 2:26 PM, "Asbjørn Ulsberg" <asbjorn@tigerstaden.no> wrote:

>> I'm hanging out for a future version that differentiates modifications
>> of old entries from completely new entries.
> 
> Wouldn't it be better to differentiate between minor and major updates?

> Atom currently doesn't support «minor» and «major» changes; everything is
> just «changes» and all changes will (or at least should) update the
> 'atom:modified' date.

Atom does support minor/major changes: if the modified date changes, but the
issued date doesn't, then it's a minor change. If the modified date changes,
and the issued date does too, then it's a major change. If the modified date
doesn't change, but the issued date does, then you can consider it
assertively no changes (but no longer old news).

(the fourth combination where neither changes means it's old news, caveat
emptor)

e.




From owner-atom-syntax@mail.imc.org  Mon Jul 12 04:44: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 EAA23439
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 04:44: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 i6C8PDad095042;
	Mon, 12 Jul 2004 01:25: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 i6C8PDR0095041;
	Mon, 12 Jul 2004 01:25:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from homer.w3.org (homer.w3.org [18.29.0.30])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6C8PDHl095034
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 01:25:13 -0700 (PDT)
	(envelope-from danbri@w3.org)
Received: by homer.w3.org (Postfix, from userid 13522)
	id BA28A4F5A3; Mon, 12 Jul 2004 04:25:13 -0400 (EDT)
Date: Mon, 12 Jul 2004 04:25:13 -0400
From: Dan Brickley <danbri@w3.org>
To: Tim Bray <Tim.Bray@Sun.COM>
Cc: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Version vs. Namespace
Message-ID: <20040712082513.GA15423@homer.w3.org>
References: <87smbymve3.fsf@nwalsh.com> <B40394C3-D356-11D8-9A61-000A95BD86C0@mnot.net> <87llhqjycb.fsf@nwalsh.com> <8725AB57-D39C-11D8-9A61-000A95BD86C0@mnot.net> <D5C4C862-D3C1-11D8-9DBF-000A95A51C9E@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <D5C4C862-D3C1-11D8-9DBF-000A95A51C9E@sun.com>
User-Agent: Mutt/1.5.6+20040523i
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> [2004-07-11 22:10-0700]
> 
> On Jul 11, 2004, at 5:43 PM, Mark Nottingham wrote:
> 
> >In other words, I'm proposing that we refine our approach to 
> >versioning to three separate things:
> 
> I'm massively unconvinced that this added complexity has noticeable 
> benefit.  I want to see a single namespace that means "this is Atom", 
> and I don't expect the semantics of atom:title to change for a long 
> time so I don't think its name should change, and I do want a 
> root-level "version" attribute.  Going down the path of solving the 
> versioning problem in the general case reliably leads to convulsions 
> and hairy palms.  Let's do the simplest thing that could possibly work: 
> a fixed namespace and a root version attribute. -Tim

+1

Dan



From owner-atom-syntax@mail.imc.org  Mon Jul 12 05: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 FAA24055
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 05: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 i6C8jt8R097121;
	Mon, 12 Jul 2004 01:45: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 i6C8jtgl097120;
	Mon, 12 Jul 2004 01:45:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail-relay-2.tiscali.it (mail-relay-2.tiscali.it [212.123.84.92])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6C8jsU2097103
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 01:45:55 -0700 (PDT)
	(envelope-from danny666@virgilio.it)
Received: from virgilio.it (62.11.126.162) by mail-relay-2.tiscali.it (7.1.021.3)
        id 40E56D3E0036CF33; Mon, 12 Jul 2004 10:45:44 +0200
Message-ID: <40F24F35.8040801@virgilio.it>
Date: Mon, 12 Jul 2004 10:43:33 +0200
From: Danny Ayers <danny666@virgilio.it>
Reply-To: danny666@virgilio.it
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
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: Craeted proposal: PaceProvideSchema
References: <20040711002331.70993.qmail@web41208.mail.yahoo.com> <53518515-D2E7-11D8-9DBF-000A95A51C9E@sun.com>
In-Reply-To: <53518515-D2E7-11D8-9DBF-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:

> Having said that, I'm inclined to declare rough consensus in favor of 
> writing at least one schema, and the jury being out on whether it can 
> be made usefully normative. 


+1

> We seem to have multiple eager volunteers to do the schemas; to them I 
> counsel holding on a couple of revs in the draft till things 
> stabilize. -Tim


I agree that I don't think we can call either way on making any schema 
normative without more work, so it makes sense to put that on hold. But 
regarding informative schemas - I'd say the more different kinds the 
better*, although it would be useful to have one reference version of 
each type.

I'm not sure of the IETF way of doing the documentation - are there any 
conventions for informative references?

* I'd include RDF/OWL schema/ontology(s) - as an informative resource 
the draft I did based on format 0.3 has already been used as a starting 
point for Henry's BlogEd work.

Cheers,
Danny.

-- 

Raw
http://dannyayers.com



From owner-atom-syntax@mail.imc.org  Mon Jul 12 06:32: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 GAA28317
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 06: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 i6CAAai7008123;
	Mon, 12 Jul 2004 03:10: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 i6CAAaX8008122;
	Mon, 12 Jul 2004 03:10:36 -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 i6CAAZUx008095
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 03:10:35 -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 7DC567C125; Mon, 12 Jul 2004 13:08:46 +0200 (CEST)
To: Graham <dtcd@mac.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Q: modfied vs issued vs created
References: <BD17A473.1EDB8%eric.scheid@ironclad.net.au> <opsa0bynaauvpchu@quark> <71F7A31B-D3BE-11D8-82B1-000A95DC3D90@mac.com> <opsa0doeb0uvpchu@quark> <7FAA6B42-D3C1-11D8-82B1-000A95DC3D90@mac.com>
Message-ID: <opsa0r1po1uvpchu@quark>
Date: Mon, 12 Jul 2004 12:14:03 +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: <7FAA6B42-D3C1-11D8-82B1-000A95DC3D90@mac.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Mon, 12 Jul 2004 01:08:22 -0400, Graham <dtcd@mac.com> wrote:

> What does supercedes offer that linking all major and minor versions by
> the same atom:id doesn't?

«Linking these» ID's effectively overwrites old versions with new ones.  
Superseding them keeps every version intact.

> Wouldn't a more direct approach to versioning be better - version ids
> or version numbers?

Nah, too complicated. PaceSupersede isn't supposed to solve versioning,  
nonetheless.

-- 
Asbjørn Ulsberg         -=|=-        asbjornu@hotmail.com
«He's a loathsome offensive brute, yet I can't look away»



From owner-atom-syntax@mail.imc.org  Mon Jul 12 07:47:45 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01162
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 07: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 i6CBUvD6013520;
	Mon, 12 Jul 2004 04:30:57 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6CBUvP3013519;
	Mon, 12 Jul 2004 04:30:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf05.cluster1.charter.net (mxsf05.cluster1.charter.net [209.225.28.205])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CBUucw013510
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 04:30:56 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip20.cluster1.charter.net (mxip20a.cluster1.charter.net [209.225.28.150])
	by mxsf05.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6CBXfik029860
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 07:33:42 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip20.cluster1.charter.net with ESMTP; 12 Jul 2004 07:30:49 -0400
X-Ironport-AV: i="3.81R,161,1083556800"; 
   d="scan'208"; a="41666334:sNHT17310744"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1Bjyzq-0000Hu-00
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 07:29:22 -0400
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Created proposal: PaceProvideSchema
References: <20040712013717.19749.qmail@web41501.mail.yahoo.com>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Mon, 12 Jul 2004 07:29:20 -0400
In-Reply-To: <20040712013717.19749.qmail@web41501.mail.yahoo.com> (Randy
 Charles Morin's message of "Sun, 11 Jul 2004 18:37:17 -0700 (PDT)")
Message-ID: <873c3xihv3.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: <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-Type: text/plain

/ Randy Charles Morin <randymorin@yahoo.com> was heard to say:
| Norman Walsh wrote:
|>Uhm. So don't use XSD?
|
| So, we shouldn't use the schema language that is most supported by
| vendors. Don't use the schema language language which Microsoft and
| Apache/IBM have created countless tools from. Let's start from
| scratch. Clean slate. Thanks,

I didn't propose a schema for the spec so that it would be easy to plug
into a data binding application and build a Java object graph of an
Atom feed. I didn't propose it so that an Atom feed could be decomposed
into a set of complex types for use in building an aggregator application.
I didn't proposed it for any of a number of reasons that would make XSD
the natural choice.

I proposed it in order to aid human comprehension. I think it should
simultaneously satisfy two criteria: conciseness and accuracy. For this
application, I think RELAX NG satisfies those two criteria better.

Actually, I proposed[1] that we provide both a RELAX NG grammar and an XSD
precisely so that we could avoid this sort of pissing contest.

Here's an XSD that approximates the RNC I posted the other day.

<?xml version="1.0" encoding="UTF-8"?>
<!-- -*- Relax NG -*- -->
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" targetNamespace="http://purl.org/atom/ns#" xmlns:atom="http://purl.org/atom/ns#">
  <xs:import schemaLocation="local.xsd"/>
  <xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="xml.xsd"/>
  <!-- Attribute definitions -->
  <xs:attributeGroup name="atomCommonAttributes">
    <xs:attribute ref="xml:base"/>
    <xs:attribute ref="xml:lang"/>
  </xs:attributeGroup>
  <xs:attributeGroup name="atomVersionAttribute">
    <xs:attribute name="version" use="required"/>
  </xs:attributeGroup>
  <!-- Common Atom Constructs -->
  <xs:complexType name="atomContentConstruct" mixed="true">
    <xs:group minOccurs="0" maxOccurs="unbounded" ref="atom:anyElement"/>
    <xs:attributeGroup ref="atom:atomCommonAttributes"/>
    <xs:attribute name="type"/>
    <xs:attribute name="mode">
      <xs:simpleType>
        <xs:restriction base="xs:token">
          <xs:enumeration value="xml"/>
          <xs:enumeration value="escaped"/>
          <xs:enumeration value="base64"/>
        </xs:restriction>
      </xs:simpleType>
    </xs:attribute>
  </xs:complexType>
  <xs:complexType name="atomPersonConstruct">
    <xs:choice minOccurs="0" maxOccurs="unbounded">
      <xs:element ref="atom:name"/>
      <xs:element ref="atom:url"/>
      <xs:element ref="atom:email"/>
    </xs:choice>
    <xs:attributeGroup ref="atom:atomCommonAttributes"/>
  </xs:complexType>
  <xs:element name="name" type="xs:string"/>
  <xs:element name="url" type="xs:string"/>
  <xs:element name="email" type="xs:string"/>
  <xs:complexType name="atomDateConstruct">
    <xs:simpleContent>
      <xs:extension base="xs:dateTime">
        <xs:attributeGroup ref="atom:atomCommonAttributes"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:attributeGroup name="atomLinkConstruct">
    <xs:attributeGroup ref="atom:atomCommonAttributes"/>
    <xs:attribute name="rel" use="required">
      <xs:simpleType>
        <xs:restriction base="xs:token">
          <xs:enumeration value="alternate"/>
          <xs:enumeration value="start"/>
          <xs:enumeration value="next"/>
          <xs:enumeration value="prev"/>
          <xs:enumeration value="service.edit"/>
          <xs:enumeration value="service.post"/>
          <xs:enumeration value="service.feed"/>
        </xs:restriction>
      </xs:simpleType>
    </xs:attribute>
    <xs:attribute name="type" use="required"/>
    <xs:attribute name="href" use="required"/>
    <xs:attribute name="hreflang"/>
    <xs:attribute name="title"/>
  </xs:attributeGroup>
  <!--
    atom:feed
    TODO: Test for multiple atom:link/@rel='alternate' with the same @type
    The following tests are simple to do, but my validator is giving me trouble.
    TODO: Debug and add them back
          Test for at least one atom:link/@rel='alternate'
          Test for atom:author or all atom:entry have atom:author
  -->
  <xs:element name="feed">
    <xs:complexType>
      <xs:choice minOccurs="0" maxOccurs="unbounded">
        <xs:element ref="atom:title"/>
        <xs:element ref="atom:link"/>
        <xs:element ref="atom:author"/>
        <xs:element ref="atom:contributor"/>
        <xs:element ref="atom:tagline"/>
        <xs:element ref="atom:id"/>
        <xs:element ref="atom:generator"/>
        <xs:element ref="atom:copyright"/>
        <xs:element ref="atom:info"/>
        <xs:element ref="atom:modified"/>
        <xs:element ref="atom:entry"/>
        <xs:group ref="atom:anyElement"/>
      </xs:choice>
      <xs:attributeGroup ref="atom:atomCommonAttributes"/>
      <xs:attributeGroup ref="atom:atomVersionAttribute"/>
    </xs:complexType>
  </xs:element>
  <!-- atom:title -->
  <xs:element name="title" type="atom:atomContentConstruct"/>
  <!-- atom:link -->
  <xs:element name="link">
    <xs:complexType>
      <xs:attributeGroup ref="atom:atomLinkConstruct"/>
    </xs:complexType>
  </xs:element>
  <!-- atom:author -->
  <xs:element name="author" type="atom:atomPersonConstruct"/>
  <!-- atom:contributor -->
  <xs:element name="contributor" type="atom:atomPersonConstruct"/>
  <!-- atom:tagline -->
  <xs:element name="tagline" type="atom:atomContentConstruct"/>
  <!-- atom:id -->
  <xs:element name="id" type="xs:string"/>
  <!-- atom:generator -->
  <xs:element name="generator">
    <xs:complexType mixed="true">
      <xs:attributeGroup ref="atom:atomCommonAttributes"/>
      <xs:attribute name="version"/>
      <xs:attribute name="url"/>
    </xs:complexType>
  </xs:element>
  <!-- atom:copyright -->
  <xs:element name="copyright" type="atom:atomContentConstruct"/>
  <!-- atom:info -->
  <xs:element name="info" type="atom:atomContentConstruct"/>
  <!--
    atom:modified
    TODO: Test for a timezone that SHOULD be UTC
  -->
  <xs:element name="modified" type="atom:atomDateConstruct"/>
  <!--
    atom:entry
    TODO: Test for multiple atom:link @rel='alternate' with the same @type
  -->
  <xs:element name="entry">
    <xs:complexType>
      <xs:choice minOccurs="0" maxOccurs="unbounded">
        <xs:element ref="atom:title"/>
        <xs:element ref="atom:link"/>
        <xs:element ref="atom:author"/>
        <xs:element ref="atom:contributor"/>
        <xs:element ref="atom:id"/>
        <xs:element ref="atom:modified"/>
        <xs:element ref="atom:issued"/>
        <xs:element ref="atom:created"/>
        <xs:element ref="atom:summary"/>
        <xs:element ref="atom:content"/>
        <xs:element ref="atom:copyright"/>
        <xs:group ref="atom:anyElement"/>
      </xs:choice>
      <xs:attributeGroup ref="atom:atomCommonAttributes"/>
      <xs:attribute name="version"/>
    </xs:complexType>
  </xs:element>
  <!-- atom:issued -->
  <xs:element name="issued" type="atom:atomDateConstruct"/>
  <!--
    atom:created
    TODO: Test for a timezone that SHOULD be UTC
  -->
  <xs:element name="created" type="atom:atomDateConstruct"/>
  <!-- atom:summary -->
  <xs:element name="summary" type="atom:atomContentConstruct"/>
  <!-- atom:content -->
  <xs:element name="content" type="atom:atomContentConstruct"/>
  <!-- Low-level simple types -->
  <!-- TODO: can anything more specific be said about these types? -->
  <!-- Extensibility -->
  <xs:group name="anyForeignElement">
    <xs:sequence>
      <xs:any namespace="##other" processContents="skip"/>
    </xs:sequence>
  </xs:group>
  <xs:attributeGroup name="anyForeignAttribute">
    <xs:anyAttribute processContents="skip"/>
  </xs:attributeGroup>
  <xs:group name="anyElement">
    <xs:sequence>
      <xs:group ref="local"/>
    </xs:sequence>
  </xs:group>
</xs:schema>
<!-- EOF -->

                                        Be seeing you,
                                          norm

[1] http://www.imc.org/atom-syntax/mail-archive/msg06494.html
-- 
Norman Walsh <ndw@nwalsh.com> | I have animal magnetism. When I go
http://nwalsh.com/            | outside, squirrels stick to my clothes.

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA8nYSOyltUcwYWjsRAkmlAJ0UiRN8HRFFIDFWaTh7ulgKbii4lwCfU346
1Ksdc1ednfSEr62a2Q/hkDU=
=Al71
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Mon Jul 12 07:48: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 HAA01201
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 07:48: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 i6CBc8P0014277;
	Mon, 12 Jul 2004 04:38: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 i6CBc8XR014276;
	Mon, 12 Jul 2004 04:38:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf22.cluster1.charter.net (mxsf22.cluster1.charter.net [209.225.28.222])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CBc7ZF014266
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 04:38:08 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip03.cluster1.charter.net (mxip03a.cluster1.charter.net [209.225.28.133])
	by mxsf22.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6CBf75Y003861
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 07:41:08 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip03.cluster1.charter.net with ESMTP; 12 Jul 2004 07:38:02 -0400
X-Ironport-AV: i="3.81R,161,1083556800"; 
   d="scan'208"; a="109140854:sNHT15354508"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1Bjz6o-0000NN-00
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 07:36:34 -0400
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Disambiguating the subject of feed-level metadata
References: <97774BF0-D096-11D8-B2D0-000A95A51C9E@sun.com>
	<F3C7FAC8-D233-11D8-9A61-000A95BD86C0@mnot.net>
	<87smc0ownv.fsf@nwalsh.com>
	<F1AC0C56-D2AB-11D8-B2D0-000A95A51C9E@sun.com>
	<F47D290F-D2BB-11D8-9A61-000A95BD86C0@mnot.net>
	<7DEA0B24-D2ED-11D8-ACB6-000A95DC3D90@mac.com>
	<m3658up4pk.fsf@bitsko.slc.ut.us>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Mon, 12 Jul 2004 07:36:28 -0400
In-Reply-To: <m3658up4pk.fsf@bitsko.slc.ut.us> (Ken MacLeod's message of "11
 Jul 2004 17:19:19 -0500")
Message-ID: <87vfgth2yr.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: <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-Type: text/plain

/ Ken MacLeod <ken@bitsko.slc.ut.us> was heard to say:
[...]
| With all the use-cases for multiple feeds, synthetic feeds,
| independent entries, I'm leaning heavily towards -1 on inheritance or
| defaults in any manner.  Making entries as independent as possible
| would be a good "core Atom" goal, and then explicit references for
| "more info".  I'm still good with "hard local references", such as
| <site> and <author> with known required-to-be-copied elements:
|
| <feed>
|   <site id="site1" />
|   <person id="person A" />
|   <person id="person B" />
|   <entry>
|     <site ref="site1" />
|     <author ref="person A" />
|   </entry>
|   <entry>
|     <site ref="site1" />
|     <author ref="person B" />
|     <contributor ref="person A" />
|   </entry>
| </feed>
|
| In this scenario, the "redundantly replicated" @ref elements in, yes,
| every entry are acting like foreign keys in a database table.
| Absolutely no inheritance of any kind -- it's all explicit.

The question here though is, what are the real benefits of these
references. Wouldn't this be better still for achieving independence
of entries?

<feed>
  <entry>
    <site>site1</site>
    <author>personA</author>
  </entry>
  <entry>
    <site>site1</site>
    <author>personB</author>
    <contributor>personA</contributor>
  </entry>
</feed>

References would give you a way of establishing that two entries
really refer to the same author, but in a single original feed, that's
going to be the case in the vastly overwhelming majority of cases with
no possibility of confusion. And in an aggregated feed, you aren't
going to be able to collapse refs unless we give authors and sites a
unique identifier.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | How can there be laughter, how can
http://nwalsh.com/            | there be pleasure, when the world is
                              | burning?--The Dhammapada (probably 3rd
                              | century BC)

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA8ne9OyltUcwYWjsRAu0gAJ9l9eOQobhZDaEVC8n211irkEqozwCeOFFu
ANhuzXAkitluthwUz8eOkcA=
=5yz/
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Mon Jul 12 08:30: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 IAA03404
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 08:30:38 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CCIVkF017877;
	Mon, 12 Jul 2004 05: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 i6CCIVZt017876;
	Mon, 12 Jul 2004 05:18:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf17.cluster1.charter.net (mxsf17.cluster1.charter.net [209.225.28.217])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CCI6dc017826
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 05:18:30 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip16.cluster1.charter.net (mxip16a.cluster1.charter.net [209.225.28.146])
	by mxsf17.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6CCLkXq019830
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 08:21:47 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip16.cluster1.charter.net with ESMTP; 12 Jul 2004 08:18:01 -0400
X-Ironport-AV: i="3.81R,161,1083556800"; 
   d="scan'208"; a="110256052:sNHT27527482"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BjzjS-0000pw-00
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 08:16:30 -0400
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: atom:author in feed and entry
References: <87oemmmuy5.fsf@nwalsh.com>
	<9340AD71-D3B0-11D8-9A61-000A95BD86C0@mnot.net>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Mon, 12 Jul 2004 08:16:30 -0400
In-Reply-To: <9340AD71-D3B0-11D8-9A61-000A95BD86C0@mnot.net> (Mark
 Nottingham's message of "Sun, 11 Jul 2004 20:07:14 -0700")
Message-ID: <87n025h141.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: <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-Type: text/plain

/ Mark Nottingham <mnot@mnot.net> was heard to say:
| I think this is the crux of the defaulting discussion going on in the
| PaceElementOrder thread; see those messages titled "Disambiguating the
| subject of feed-level metadata." Once we figure that out, this should
| follow...

I agree. That comment, and the one about summary/content, and several
others were intended only to highlight areas where I thought the spec
was insufficiently clear. I don't have a strong opinion one way or the
other about what the answer is, only that the spec must provide an
answer.

|
| On Jul 11, 2004, at 8:20 AM, Norman Walsh wrote:
|
|> The draft 00 spec says "atom:feed elements MUST contain exactly one
|> atom:author element, UNLESS all of the atom:feed element's child
|> atom:entry elements contain an atom:author element".
|>
|> May the atom:feed element contain an atom:author if all of the
|> relevant atom:entry elements ALSO contain an atom:author?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | We humans are such limited
http://nwalsh.com/            | creatures--how is it that there are so
                              | few limits when it comes to human
                              | suffering?--Pierre Marivaux

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA8oEeOyltUcwYWjsRAlOiAJ0f3AKqmsUnQ/SX4ncRgTRgoxIlAQCePNex
Ls6M0R0yaN6PljFRvq/Ygrw=
=oIUZ
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Mon Jul 12 08:36: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 IAA03743
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 08:36: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 i6CCFWHY017565;
	Mon, 12 Jul 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 i6CCFWJF017564;
	Mon, 12 Jul 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 mxsf11.cluster1.charter.net (mxsf11.cluster1.charter.net [209.225.28.211])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CCFV8E017553
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 05:15:32 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip02.cluster1.charter.net (mxip02a.cluster1.charter.net [209.225.28.132])
	by mxsf11.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6CCJRai021203
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 08:19:27 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip02.cluster1.charter.net with ESMTP; 12 Jul 2004 08:15:27 -0400
X-Ironport-AV: i="3.81R,161,1083556800"; 
   d="scan'208"; a="116333626:sNHT31374616"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1Bjzh2-0000nj-00
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 08:14:00 -0400
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Version vs. Namespace
References: <87smbymve3.fsf@nwalsh.com>
	<B40394C3-D356-11D8-9A61-000A95BD86C0@mnot.net>
	<87llhqjycb.fsf@nwalsh.com>
	<8725AB57-D39C-11D8-9A61-000A95BD86C0@mnot.net>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Mon, 12 Jul 2004 08:13:59 -0400
In-Reply-To: <8725AB57-D39C-11D8-9A61-000A95BD86C0@mnot.net> (Mark
 Nottingham's message of "Sun, 11 Jul 2004 17:43:44 -0700")
Message-ID: <87r7rhh188.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: <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-Type: text/plain

/ Mark Nottingham <mnot@mnot.net> was heard to say:
| 1) Atom container constructs (e.g., atom:feed, atom:entry) are
| identified by their namespace URI; if we change the containment
| semantics, processing model, etc. we have to change that namespace.
|
| 2) Atom and extension metadata are likewise identified by their
| namespace; if their syntax or semantics change, they need a differnent
| Qname. This means that the metadata in our final release of Atom had
| better be well-understood and stable, because they'll be baked in (I
| think that's OK because it's true no matter what we do, and we're
| chartered to be conservative about the metadata we bake in).

Extension metadata is already going to be in another namespace, so
that's not really an issue. If I understand you, what you're proposing
boils down to a namespace name for the atom:feed/atom:entry elements
and a different namespace name for the atommeta:title, atommeta:author,
etc. elements.

I think that's going to make Atom significantly harder for new users
that are trying to write, understand, or process feeds. I think
keeping everything in a single namespace so that a vanilla feed can
just use the default namespace for all elements is a feature we should
not lose without compelling motivation.

| 3) The "package" of metadata used in a feed is described by a
| "profile" or "version" attribute, e.g.,
|    <atom:feed profile="http://.../..."> ... </atom:feed>
|    Atom would ship with a "default" profile that says there MUST be an
| atom:title, etc. -- just as the spec currently does -- and that
| extensions are allowed on top of that. More specialised vertical uses
| of Atom can likewise describe their own profiles; if they can get tool
| support for them, good on them.

Calling the "version" attribute "profile" and allowing others to
define their own profiles is an interesting idea. I could probably
live with that.

But I don't think you've covered the use case that I think is most important.
Suppose that a year from now, we all have Atom 1.0 under our belts and we've
been using it for a while. Discussion has continued after the 1.0 release and
we're pretty sure we have the categorization problem solved (just to pick an
example, choose anything that isn't scheduled for the 1.0 release).

Now we want to publish Atom 1.1 with a new, optional element, atom:category.

We could:

 1. Add this in a new namespace
 2. Add this in a new namespace and change *all* the elements to the new namespace
 3. Add this in the old namespace and change the version/profile attribute.

Choice 1 is "right" by some metrics, but won't feel like we're integrating
atom:category into Atom proper.

Choice 2 is "right" by some metrics, but it really is a heck of a cliff that
everyone has to jump off. It will be *years* before everyone is ready to change
all their feeds and tools.

Choice 3 is "right" by some metrics, and if its combined with a
reasonable versioning policy in 1.0 offers the maximum bang for the
minumum buck, IMHO.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Wandering in a vast forest at night, I
http://nwalsh.com/            | have only a faint light to guide me. A
                              | stranger appears and says to me: "My
                              | friend, you should blow out your candle
                              | in order to find your way more
                              | clearly." This man is a theologian.--
                              | Diderot

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA8oCHOyltUcwYWjsRAo2gAJ9JCpyEjQa4j54GcgMGJd2DRs7xiwCgrzor
pLt62uO636XDwBz0naArdRE=
=eijJ
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Mon Jul 12 09:21: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 JAA05958
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 09:21: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 i6CD8ZWU021541;
	Mon, 12 Jul 2004 06:08: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 i6CD8ZeM021540;
	Mon, 12 Jul 2004 06:08:35 -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 i6CD7gdu021364
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 06:08:35 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Received: from mail.online.no (ti132110a080-3373.bb.online.no [80.212.221.45])
	by mail43.fg.online.no (8.12.11/8.12.11) with ESMTP id i6CD7M4l023080;
	Mon, 12 Jul 2004 15:07:28 +0200 (CEST)
To: "Eric Scheid" <eric.scheid@ironclad.net.au>,
        Atom-syntax <atom-syntax@imc.org>
Subject: Re: Q: modfied vs issued vs created
References: <BD187FBE.1F041%eric.scheid@ironclad.net.au>
Message-ID: <opsa0z2hah6dxgxk@mail.online.no>
Date: Mon, 12 Jul 2004 15:07:19 +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: <BD187FBE.1F041%eric.scheid@ironclad.net.au>
User-Agent: Opera M2/7.52 (Win32, build 3826)
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 Mon, 12 Jul 2004 17:49:50 +1000, Eric Scheid  
<eric.scheid@ironclad.net.au> wrote:

> Atom does support minor/major changes: if the modified date changes, but  
> the issued date doesn't, then it's a minor change. If the modified date  
> changes,and the issued date does too, then it's a major change. If the  
> modified date doesn't change, but the issued date does, then you can  
> consider it
> assertively no changes (but no longer old news).

The "issue" date is the date of "formal issuance" (e.g initial  
publication) and should _never ever change._ [1] If the issued date  
changes, it is no longer the same entry. Hence, a new ID and a superesede  
mechanism.

That the current blog-like CMSes doesn't handle this, should be no excuse  
for not adding such a mechanism.  Old systems, like MT, will happily go on  
working the way they do.

-- 
Arve Bersvendsen

http://www.virtuelvis.com
http://www.bersvendsen.com



From owner-atom-syntax@mail.imc.org  Mon Jul 12 09:29: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 JAA06367
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 09:29:24 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CDGElr022310;
	Mon, 12 Jul 2004 06: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 i6CDGE0Q022308;
	Mon, 12 Jul 2004 06:16:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CDGD5w022291
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 06:16: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 EB8167C117; Mon, 12 Jul 2004 16:14:23 +0200 (CEST)
Date: Mon, 12 Jul 2004 15:20:17 +0200
To: "Eric Scheid" <eric.scheid@ironclad.net.au>
Subject: Re: Q: modfied vs issued vs created
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <BD187FBE.1F041%eric.scheid@ironclad.net.au>
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: <opsa00n3cguvpchu@quark>
In-Reply-To: <BD187FBE.1F041%eric.scheid@ironclad.net.au>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Mon, 12 Jul 2004 17:49:50 +1000, Eric Scheid  
<eric.scheid@ironclad.net.au> wrote:

> Atom does support minor/major changes: if the modified date changes, but  
> the issued date doesn't, then it's a minor change. If the modified date  
> changes, and the issued date does too, then it's a major change.

atom:issued should _never_ change. Period. Alas, Atom does not have  
support for minor and major changes.

> If the modified date doesn't change, but the issued date does, then you
> can consider it assertively no changes (but no longer old news).

What's the use case for this? What you're really should be doing here is  
alter 'modified' and keep 'issued' the same. Then, it's up to the client  
to choose to show this modification or not. As we don't have a  
supersede-mechanism at the moment, there's no way to separate major  
changes from minor, so users  will either have to choose «show all  
changes» or «never show changes».

> (the fourth combination where neither changes means it's old news, caveat
> emptor)

If it's old news, would you ever find it in a feed? An archive feed,  
perhaps?

-- 
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 Jul 12 09:46: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 JAA07115
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 09:46: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 i6CDSN2e023195;
	Mon, 12 Jul 2004 06:28: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 i6CDSN6H023194;
	Mon, 12 Jul 2004 06:28: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 i6CDS7Ab023168
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 06:28:23 -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 1Bk0qi-0002H4-Bk; Mon, 12 Jul 2004 13:28:04 +0000
Message-ID: <40F291DB.3070307@franklinmint.fm>
Date: Mon, 12 Jul 2004 09:27:55 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
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: Q: modfied vs issued vs created
References: <BD187FBE.1F041%eric.scheid@ironclad.net.au>
In-Reply-To: <BD187FBE.1F041%eric.scheid@ironclad.net.au>
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


Eric Scheid wrote:

>
>Atom does support minor/major changes: if the modified date changes, but the
>issued date doesn't, then it's a minor change. If the modified date changes,
>and the issued date does too, then it's a major change. 
>  
>

There is nothing in the spec to this effect, and that's not what 
dc:issued means.

Robert Sayre



From owner-atom-syntax@mail.imc.org  Mon Jul 12 09: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 JAA07313
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 09:50: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 i6CDbKf2024113;
	Mon, 12 Jul 2004 06:37: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 i6CDbKrL024112;
	Mon, 12 Jul 2004 06:37: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 i6CDb1XF024068
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 06:37: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 i6CDav53010125
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 08:36:58 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6CDau49010121;
	Mon, 12 Jul 2004 08:36:56 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Q: modfied vs issued vs created
References: <BD187FBE.1F041%eric.scheid@ironclad.net.au>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 12 Jul 2004 08:36:56 -0500
In-Reply-To: <BD187FBE.1F041%eric.scheid@ironclad.net.au>
Message-ID: <m3smbxny87.fsf@bitsko.slc.ut.us>
Lines: 32
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


Eric Scheid <eric.scheid@ironclad.net.au> writes:

> Atom does support minor/major changes: if the modified date changes,
> but the issued date doesn't, then it's a minor change. If the
> modified date changes, and the issued date does too, then it's a
> major change. If the modified date doesn't change, but the issued
> date does, then you can consider it assertively no changes (but no
> longer old news).

This behavior is not described in the current spec or any proposals
that I'm aware of.  Are you proposing this behavior?

I'm -1 on any proposal for *core Atom* that seeks to propose
information that indicates "meaningful change".

"Meaningful change" can only be interpreted by a human, and this
particular informational indicator is one that requires a significant
amount of discipline to achieve.  The chances of this happening enough
in the general population of publishers is near nil, which makes it a
very unlikely feature to be supported by clients.

I would favor an "editing" extension (mod_editing) that provided terms
for the purpose of indicating "meaningful change", because the
likelyhood of someone adopting and using mod_editing significantly
increases the likelyhood that they have a "publishing process" (note,
not "system") that includes enough discipline to properly indicate
meaningful change.  That's something clients can depend on.

Note, mod_editing could also include the "supersedes" functionality
being described in another thread.

  -- Ken



From owner-atom-syntax@mail.imc.org  Mon Jul 12 10:10: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 KAA09341
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 10: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 i6CDpAve025290;
	Mon, 12 Jul 2004 06:51: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 i6CDpAKt025289;
	Mon, 12 Jul 2004 06:51:10 -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 [212.123.84.93])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CDo9UB025165
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 06:51:09 -0700 (PDT)
	(envelope-from danny666@virgilio.it)
Received: from virgilio.it (62.11.119.104) by mail-relay-3.tiscali.it (7.1.021.3)
        id 40EB9560001E0776; Mon, 12 Jul 2004 15:50:01 +0200
Message-ID: <40F29686.10906@virgilio.it>
Date: Mon, 12 Jul 2004 15:47:50 +0200
From: Danny Ayers <danny666@virgilio.it>
Reply-To: danny666@virgilio.it
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: danny666@virgilio.it
CC: Mark Nottingham <mnot@mnot.net>, Tim Bray <Tim.Bray@Sun.COM>,
        Atom Syntax <atom-syntax@imc.org>
Subject: XML Schema and PaceElementOrder
References: <97774BF0-D096-11D8-B2D0-000A95A51C9E@sun.com> <F3C7FAC8-D233-11D8-9A61-000A95BD86C0@mnot.net> <63690128-D237-11D8-B2D0-000A95A51C9E@sun.com> <98FB4CE4-D237-11D8-9A61-000A95BD86C0@mnot.net> <40F011AE.1090502@virgilio.it>
In-Reply-To: <40F011AE.1090502@virgilio.it>
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


The desire for schema-validity in the group seems to be pretty strong 
(more so than I guessed). Which means an XML Schema is more desirable, 
which in turn means that element order standardization is probably also 
desirable.

--verbose :  granted that the normative schema will (only) be defined in 
prose, schema-validity in this sense will be a MUST. The informative 
machine-readable schemas would in effect offer schema-validation as a 
MAY. But a very desirable MAY in development, to assist with 
forementioned MUST. Given that lack of element order (and nesting) make 
the XSD either painful or under-constrained, I think there's a good case 
for mandating an order (disallowing any optional nesting).

Cheers,
Danny.

Danny Ayers wrote:

>
> Mark Nottingham wrote:
>
>>
>>
>> On Jul 9, 2004, at 11:07 PM, Tim Bray wrote:
>>
>>>
>>> On the other hand, leaving the order semi-unconstrained (i.e. 
>>> requiring only that the <atom:entry> crowd bring up the rear) is 
>>> going to result in serious ugliness in any XSD we produce, which may 
>>> spill over into SOAP/WSDL territory... still, I lean to -1. -Tim
>>
>>
>>
>> XSD's problem, not mine.
>
>
>
> Quite.
>
> It seems like putting the cart before the horse to constrain order in 
> the spec for the benefit of the schema without some reference to 
> schema-validity.  If we really want a schema, we should be prepared to 
> use it. I'd suggest either making schema-validity a SHOULD (and 
> processor validation a MAY) or allowing any order. I suspect the 
> latter is more likely to gain consensus.
>
> Cheers,
> Danny.
>


-- 

Raw
http://dannyayers.com



From owner-atom-syntax@mail.imc.org  Mon Jul 12 10:41: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 KAA12395
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 10:41: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 i6CEHhCS027370;
	Mon, 12 Jul 2004 07:17:43 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6CEHhkI027369;
	Mon, 12 Jul 2004 07:17:43 -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 i6CEH7JV027227
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 07:17:43 -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 <2004071214170401500i5t84e>; Mon, 12 Jul 2004 14:17:05 +0000
Date: Mon, 12 Jul 2004 08:17:03 -0600
Subject: Re: MUST be UTC?
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: <03c901c46774$a38e0f40$200ca8c0@wkearney.com>
Message-Id: <25AD9932-D40E-11D8-9D0B-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 Sunday, July 11, 2004, at 12:26  PM, Bill Kearney wrote:
> And as long as the developers understand that PDT/PST mean 
> -07:00/-08:00.  It
> varies based on the /date/ involved.
>
> Take, for example, Noon in LA:
>
> 07/01/2004 12:00PDT is 07/01/2004 19:00Z
> (seven hours off UTC during DST)
> but
> 12/01/2004 12:00PST is 07/01/2004 20:00Z
> (eight hours off during standard time)
>
> This is also why it's often a better idea all around to store in UTC.  
> Doing
> 'date math' across ranges when you cross daylight savings periods can 
> often have
> unexpected results.  As in, converting a timestamp from outside your 
> current
> shift (May during December, and vice versa).
>
> Oh, and to make matters worse, not all areas/countries observe DST
> "consistently".  Thus flipping the date to UTC as quickly as possible 
> in the
> collection process makes a whooooole lot of sense.
>
Requiring use of numeric offsets rather than "PST", etc., solves the 
problem too.  Of course, the software may wish to let the user indicate 
"PST" in case they don't know how many hours they are offset from 
UTC--but the software should publish the feed with a numeric offset.



From owner-atom-syntax@mail.imc.org  Mon Jul 12 10:53: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 KAA14445
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 10:53: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 i6CEWaxl028598;
	Mon, 12 Jul 2004 07:32:38 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6CEWaFX028597;
	Mon, 12 Jul 2004 07:32:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail06.svc.cra.dublin.eircom.net (mail06.svc.cra.dublin.eircom.net [159.134.118.22])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6CEW9dN028553
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 07:32:36 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 74061 messnum 2838786 invoked from network[83.70.39.115/83-70-39-115.bas2.prp.dublin.eircom.net]); 12 Jul 2004 14:32:06 -0000
Received: from 83-70-39-115.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.39.115)
  by mail06.svc.cra.dublin.eircom.net (qp 74061) with SMTP; 12 Jul 2004 14:32:06 -0000
Message-ID: <40F2A0DE.4050908@dehora.net>
Date: Mon, 12 Jul 2004 15:31:58 +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: Created proposal: PaceProvideSchema
References: <OF082EA495.E5B00BA7-ON88256ECF.00156336-88256ECF.0015AEC0@us.ibm.com> <69D21DD5-D3BA-11D8-9A61-000A95BD86C0@mnot.net>
In-Reply-To: <69D21DD5-D3BA-11D8-9A61-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: <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



> However, it shouldn't be normative, for reasons described before, and 
> the design of Atom shouldn't be subjugated by the needs of Schema; if 
> there's contention between real-world requirements and the contortions 
> that Schema makes you go through, Schema should lose (i.e., the schema 
> should be less expressive).


I don't' understand why Mark is having to labour this point. It's 
normal that specs with ebnf, logic or something equally precise go 
out where the prose is the last word when the ebnf, logic or 
something else isn't adequate. Why would schemata be any different?

On the other hand, I would like to see which structural constraints 
of Atom can't be expressed or can't be expressed easily by RNG or 
Schematron*, as opposed to predictions and assumptions. The ones I'm 
aware of are element ordering and 'extensibility' spots such as 
@rel. Apart from mild skepticism, such constraints are an ideal 
point of departure for conformance tests.

As an aside. The issue with non-normative schemata is that people 
drop them into their normative systems and are often disappointed at 
the outcome. When this matter comes onto the work list, we should 
expect to see big friendly letters nearby warning people what they 
may and may not assume about the schema.

Thus:

+1 to a schema in the spec. I don't care whether it's normative of not.

+1 to using RNG for this purpose. I don't care whether it's XML or 
compact format.

-1 to not tracking the schema across editions of the specs.  If 
schemata seem to be valuable, then they seem to me to be constantly 
valuable. I have no problem doing this, nor it seems do others.


cheers
Bill

* DTD/WXS I'll exclude due to their limited power of expression. Yes 
I know the tool support is better.



From owner-atom-syntax@mail.imc.org  Mon Jul 12 10:58: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 KAA14818
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 10:58: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 i6CEirSQ029419;
	Mon, 12 Jul 2004 07:45: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 i6CEirU5029418;
	Mon, 12 Jul 2004 07:44: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 (mproxy.gmail.com [216.239.56.245])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6CEiVPH029392
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 07:44:52 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so10315937cwc
        for <atom-syntax@imc.org>; Mon, 12 Jul 2004 07:44:27 -0700 (PDT)
Received: by 10.11.118.39 with SMTP id q39mr101062cwc;
        Mon, 12 Jul 2004 07:44:27 -0700 (PDT)
Message-ID: <3f1451f504071207447ae9f08f@mail.gmail.com>
Date: Mon, 12 Jul 2004 10:44:27 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: danny666@virgilio.it
Subject: Re: XML Schema and PaceElementOrder
Cc: Mark Nottingham <mnot@mnot.net>, Tim Bray <tim.bray@sun.com>,
        Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <40F29686.10906@virgilio.it>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <97774BF0-D096-11D8-B2D0-000A95A51C9E@sun.com> <F3C7FAC8-D233-11D8-9A61-000A95BD86C0@mnot.net> <63690128-D237-11D8-B2D0-000A95A51C9E@sun.com> <98FB4CE4-D237-11D8-9A61-000A95BD86C0@mnot.net> <40F011AE.1090502@virgilio.it> <40F29686.10906@virgilio.it>
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 Mon, 12 Jul 2004 15:47:50 +0200, Danny Ayers <danny666@virgilio.it> wrote:
> 
> The desire for schema-validity in the group seems to be pretty strong
> (more so than I guessed). Which means an XML Schema is more desirable,
> which in turn means that element order standardization is probably also
> desirable.
> 
> --verbose :  granted that the normative schema will (only) be defined in
> prose, schema-validity in this sense will be a MUST. The informative
> machine-readable schemas would in effect offer schema-validation as a
> MAY. But a very desirable MAY in development, to assist with
> forementioned MUST. Given that lack of element order (and nesting) make
> the XSD either painful or under-constrained, I think there's a good case
> for mandating an order (disallowing any optional nesting).

-1 

Let's not twist ourselves in knots
to accomdate the shortcomings of XSD.

    -joe



From owner-atom-syntax@mail.imc.org  Mon Jul 12 11:01: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 LAA14936
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 11:01: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 i6CEjXSr029467;
	Mon, 12 Jul 2004 07:45: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 i6CEjXEm029466;
	Mon, 12 Jul 2004 07:45:33 -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 i6CEjMCg029438
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 07:45:32 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 26317 messnum 5040642 invoked from network[83.70.39.115/83-70-39-115.bas2.prp.dublin.eircom.net]); 12 Jul 2004 14:45:20 -0000
Received: from 83-70-39-115.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.39.115)
  by mail04.svc.cra.dublin.eircom.net (qp 26317) with SMTP; 12 Jul 2004 14:45:20 -0000
Message-ID: <40F2A3F8.6080602@dehora.net>
Date: Mon, 12 Jul 2004 15:45:12 +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: Resource terminology
References: <40EEFB88.3020403@virgilio.it> <55668634-D233-11D8-9A61-000A95BD86C0@mnot.net> <40F00E83.9020506@virgilio.it>
In-Reply-To: <40F00E83.9020506@virgilio.it>
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:

> 
> Mark Nottingham wrote:
>>> Can someone please tell me if this was intentional (and if so, why?!) -
>>>
>>> The charter, early on says:
>>>
>>> Atom consists of:
>>>    * A conceptual model of a resource
>>>
>>> Is this a resource in the URI sense, or a new term for an Atom thing?
>>
>> In the Web sense, yes.

I think you can strike the statement in question without any loss of 
meaning to the spec.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Mon Jul 12 11:02: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 LAA14981
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 11:02: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 i6CEnWKY029833;
	Mon, 12 Jul 2004 07:49:32 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6CEnWUq029832;
	Mon, 12 Jul 2004 07:49:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from 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 i6CEnOKD029801
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 07:49:31 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 96617 messnum 4164126 invoked from network[83.70.39.115/83-70-39-115.bas2.prp.dublin.eircom.net]); 12 Jul 2004 14:49:21 -0000
Received: from 83-70-39-115.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.39.115)
  by mail00.svc.cra.dublin.eircom.net (qp 96617) with SMTP; 12 Jul 2004 14:49:21 -0000
Message-ID: <40F2A4E9.3050007@dehora.net>
Date: Mon, 12 Jul 2004 15:49:13 +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 Syntax <atom-syntax@imc.org>
Subject: Re: Disambiguating the subject of feed-level metadata
References: <97774BF0-D096-11D8-B2D0-000A95A51C9E@sun.com> <F3C7FAC8-D233-11D8-9A61-000A95BD86C0@mnot.net> <87smc0ownv.fsf@nwalsh.com> <F1AC0C56-D2AB-11D8-B2D0-000A95A51C9E@sun.com> <F47D290F-D2BB-11D8-9A61-000A95BD86C0@mnot.net> <7DEA0B24-D2ED-11D8-ACB6-000A95DC3D90@mac.com>
In-Reply-To: <7DEA0B24-D2ED-11D8-ACB6-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: <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 10 Jul 2004, at 5:56 pm, Mark Nottingham wrote:
> 
>> This leads me to believe that there may be some value in separating 
>> feed-wide metadata with entry defaults, in a manner something like this:
> 


If this is what is really wanted, let's mark it up:

<feed>
   <defaults>
     <author name="person A">
      ...
   </defaults>
   <entry />
   <entry />
   ...
  </author>

cheers
Bill



From owner-atom-syntax@mail.imc.org  Mon Jul 12 11: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 LAA16726
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 11: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 i6CF6JNn031308;
	Mon, 12 Jul 2004 08:06:19 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6CF6JUZ031307;
	Mon, 12 Jul 2004 08:06:19 -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 i6CF6Gc4031296
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 08:06:18 -0700 (PDT)
	(envelope-from Janne.Jalkanen@nokia.com)
Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158])
	by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6CF6Fs11328;
	Mon, 12 Jul 2004 18:06:15 +0300 (EET DST)
X-Scanned: Mon, 12 Jul 2004 18:05:59 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost)
	by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i6CF5x90004239;
	Mon, 12 Jul 2004 18:05:59 +0300
Received: from mgw-int1.ntc.nokia.com (172.21.143.96)
	by esdks003.ntc.nokia.com 00vYsFO1; Mon, 12 Jul 2004 18:05:57 EEST
Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28])
	by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6CF5un16089;
	Mon, 12 Jul 2004 18:05:56 +0300 (EET DST)
Received: from nokia.com ([172.21.60.114]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Mon, 12 Jul 2004 18:05:39 +0300
Message-ID: <40F2A8C1.60103@nokia.com>
Date: Mon, 12 Jul 2004 18:05:37 +0300
From: Janne Jalkanen <Janne.Jalkanen@nokia.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040122
X-Accept-Language: fi, en-us, en
MIME-Version: 1.0
To: ext Robert Sayre <mint@franklinmint.fm>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Pace409Response
References: <BD1497CA.1205C%mint@franklinmint.fm>
In-Reply-To: <BD1497CA.1205C%mint@franklinmint.fm>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 12 Jul 2004 15:05:39.0502 (UTC) FILETIME=[B189BCE0:01C46821]
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



>3.1.3.x Status Code 409
>
>   The request contained a valid Atom Entry, but it conflicts with state on
>the server.The response SHOULD contain enough for information for the user
>to resolve the conflict.
>  
>
+1

This would be immensely useful with Wikis, for example.  Though the 
response format needs to be worked out - perhaps the current contents of 
the page?

However, there needs to be a way to tell the Wiki that "ok, this is no 
longer an editing conflict, but a resolved version".  Typically this is 
done with some nonce or datetime value.

/Janne



From owner-atom-syntax@mail.imc.org  Mon Jul 12 11:22: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 LAA16933
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 11: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 i6CF8SIq031443;
	Mon, 12 Jul 2004 08:08:28 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6CF8Sst031442;
	Mon, 12 Jul 2004 08:08:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail06.svc.cra.dublin.eircom.net (mail06.svc.cra.dublin.eircom.net [159.134.118.22])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6CF8PGX031429
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 08:08:28 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 30456 messnum 2831218 invoked from network[83.70.39.115/83-70-39-115.bas2.prp.dublin.eircom.net]); 12 Jul 2004 15:08:22 -0000
Received: from 83-70-39-115.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.39.115)
  by mail06.svc.cra.dublin.eircom.net (qp 30456) with SMTP; 12 Jul 2004 15:08:22 -0000
Message-ID: <40F2A95E.3090607@dehora.net>
Date: Mon, 12 Jul 2004 16:08:14 +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: PaceElementOrder
References: <97774BF0-D096-11D8-B2D0-000A95A51C9E@sun.com>	<F3C7FAC8-D233-11D8-9A61-000A95BD86C0@mnot.net> <87smc0ownv.fsf@nwalsh.com>
In-Reply-To: <87smc0ownv.fsf@nwalsh.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


Norman Walsh wrote:

> If we want to make a distinction between atom:entry children and other
> children, I suggest that we put the other children in a wrapper.
> 
>   <atom:feed>
>     <atom:feedinfo>
>       <atom:title>...</atom:title>
>     </atom:feedinfo>
>     <atom:entry>...</atom:entry>
>   </atom:feed>

No, the issue I had in mind when I wrote that Pace remains:

   <atom:feed>
     <atom:entry>...</atom:entry>
     <atom:feedinfo>
       <atom:title>...</atom:title>
     </atom:feedinfo>
     <atom:entry>...</atom:entry>
   </atom:feed>


cheers
Bill



From owner-atom-syntax@mail.imc.org  Mon Jul 12 11: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 LAA17483
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 11: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 i6CFHcje032332;
	Mon, 12 Jul 2004 08: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 i6CFHcR9032331;
	Mon, 12 Jul 2004 08:17:38 -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 i6CFHQPX032301
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 08:17:37 -0700 (PDT)
	(envelope-from roger@agincourtmedia.com)
Received: from biggreen ([216.63.148.42]) by journurl.com with MailEnable ESMTP; Mon, 12 Jul 2004 10:16:34 -0500
From: "Roger B." <roger@agincourtmedia.com>
To: "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: RE: Q: modfied vs issued vs created
Date: Mon, 12 Jul 2004 10:18:29 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <opsavm6g0ruvpchu@quark>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Thread-Index: AcRlyqsBWT2S4kqGTtiH192b0leG2wCVF7oQ
Message-ID: <46D167FDA4C4E5B8EB0AF52D1B774.MAI@journurl.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6CFHcPX032326
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


> But what is the purpose of having 'issued' in the format at all, if it's
> basically just some random string, formatted as a W3CDTF?

Asbjørn: The "published date" is the date that the author wants attached to
her entry. That date controls when and where the entry shows up in her blog
and feed. It is also the date that aggregators will want to use for sorting
in most instances. In short, it's the most important date available, and the
one users most want to control.

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/ 








From owner-atom-syntax@mail.imc.org  Mon Jul 12 11:48: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 LAA18914
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 11:48: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 i6CFaIvH033880;
	Mon, 12 Jul 2004 08:36: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 i6CFaIng033879;
	Mon, 12 Jul 2004 08:36:18 -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 i6CFZbMH033821
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 08:36: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 i6CFZZ53011714
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 10:35:35 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6CFZYbB011710;
	Mon, 12 Jul 2004 10:35:34 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom-Syntax Syntax <atom-syntax@imc.org>
Subject: Re: Disambiguating the subject of feed-level metadata
References: <97774BF0-D096-11D8-B2D0-000A95A51C9E@sun.com>
	<F3C7FAC8-D233-11D8-9A61-000A95BD86C0@mnot.net>
	<87smc0ownv.fsf@nwalsh.com>
	<F1AC0C56-D2AB-11D8-B2D0-000A95A51C9E@sun.com>
	<F47D290F-D2BB-11D8-9A61-000A95BD86C0@mnot.net>
	<7DEA0B24-D2ED-11D8-ACB6-000A95DC3D90@mac.com>
	<40F2A4E9.3050007@dehora.net>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 12 Jul 2004 10:35:34 -0500
In-Reply-To: <40F2A4E9.3050007@dehora.net>
Message-ID: <m3oemlnsqh.fsf@bitsko.slc.ut.us>
Lines: 20
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 i6CFaIMH033873
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 <bill@dehora.net> writes:

> If this is what is really wanted, let's mark it up:
> 
> <feed>
>    <defaults>
>      <author name="person A">
>       ...
>    </defaults>
>    <entry />
>    <entry />
>    ...
>   </author>

Is it your preference for a "defaulting" model rather than an
"explicit reference" model?

Just want to make sure.

  -- Ken



From owner-atom-syntax@mail.imc.org  Mon Jul 12 11: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 LAA18935
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 11:49: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 i6CFZN9g033815;
	Mon, 12 Jul 2004 08:35: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 i6CFZNKV033814;
	Mon, 12 Jul 2004 08:35:23 -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 i6CFZNoR033800
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 08:35:23 -0700 (PDT)
	(envelope-from antone@geckotribe.com)
Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134])
          by comcast.net (rwcrmhc12) with SMTP
          id <2004071215352001400lp11fe>; Mon, 12 Jul 2004 15:35:20 +0000
Date: Mon, 12 Jul 2004 09:35:19 -0600
Subject: Re: MUST be UTC?
Content-Type: text/plain; delsp=yes; 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: <40F16B51.3000602@intertwingly.net>
Message-Id: <14B72756-D419-11D8-9D0B-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 Sunday, July 11, 2004, at 10:31  AM, Sam Ruby wrote:
> We need to better define what we expect people who "work with" these  
> dates can expect.  I explored this in
>
> http://www.intertwingly.net/blog/2003/07/01/Subjective-and-objective- 
> dates
...
> There is no question in my mind that <modified> dates should be  
> strictly ordered, so either an indication of timezone or  
> canonicalization to UTC would be required.  Doing so would allow  
> aggregator authors to order entries across all weblogs, if they chose  
> to do so.
>
> What Bloggers calls Post Date and Time [1], and what LiveJournal  
> simply calls Date and Local Time of an entry is different.   
> Qualitatively different.  It is subjective.  It's primary purpose is  
> for display.  For human consumption.
...
> The most you can assume about this particular date is that it is the  
> date that the author wants associated with the entry, nothing more,  
> nothing less.
...
> One date is objective, intended to be processed by cold hard machines.  
> One date is subjective, intended to be processed by warm squishy  
> humans.

On Sunday, July 11, 2004, at 10:46  PM, Graham wrote:
> A major change should result in a new atom:issued

Okay, here's an attempt at a methodical approach to defining what date  
elements we need and what the requirements and recommendations should  
be for each.

Dates (where "date" = "date and time") that might be associated with an  
entry:

1) objective creation date
2) each objective major modification date
3) each objective minor modification date
4) each objective publication date
5) any subjective creation date the author may wish to associate with  
the entry
6) any subjective major modification date the author may wish to  
associate with the entry
7) any subjective minor modification date the author may wish to  
associate with the entry
8) any subjective publication date the author may wish to associate  
with the entry

Questions:
A) Which of these should appear in the feed?
B) Which of these can be consolidated into a single element in a feed?
C) What timezone requirements/recommendations should each carry?

Interested parties:
I) Author: Most interested in 8. Prefers their local timezone.
II) Publishing client software: Just an intermediary--probably doesn't  
care about anything.
III) Publishing server software: Most interested in 2-4, possibly  
including all iterations. No strong timezone preference.
IV) Aggregators: Most interested in 2-4, perhaps including only the  
first, last, or first and last of each. Perfers UTC.
V) Feed reader software: Most interested in 2-3 for ordering and  
determining whether to call something "new" or "updated". No strong  
timezone preference.
VI) Human reader: Most interested in the last of each in 2-3 and one of  
4 or 8 (depends on the person)--possibly also interested in the first  
of 4 or 8--and may wish the timezone to be either the author's local  
timezone or their own local timezone.

Comments (correct me if I'm wrong or you disagree--these are my  
perceptions and opinions):
i) The publishing software can store the dates in whatever timezone  
they want. They can present it to the author in the author's local  
timezone, and can publish it as best benefits everyone else.
ii) Nobody really cares about 5-7.
iii) Nobody reading the feed really cares about 1, so including it in  
the feed should be optional. I suppose there may be uses for it, but I  
wouldn't complain if it weren't even supported.
iv) Nobody reading the feed cares much about anything that occurred  
before the first 4.

Conclusions:
a) 2-4 and 8 are the only dates that may need to be in the feed.
b) At most the first and last of each should appear in the feed.
c) Only 8 should be allowed to omit the timezone.
d) 2 could be used instead of 4 in the feed.

Proposed Date Constructs:

atom:first-issued or atom:first-published (first 4)
	An objective publication date. REQUIRED. MUST specify a timezone  
(which might be -00:00 if the timezone is unknown) which MUST be  
numeric.

atom:issued or atom:published (last 8)
	A subjective publication date. OPTIONAL. It is RECOMMENDED that it  
include a timezone, that the timezone be numeric, and that it be the  
author's timezone, or the timezone relevant to the content of the entry  
(for example, if I, in Utah, am writing about something that happened  
in Iraq, I might use Iraq's timezone).

atom:modified (last 2)
	The objective date when the last major change--a change which alters  
or non-trivially expands the message--was made to the entry. REQUIRED  
if different from atom:first-issued|published. It MUST specify a  
timezone (which might be -00:00 if the timezone is unknown), which MUST  
be UTC.

atom:updated (last 3)
	The objective date when the last minor change--for example a spelling  
correction, clarification which doesn't expand the message, etc.--was  
made to the entry. RECOMMENDED if different from  
atom:first-issued|published and later than atom:modified. MUST NOT be  
included if earlier than atom:modified. MUST specify a timezone (which  
might be -00:00 if the timezone is unknown), which MUST be UTC.

I would also propose that the spec text for each Date Construct, or  
some text appearing before the list of Date Constructs, point out that  
the requirements for each are different because some are intended to  
use by software and others for presentation to humans.

The "objective" dates should have spec text to point out that these  
dates MUST NOT be modified except to correct for errors in the actual  
timestamp (for example, if the computers clock was incorrect).

Note that the dates that are required to be specified in UTC may be  
converted by client software to the timezone indicated in  
atom:issued|published if it appears in the feed. All dates may also be  
converted to the user's local timezone.



From owner-atom-syntax@mail.imc.org  Mon Jul 12 11:51:31 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19048
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 11:51:30 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CFelSU034150;
	Mon, 12 Jul 2004 08:40: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 i6CFelj7034149;
	Mon, 12 Jul 2004 08:40:47 -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 i6CFehA5034138
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 08:40:46 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 70263 messnum 9193090 invoked from network[83.70.39.115/83-70-39-115.bas2.prp.dublin.eircom.net]); 12 Jul 2004 15:40:41 -0000
Received: from 83-70-39-115.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.39.115)
  by mail10.svc.cra.dublin.eircom.net (qp 70263) with SMTP; 12 Jul 2004 15:40:41 -0000
Message-ID: <40F2B0F1.3000803@dehora.net>
Date: Mon, 12 Jul 2004 16:40:33 +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: danny666@virgilio.it
CC: Tim Bray <Tim.Bray@Sun.COM>, Atom Syntax <atom-syntax@imc.org>
Subject: Re: Craeted proposal: PaceProvideSchema
References: <20040711002331.70993.qmail@web41208.mail.yahoo.com> <53518515-D2E7-11D8-9DBF-000A95A51C9E@sun.com> <40F24F35.8040801@virgilio.it>
In-Reply-To: <40F24F35.8040801@virgilio.it>
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:

> I'm not sure of the IETF way of doing the documentation - are there any 
> conventions for informative references?

I suspect the way to do this would be to invert dependencies. 
Publish an Atom/OWL RFC referring to an Atom RFC, not the other way 
around.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Mon Jul 12 11:51:36 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19066
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 11:51:35 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CFOqpT032977;
	Mon, 12 Jul 2004 08: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 i6CFOq3u032976;
	Mon, 12 Jul 2004 08:24:52 -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 i6CFOp7Y032958
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 08:24:52 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 97397 messnum 9200382 invoked from network[83.70.39.115/83-70-39-115.bas2.prp.dublin.eircom.net]); 12 Jul 2004 15:24:48 -0000
Received: from 83-70-39-115.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.39.115)
  by mail10.svc.cra.dublin.eircom.net (qp 97397) with SMTP; 12 Jul 2004 15:24:48 -0000
Message-ID: <40F2AD38.3040000@dehora.net>
Date: Mon, 12 Jul 2004 16:24:40 +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: Tim Bray <Tim.Bray@Sun.COM>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceElementOrder: options
References: <97774BF0-D096-11D8-B2D0-000A95A51C9E@sun.com> <F3C7FAC8-D233-11D8-9A61-000A95BD86C0@mnot.net> <87smc0ownv.fsf@nwalsh.com> <F1AC0C56-D2AB-11D8-B2D0-000A95A51C9E@sun.com>
In-Reply-To: <F1AC0C56-D2AB-11D8-B2D0-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:
> 
> So, it seems like we have the following options on this:
> 
> 1. Do nothing, no rules about ordering
> 2. Require all the feed-level elements appear before the <atom:entry> 
> elements
> 3. #2, but have an <atom:feed-info> to contain all that stuff.  Thus the
>    content-model of <atom:feed> becomes
>    atom:feed-info, atom:entry+
> 4. Require a specific ordering for all the elements.
> 
> Until #3 came along, I'd have said that the general leaning was to #2; 
> there was no support voiced for #1 and not much for #4.  Now would be a 
> good time to prove me wrong by speaking up for #1 or #4, or point out 
> why one of #2 or #3 is better than the other.  -Tim

As the Pace author, 2 captures my intent. Here's what I was after

  1. I don't care how anyone orders or sorts entry elements. That 
seems to be the /intent/ of the wording I wanted to change. 
Unfortunately the wording is not limited to just that intent.

  2. I care that we do not have non-entry elements and entry 
elements interpolated. They are written in the document in a 
particular order; Atom markup should respect that order. There is no 
requirement for it to do so.

I can't get past the notion that having all the feed metadata and 
entries at the same level is poor design. That is, mixing of 
individual and repeating elements at the same level while explicitly 
allowing arbitrary ordering is poor design.

3 is interesting - imho RSS1.0 via its channel element gets this 
right; we don't.

cheers
Bill




From owner-atom-syntax@mail.imc.org  Mon Jul 12 11: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 LAA19523
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 11:55: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 i6CFaPt2033890;
	Mon, 12 Jul 2004 08:36: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 i6CFaP4a033889;
	Mon, 12 Jul 2004 08:36:25 -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 i6CFa8YI033862
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 08:36:24 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 77215 messnum 368363 invoked from network[83.70.39.115/83-70-39-115.bas2.prp.dublin.eircom.net]); 12 Jul 2004 15:36:05 -0000
Received: from 83-70-39-115.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.39.115)
  by mail05.svc.cra.dublin.eircom.net (qp 77215) with SMTP; 12 Jul 2004 15:36:05 -0000
Message-ID: <40F2AFDD.9040302@dehora.net>
Date: Mon, 12 Jul 2004 16:35:57 +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: Tim Bray <Tim.Bray@Sun.COM>, Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceElementOrder: options
References: <97774BF0-D096-11D8-B2D0-000A95A51C9E@sun.com> <F3C7FAC8-D233-11D8-9A61-000A95BD86C0@mnot.net> <87smc0ownv.fsf@nwalsh.com> <F1AC0C56-D2AB-11D8-B2D0-000A95A51C9E@sun.com> <40F074E7.9040502@virgilio.it>
In-Reply-To: <40F074E7.9040502@virgilio.it>
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:

> 
> Some questions, starting with the biggy:
> 
> Why order the elements?

XML. Schemata. Clarity, Robustness.

But really we should be asking why are we specifying disorder.


> Would an order make any significant difference to an application?

Again, I would instead ask what the value of no order is.


> How useful is it to have feed-level metadata up front? Are incomplete 
> parsing/readings likely?

I've always found this a strawman, but yes, they are.


> Would it make any significant difference to the XML processor?

That depends on the processor.


> If not, in what respect is the format underconstrained? 

The intent of the wording *seems to be* and all discussion here 
about ordering prior to that Pace *was* that the spec is not going 
to tell you how to order entries - there shall be no mandated 
natural order entries. But the wording spills over to cover all 
immediate children atom:feed. Thus I claim the spec wording is 
underconstrained.


> If there is to be a specific ordering, what should it be?

As we're not going to have normative schema, then it should be the 
order written out in the spec. That is if atom:author comes after 
atom:entry in the spec then atom:author comes after *every* 
atom:entry in every instance of valid Atom markup.

Seriously, if we're going to allow free for all ordering of elements 
Atom, XML syntax becomes something a non-requirement. We should be 
using Python dicts or something that better reflects the needs of 
the spec.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Mon Jul 12 12:01:31 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19957
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 12:01: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 i6CFmHHC034528;
	Mon, 12 Jul 2004 08:48: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 i6CFmH49034527;
	Mon, 12 Jul 2004 08:48:17 -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 i6CFmGrv034513
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 08:48:16 -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 i6CFmD53011925
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 10:48:13 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6CFmD4r011921;
	Mon, 12 Jul 2004 10:48:13 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Disambiguating the subject of feed-level metadata
References: <97774BF0-D096-11D8-B2D0-000A95A51C9E@sun.com>
	<F3C7FAC8-D233-11D8-9A61-000A95BD86C0@mnot.net>
	<87smc0ownv.fsf@nwalsh.com>
	<F1AC0C56-D2AB-11D8-B2D0-000A95A51C9E@sun.com>
	<F47D290F-D2BB-11D8-9A61-000A95BD86C0@mnot.net>
	<7DEA0B24-D2ED-11D8-ACB6-000A95DC3D90@mac.com>
	<m3658up4pk.fsf@bitsko.slc.ut.us> <87vfgth2yr.fsf@nwalsh.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 12 Jul 2004 10:48:13 -0500
In-Reply-To: <87vfgth2yr.fsf@nwalsh.com>
Message-ID: <m3k6x9ns5e.fsf@bitsko.slc.ut.us>
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


Norman Walsh <ndw@nwalsh.com> writes:

> The question here though is, what are the real benefits of these
> references. Wouldn't this be better still for achieving independence
> of entries?

The benefits of using references is misunderstood when communicative
shorthands are used in examples.  This isn't so much about
establishing referential identity as it is about redundancy.

Here's a less-shorthanded version of the example:

<feed>
  <entry>
    <site>
      <title>Kitty Adventures.</title>
      <link rel="alternate" type="text/html" href="http://example.com/kitties/"/>
    </site>

    <author>
      <name>Kitty Owner</name>
    </author>
      ...
  </entry>
  <entry>
    <site>
      <title>Kitty Adventures.</title>
      <link rel="alternate" type="text/html" href="http://example.com/kitties/"/>
      <author ref="tag:example.com,2004:authors/kitty"/>
    </site>

    <author>
      <name>Kitty Owner</name>
    </author>
    <contributor>
      <name>Best Friend</name>
    </contributor>
    ...
  </entry>
</feed>

I see the primary solution for "solving" the "physical feed
defaulting/inheritance" issue as having entries be as independent as
possible.  The above example most definitely achieves that, but at a
cost of significant redundancy.  A secondary solution of references is
therefore proposed to address the newly created redundancy issue.

  -- Ken



From owner-atom-syntax@mail.imc.org  Mon Jul 12 12: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 MAA20161
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 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 i6CFpMBQ034709;
	Mon, 12 Jul 2004 08:51: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 i6CFpMZJ034708;
	Mon, 12 Jul 2004 08:51:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CFpLun034699
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 08:51:21 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from phys-bur-1 ([129.148.9.72])
	by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i6CFpH0R006868
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 08:51: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 <0I0Q00401X9PZJ@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com)
 for atom-syntax@imc.org; Mon, 12 Jul 2004 11:51:17 -0400 (EDT)
Received: from mercury (vpn-129-159-0-65.EMEA.Sun.COM [129.159.0.65])
 by bur-mail1.east.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
 with ESMTP id <0I0Q006IWXD87D@bur-mail1.east.sun.com> for atom-syntax@imc.org;
 Mon, 12 Jul 2004 11:51:13 -0400 (EDT)
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1Bk33p-0005BM-00	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 11:49:45 -0400
X-URL: http://nwalsh.com/
Date: Mon, 12 Jul 2004 11:49:42 -0400
From: Norman Walsh <ndw@nwalsh.com>
Subject: Re: PaceElementOrder
In-reply-to: <40F2A95E.3090607@dehora.net>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <87oeml5ip5.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: <97774BF0-D096-11D8-B2D0-000A95A51C9E@sun.com>
 <F3C7FAC8-D233-11D8-9A61-000A95BD86C0@mnot.net> <87smc0ownv.fsf@nwalsh.com>
 <40F2A95E.3090607@dehora.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-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

/ Bill de h=D3ra <bill@dehora.net> was heard to say:
| Norman Walsh wrote:
|
|> If we want to make a distinction between atom:entry children and other
|> children, I suggest that we put the other children in a wrapper.
|>   <atom:feed>
|>     <atom:feedinfo>
|>       <atom:title>...</atom:title>
|>     </atom:feedinfo>
|>     <atom:entry>...</atom:entry>
|>   </atom:feed>
|
| No, the issue I had in mind when I wrote that Pace remains:
|
|    <atom:feed>
|      <atom:entry>...</atom:entry>
|      <atom:feedinfo>
|        <atom:title>...</atom:title>
|      </atom:feedinfo>
|      <atom:entry>...</atom:entry>
|    </atom:feed>

Sorry. Having put all the metadata into feedinfo, I imagined that we would
also require feedinfo to be first.

  atom:feed =3D atom:feedinfo, (atom:entry|anyExtensionElement)*

                                        Be seeing you,
                                          norm

=2D-=20
Norman Walsh <ndw@nwalsh.com> | Simplicity is always a virtue.--Edward
http://nwalsh.com/            | Abbey

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA8rMYOyltUcwYWjsRAu1pAJoDTi6qsH6r4QntWL+aqB8by5RfbgCgiK29
SQuhOs0fSuOV0N9OHXPhpik=
=Mtpa
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Mon Jul 12 12: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 MAA20271
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 12: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 i6CFsEq8034972;
	Mon, 12 Jul 2004 08: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 i6CFsENS034971;
	Mon, 12 Jul 2004 08:54:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail09.svc.cra.dublin.eircom.net (mail09.svc.cra.dublin.eircom.net [159.134.118.25])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6CFsDk7034963
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 08:54:13 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 54043 messnum 242993 invoked from network[83.70.39.115/83-70-39-115.bas2.prp.dublin.eircom.net]); 12 Jul 2004 15:54:10 -0000
Received: from 83-70-39-115.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.39.115)
  by mail09.svc.cra.dublin.eircom.net (qp 54043) with SMTP; 12 Jul 2004 15:54:10 -0000
Message-ID: <40F2B41A.9090103@dehora.net>
Date: Mon, 12 Jul 2004 16:54:02 +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: Ken MacLeod <ken@bitsko.slc.ut.us>
CC: Atom-Syntax Syntax <atom-syntax@imc.org>
Subject: Re: Disambiguating the subject of feed-level metadata
References: <97774BF0-D096-11D8-B2D0-000A95A51C9E@sun.com>	<F3C7FAC8-D233-11D8-9A61-000A95BD86C0@mnot.net>	<87smc0ownv.fsf@nwalsh.com>	<F1AC0C56-D2AB-11D8-B2D0-000A95A51C9E@sun.com>	<F47D290F-D2BB-11D8-9A61-000A95BD86C0@mnot.net>	<7DEA0B24-D2ED-11D8-ACB6-000A95DC3D90@mac.com>	<40F2A4E9.3050007@dehora.net> <m3oemlnsqh.fsf@bitsko.slc.ut.us>
In-Reply-To: <m3oemlnsqh.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: <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


Ken MacLeod wrote:


> Is it your preference for a "defaulting" model rather than an
> "explicit reference" model?
> 
> Just want to make sure.
> 
>   -- Ken

Ken,


Explicit reference (ie "let's be clear about what we're doing 
here...").

I'm agreeing with you so far on the need for defaulting (we don't).

cheers
Bill



From owner-atom-syntax@mail.imc.org  Mon Jul 12 12:12: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 MAA20527
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 12:12: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 i6CFxFul035461;
	Mon, 12 Jul 2004 08: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 i6CFxFE7035460;
	Mon, 12 Jul 2004 08:59:15 -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 i6CFx88O035450
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 08:59:15 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 27462 messnum 6480249 invoked from network[83.70.39.115/83-70-39-115.bas2.prp.dublin.eircom.net]); 12 Jul 2004 15:59:05 -0000
Received: from 83-70-39-115.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.39.115)
  by mail12.svc.cra.dublin.eircom.net (qp 27462) with SMTP; 12 Jul 2004 15:59:05 -0000
Message-ID: <40F2B541.6050402@dehora.net>
Date: Mon, 12 Jul 2004 16:58:57 +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: Norman Walsh <ndw@nwalsh.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceElementOrder
References: <97774BF0-D096-11D8-B2D0-000A95A51C9E@sun.com> <F3C7FAC8-D233-11D8-9A61-000A95BD86C0@mnot.net> <87smc0ownv.fsf@nwalsh.com> <40F2A95E.3090607@dehora.net> <87oeml5ip5.fsf@nwalsh.com>
In-Reply-To: <87oeml5ip5.fsf@nwalsh.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


Norman Walsh wrote:

> Sorry. Having put all the metadata into feedinfo, I imagined that we would
> also require feedinfo to be first.
> 
>   atom:feed = atom:feedinfo, (atom:entry|anyExtensionElement)*

That's the point. Even if you put all feed metadata into a feedinfo 
block, you still need to alter the wording in question to specify 
said block can't appear just anywhere (it can at the moment).

cheers
Bill



From owner-atom-syntax@mail.imc.org  Mon Jul 12 12: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 MAA21016
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 12:19:35 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CFoklb034672;
	Mon, 12 Jul 2004 08:50: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 i6CFok3e034671;
	Mon, 12 Jul 2004 08:50:46 -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 i6CFojXi034664
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 08:50:45 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 37281 messnum 226588 invoked from network[83.70.39.115/83-70-39-115.bas2.prp.dublin.eircom.net]); 12 Jul 2004 15:50:41 -0000
Received: from 83-70-39-115.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.39.115)
  by mail09.svc.cra.dublin.eircom.net (qp 37281) with SMTP; 12 Jul 2004 15:50:41 -0000
Message-ID: <40F2B348.6080908@dehora.net>
Date: Mon, 12 Jul 2004 16:50: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 <atom-syntax@imc.org>
Subject: Re: XML Schema and PaceElementOrder
References: <97774BF0-D096-11D8-B2D0-000A95A51C9E@sun.com> <F3C7FAC8-D233-11D8-9A61-000A95BD86C0@mnot.net> <63690128-D237-11D8-B2D0-000A95A51C9E@sun.com> <98FB4CE4-D237-11D8-9A61-000A95BD86C0@mnot.net> <40F011AE.1090502@virgilio.it> <40F29686.10906@virgilio.it> <3f1451f504071207447ae9f08f@mail.gmail.com>
In-Reply-To: <3f1451f504071207447ae9f08f@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


Joe Gregorio wrote:


> Let's not twist ourselves in knots
> to accomdate the shortcomings of XSD.

It's not an XSD issue. It's an XML issue. In my mind anyway.

cheers
Bill




From owner-atom-syntax@mail.imc.org  Mon Jul 12 12:23: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 MAA21295
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 12:23: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 i6CG4Ulj035900;
	Mon, 12 Jul 2004 09:04: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 i6CG4UCs035899;
	Mon, 12 Jul 2004 09:04: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 i6CG4T0q035889
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 09:04:29 -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 i6CG4Q53012173
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 11:04:27 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6CG4QfK012169;
	Mon, 12 Jul 2004 11:04:26 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Q: modfied vs issued vs created
References: <BD187FBE.1F041%eric.scheid@ironclad.net.au>
	<m3smbxny87.fsf@bitsko.slc.ut.us>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 12 Jul 2004 11:04:26 -0500
In-Reply-To: <m3smbxny87.fsf@bitsko.slc.ut.us>
Message-ID: <m3fz7xnred.fsf@bitsko.slc.ut.us>
Lines: 22
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


Ken MacLeod <ken@bitsko.slc.ut.us> writes:

> I would favor an "editing" extension (mod_editing) that provided
> terms for the purpose of indicating "meaningful change", because the
> likelyhood of someone adopting and using mod_editing significantly
> increases the likelyhood that they have a "publishing process"
> (note, not "system") that includes enough discipline to properly
> indicate meaningful change.  That's something clients can depend on.

Another possible solution is a "date discipline" profile indicator.
Atom core would define the dates using the precisely imprecise Dublin
Core definitions, and a "date discipline" profile would indicate a
site's self-certification of conformance to a stricter profile.

<entry>
  <profile:date-discipline xmlns:profile="http://purl.org/atom/profile/date#"/>
  <title>Created will be present and will not change, etc.</title>
  <created>2004-03-11T12:13:14Z</created>
  ...
</entry>

  -- Ken



From owner-atom-syntax@mail.imc.org  Mon Jul 12 12:30: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 MAA21676
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 12:30: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 i6CGIJW7036922;
	Mon, 12 Jul 2004 09:18: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 i6CGIJIG036921;
	Mon, 12 Jul 2004 09:18:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CGICXO036911;
	Mon, 12 Jul 2004 09:18:13 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p06110430bd1869a39775@[10.20.30.249]>
In-Reply-To: <40F24F35.8040801@virgilio.it>
References: <20040711002331.70993.qmail@web41208.mail.yahoo.com>
 <53518515-D2E7-11D8-9DBF-000A95A51C9E@sun.com>
 <40F24F35.8040801@virgilio.it>
Date: Mon, 12 Jul 2004 09:18:36 -0700
To: danny666@virgilio.it, Tim Bray <Tim.Bray@Sun.COM>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: Craeted proposal: PaceProvideSchema
Cc: Atom Syntax <atom-syntax@imc.org>
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 10:43 AM +0200 7/12/04, Danny Ayers wrote:
>I'm not sure of the IETF way of doing the documentation - are there 
>any conventions for informative references?

Absolutely. In fact, they're required. The "References" section of an 
Internet Draft splits the references into "Normative" and 
"Non-normative". The latter is often called "informative".

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Mon Jul 12 12: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 MAA21728
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 12:31: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 i6CGHoKG036866;
	Mon, 12 Jul 2004 09:17: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 i6CGHoL3036865;
	Mon, 12 Jul 2004 09:17:50 -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 i6CGHnV3036842
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 09:17:49 -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 i6CGHp4Q025362;
	Mon, 12 Jul 2004 09:17:51 -0700
Received: from ussjex01.amer.bea.com ([172.16.120.50]) by ussjfe01.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 12 Jul 2004 09:17:50 -0700
x-mimeole: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Version vs. Namespace
Date: Mon, 12 Jul 2004 09:17:50 -0700
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF08C9B872@ussjex01.amer.bea.com>
Thread-Topic: Version vs. Namespace
Thread-Index: AcRnzrrgwYJ6zcSDRMWLCF2LjMDlLwAW8hZQ
From: "David Orchard" <dorchard@bea.com>
To: "Tim Bray" <Tim.Bray@Sun.COM>, "Atom Syntax" <atom-syntax@imc.org>
X-OriginalArrivalTime: 12 Jul 2004 16:17:50.0374 (UTC) FILETIME=[C6F05C60:01C4682B]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6CGHoV3036860
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


What kind of an answer is this? "No, it's hard?" 

Who said anything about Atom solving the versioning problem in the general case?  And btw, what ARE the versioning use cases of Atom?  I've started writing up some work on Atom extensibility/versioning, but it's become a bit hard because it seems like everything could be extended/versioned...

Tim, you should know as well as anybody, that the problems of figuring out what a "version" of a mixed namespace document is can rarely be done with a single integer.  What does a "version" mean under distributed and multi-ns extensibility?

While Mark's proposal of a profile might appear to be complicated, it ought to get a bit more air time and explanation than the very next message saying "no", especially with discussion of concrete use cases/scenarios.

Cheers,
Dave 

> -----Original Message-----
> From: owner-atom-syntax@mail.imc.org
> [mailto:owner-atom-syntax@mail.imc.org]On Behalf Of Tim Bray
> Sent: Sunday, July 11, 2004 10:11 PM
> To: Atom Syntax
> Subject: Re: Version vs. Namespace
> 
> 
> 
> On Jul 11, 2004, at 5:43 PM, Mark Nottingham wrote:
> 
> > In other words, I'm proposing that we refine our approach to 
> > versioning to three separate things:
> 
> I'm massively unconvinced that this added complexity has noticeable 
> benefit.  I want to see a single namespace that means "this is Atom", 
> and I don't expect the semantics of atom:title to change for a long 
> time so I don't think its name should change, and I do want a 
> root-level "version" attribute.  Going down the path of solving the 
> versioning problem in the general case reliably leads to convulsions 
> and hairy palms.  Let's do the simplest thing that could 
> possibly work: 
> a fixed namespace and a root version attribute. -Tim
> 
> 



From owner-atom-syntax@mail.imc.org  Mon Jul 12 12: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 MAA22087
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 12:36: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 i6CGPYWY037603;
	Mon, 12 Jul 2004 09: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 i6CGPYTe037602;
	Mon, 12 Jul 2004 09:25:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CGPXBH037573;
	Mon, 12 Jul 2004 09:25:33 -0700 (PDT)
	(envelope-from jasnell@us.ibm.com)
Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32])
	by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i6CGPV10486374;
	Mon, 12 Jul 2004 12:25:31 -0400
Received: from d03nm122.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170])
	by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6CGPU33153826;
	Mon, 12 Jul 2004 10:25:30 -0600
In-Reply-To: <69D21DD5-D3BA-11D8-9A61-000A95BD86C0@mnot.net>
To: Mark Nottingham <mnot@mnot.net>
Cc: Atom Syntax <atom-syntax@imc.org>, Norman Walsh <ndw@nwalsh.com>,
        owner-atom-syntax@mail.imc.org
MIME-Version: 1.0
Subject: Re: Created proposal: PaceProvideSchema
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
From: James M Snell <jasnell@us.ibm.com>
X-MIMETrack: S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 09:24:39 AM,
	Serialize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 09:24:39 AM,
	Serialize complete at 07/12/2004 09:24:39 AM,
	Itemize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 09:24:39 AM,
	S/MIME Sign complete at 07/12/2004 09:24:39 AM,
	S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 09:25:23 AM,
	S/MIME Sign complete at 07/12/2004 09:25:23 AM,
	Serialize by Router on D03NM122/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at
 07/12/2004 10:25:30,
	Serialize complete at 07/12/2004 10:25:30
Message-ID: <OFD3493D83.80E63F0A-ON88256ECF.005A19AF-88256ECF.005A36FB@us.ibm.com>
Date: Mon, 12 Jul 2004 10:25:24 -0600
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z22869_boundary_sign
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>


This is an S/MIME signed message.

---------z22869_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 005A25C388256ECF_="

This is a multipart message in MIME format.
--=_alternative 005A25C388256ECF_=
Content-Type: text/plain; charset="US-ASCII"

:-) No problem there.  +1 on NOT requiring the XSD Schema to be normative.

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



Mark Nottingham <mnot@mnot.net> 
Sent by: owner-atom-syntax@mail.imc.org
07/11/2004 09:17 PM

To
James M Snell/Fresno/IBM@IBMUS
cc
Atom Syntax <atom-syntax@imc.org>, owner-atom-syntax@mail.imc.org, Norman 
Walsh <ndw@nwalsh.com>
Subject
Re: Created proposal: PaceProvideSchema







To be clear -

I have no problem with providing an XML Schema; it is a genuinely 
useful thing to provide for some people. In fact, I'd be disappointed 
if we didn't provide one.

However, it shouldn't be normative, for reasons described before, and 
the design of Atom shouldn't be subjugated by the needs of Schema; if 
there's contention between real-world requirements and the contortions 
that Schema makes you go through, Schema should lose (i.e., the schema 
should be less expressive).

That's what I meant by +1'ing "not using XML Schema" -- apologies if 
that wasn't clear.

Cheers,


On Jul 11, 2004, at 8:56 PM, James M Snell wrote:

> -1 on this.  Those of us who care about XML Schema should provide an 
> XML Schema... not for normative purposes, however.  Those who care 
> about Relax should provide a Relax thing.  Let's not rule such things 
> out simply because of our personal feelings about various technologies 
> or the companies who promote them.  There are sound technical reasons 
> why some folks may want an XSD.  I am not saying it should be codified 
> as part of the Atom specification, but something could and should be 
> made available.



--
Mark Nottingham     http://www.mnot.net/




--=_alternative 005A25C388256ECF_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">:-) No problem there. &nbsp;+1 on NOT
requiring the XSD Schema to be normative.</font>
<br>
<br><font size=2 face="sans-serif">- James M Snell<br>
 &nbsp;jasnell@us.ibm.com<br>
 &nbsp;http://www.ibm.com<br>
 &nbsp;(877) 511-5082 / Office<br>
 &nbsp;930-1979 / Tie Line</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Mark Nottingham &lt;mnot@mnot.net&gt;</b>
</font>
<br><font size=1 face="sans-serif">Sent by: owner-atom-syntax@mail.imc.org</font>
<p><font size=1 face="sans-serif">07/11/2004 09:17 PM</font>
<td width=59%>
<table width=100%>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td valign=top><font size=1 face="sans-serif">James M Snell/Fresno/IBM@IBMUS</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td valign=top><font size=1 face="sans-serif">Atom Syntax &lt;atom-syntax@imc.org&gt;,
owner-atom-syntax@mail.imc.org, Norman Walsh &lt;ndw@nwalsh.com&gt;</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td valign=top><font size=1 face="sans-serif">Re: Created proposal: PaceProvideSchema</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2><tt><br>
To be clear -<br>
<br>
I have no problem with providing an XML Schema; it is a genuinely <br>
useful thing to provide for some people. In fact, I'd be disappointed <br>
if we didn't provide one.<br>
<br>
However, it shouldn't be normative, for reasons described before, and <br>
the design of Atom shouldn't be subjugated by the needs of Schema; if <br>
there's contention between real-world requirements and the contortions
<br>
that Schema makes you go through, Schema should lose (i.e., the schema
<br>
should be less expressive).<br>
<br>
That's what I meant by +1'ing &quot;not using XML Schema&quot; -- apologies
if <br>
that wasn't clear.<br>
<br>
Cheers,<br>
<br>
<br>
On Jul 11, 2004, at 8:56 PM, James M Snell wrote:<br>
<br>
&gt; -1 on this. &nbsp;Those of us who care about XML Schema should provide
an <br>
&gt; XML Schema... not for normative purposes, however. &nbsp;Those who
care <br>
&gt; about Relax should provide a Relax thing. &nbsp;Let's not rule such
things <br>
&gt; out simply because of our personal feelings about various technologies
<br>
&gt; or the companies who promote them. &nbsp;There are sound technical
reasons <br>
&gt; why some folks may want an XSD. &nbsp;I am not saying it should be
codified <br>
&gt; as part of the Atom specification, but something could and should
be <br>
&gt; made available.<br>
<br>
<br>
<br>
--<br>
Mark Nottingham &nbsp; &nbsp; http://www.mnot.net/<br>
<br>
<br>
</tt></font>
<br>
--=_alternative 005A25C388256ECF_=--

---------z22869_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIIUOAIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIISWDCCAtow
ggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1
aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAy
MDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA629xc49NpAPz
cAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7glzJKgPkPzlTZZfznznGbmAWVnNBQ
lyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnwNclOnnP2sKufuPzbTImQTTi5c8JZNZcM
J0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEEBAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1Ud
DgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAPBgNVHRMBAf8EBTADAQH/MDEGA1UdJQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUH
AwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvu
jQupk2oCScMd3FIHLE7hOfu8YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14ke
McF9ViNdewEoBGiAycUq8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIC2jCCAkOgAwIB
AgIDAxS2MA0GCSqGSIb3DQEBBAUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwMTE0MjIw
NzExWhcNMTExMjMxMjIwNzExWjBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25h
bCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrb3Fzj02kA/NwCy5KFMiY
tFgyTJ6kMSQLVSs9uwVHIAVkqy/enDQwZ9b/7uCXMkqA+Q/OVNll/OfOcZuYBZWc0FCXI9qw60KO
J/rTd65FdF4dwp8cw8si0qjOJtYg8cm46fA1yU6ec/awq5+4/NtMiZBNOLlzwlk1lwwnRgXNNwID
AQABo4GqMIGnMBEGCWCGSAGG+EIBAQQEAwIAhzAOBgNVHQ8BAf8EBAMCAcYwHQYDVR0OBBYEFK5U
DpLqqDOpKyQtx8hvMNze80pAMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMA8GA1Ud
EwEB/wQFMAMBAf8wMQYDVR0lBCowKAYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYB
BQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAMnJ7c2YLyrY/PKlFl+7sm8NENfWtFxqdm+6NC6mTagJJ
wx3cUgcsTuE5+7xh9+/G0tTfLzA1qZAQ5GNMPXvmoB9+vJfKnC2JWMFQpIOUEJDXiR4xwX1WI117
ASgEaIDJxSrxHcuuV/hMIO9bgZ6C41MUVmdLTKBgBOImTuIPK8QwggMgMIICiaADAgECAgQ13vTP
MA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQL
EyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0MTUxWhcN
MTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMk
RXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKKlQRkrPFr
U18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkwrFEeO68r
1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOgYaRfMF0x
CzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBD
ZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAxODA4MjIx
NjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAdBgNV
HQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0HQQAEDTAL
GwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwlMQ0AppJu
f7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn00DbOyZY
sih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMgMIICiaADAgEC
AgQ13vTPMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0
MTUxWhcNMTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsG
A1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKK
lQRkrPFrU18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkw
rFEeO68r1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOg
YaRfMF0xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNl
Y3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAx
ODA4MjIxNjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAdBgNVHQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0H
QQAEDTALGwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwl
MQ0AppJuf7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn
00DbOyZYsih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMmMIIC
j6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIxNjM2NTRaMIGFMQsw
CQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEXMBUGA1UEAxMOSmFt
ZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkqhkiG9w0BCQEWEmph
c25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwKpbDG3zMatEuuOT
FYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSyd+7nwqAvbBfPj+0S
vcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7tBJlLrwDRCMoNlPuQ
Kg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQW
BBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOgFAwSamFzbmVs
bEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pAMCcGA1UdJQQgMB4G
CCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAZMKevB7dFfb9
23OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY8BjwVHxiYgG4xkxf
B1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOIzj3lz3xd+uOzqRFg
/Wsg/VMwggMmMIICj6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAy
BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNV
BAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIx
NjM2NTRaMIGFMQswCQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEX
MBUGA1UEAxMOSmFtZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkq
hkiG9w0BCQEWEmphc25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
wKpbDG3zMatEuuOTFYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSy
d+7nwqAvbBfPj+0SvcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7t
BJlLrwDRCMoNlPuQKg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQD
AgXgMB0GA1UdDgQWBBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcU
AgOgFAwSamFzbmVsbEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA
MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQAD
gYEAZMKevB7dFfb923OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY
8BjwVHxiYgG4xkxfB1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOI
zj3lz3xd+uOzqRFg/Wsg/VMxggG7MIIBtwIBATBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJ
bnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0g
Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwF+kzAJBgUrDgMCGgUAoIGiMBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDcxMjE2MjQzOVowIwYJKoZIhvcNAQkEMRYE
FFLl15ICJJuDThF6wSwVdnSQST+EMEMGCSqGSIb3DQEJDzE2MDQwBwYFKw4DAh0wDgYIKoZIhvcN
AwICAgCAMAoGCCqGSIb3DQMHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAJxWumeuu
QXPjK+Lh+WgssXCnRAfDX9dLJ2aggMlyGg0sge6PsHp0i5D4bcBKZ9hVgkbZzyootuUiiBexLOsU
3oXr2ONxmi7qC+a8TYZ7SSTFWTaq6ADHJ9TKFcfesXMRkvogi0uwMeGOgqr4P9nCcQ9Hgqv7tAo/
g/69Jqh8/FMAAAAA

---------z22869_boundary_sign--



From owner-atom-syntax@mail.imc.org  Mon Jul 12 12: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 MAA22266
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 12: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 i6CGUN6L038107;
	Mon, 12 Jul 2004 09:30: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 i6CGUNYm038106;
	Mon, 12 Jul 2004 09:30: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 i6CGUFo2038088
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 09:30:21 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 13 Jul 2004 02:35:21 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Tue, 13 Jul 2004 02:30:09 +1000
Subject: Re: Q: modfied vs issued vs created
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD18F9B1.1F11D%eric.scheid@ironclad.net.au>
In-Reply-To: <m3smbxny87.fsf@bitsko.slc.ut.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


On 12/7/04 11:36 PM, "Ken MacLeod" <ken@bitsko.slc.ut.us> wrote:
> Eric Scheid <eric.scheid@ironclad.net.au> writes:
> 
>> Atom does support minor/major changes: if the modified date changes,
>> but the issued date doesn't, then it's a minor change. If the
>> modified date changes, and the issued date does too, then it's a
>> major change. If the modified date doesn't change, but the issued
>> date does, then you can consider it assertively no changes (but no
>> longer old news).
> 
> This behavior is not described in the current spec or any proposals
> that I'm aware of.  Are you proposing this behavior?

Since the spec is silent w.r.t. interpreting various combinations of changes
in issued/modified, then yes, I am proposing this. Looks like I'm stuck with
being the one to write the pace.

> I'm -1 on any proposal for *core Atom* that seeks to propose
> information that indicates "meaningful change".
> 
> "Meaningful change" can only be interpreted by a human, and this
> particular informational indicator is one that requires a significant
> amount of discipline to achieve.

not to mention honesty and integrity. Anyhow, someone lacking in any of
those qualities could still push through a major change as a "minor change",
sneaking it under the radar. No system or process can stop that. Even the
Newspapers Of Record have a hard time guaranteeing that.

Bottom line - do we need a more complicated and more granular mechanism for
indicating change (assuming veracity)? I'd say no, not for _atom-core_. If
some environment needs more finesse, then they can use mod_editing or
similar. 

e.



From owner-atom-syntax@mail.imc.org  Mon Jul 12 12: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 MAA22337
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 12: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 i6CGQ2Bd037653;
	Mon, 12 Jul 2004 09: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 i6CGQ2Zl037652;
	Mon, 12 Jul 2004 09:26:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CGPodp037566
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 09:25:57 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 13 Jul 2004 02:30:30 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Tue, 13 Jul 2004 02:25:18 +1000
Subject: Re: Disambiguating the subject of feed-level metadata
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD18F88E.1F11B%eric.scheid@ironclad.net.au>
In-Reply-To: <m3k6x9ns5e.fsf@bitsko.slc.ut.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


On 13/7/04 1:48 AM, "Ken MacLeod" <ken@bitsko.slc.ut.us> wrote:

> I see the primary solution for "solving" the "physical feed
> defaulting/inheritance" issue as having entries be as independent as
> possible.  The above example most definitely achieves that, but at a
> cost of significant redundancy.  A secondary solution of references is
> therefore proposed to address the newly created redundancy issue.

your extended example has some confusing things in it. For example, where is
"tag:example.com,2004:authors/kitty" defined? It is referenced, but not
defined.

perhaps this:

<feed>
    <definitions>
        <channel id="tag:example.com,2004:channelOne">
            <title />
            <tagline />
            ...
        </channel>
        <person id="fred">
            ...
        </person>
    </definitions>
    <entries>
        <entry>
            <channel ref="tag:example.com,2004:channelOne" />
            <author ref="fred" />
            <contributor>
                ...
            </contributor>
        </entry>
        <entry />
        <entry />
        <entry />
        <entry />
        <entry />
     </entries>
</feed>

Here we can have a "site" [1] represented only once, and within a container
that allows "site" specific ns-extensions, and then repeatedly referenced by
multiple entries in a minimal manner. Ditto with persons and copyright and
whatever else comes to mind. We could also allow multiple different
definitions of the same type (eg. multiple "sites") ... which allows for
synthetic feeds nicely.

Note that it wouldn't be necessary to use the <definitions> mechanisms ... a
fully flattened feed could be published which contains no id/ref uses, just
massive redundancy (which gzip helps, a bit).

What's missing here though is the concept of who is producing/publishing
this [entire document]. That is, if pubsub was to publish a synthetic feed,
then we would see multiple <channel> elements defined and used, but we'd
still need one more to say "this is a pubsub feed, even though none of the
entries come from pubsub". We need another another container on peer with
<definitions> and <entries>. Maybe <publication> or <feed>??

e.

[1] "site" ???? some sites have multiple feeds. "channel" fits better.



From owner-atom-syntax@mail.imc.org  Mon Jul 12 12:39: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 MAA22375
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 12:39: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 i6CGTPVG038032;
	Mon, 12 Jul 2004 09:29: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 i6CGTPRc038031;
	Mon, 12 Jul 2004 09:29: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 i6CGTNPY038009
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 09:29:24 -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 4D6DC7C112; Mon, 12 Jul 2004 19:27:39 +0200 (CEST)
Date: Mon, 12 Jul 2004 18:32:57 +0200
To: "Mark Nottingham" <mnot@mnot.net>
Subject: Re: Proposal: PaceSyntaxGuidelines
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <opr99igudbuvpchu@quark> <9784AD46-D236-11D8-9A61-000A95BD86C0@mnot.net> <opsax10rxpuvpchu@quark> <C4EBE4F8-D2CA-11D8-9A61-000A95BD86C0@mnot.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: <opsa09k7bkuvpchu@quark>
In-Reply-To: <C4EBE4F8-D2CA-11D8-9A61-000A95BD86C0@mnot.net>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 10 Jul 2004 16:42:13 -0700, Mark Nottingham <mnot@mnot.net> wrote:

> Let me be clear. I'm not convinced that this is useful material to  
> include in the specification.

Ah, ok. Then let's see if that's the consensus, and if so, withdraw the  
proposal as it is, and repropose it as a non-normative appendix.

> Furthermore,  attempting to improve it to sufficient quality

Are you implying that the current quality sucks? ;)

> and I don't see how this information actually improves the
> specification, the quality of Atom extensions, or the
> interoperability of implementations.

This guideline only makes the current Atom format and its extensions more  
uniform and consistent, that's all.

> Does HTTP give style guides for naming new HTTP headers?

Unfortunately; no.

> HTML for extension attributes?

Unfortunately; 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  Mon Jul 12 12:40: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 MAA22408
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 12:40:11 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CGTMxv038022;
	Mon, 12 Jul 2004 09:29: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 i6CGTMFK038021;
	Mon, 12 Jul 2004 09:29:22 -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 i6CGTLBl037991
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 09:29:21 -0700 (PDT)
	(envelope-from roger@agincourtmedia.com)
Received: from biggreen ([216.63.148.42]) by journurl.com with MailEnable ESMTP; Mon, 12 Jul 2004 11:28:29 -0500
From: "Roger B." <roger@agincourtmedia.com>
To: "'Antone Roundy'" <antone@geckotribe.com>, <atom-syntax@imc.org>
Subject: RE: MUST be UTC?
Date: Mon, 12 Jul 2004 11:29:27 -0500
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: <14B72756-D419-11D8-9D0B-003065EA6144@geckotribe.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Thread-Index: AcRoJc8M7HyMAUjPT/ulX/tyIefvyAABVAVA
Message-ID: <BFB35EDF99E549B4A682765D36F2D.MAI@journurl.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


> atom:first-issued or atom:first-published (first 4)
> 	An objective publication date. REQUIRED
> 
> atom:issued or atom:published (last 8)
> 	A subjective publication date. OPTIONAL.

Antone: This is an example of setting up a self-defeating scenario. Few (if
any) blogapps track an objective publication date... they're generally
subjective. So subjective dates will simply be slammed into the required
element, and the optional element will be considered superfluous. Atom
consumers, in turn, will simply ignore the spec and assume that first-issued
is a subjective date.

If folks absolutely must have some sort of immutable publishing date, then
it will have to be optional. Or better yet, just give atom:issued an
optional atom:objective="true|false" attribute, with the attribute
defaulting to "false".

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/ 







From owner-atom-syntax@mail.imc.org  Mon Jul 12 12:40: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 MAA22437
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 12:40: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 i6CGOUrb037460;
	Mon, 12 Jul 2004 09:24:30 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6CGOUBp037459;
	Mon, 12 Jul 2004 09:24:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CGOTb9037451
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 09:24: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 D4F197C112; Mon, 12 Jul 2004 19:22:44 +0200 (CEST)
Date: Mon, 12 Jul 2004 18:28:02 +0200
To: "Roger B." <roger@agincourtmedia.com>
Subject: Re: Q: modfied vs issued vs created
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <46D167FDA4C4E5B8EB0AF52D1B774.MAI@journurl.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: <opsa09c0vjuvpchu@quark>
In-Reply-To: <46D167FDA4C4E5B8EB0AF52D1B774.MAI@journurl.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Mon, 12 Jul 2004 10:18:29 -0500, Roger B. <roger@agincourtmedia.com>  
wrote:

> Asbjørn: The "published date" is the date that the author wants attached  
> to her entry.

Okay. Fine so far.

> That date controls when and where the entry shows up in her blog and  
> feed.

Shouldn't that be 'available'[1] in Dublin Core terms?

> It is also the date that aggregators will want to use for sorting in most
> instances.

It might be used for sorting, but the sorting will be the most rediculous  
thing you've ever seen when the date:

   - Is without timezone information
   - Is randomly user-specified
   - Can change any time anyone wants

> In short, it's the most important date available, and the one users most
> want to control.

The most important date is something the user _should not_ be able to  
control. Of course, they do what they want in the end, but the most  
reliable and «trustworthy» dates are those provided by the tools, not by  
the user.

____
[1] <url: http://dublincore.org/documents/dcmi-terms/#available>

-- 
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 Jul 12 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 MAA22511
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 12:42: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 i6CGU5KY038074;
	Mon, 12 Jul 2004 09:30: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 i6CGU5Kw038073;
	Mon, 12 Jul 2004 09:30: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 i6CGU48S038061
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 09:30:05 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 13 Jul 2004 02:35:17 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Tue, 13 Jul 2004 02:30:06 +1000
Subject: Re: Q: modfied vs issued vs created
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD18F9AE.1F11D%eric.scheid@ironclad.net.au>
In-Reply-To: <opsa00n3cguvpchu@quark>
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 i6CGU58S038067
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 12/7/04 11:20 PM, "Asbjørn Ulsberg" <asbjorn@tigerstaden.no> wrote:

>> If the modified date doesn't change, but the issued date does, then you
>> can consider it assertively no changes (but no longer old news).
> 
> What's the use case for this? What you're really should be doing here is
> alter 'modified' and keep 'issued' the same.

then how would you distinguish that from a minor change, which has the same
pattern?

> Then, it's up to the client
> to choose to show this modification or not. As we don't have a
> supersede-mechanism at the moment, there's no way to separate major
> changes from minor, so users  will either have to choose «show all
> changes» or «never show changes».

we do if we use modified and issued as I've outlined. We've got expressions
of minor change, major change, no change, and old news confirmed to be
current news.

>> (the fourth combination where neither changes means it's old news, caveat
>> emptor)
> 
> If it's old news, would you ever find it in a feed? An archive feed,
> perhaps?

There's more than a few rss/atom feeds I could point you to which have
entries from more than 48 hours ago. That's news old enough to wrap fish in.

e.




From owner-atom-syntax@mail.imc.org  Mon Jul 12 12:44: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 MAA22764
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 12:44: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 i6CGVZ9H038242;
	Mon, 12 Jul 2004 09:31: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 i6CGVZXG038241;
	Mon, 12 Jul 2004 09:31: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 i6CGVXL2038231
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 09:31: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 3D0117C112; Mon, 12 Jul 2004 19:29:49 +0200 (CEST)
To: "Ken MacLeod" <ken@bitsko.slc.ut.us>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Q: modfied vs issued vs created
References: <BD187FBE.1F041%eric.scheid@ironclad.net.au> <m3smbxny87.fsf@bitsko.slc.ut.us> <m3fz7xnred.fsf@bitsko.slc.ut.us>
Message-ID: <opsa09oulzuvpchu@quark>
Date: Mon, 12 Jul 2004 18:35:08 +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: <m3fz7xnred.fsf@bitsko.slc.ut.us>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 12 Jul 2004 11:04:26 -0500, Ken MacLeod <ken@bitsko.slc.ut.us> wrote:

> Another possible solution is a "date discipline" profile indicator.
> Atom core would define the dates using the precisely imprecise Dublin
> Core definitions, and a "date discipline" profile would indicate a
> site's self-certification of conformance to a stricter profile.

I'm not sure yet, but I think I like this proposal. I'll have to let it  
sink and digest some before I make up my mind, but I think it's the best  
solution to what we currently have, when I can't have «trustworthy»  
required data in the Atom Core.

-- 
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 Jul 12 12:48: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 MAA23044
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 12:48: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 i6CGcsts039010;
	Mon, 12 Jul 2004 09:38: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 i6CGcspU039009;
	Mon, 12 Jul 2004 09:38:54 -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 i6CGcs7j038971
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 09:38: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 (rwcrmhc11) with SMTP
          id <2004071216385201300j07gve>; Mon, 12 Jul 2004 16:38:52 +0000
Date: Mon, 12 Jul 2004 10:38:51 -0600
Subject: Re: Disambiguating the subject of feed-level metadata
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: <m3oemlnsqh.fsf@bitsko.slc.ut.us>
Message-Id: <F4FA5D92-D421-11D8-9D0B-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 Monday, July 12, 2004, at 09:35  AM, Ken MacLeod wrote:
>> <feed>
>>    <defaults>
>>      <author name="person A">
>>       ...
>>    </defaults>
>>    <entry />
>>    <entry />
>>    ...
>>   </author>
>
> Is it your preference for a "defaulting" model rather than an
> "explicit reference" model?
Just for the record, we can have both.

<feed>
	<referenceable>
		<person name="asdf">
			...
		</person>
	<referenceable>
	<defaults>
		<author>
			...
		</author>
	</defaults>
	<entry>
		<!--default author-->
	</entry>
	<entry>
		<author ref="asdf" />
	</entry>
	...
</feed>



From owner-atom-syntax@mail.imc.org  Mon Jul 12 13: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 NAA24749
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 13: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 i6CGxTUJ041014;
	Mon, 12 Jul 2004 09: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 i6CGxTYa041013;
	Mon, 12 Jul 2004 09:59:29 -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 i6CGxTWs040998
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 09:59:29 -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 <20040712165927011009pg49e>; Mon, 12 Jul 2004 16:59:27 +0000
Date: Mon, 12 Jul 2004 10:59:22 -0600
Subject: Re: MUST be UTC?
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: <BFB35EDF99E549B4A682765D36F2D.MAI@journurl.com>
Message-Id: <D2BB8CDE-D424-11D8-9D0B-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 Monday, July 12, 2004, at 10:29  AM, Roger B. wrote:
>> atom:first-issued or atom:first-published (first 4)
>> 	An objective publication date. REQUIRED
>>
>> atom:issued or atom:published (last 8)
>> 	A subjective publication date. OPTIONAL.
>
> Antone: This is an example of setting up a self-defeating scenario. 
> Few (if
> any) blogapps track an objective publication date... they're generally
> subjective. So subjective dates will simply be slammed into the 
> required
> element, and the optional element will be considered superfluous. Atom
> consumers, in turn, will simply ignore the spec and assume that 
> first-issued
> is a subjective date.

Good point--I was being overly idealistic.  How about making 
atom:issued REQUIRED and atom:first-issued RECOMMENDED, at least if 
different from atom:issued or if atom:issued doesn't specify a numeric 
timezone.  I've gotten the impression from some of the discussion here 
that this information would be desirable (and I myself would consider 
it useful), so if it's not currently tracked by blog apps, perhaps this 
is an opportunity to encourage an improvement.



From owner-atom-syntax@mail.imc.org  Mon Jul 12 13:16: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 NAA24956
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 13:16: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 i6CGuoSr040778;
	Mon, 12 Jul 2004 09:56: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 i6CGun0J040777;
	Mon, 12 Jul 2004 09:56:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CGumYK040771
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 09:56: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 i6CGvKqJ010165;
	Mon, 12 Jul 2004 12:57:23 -0400
Message-ID: <40F2C2CD.9020307@intertwingly.net>
Date: Mon, 12 Jul 2004 12:56:45 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Antone Roundy <antone@geckotribe.com>
CC: atom-syntax@imc.org
Subject: a methodical approach to defining what date  elements we need
References: <14B72756-D419-11D8-9D0B-003065EA6144@geckotribe.com>
In-Reply-To: <14B72756-D419-11D8-9D0B-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


I like the below so much that I am republishing it with a new subject line.

What I like is the methodical approach.  I don't believe that the names 
of these proposed elements are anything more than something to seed the 
discussion.  And may of the specifics are subject to discussion, but 
this is an excellent way to approach the problem.

- Sam Ruby

Antone Roundy wrote:
> 
> On Sunday, July 11, 2004, at 10:31  AM, Sam Ruby wrote:
> 
>> We need to better define what we expect people who "work with" these  
>> dates can expect.  I explored this in
>>
>> http://www.intertwingly.net/blog/2003/07/01/Subjective-and-objective- 
>> dates
> 
> ...
> 
>> There is no question in my mind that <modified> dates should be  
>> strictly ordered, so either an indication of timezone or  
>> canonicalization to UTC would be required.  Doing so would allow  
>> aggregator authors to order entries across all weblogs, if they chose  
>> to do so.
>>
>> What Bloggers calls Post Date and Time [1], and what LiveJournal  
>> simply calls Date and Local Time of an entry is different.   
>> Qualitatively different.  It is subjective.  It's primary purpose is  
>> for display.  For human consumption.
> 
> ...
> 
>> The most you can assume about this particular date is that it is the  
>> date that the author wants associated with the entry, nothing more,  
>> nothing less.
> 
> ...
> 
>> One date is objective, intended to be processed by cold hard 
>> machines.  One date is subjective, intended to be processed by warm 
>> squishy  humans.
> 
> 
> On Sunday, July 11, 2004, at 10:46  PM, Graham wrote:
> 
>> A major change should result in a new atom:issued
> 
> 
> Okay, here's an attempt at a methodical approach to defining what date  
> elements we need and what the requirements and recommendations should  
> be for each.
> 
> Dates (where "date" = "date and time") that might be associated with an  
> entry:
> 
> 1) objective creation date
> 2) each objective major modification date
> 3) each objective minor modification date
> 4) each objective publication date
> 5) any subjective creation date the author may wish to associate with  
> the entry
> 6) any subjective major modification date the author may wish to  
> associate with the entry
> 7) any subjective minor modification date the author may wish to  
> associate with the entry
> 8) any subjective publication date the author may wish to associate  
> with the entry
> 
> Questions:
> A) Which of these should appear in the feed?
> B) Which of these can be consolidated into a single element in a feed?
> C) What timezone requirements/recommendations should each carry?
> 
> Interested parties:
> I) Author: Most interested in 8. Prefers their local timezone.
> II) Publishing client software: Just an intermediary--probably doesn't  
> care about anything.
> III) Publishing server software: Most interested in 2-4, possibly  
> including all iterations. No strong timezone preference.
> IV) Aggregators: Most interested in 2-4, perhaps including only the  
> first, last, or first and last of each. Perfers UTC.
> V) Feed reader software: Most interested in 2-3 for ordering and  
> determining whether to call something "new" or "updated". No strong  
> timezone preference.
> VI) Human reader: Most interested in the last of each in 2-3 and one of  
> 4 or 8 (depends on the person)--possibly also interested in the first  
> of 4 or 8--and may wish the timezone to be either the author's local  
> timezone or their own local timezone.
> 
> Comments (correct me if I'm wrong or you disagree--these are my  
> perceptions and opinions):
> i) The publishing software can store the dates in whatever timezone  
> they want. They can present it to the author in the author's local  
> timezone, and can publish it as best benefits everyone else.
> ii) Nobody really cares about 5-7.
> iii) Nobody reading the feed really cares about 1, so including it in  
> the feed should be optional. I suppose there may be uses for it, but I  
> wouldn't complain if it weren't even supported.
> iv) Nobody reading the feed cares much about anything that occurred  
> before the first 4.
> 
> Conclusions:
> a) 2-4 and 8 are the only dates that may need to be in the feed.
> b) At most the first and last of each should appear in the feed.
> c) Only 8 should be allowed to omit the timezone.
> d) 2 could be used instead of 4 in the feed.
> 
> Proposed Date Constructs:
> 
> atom:first-issued or atom:first-published (first 4)
>     An objective publication date. REQUIRED. MUST specify a timezone  
> (which might be -00:00 if the timezone is unknown) which MUST be  numeric.
> 
> atom:issued or atom:published (last 8)
>     A subjective publication date. OPTIONAL. It is RECOMMENDED that it  
> include a timezone, that the timezone be numeric, and that it be the  
> author's timezone, or the timezone relevant to the content of the entry  
> (for example, if I, in Utah, am writing about something that happened  
> in Iraq, I might use Iraq's timezone).
> 
> atom:modified (last 2)
>     The objective date when the last major change--a change which 
> alters  or non-trivially expands the message--was made to the entry. 
> REQUIRED  if different from atom:first-issued|published. It MUST specify 
> a  timezone (which might be -00:00 if the timezone is unknown), which 
> MUST  be UTC.
> 
> atom:updated (last 3)
>     The objective date when the last minor change--for example a 
> spelling  correction, clarification which doesn't expand the message, 
> etc.--was  made to the entry. RECOMMENDED if different from  
> atom:first-issued|published and later than atom:modified. MUST NOT be  
> included if earlier than atom:modified. MUST specify a timezone (which  
> might be -00:00 if the timezone is unknown), which MUST be UTC.
> 
> I would also propose that the spec text for each Date Construct, or  
> some text appearing before the list of Date Constructs, point out that  
> the requirements for each are different because some are intended to  
> use by software and others for presentation to humans.
> 
> The "objective" dates should have spec text to point out that these  
> dates MUST NOT be modified except to correct for errors in the actual  
> timestamp (for example, if the computers clock was incorrect).
> 
> Note that the dates that are required to be specified in UTC may be  
> converted by client software to the timezone indicated in  
> atom:issued|published if it appears in the feed. All dates may also be  
> converted to the user's local timezone.
> 



From owner-atom-syntax@mail.imc.org  Mon Jul 12 13: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 NAA25662
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 13: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 i6CHB7Pe041975;
	Mon, 12 Jul 2004 10:11: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 i6CHB7Nv041974;
	Mon, 12 Jul 2004 10:11:07 -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 i6CHB6WX041967
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 10:11:06 -0700 (PDT)
	(envelope-from distobj@acm.org)
Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian))
	id 1Bk4L1-0001CO-00; Mon, 12 Jul 2004 13:11:35 -0400
Date: Mon, 12 Jul 2004 13:11:35 -0400
To: David Orchard <dorchard@bea.com>
Cc: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Version vs. Namespace
Message-ID: <20040712171135.GR30868@markbaker.ca>
References: <32D5845A745BFB429CBDBADA57CD41AF08C9B872@ussjex01.amer.bea.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <32D5845A745BFB429CBDBADA57CD41AF08C9B872@ussjex01.amer.bea.com>
User-Agent: Mutt/1.3.28i
From: Mark Baker <distobj@acm.org>
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 was just about to say the same thing.  +1

On Mon, Jul 12, 2004 at 09:17:50AM -0700, David Orchard wrote:
> 
> What kind of an answer is this? "No, it's hard?" 
> 
> Who said anything about Atom solving the versioning problem in the general case?  And btw, what ARE the versioning use cases of Atom?  I've started writing up some work on Atom extensibility/versioning, but it's become a bit hard because it seems like everything could be extended/versioned...
> 
> Tim, you should know as well as anybody, that the problems of figuring out what a "version" of a mixed namespace document is can rarely be done with a single integer.  What does a "version" mean under distributed and multi-ns extensibility?
> 
> While Mark's proposal of a profile might appear to be complicated, it ought to get a bit more air time and explanation than the very next message saying "no", especially with discussion of concrete use cases/scenarios.
> 
> Cheers,
> Dave 



From owner-atom-syntax@mail.imc.org  Mon Jul 12 13:28: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 NAA26014
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 13:28: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 i6CHI2ew042523;
	Mon, 12 Jul 2004 10: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 i6CHI2Mq042522;
	Mon, 12 Jul 2004 10:18: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 i6CHI1wU042501
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 10:18: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 BC4237C112; Mon, 12 Jul 2004 20:16:16 +0200 (CEST)
Date: Mon, 12 Jul 2004 19:21:45 +0200
To: "Eric Scheid" <eric.scheid@ironclad.net.au>
Subject: Re: Q: modfied vs issued vs created
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <BD18F9AE.1F11D%eric.scheid@ironclad.net.au>
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: <opsa1buj0ruvpchu@quark>
In-Reply-To: <BD18F9AE.1F11D%eric.scheid@ironclad.net.au>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Tue, 13 Jul 2004 02:30:06 +1000, Eric Scheid  
<eric.scheid@ironclad.net.au> wrote:

>> What's the use case for this? What you're really should be doing here is
>> alter 'modified' and keep 'issued' the same.
>
> then how would you distinguish that from a minor change, which has the  
> same pattern?

Exactly. You can't.

> we do if we use modified and issued as I've outlined.

That's not a good idea, imho, so I have to give a -1 to that proposal.

> We've got expressions of minor change, major change, no change, and old
> news confirmed to be current news.

To me, it's a lot more important to have «initial creation or publish  
date» than to be able to separate minor and major changes. Therefore, I'd  
rather see a static non-changed atom:issued than a dynamic «I'll change  
all the time»-atom:issued.

-- 
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 Jul 12 13: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 NAA26062
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 13:29: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 i6CHJ2AG042575;
	Mon, 12 Jul 2004 10:19:02 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6CHJ2if042574;
	Mon, 12 Jul 2004 10:19:02 -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 i6CHJ2Bs042568
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 10:19:02 -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 i6CHJ54Q031631;
	Mon, 12 Jul 2004 10:19:05 -0700
Received: from ussjex01.amer.bea.com ([172.16.120.50]) by ussjfe01.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 12 Jul 2004 10:19:04 -0700
x-mimeole: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Craeted proposal: PaceProvideSchema
Date: Mon, 12 Jul 2004 10:19:04 -0700
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF08C9B9FF@ussjex01.amer.bea.com>
Thread-Topic: Craeted proposal: PaceProvideSchema
Thread-Index: AcRm2QgussAoVNshS1KXcj7uvphm3QBVxjSA
From: "David Orchard" <dorchard@bea.com>
To: "Mark Nottingham" <mnot@mnot.net>, "Tim Bray" <Tim.Bray@Sun.COM>
Cc: "Atom Syntax" <atom-syntax@imc.org>, <danny666@virgilio.it>,
        "Norman Walsh" <ndw@nwalsh.com>
X-OriginalArrivalTime: 12 Jul 2004 17:19:04.0898 (UTC) FILETIME=[55203A20:01C46834]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6CHJ2Bs042569
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 that in almost all cases, the schema expresses a subset of the prose constraints.  However, machines have a tough time reading prose.  

There are 3 different things to think about when working on schemas that have been muddled together here:
1. Sorting out the ambiguities between prose and schema
2. Dealing with the constraints of the schema lanaguage
3. The meaning of normative versus non-normative.

1. Ambiguities.

I agree that there will be a period of time of sorting out differences and ambiguities.  But I've typically found that skipping that step is robbing peter to pay paul, that is the problems are just defered to the community forcing some kind of "interop" organization to figure out all the niggly bits when interop doesn't just happen.  

Would the "long period of sorting out ambiguities" be skipped in producing a non-normative schema compared to a normative schema?  It seems to me like people are thinking that "non-normative" means less work, ie lower quality.  

I think either sort out the ambiguities, or don't do the work at all.

2. Schema language constraints
Where I think this gets tricky is that different schema languages express different constraints and some constraints are impossible to express in certain schema languages.  For example: W3C Schema does not allow optional elements before a wildcard extensibilility in the optional elements ns (the determinism constraint).   If Atom wants to allow same ns extensibility after optional elements, it either can't write the XML Schema or it has to do some extra work to get around determinism.  The work is basically wrapping the extension with a known marker or element.  That also means that all the non w3c Schema languages would have to do the same work.  RelaxNG doesn't have this problem btw.  Should relaxNG schema have to do this work?

I think this is the biggest problem, that of the schema language constraints "leaking" back into the prose.  And how far does this go?  The probably knee-jerk response is "no leaky abstractions!", but that means that it might be 100% impossible to write a schema in a given language.  

3. Meaning of *-normative schema

I'm not quite sure that I understand the purpose of having an "informative" schema compared to a normative schema.  If the non-normative is the same quality as the normative, I don't get why it would be non-normative instead of normative.  

Sometimes people make schemas non-normative because they haven't done as much work as they think they need to, which I addressed in #1.  Other times, the schemas are non-normative because they use a schema language (maybe a pseudo-schema language even) that isn't widely deployed.  

I think the decision about *-normative should happen after the group decides whether the ambiguities between schema and prose will be resolved, and whether the schema language(s) will leak into the prose.  

Cheers,
Daave 

> -----Original Message-----
> From: owner-atom-syntax@mail.imc.org
> [mailto:owner-atom-syntax@mail.imc.org]On Behalf Of Mark Nottingham
> Sent: Saturday, July 10, 2004 4:51 PM
> To: Tim Bray
> Cc: Atom Syntax; danny666@virgilio.it; Norman Walsh
> Subject: Re: Craeted proposal: PaceProvideSchema
> 
> 
> 
> 
> On Jul 10, 2004, at 12:00 PM, Tim Bray wrote:
> 
> > On Jul 10, 2004, at 11:48 AM, Mark Nottingham wrote:
> >
> >>> That would be unacceptable, the schema and the prose have to be 
> >>> consistent. -Tim
> >>
> >> In practice, that's tricky to achieve.
> >
> > I disagree.  The syntax constraints you express in the schema are a 
> > small, tractable subset of the general constraints that 
> appear in the 
> > prose.
> 
> I predict that it will be very difficult to have a one-to-one 
> relationship between the constraints in an XML Schema and prose, and 
> furthermore, that small differences and ambiguities between them will 
> conflict despite our best efforts. This will lead to a long period of 
> sorting out conflicting normative statements in the prose and schema, 
> and errata releases of the specification after we've thought it final.
> 
> Specifying something twice is not a good idea; if you give people two 
> different readings of a constraint, they'll pick one and ignore the 
> other.
> 
> Since people seem to feel strongly about making the schema as well as 
> the prose normative, let's take a look at them after the next 
> round of 
> drafts and see where this approach gets us. If we find ourselves 
> sinking significant resources into aligning them, however, 
> I'd ask that 
> we reconsider such a decision.
> 
> --
> Mark Nottingham     http://www.mnot.net/
> 
> 



From owner-atom-syntax@mail.imc.org  Mon Jul 12 13:36: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 NAA26385
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 13:36: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 i6CHNeiU042874;
	Mon, 12 Jul 2004 10:23: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 i6CHNeoC042873;
	Mon, 12 Jul 2004 10:23:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CHNdm5042867
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 10:23:39 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6CHNhil004440
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 11:23:43 -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 <0I0R00LR81NI2G@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Mon, 12 Jul 2004 11:23:43 -0600 (MDT)
Received: from [192.168.1.9] ([154.20.133.9])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0R00CHK1NIE1@mail.sun.net> for atom-syntax@imc.org; Mon,
 12 Jul 2004 11:23:42 -0600 (MDT)
Date: Mon, 12 Jul 2004 10:23:38 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Version vs. Namespace
In-reply-to: <32D5845A745BFB429CBDBADA57CD41AF08C9B872@ussjex01.amer.bea.com>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <36879593-D428-11D8-9DBF-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: <32D5845A745BFB429CBDBADA57CD41AF08C9B872@ussjex01.amer.bea.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 Jul 12, 2004, at 9:17 AM, David Orchard wrote:

> While Mark's proposal of a profile might appear to be complicated, it 
> ought to get a bit more air time and explanation than the very next 
> message saying "no", especially with discussion of concrete use 
> cases/scenarios.

OK.  I claim that a single fixed namespace plus a single version 
attribute on the root element, plus an extensibility framework 
involving the usual mustUnderstand/mustIgnore primitives, will provide 
a nice efficient framework for the long term.  I further claim that 
there is now enough experience with this kind of versioning 
architecture that we understand the implementation issues.  I further 
express doubt that any further steps down the road to more complexity 
will have positive ROI.

So...... those who want a more complex and abstract versioning set-up 
should start, I think, from use-cases, so that we get a nice clean 
clear sense of exactly what the complexity buys us.  -Tim



From owner-atom-syntax@mail.imc.org  Mon Jul 12 13: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 NAA26638
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 13:38: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 i6CHPbkx043000;
	Mon, 12 Jul 2004 10:25:37 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6CHPbEP042999;
	Mon, 12 Jul 2004 10:25: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 i6CHPafp042989
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 10:25:36 -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 i6CHPY53013465
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 12:25:34 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6CHPYM0013461;
	Mon, 12 Jul 2004 12:25:34 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Disambiguating the subject of feed-level metadata
References: <BD18F88E.1F11B%eric.scheid@ironclad.net.au>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 12 Jul 2004 12:25:34 -0500
In-Reply-To: <BD18F88E.1F11B%eric.scheid@ironclad.net.au>
Message-ID: <m3658tnnn5.fsf@bitsko.slc.ut.us>
Lines: 76
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 i6CHPbfp042994
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


Eric Scheid <eric.scheid@ironclad.net.au> writes:

> On 13/7/04 1:48 AM, "Ken MacLeod" <ken@bitsko.slc.ut.us> wrote:
> 
> > I see the primary solution for "solving" the "physical feed
> > defaulting/inheritance" issue as having entries be as independent
> > as possible.  The above example most definitely achieves that, but
> > at a cost of significant redundancy.  A secondary solution of
> > references is therefore proposed to address the newly created
> > redundancy issue.
> 
> your extended example has some confusing things in it. For example,
> where is "tag:example.com,2004:authors/kitty" defined? It is
> referenced, but not defined.

gah.  copy-n-paste error from another example, the second embedded
"site" should not be referencing an author, since the entry explicitly
embeds the author.

> Note that it wouldn't be necessary to use the <definitions>
> mechanisms ... a fully flattened feed could be published which
> contains no id/ref uses, just massive redundancy (which gzip helps,
> a bit).

Rather than a <definitions> element, I think free-standing "entity
constructs" beneath <feed> would be fine (and supporting the streaming
order requirements intended by PaceElementOrder).  I think it was Bill
de hÓra who just mentioned that this is pretty much how RSS/RDF 1.0
does it with <rss:channel>.

> What's missing here though is the concept of who is
> producing/publishing this [entire document]. That is, if pubsub was
> to publish a synthetic feed, then we would see multiple <channel>
> elements defined and used, but we'd still need one more to say "this
> is a pubsub feed, even though none of the entries come from
> pubsub". We need another another container on peer with
> <definitions> and <entries>. Maybe <publication> or <feed>??

Note: in this model I think of all <feed>s as a "physical feed",
distinct from some "logical" model of where entries come from (site,
category, query).  Here is how you associate a physical feed to its
source site:

<feed id="tag:synth-site,2004:synth-feed-42">
  <site ref="synth-site"/>
  <modified>2004-05-27T03:48:48Z</modified>
  <site id="site1">
    ...
  </site>
  <site id="synth-site">
    <title>Synthesizing site</title>
    ...
  </site>
  <person id="person A">
    ...
  </person>
  <person id="person B">
    ...
  </person>
  <entry id="tag:site1,2004:00001">
    <site ref="site1" />
    <author ref="person A" />
  </entry>
  <entry id="tag:site1,2004:00002">
    <site ref="site1" />
    <author ref="person B" />
    <contributor ref="person A" />
  </entry>
</feed>

Here, elements that have an @id are "entity constructs" that are
effectively independent whereever they occur, and any other elements
are properties of the containing element.  Elements with @ref are
property elements that reference other entity constructs.

  -- Ken



From owner-atom-syntax@mail.imc.org  Mon Jul 12 13:47: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 NAA26973
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 13: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 i6CHX9qw044062;
	Mon, 12 Jul 2004 10:33: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 i6CHX9gX044061;
	Mon, 12 Jul 2004 10:33:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CHX9Jv044048;
	Mon, 12 Jul 2004 10:33:09 -0700 (PDT)
	(envelope-from jasnell@us.ibm.com)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11])
	by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i6CHX0qq492704;
	Mon, 12 Jul 2004 13:33:00 -0400
Received: from d03nm122.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170])
	by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6CHWxMH168560;
	Mon, 12 Jul 2004 11:33:00 -0600
In-Reply-To: <20040712171135.GR30868@markbaker.ca>
To: Mark Baker <distobj@acm.org>
Cc: Atom Syntax <atom-syntax@imc.org>, David Orchard <dorchard@bea.com>,
        owner-atom-syntax@mail.imc.org
MIME-Version: 1.0
Subject: Re: Version vs. Namespace
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
From: James M Snell <jasnell@us.ibm.com>
X-MIMETrack: S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 10:32:35 AM,
	Serialize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 10:32:35 AM,
	Serialize complete at 07/12/2004 10:32:35 AM,
	Itemize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 10:32:35 AM,
	S/MIME Sign complete at 07/12/2004 10:32:35 AM,
	S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 10:32:57 AM,
	S/MIME Sign complete at 07/12/2004 10:32:57 AM,
	Serialize by Router on D03NM122/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at
 07/12/2004 11:33:00,
	Serialize complete at 07/12/2004 11:33:00
Message-ID: <OFC66635FE.A2AF5F93-ON88256ECF.0060057C-88256ECF.0060668D@us.ibm.com>
Date: Mon, 12 Jul 2004 11:32:58 -0600
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z31242_boundary_sign
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>


This is an S/MIME signed message.

---------z31242_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 00605E2988256ECF_="

This is a multipart message in MIME format.
--=_alternative 00605E2988256ECF_=
Content-Type: text/plain; charset="US-ASCII"

Personally I like the idea of using profiles as opposed to version 
numbers.  The issue is in determining which profile a particular feed 
validates against.  However, one could easily imagine various profiles 
based on specific use cases of the syntax, where each profile determines 
which extension elements to expect in the feed, strict definition of 
various optional elements, etc.  Yes, it does add a bit of complexity, but 
I believe the benefits would be significant.  I do not believe, however, 
that the core specification should define normative profiles.  Profiles 
should be submitted as separate RFCs.  The core spec could specify the 
process of creating profiles.

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



Mark Baker <distobj@acm.org> 
Sent by: owner-atom-syntax@mail.imc.org
07/12/2004 10:11 AM

To
David Orchard <dorchard@bea.com>
cc
Atom Syntax <atom-syntax@imc.org>
Subject
Re: Version vs. Namespace







I was just about to say the same thing.  +1

On Mon, Jul 12, 2004 at 09:17:50AM -0700, David Orchard wrote:
> 
> What kind of an answer is this? "No, it's hard?" 
> 
> Who said anything about Atom solving the versioning problem in the 
general case?  And btw, what ARE the versioning use cases of Atom?  I've 
started writing up some work on Atom extensibility/versioning, but it's 
become a bit hard because it seems like everything could be 
extended/versioned...
> 
> Tim, you should know as well as anybody, that the problems of figuring 
out what a "version" of a mixed namespace document is can rarely be done 
with a single integer.  What does a "version" mean under distributed and 
multi-ns extensibility?
> 
> While Mark's proposal of a profile might appear to be complicated, it 
ought to get a bit more air time and explanation than the very next 
message saying "no", especially with discussion of concrete use 
cases/scenarios.
> 
> Cheers,
> Dave 



--=_alternative 00605E2988256ECF_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">Personally I like the idea of using
profiles as opposed to version numbers. &nbsp;The issue is in determining
which profile a particular feed validates against. &nbsp;However, one could
easily imagine various profiles based on specific use cases of the syntax,
where each profile determines which extension elements to expect in the
feed, strict definition of various optional elements, etc. &nbsp;Yes, it
does add a bit of complexity, but I believe the benefits would be significant.
&nbsp;I do not believe, however, that the core specification should define
normative profiles. &nbsp;Profiles should be submitted as separate RFCs.
&nbsp;The core spec could specify the process of creating profiles.</font>
<br>
<br><font size=2 face="sans-serif">- James M Snell<br>
 &nbsp;jasnell@us.ibm.com<br>
 &nbsp;http://www.ibm.com<br>
 &nbsp;(877) 511-5082 / Office<br>
 &nbsp;930-1979 / Tie Line</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Mark Baker &lt;distobj@acm.org&gt;</b>
</font>
<br><font size=1 face="sans-serif">Sent by: owner-atom-syntax@mail.imc.org</font>
<p><font size=1 face="sans-serif">07/12/2004 10:11 AM</font>
<td width=59%>
<table width=100%>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td valign=top><font size=1 face="sans-serif">David Orchard &lt;dorchard@bea.com&gt;</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td valign=top><font size=1 face="sans-serif">Atom Syntax &lt;atom-syntax@imc.org&gt;</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td valign=top><font size=1 face="sans-serif">Re: Version vs. Namespace</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2><tt><br>
I was just about to say the same thing. &nbsp;+1<br>
<br>
On Mon, Jul 12, 2004 at 09:17:50AM -0700, David Orchard wrote:<br>
&gt; <br>
&gt; What kind of an answer is this? &quot;No, it's hard?&quot; <br>
&gt; <br>
&gt; Who said anything about Atom solving the versioning problem in the
general case? &nbsp;And btw, what ARE the versioning use cases of Atom?
&nbsp;I've started writing up some work on Atom extensibility/versioning,
but it's become a bit hard because it seems like everything could be extended/versioned...<br>
&gt; <br>
&gt; Tim, you should know as well as anybody, that the problems of figuring
out what a &quot;version&quot; of a mixed namespace document is can rarely
be done with a single integer. &nbsp;What does a &quot;version&quot; mean
under distributed and multi-ns extensibility?<br>
&gt; <br>
&gt; While Mark's proposal of a profile might appear to be complicated,
it ought to get a bit more air time and explanation than the very next
message saying &quot;no&quot;, especially with discussion of concrete use
cases/scenarios.<br>
&gt; <br>
&gt; Cheers,<br>
&gt; Dave <br>
<br>
</tt></font>
<br>
--=_alternative 00605E2988256ECF_=--

---------z31242_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIIUOAIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIISWDCCAtow
ggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1
aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAy
MDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA629xc49NpAPz
cAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7glzJKgPkPzlTZZfznznGbmAWVnNBQ
lyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnwNclOnnP2sKufuPzbTImQTTi5c8JZNZcM
J0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEEBAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1Ud
DgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAPBgNVHRMBAf8EBTADAQH/MDEGA1UdJQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUH
AwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvu
jQupk2oCScMd3FIHLE7hOfu8YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14ke
McF9ViNdewEoBGiAycUq8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIC2jCCAkOgAwIB
AgIDAxS2MA0GCSqGSIb3DQEBBAUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwMTE0MjIw
NzExWhcNMTExMjMxMjIwNzExWjBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25h
bCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrb3Fzj02kA/NwCy5KFMiY
tFgyTJ6kMSQLVSs9uwVHIAVkqy/enDQwZ9b/7uCXMkqA+Q/OVNll/OfOcZuYBZWc0FCXI9qw60KO
J/rTd65FdF4dwp8cw8si0qjOJtYg8cm46fA1yU6ec/awq5+4/NtMiZBNOLlzwlk1lwwnRgXNNwID
AQABo4GqMIGnMBEGCWCGSAGG+EIBAQQEAwIAhzAOBgNVHQ8BAf8EBAMCAcYwHQYDVR0OBBYEFK5U
DpLqqDOpKyQtx8hvMNze80pAMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMA8GA1Ud
EwEB/wQFMAMBAf8wMQYDVR0lBCowKAYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYB
BQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAMnJ7c2YLyrY/PKlFl+7sm8NENfWtFxqdm+6NC6mTagJJ
wx3cUgcsTuE5+7xh9+/G0tTfLzA1qZAQ5GNMPXvmoB9+vJfKnC2JWMFQpIOUEJDXiR4xwX1WI117
ASgEaIDJxSrxHcuuV/hMIO9bgZ6C41MUVmdLTKBgBOImTuIPK8QwggMgMIICiaADAgECAgQ13vTP
MA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQL
EyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0MTUxWhcN
MTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMk
RXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKKlQRkrPFr
U18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkwrFEeO68r
1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOgYaRfMF0x
CzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBD
ZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAxODA4MjIx
NjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAdBgNV
HQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0HQQAEDTAL
GwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwlMQ0AppJu
f7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn00DbOyZY
sih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMgMIICiaADAgEC
AgQ13vTPMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0
MTUxWhcNMTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsG
A1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKK
lQRkrPFrU18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkw
rFEeO68r1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOg
YaRfMF0xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNl
Y3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAx
ODA4MjIxNjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAdBgNVHQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0H
QQAEDTALGwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwl
MQ0AppJuf7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn
00DbOyZYsih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMmMIIC
j6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIxNjM2NTRaMIGFMQsw
CQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEXMBUGA1UEAxMOSmFt
ZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkqhkiG9w0BCQEWEmph
c25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwKpbDG3zMatEuuOT
FYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSyd+7nwqAvbBfPj+0S
vcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7tBJlLrwDRCMoNlPuQ
Kg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQW
BBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOgFAwSamFzbmVs
bEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pAMCcGA1UdJQQgMB4G
CCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAZMKevB7dFfb9
23OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY8BjwVHxiYgG4xkxf
B1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOIzj3lz3xd+uOzqRFg
/Wsg/VMwggMmMIICj6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAy
BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNV
BAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIx
NjM2NTRaMIGFMQswCQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEX
MBUGA1UEAxMOSmFtZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkq
hkiG9w0BCQEWEmphc25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
wKpbDG3zMatEuuOTFYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSy
d+7nwqAvbBfPj+0SvcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7t
BJlLrwDRCMoNlPuQKg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQD
AgXgMB0GA1UdDgQWBBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcU
AgOgFAwSamFzbmVsbEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA
MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQAD
gYEAZMKevB7dFfb923OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY
8BjwVHxiYgG4xkxfB1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOI
zj3lz3xd+uOzqRFg/Wsg/VMxggG7MIIBtwIBATBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJ
bnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0g
Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwF+kzAJBgUrDgMCGgUAoIGiMBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDcxMjE3MzIzNVowIwYJKoZIhvcNAQkEMRYE
FE29PQZy6Cv0NisWMOjbrmyD9KHhMEMGCSqGSIb3DQEJDzE2MDQwBwYFKw4DAh0wDgYIKoZIhvcN
AwICAgCAMAoGCCqGSIb3DQMHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAQVFS0gZ7
eAXtCqBKljX7Qqz9ZMvaoYpChE6iw2lS7i1Pk+v3QQrTUdOgf4rslzKYQglsr7+lNJRcv5qnOYTH
7R0lZCdps6ktUykO+Ke4SvIoCKvZ0hSn8U+9nMUm1TR0LPFxl93/hs5zo5qpQA08cCjyeGq7YwqZ
CnmCvJGZ5YUAAAAA

---------z31242_boundary_sign--



From owner-atom-syntax@mail.imc.org  Mon Jul 12 13: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 NAA27169
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 13: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 i6CHcWXw044525;
	Mon, 12 Jul 2004 10: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 i6CHcWg2044524;
	Mon, 12 Jul 2004 10:38:32 -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 i6CHcWf6044518
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 10:38:32 -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 i6CHcYrT000262;
	Mon, 12 Jul 2004 10:38:34 -0700 (PDT)
Received: from [192.168.1.100] (h00080d858303.ne.client2.attbi.com [24.61.1.243])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id i6CHcSC5028316;
	Mon, 12 Jul 2004 10:38:29 -0700 (PDT)
In-Reply-To: <40F2C2CD.9020307@intertwingly.net>
References: <14B72756-D419-11D8-9D0B-003065EA6144@geckotribe.com> <40F2C2CD.9020307@intertwingly.net>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8--322444363; protocol="application/pkcs7-signature"
Message-Id: <47071860-D42A-11D8-82B1-000A95DC3D90@mac.com>
Cc: Antone Roundy <antone@geckotribe.com>, atom-syntax@imc.org
From: Graham <dtcd@mac.com>
Subject: Re: a methodical approach to defining what date  elements we need
Date: Mon, 12 Jul 2004 13:38:25 -0400
To: Sam Ruby <rubys@intertwingly.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-8--322444363
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 12 Jul 2004, at 12:56 pm, Sam Ruby wrote:

>
> I like the below so much that I am republishing it with a new subject 
> line.
>
> What I like is the methodical approach.  I don't believe that the 
> names of these proposed elements are anything more than something to 
> seed the discussion.  And may of the specifics are subject to 
> discussion, but this is an excellent way to approach the problem.

I think the list of dates is way too abstract to be useful. As an 
aggregator author, I am only interested in one, maybe 2 dates:

1) The date I would have first found the entry had I been checking once 
a minute
2) A date to show the user, usually the same as above

There is an exception to number 1. Sometimes an old entry will reappear 
in a feed, usually because it has been updated. Most sites don't do 
this - their feed is fixed as the last n entries by creation date, 
which is fine. But when a site does do this, I consider it as 
significant as publishing a new entry. So I am not *at all* interested 
in the date of minor or major modifications, but I am interested in 
when the publisher deliberately bounces an old entry back to the top of 
their list. Re-issuing is much more significant than modification.

Graham
--Apple-Mail-8--322444363
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
9w0BCQUxDxcNMDQwNzEyMTczODI1WjAjBgkqhkiG9w0BCQQxFgQUDX7EGNjCYAN+2UoOkYdidyjT
xrgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAdf1fm5Jsuc8TuSWT8alaspj5
7QDsDaCnZvuV13AaOb2TxSVOBB07elkBs/HPHf52qVfXqibBjZP/Ww5OCbC6rzUPVmoCb62hX1pp
P18P34wFvOu6lQ9V61ZfcgYP9eEHrfXV3h/iCQJp88Zo/2ZvidPK95TakOBh80PbkRZr/leynz7h
UFVpNCnlMBHb+J2CTeyJkVuVaEAWSo4UJ7zL5bD3HIS4T2dlWkEWLEtx+46iFn3a0k8kHPhiM2ET
0G/CHmSPCWBx9/ULDs1X9ldN1eUHDvx+/fs+amG5kYgSa8gy1cOl5FefwBGw4g2c9wT/MNiyixc1
/ADpwbcZMuoo5AAAAAAAAA==

--Apple-Mail-8--322444363--



From owner-atom-syntax@mail.imc.org  Mon Jul 12 13:54: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 NAA27280
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 13:54: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 i6CHXjpc044128;
	Mon, 12 Jul 2004 10:33: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 i6CHXjS6044127;
	Mon, 12 Jul 2004 10:33:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CHXhKB044121
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 10:33:44 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 13 Jul 2004 03:38:51 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Tue, 13 Jul 2004 03:33:37 +1000
Subject: Re: Q: modfied vs issued vs created
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD190891.1F1B6%eric.scheid@ironclad.net.au>
In-Reply-To: <opsa1buj0ruvpchu@quark>
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 i6CHXjKB044122
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 13/7/04 3:21 AM, "Asbjørn Ulsberg" <asbjorn@tigerstaden.no> wrote:

>>> What's the use case for this? What you're really should be doing here is
>>> alter 'modified' and keep 'issued' the same.
>> 
>> then how would you distinguish that from a minor change, which has the
>> same pattern?
> 
> Exactly. You can't.

Thank you, my point exactly. What you propose above doesn't let us
distinguish an interesting change from a trivial change, by smushing the two
together. I propose a means to differentiate the two types of changes, and
that is to our benefit.

>> we do if we use modified and issued as I've outlined.
> 
> That's not a good idea, imho, so I have to give a -1 to that proposal.
> 
>> We've got expressions of minor change, major change, no change, and old
>> news confirmed to be current news.
> 
> To me, it's a lot more important to have «initial creation or publish
> date» than to be able to separate minor and major changes. Therefore, I'd
> rather see a static non-changed atom:issued than a dynamic «I'll change
> all the time»-atom:issued.

Then you'll need to write some spec text explaining what an aggregator
should do if it does happen to come across with an entry where <modified> is
after <issued>. 

I'm saying:

    <modified> changed = the entry has changed in some way
    <issued> changed = pay attention!

At the root of it all I'm just not convinced that <issued> shouldn't be
changeable. I can see however some utility in an optional <first-issued>.

e.




From owner-atom-syntax@mail.imc.org  Mon Jul 12 13:57: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 NAA27454
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 13:57:50 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CHf1hq044721;
	Mon, 12 Jul 2004 10:41: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 i6CHf1re044720;
	Mon, 12 Jul 2004 10:41: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-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 i6CHf0Ve044711
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 10:41:00 -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 i6CHf4il014967
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 11:41:04 -0600 (MDT)
Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0I0R00HMD2GF8F@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Mon, 12 Jul 2004 11:41:04 -0600 (MDT)
Received: from [192.168.1.9] ([154.20.133.9])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0R00CPV2GFE1@mail.sun.net> for atom-syntax@imc.org; Mon,
 12 Jul 2004 11:41:03 -0600 (MDT)
Date: Mon, 12 Jul 2004 10:41:04 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Rough consensus on PaceElementOrder?
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <A5F347BE-D42A-11D8-9DBF-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: <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 think that we are approaching rough consensus on PaceElementOrder, 
like so:

1. I think we clearly have consensus that the feed-level elements 
should all appear before the <atom:entry> elements.

2. I think we have probably have good-enough rough consensus that it's 
worthwhile grouping all the non-entry stuff in an <atom:feedinfo> or 
some such, so that the content model for <atom:feed> is something like

   atom:feedinfo, atom:entry*

The cost of doing this seems effectively zero and there are some 
detectable advantages.

3. There has been some discussion around the notion that there are some 
feed-level things that are really mostly about providing defaults for 
the <atom:entries>, with the consequent suggestion that maybe they 
deserve their own top-level element, with further digressions into 
doing defaulting by reference rather than by inheritance.  I do not 
detect consensus in these discussions (in fact I'm not convinced that 
it's been demonstrated that there things that are have pure 
entry-default as opposed to feed-metadata semantics).

SO: I propose that rather than tear this one apart any further, we ask 
the editors to, in the -01 drafts, recast the data format with the 
<atom:feedinfo> element (anyone should feel free to suggest a better 
name than "feedinfo"), and that those who care about defaulting cook up 
a Pace or three outlining specifically what the options are.  -Tim



From owner-atom-syntax@mail.imc.org  Mon Jul 12 13:58: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 NAA27473
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 13:58: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 i6CHnwDa045462;
	Mon, 12 Jul 2004 10:49:58 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6CHnw43045461;
	Mon, 12 Jul 2004 10:49:58 -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 i6CHnwdn045454
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 10:49:58 -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 i6CHo24Q002249;
	Mon, 12 Jul 2004 10:50:02 -0700
Received: from ussjex01.amer.bea.com ([172.16.120.50]) by ussjfe01.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 12 Jul 2004 10:50:01 -0700
x-mimeole: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Version vs. Namespace
Date: Mon, 12 Jul 2004 10:50:00 -0700
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF08C9BAA3@ussjex01.amer.bea.com>
Thread-Topic: Version vs. Namespace
Thread-Index: AcRnagnssxyfiPdRRWqOf5fwv7pSxQAzrgcg
From: "David Orchard" <dorchard@bea.com>
To: "Sam Ruby" <rubys@intertwingly.net>, "Norman Walsh" <ndw@nwalsh.com>
Cc: "Atom Syntax" <atom-syntax@imc.org>
X-OriginalArrivalTime: 12 Jul 2004 17:50:01.0479 (UTC) FILETIME=[A7BC0170:01C46838]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6CHnwdn045456
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


You betcha.  It's got all the expected stuff like must ignore, must Understand, extensibility points.  

> > It strikes me that we need to specify the rules for processing Atom
> > documents that have a version that isn't recognized. We may 
> also want
> > to add an atom:mustUnderstand attribute globally.
> 
> It has been alleged that David Orchard is working on such a proposal.
> 
> - Sam Ruby
> 
> 



From owner-atom-syntax@mail.imc.org  Mon Jul 12 13:58: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 NAA27510
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 13:58: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 i6CHmD6s045378;
	Mon, 12 Jul 2004 10:48:13 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6CHmD3i045377;
	Mon, 12 Jul 2004 10:48:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CHmC9h045365
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 10:48: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 7DD3A7C117; Mon, 12 Jul 2004 20:46:27 +0200 (CEST)
Date: Mon, 12 Jul 2004 19:52:02 +0200
To: "Roger B." <roger@agincourtmedia.com>
Subject: Re: MUST be UTC?
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <BFB35EDF99E549B4A682765D36F2D.MAI@journurl.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: <opsa1c80qruvpchu@quark>
In-Reply-To: <BFB35EDF99E549B4A682765D36F2D.MAI@journurl.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Mon, 12 Jul 2004 11:29:27 -0500, Roger B. <roger@agincourtmedia.com>  
wrote:

> Few (if any) blogapps track an objective publication date...

Okay. I just have to ask. Is it consensus that Atom should:

   1. Only cater for the blogging community.
   2. Only cater for existing blogging tools.
   3. Just adopt current (bad) practices and not try to do anything to
      improve the quality of service or data in the syndication sphere.

If not, what does it matter that blog applications have bad practice on  
this field? Have you thought about how incredibly simple it is to  
implement a 'first-issued' or 'first-published' in a tool? It's one extra  
field in the data storage and one statement in SQL, if the storage is an  
RDBMS. This would take me less than two minutes to implement in my tool.

Okay, that won't do for existing blog applications, but that's a symptom  
and not the problem itself. We have to deal with that and instead try to  
aim a bit higher in our search for the «best» solution. We are sure to  
wind up with a crap solution if that's what we're aiming for.

Making Atom require 'first-issued' or 'first-published' would elevate the  
data quality a great number of notches, and I can't see why that's a bad  
thing. In Atom today, people already have to provide an 'atom:issued'. If  
you're having problems with providing a 'first-issued', then you're having  
problems with providing 'issued' as well, and thus you're serving an  
invalid Atom feed.

If you indeed are serving 'issued' correctly, 'first-issued' is just the  
first instance of all the possible values in 'issued'. E.g. 'first-issued  
= issued'. The former can't change while the latter can.

Also, I'd like to note that most of the large CMS's I've had my hands on,  
already supports this. Why this cares goes to point 1) and 2) in the above  
list. If Atom is supposed to cater something else than the extreme narrow  
and poor metadata-quality blogging community, it should provide mechanisms  
to not only allow for, but _promote_, high quality data.

As of now, Atom not only makes (high) quality data optional, it promotes  
bad quality data. How can we ever expect the data quality to improve if we  
encourage people to continue to spew out bad data?

> they're generally subjective.

Yes, and see how wonderful that's worked out for LiveJournal.

> So subjective dates will simply be slammed into the required
> element, and the optional element will be considered superfluous.

Yes, please fill the format with the _least_ trustworthy and reliable  
information, and leave all the reliable stuff out. Heck, even make the  
unreliable information _required_, and the reliable information highly  
optional. Yay!

> Atom consumers, in turn, will simply ignore the spec and assume that  
> first-issued is a subjective date.

Uh. Okay? I'm an Atom consumer, and I would _never_ expect 'first-issued'  
to be subjective. Even less so 'first-published' or 'published'. Not more  
than 'modified' or 'created', at least. Up until the date discussion  
surfaced just recently, I actually thought all Atom dates were objective.  
I'm still amazed that's not the case.

> If folks absolutely must have some sort of immutable publishing date,  
> then it will have to be optional.

Then it's useless, really. The whole point in having such a reliable date  
would be to actually be able to count on it (being there. Always).

> Or better yet, just give atom:issued an optional
> atom:objective="true|false" attribute, with the attribute
> defaulting to "false".

Then, Ken's profile proposal is a much better idea. I still hope we can do  
better than that and not only cater for current bad implementations,  
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  Mon Jul 12 14: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 OAA27946
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 14:04: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 i6CHrkMj046076;
	Mon, 12 Jul 2004 10: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 i6CHrkGa046075;
	Mon, 12 Jul 2004 10:53:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CHrgqH046065
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 10:53:44 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 13 Jul 2004 03:58:51 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Tue, 13 Jul 2004 03:53:38 +1000
Subject: Re: Disambiguating the subject of feed-level metadata
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD190D42.1F1C1%eric.scheid@ironclad.net.au>
In-Reply-To: <m3658tnnn5.fsf@bitsko.slc.ut.us>
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 i6CHrkqH046070
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 13/7/04 3:25 AM, "Ken MacLeod" <ken@bitsko.slc.ut.us> wrote:
> Rather than a <definitions> element, I think free-standing "entity
> constructs" beneath <feed> would be fine (and supporting the streaming
> order requirements intended by PaceElementOrder).  I think it was Bill
> de hÓra who just mentioned that this is pretty much how RSS/RDF 1.0
> does it with <rss:channel>.

my thinking with <definitions> is that it is mostly obvious that what is
contained therein are definitions which need to be referenced elsewhere to
be instantiated. Compare this with a free-floating <tagline> element ...
because it is free-floating as a feed-immediate-child does that mean it
applies to this feed?

> <feed id="tag:synth-site,2004:synth-feed-42">
> <site ref="synth-site"/>
> <modified>2004-05-27T03:48:48Z</modified>
> <site id="site1">
>   ...
> </site>
> <site id="synth-site">
>   <title>Synthesizing site</title>
>   ...
> </site>

if you want to satisfy a streaming parser, you'd better define <site
id="synth-site"> before you reference it with <site ref="synth-site"> ;-)

bundling them all in <definitions>, and requiring that block to be before
<entries> or <this-feed-info>, is one way to support block level
cardinality.

> Note: in this model I think of all <feed>s as a "physical feed",
> distinct from some "logical" model of where entries come from (site,
> category, query).

With synthetic feeds you would want to reference sources, but we still have
to allow for including entries which are specific to this particular feed.
That is, they are not synthetically included in from elsewhere. These could
be little editorial/advertorial announcements (like "this feed provided by
SynthetiCorp - upgrade now to get full content!"), or maintenance notes
("news from abroad will be delayed today"), or even blatent advertisments
("Soylent Corp says eat the green crackers!").

Thus, we'd need a way of saying "this feed document is the source of this
entry, not someplace else".

e.




From owner-atom-syntax@mail.imc.org  Mon Jul 12 14: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 OAA28423
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 14:15: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 i6CI3Mh5048180;
	Mon, 12 Jul 2004 11:03: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 i6CI3Mh3048179;
	Mon, 12 Jul 2004 11:03:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CI3IeL048172
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 11:03:20 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 13 Jul 2004 04:08:31 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Tue, 13 Jul 2004 04:03:18 +1000
Subject: Re: Q: modfied vs issued vs created
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD190F86.1F1CA%eric.scheid@ironclad.net.au>
In-Reply-To: <BD190891.1F1B6%eric.scheid@ironclad.net.au>
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 13/7/04 3:33 AM, "Eric Scheid" <eric.scheid@ironclad.net.au> wrote:

> Then you'll need to write some spec text explaining what an aggregator
> should do if it does happen to come across with an entry where <modified> is
> after <issued>. 

sorry - ignore this bit ... I wrote a longer paragraph to explain why that
would be necessary, thought better of it, deleted that paragraph, and left
this stupid bit in. sorry sorry sorry. It is (subjective time!) 04:00 here.

What an aggregator should do, in a world where entries are modified but
never re-issued, is simply mark the entry as modified. It would be up to the
user not to get annoyed at trudging through endless dreck of trivial
changes, instead being required to make that judgment call themselves every
time (despite the author's frustration in not being able to signal that with
a minor/major semantic). Bah, cranky eric needs sleep.

I can imagine an aggregator could present the user with general +
feed-specific preferences: show all changes, hide minor changes, hide all
changes. If the user doesn't trust a certain author's judgment as to what is
minor or major, then they wouldn't use that hide-minor preference.

e.



From owner-atom-syntax@mail.imc.org  Mon Jul 12 14:16:07 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28460
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 14:16:07 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CI6k4v048374;
	Mon, 12 Jul 2004 11:06:46 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6CI6k5w048373;
	Mon, 12 Jul 2004 11:06:46 -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 i6CI6kEl048367
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 11:06:46 -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 i6CI6crT015292;
	Mon, 12 Jul 2004 11:06:44 -0700 (PDT)
Received: from [192.168.1.100] (h00080d858303.ne.client2.attbi.com [24.61.1.243])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id i6CI6F0t008404;
	Mon, 12 Jul 2004 11:06:36 -0700 (PDT)
In-Reply-To: <BD190DB2.1F1C3%eric.scheid@ironclad.net.au>
References: <BD190DB2.1F1C3%eric.scheid@ironclad.net.au>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-9--320779132; protocol="application/pkcs7-signature"
Message-Id: <27953828-D42E-11D8-82B1-000A95DC3D90@mac.com>
Cc: Atom-Syntax Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: a methodical approach to defining what date  elements we need
Date: Mon, 12 Jul 2004 14:06:09 -0400
To: Eric Scheid <eric.scheid@ironclad.net.au>
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-9--320779132
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 12 Jul 2004, at 1:55 pm, Eric Scheid wrote:

> On 13/7/04 3:38 AM, "Graham" <dtcd@mac.com> wrote:
>
>> So I am not *at all* interested
>> in the date of minor or major modifications, but I am interested in
>> when the publisher deliberately bounces an old entry back to the top 
>> of
>> their list. Re-issuing is much more significant than modification.
>
> would this be expressed by updating the <issued> date?

That's the idea in PaceEntryDates. People object because that's not how 
dc:issued works, but if we're just going to copy DC terms then I don't 
why we're discussing dates here at all.

Graham

--Apple-Mail-9--320779132
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
9w0BCQUxDxcNMDQwNzEyMTgwNjEwWjAjBgkqhkiG9w0BCQQxFgQUskWNd8r20k0JoAxe1UhoPyfH
EFIweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAFH7EkInkVkiEqdwnYuvGCWyx
o40nX8rjuggkpXpAeUKsMoBFhBuBuSdutGv7h3GN+SeRnrsTQce8qtZ8lPrd22SRYxw8dMG+SMN8
bhiaiCtwOxs2Q6H81KDJR6ACwcEx5MWymjvqMdTgGGLdRsuGQSwoVh2FHzH0xw9udP2P4CQsdrp6
e9W1XATM4vJWdXwApFCOud4yyS1CtYEkq6okIFHKbAZD9y/EywEriayO9Gz9KcCcUxxMgFoysovF
vXf3wBy2F2LOb+xcHzRMCYKvrRTRwSUnA1ECuUy7vUaplJ+BOlgmD5dapflMvVJxDpGx1fwkJhiw
qfUZRQerzWyeBQAAAAAAAA==

--Apple-Mail-9--320779132--



From owner-atom-syntax@mail.imc.org  Mon Jul 12 14:16:17 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28480
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 14:16:16 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CI4hdb048249;
	Mon, 12 Jul 2004 11:04:43 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6CI4hW7048248;
	Mon, 12 Jul 2004 11:04:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CI4fpj048241
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 11:04:42 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 13 Jul 2004 04:09:52 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Tue, 13 Jul 2004 04:04:39 +1000
Subject: Re: Rough consensus on PaceElementOrder?
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD190FD7.1F1CC%eric.scheid@ironclad.net.au>
In-Reply-To: <A5F347BE-D42A-11D8-9DBF-000A95A51C9E@sun.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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 13/7/04 3:41 AM, "Tim Bray" <Tim.Bray@Sun.COM> wrote:

> SO: I propose that rather than tear this one apart any further, we ask
> the editors to, in the -01 drafts, recast the data format with the
> <atom:feedinfo> element (anyone should feel free to suggest a better
> name than "feedinfo"), and that those who care about defaulting cook up
> a Pace or three outlining specifically what the options are.  -Tim

+1



From owner-atom-syntax@mail.imc.org  Mon Jul 12 14:16: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 OAA28531
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 14:16: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 i6CI7km2048424;
	Mon, 12 Jul 2004 11:07: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 i6CI7kaI048423;
	Mon, 12 Jul 2004 11:07: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 i6CI7h3c048416
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 11:07:44 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 13 Jul 2004 04:12:55 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Tue, 13 Jul 2004 04:07:43 +1000
Subject: Re: MUST be UTC?
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD19108F.1F1CE%eric.scheid@ironclad.net.au>
In-Reply-To: <opsa1c80qruvpchu@quark>
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 i6CI7k3c048417
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 13/7/04 3:52 AM, "Asbjørn Ulsberg" <asbjorn@tigerstaden.no> wrote:

> Up until the date discussion  surfaced just recently, I actually thought all
> Atom dates were objective.  I'm still amazed that's not the case.
> 
you've not been following the career of Samuel Pepys then?

e.




From owner-atom-syntax@mail.imc.org  Mon Jul 12 14:24: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 OAA29028
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 14:24: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 i6CIG1qL049559;
	Mon, 12 Jul 2004 11:16: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 i6CIG1NT049558;
	Mon, 12 Jul 2004 11:16:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CIG0Bf049547
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 11:16: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 878B27C112; Mon, 12 Jul 2004 21:14:11 +0200 (CEST)
Date: Mon, 12 Jul 2004 20:19:51 +0200
To: "Eric Scheid" <eric.scheid@ironclad.net.au>
Subject: Re: Q: modfied vs issued vs created
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <BD190891.1F1B6%eric.scheid@ironclad.net.au>
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: <opsa1ejdk4uvpchu@quark>
In-Reply-To: <BD190891.1F1B6%eric.scheid@ironclad.net.au>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Tue, 13 Jul 2004 03:33:37 +1000, Eric Scheid  
<eric.scheid@ironclad.net.au> wrote:

> What you propose above doesn't let us distinguish an interesting
> change from a trivial change, by smushing the two together.

No, but what _does_ let us distinguish minor from major updates, is  
PaceSupersede. The current Atom model just can't provide the information  
needed to differ between minor and major updates.

> Then you'll need to write some spec text explaining what an aggregator
> should do if it does happen to come across with an entry where  
> <modified> is after <issued>.

Uhm. Wouldn't that be the 99% use case? The user should be able to choose  
if she wants changes to have entries reappear in bold text or whatever her  
client does. If we support supersedes, though, a user can choose what to  
do with minor and major updates as well as still be able to find out when  
the entry she's looking at was (first) issued. She can then also in a  
relatively simple manner browse backwards in the history of that  
particular entry to see the individual updates of it.

> <modified> changed = the entry has changed in some way

Yup. This is what I'm saying as well.

> <issued> changed = pay attention!

<issued> should not change. Ever.

> I can see however some utility in an optional <first-issued>.

If someone just dies if they can't change their atom:issue date, I think  
we would need 'first-issued', yes.

-- 
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 Jul 12 14:26: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 OAA29102
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 14:26: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 i6CIATFZ048535;
	Mon, 12 Jul 2004 11: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 i6CIATVe048534;
	Mon, 12 Jul 2004 11:10: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 i6CIATif048528
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 11:10:29 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.19] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id 074C47288; Mon, 12 Jul 2004 11:10:33 -0700 (PDT)
In-Reply-To: <OFC66635FE.A2AF5F93-ON88256ECF.0060057C-88256ECF.0060668D@us.ibm.com>
References: <OFC66635FE.A2AF5F93-ON88256ECF.0060057C-88256ECF.0060668D@us.ibm.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <C3C62D26-D42E-11D8-AFCB-000A95BD86C0@mnot.net>
Cc: Atom Syntax <atom-syntax@imc.org>, Mark Baker <distobj@acm.org>,
        David Orchard <dorchard@bea.com>
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: Version vs. Namespace
Date: Mon, 12 Jul 2004 11:10:32 -0700
To: James M Snell <jasnell@us.ibm.com>
X-Mailer: Apple Mail (2.618)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6CIATif048529
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


Well, at least one profile needs to ship with the core spec, so that 
people have something to grab onto and get interop with. Whether that 
lives in the same document or somewhere else is just a packaging issue.

There's already been some related discussion that shouldn't be lost:
   http://www.imc.org/atom-syntax/mail-archive/msg04336.html
   http://www.imc.org/atom-syntax/mail-archive/msg06262.html



On Jul 12, 2004, at 10:32 AM, James M Snell wrote:

> Personally I like the idea of using profiles as opposed to version 
> numbers.  The issue is in determining which profile a particular feed 
> validates against.  However, one could easily imagine various profiles 
> based on specific use cases of the syntax, where each profile 
> determines which extension elements to expect in the feed, strict 
> definition of various optional elements, etc.  Yes, it does add a bit 
> of complexity, but I believe the benefits would be significant.  I do 
> not believe, however, that the core specification should define 
> normative profiles.  Profiles should be submitted as separate RFCs. 
>  The core spec could specify the process of creating profiles.
>
> - James M Snell
>   jasnell@us.ibm.com
>   http://www.ibm.com
>   (877) 511-5082 / Office
>   930-1979 / Tie Line
>
>
>
>
> Mark Baker <distobj@acm.org>
> Sent by: owner-atom-syntax@mail.imc.org
>
> 07/12/2004 10:11 AM
>
> To
> David Orchard <dorchard@bea.com>
>
> cc
> Atom Syntax <atom-syntax@imc.org>
>
> Subject
> Re: Version vs. Namespace
>
>
>
>
>
>
>
>
>  I was just about to say the same thing.  +1
>
>  On Mon, Jul 12, 2004 at 09:17:50AM -0700, David Orchard wrote:
>  >
>  > What kind of an answer is this? "No, it's hard?"
>  >
>  > Who said anything about Atom solving the versioning problem in the 
> general case?  And btw, what ARE the versioning use cases of Atom? 
>  I've started writing up some work on Atom extensibility/versioning, 
> but it's become a bit hard because it seems like everything could be 
> extended/versioned...
>  >
>  > Tim, you should know as well as anybody, that the problems of 
> figuring out what a "version" of a mixed namespace document is can 
> rarely be done with a single integer.  What does a "version" mean 
> under distributed and multi-ns extensibility?
>  >
>  > While Mark's proposal of a profile might appear to be complicated, 
> it ought to get a bit more air time and explanation than the very next 
> message saying "no", especially with discussion of concrete use 
> cases/scenarios.
>  >
>  > Cheers,
>  > Dave
>
>
>

--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org  Mon Jul 12 14:39:49 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00032
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 14:39: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 i6CISwYT050811;
	Mon, 12 Jul 2004 11:28: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 i6CISwAv050810;
	Mon, 12 Jul 2004 11:28:58 -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 i6CISvYZ050804
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 11:28:57 -0700 (PDT)
	(envelope-from dorchard@bea.com)
Received: from ussjfe01.amer.bea.com (ussjfe01b.bea.com [172.16.120.57])
	by ussjmh01.bea.com (Switch-3.0.5/Switch-3.0.0) with ESMTP id i6CIT14Q006529;
	Mon, 12 Jul 2004 11:29:01 -0700
Received: from ussjex01.amer.bea.com ([172.16.120.50]) by ussjfe01.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 12 Jul 2004 11:29:00 -0700
x-mimeole: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: XML Schema and PaceElementOrder
Date: Mon, 12 Jul 2004 11:29:00 -0700
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF08C9BB84@ussjex01.amer.bea.com>
Thread-Topic: XML Schema and PaceElementOrder
Thread-Index: AcRoF5GODS0pTEYjR12vgZu417bKUgAJrAGQ
From: "David Orchard" <dorchard@bea.com>
To: <danny666@virgilio.it>
Cc: "Mark Nottingham" <mnot@mnot.net>, "Tim Bray" <Tim.Bray@Sun.COM>,
        "Atom Syntax" <atom-syntax@imc.org>
X-OriginalArrivalTime: 12 Jul 2004 18:29:00.0824 (UTC) FILETIME=[1A17B980:01C4683E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6CISwYZ050805
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


And if you don't have element order, you can't do schema wildcard extensibility either...

Dave

> -----Original Message-----
> From: owner-atom-syntax@mail.imc.org
> [mailto:owner-atom-syntax@mail.imc.org]On Behalf Of Danny Ayers
> Sent: Monday, July 12, 2004 6:48 AM
> To: danny666@virgilio.it
> Cc: Mark Nottingham; Tim Bray; Atom Syntax
> Subject: XML Schema and PaceElementOrder
> 
> 
> 
> The desire for schema-validity in the group seems to be pretty strong 
> (more so than I guessed). Which means an XML Schema is more 
> desirable, 
> which in turn means that element order standardization is 
> probably also 
> desirable.
> 
> --verbose :  granted that the normative schema will (only) be 
> defined in 
> prose, schema-validity in this sense will be a MUST. The informative 
> machine-readable schemas would in effect offer schema-validation as a 
> MAY. But a very desirable MAY in development, to assist with 
> forementioned MUST. Given that lack of element order (and 
> nesting) make 
> the XSD either painful or under-constrained, I think there's 
> a good case 
> for mandating an order (disallowing any optional nesting).
> 
> Cheers,
> Danny.
> 
> Danny Ayers wrote:
> 
> >
> > Mark Nottingham wrote:
> >
> >>
> >>
> >> On Jul 9, 2004, at 11:07 PM, Tim Bray wrote:
> >>
> >>>
> >>> On the other hand, leaving the order semi-unconstrained (i.e. 
> >>> requiring only that the <atom:entry> crowd bring up the rear) is 
> >>> going to result in serious ugliness in any XSD we 
> produce, which may 
> >>> spill over into SOAP/WSDL territory... still, I lean to -1. -Tim
> >>
> >>
> >>
> >> XSD's problem, not mine.
> >
> >
> >
> > Quite.
> >
> > It seems like putting the cart before the horse to 
> constrain order in 
> > the spec for the benefit of the schema without some reference to 
> > schema-validity.  If we really want a schema, we should be 
> prepared to 
> > use it. I'd suggest either making schema-validity a SHOULD (and 
> > processor validation a MAY) or allowing any order. I suspect the 
> > latter is more likely to gain consensus.
> >
> > Cheers,
> > Danny.
> >
> 
> 
> -- 
> 
> Raw
> http://dannyayers.com
> 
> 



From owner-atom-syntax@mail.imc.org  Mon Jul 12 14:47: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 OAA00450
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 14:47: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 i6CIdpEG052618;
	Mon, 12 Jul 2004 11:39:51 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6CIdpje052617;
	Mon, 12 Jul 2004 11:39:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CIdmqr052609
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 11:39:50 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 13 Jul 2004 04:45:00 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Tue, 13 Jul 2004 04:39:47 +1000
Subject: Re: Q: modfied vs issued vs created
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD191813.1F1F1%eric.scheid@ironclad.net.au>
In-Reply-To: <opsa1ejdk4uvpchu@quark>
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 i6CIdpqr052612
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 13/7/04 4:19 AM, "Asbjørn Ulsberg" <asbjorn@tigerstaden.no> wrote:

> The current Atom model just can't provide the information
> needed to differ between minor and major updates.

Only if we assume <issued> can't change.

If it can change, then we have all the information we need to communicate
minor change, major change, old news, and old news asserted to be still
valid. Pretty handy that.

e.




From owner-atom-syntax@mail.imc.org  Mon Jul 12 14: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 OAA00533
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 14:48: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 i6CIgxb4052884;
	Mon, 12 Jul 2004 11:42:59 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6CIgxmR052883;
	Mon, 12 Jul 2004 11:42:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from 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 i6CIgw4B052877
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 11:42:58 -0700 (PDT)
	(envelope-from mint@franklinmint.fm)
Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94])
	by web02.designerslab.net with asmtp (Exim 4.34)
	id 1Bk5lS-0006i2-L2; Mon, 12 Jul 2004 18:42:58 +0000
Message-ID: <40F2DBAB.7080101@franklinmint.fm>
Date: Mon, 12 Jul 2004 14:42:51 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Janne Jalkanen <Janne.Jalkanen@nokia.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Pace409Response
References: <BD1497CA.1205C%mint@franklinmint.fm> <40F2A8C1.60103@nokia.com>
In-Reply-To: <40F2A8C1.60103@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: <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


Janne Jalkanen wrote:

>
>> 3.1.3.x Status Code 409
>>
>>   The request contained a valid Atom Entry, but it conflicts with 
>> state on
>> the server.The response SHOULD contain enough for information for the 
>> user
>> to resolve the conflict.
>>  
>>
> +1
>
> This would be immensely useful with Wikis, for example.  Though the 
> response format needs to be worked out - perhaps the current contents 
> of the page?
>

We can tackle the response format later. This Pace is just about getting 
the status code in there.

> However, there needs to be a way to tell the Wiki that "ok, this is no 
> longer an editing conflict, but a resolved version".  Typically this 
> is done with some nonce or datetime value.


I'm a wiki ignoramus, so you're losing me here. Could you show me an 
example client/server exchange?

Robert Sayre



From owner-atom-syntax@mail.imc.org  Mon Jul 12 14:51: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 OAA00647
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 14:51: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 i6CIeUAO052647;
	Mon, 12 Jul 2004 11:40:30 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6CIeU3t052646;
	Mon, 12 Jul 2004 11:40: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 i6CIeTE7052640
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 11:40: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 i6CIcQ53003948
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 12:38: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 <0I0R00LQX57K2G@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Mon, 12 Jul 2004 12:40:33 -0600 (MDT)
Received: from [192.168.1.9] ([154.20.133.9])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0R003JF57KL5@mail.sun.net> for atom-syntax@imc.org; Mon,
 12 Jul 2004 12:40:32 -0600 (MDT)
Date: Mon, 12 Jul 2004 11:40:33 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Version vs. Namespace
In-reply-to: <C3C62D26-D42E-11D8-AFCB-000A95BD86C0@mnot.net>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <F50AABC6-D432-11D8-96D9-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: 
 <OFC66635FE.A2AF5F93-ON88256ECF.0060057C-88256ECF.0060668D@us.ibm.com>
 <C3C62D26-D42E-11D8-AFCB-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 Jul 12, 2004, at 11:10 AM, Mark Nottingham wrote:

> Well, at least one profile needs to ship with the core spec, so that 
> people have something to grab onto and get interop with. Whether that 
> lives in the same document or somewhere else is just a packaging 
> issue.

I would like Atom 1.0 to be minimal and finally tuned, to the extent 
that it only includes things that basically everyone would use.  Done 
that way, it would not need a profile.  I see a profile as an admission 
of bloat.  I think that if, for any feature, you could say "that 
wouldn't be in the basic profile", then it should be taken right out of 
Atom. -Tim



From owner-atom-syntax@mail.imc.org  Mon Jul 12 15:02: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 PAA01452
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 15:02: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 i6CIpMX6054229;
	Mon, 12 Jul 2004 11:51: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 i6CIpMC3054228;
	Mon, 12 Jul 2004 11:51:22 -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 i6CIpLCe054222
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 11:51:21 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.19] (unknown [63.96.165.149])
	by mail.mnot.net (Postfix) with ESMTP
	id 6BCE5727D; Mon, 12 Jul 2004 11:51:25 -0700 (PDT)
In-Reply-To: <F4FA5D92-D421-11D8-9D0B-003065EA6144@geckotribe.com>
References: <F4FA5D92-D421-11D8-9D0B-003065EA6144@geckotribe.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <78EB331C-D434-11D8-AFCB-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: Re: Disambiguating the subject of feed-level metadata
Date: Mon, 12 Jul 2004 11:51:23 -0700
To: Antone Roundy <antone@geckotribe.com>
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>
Content-Transfer-Encoding: 7bit


There's a lot of things we *could* do. What's the motivation for either 
defaulting or referencing?

   a) smaller feed representations
   b) save people from excessive keystrokes
   c) modularity
   d) ???

I'm concerned about the complexity and potential vagueness that ANY 
solution in this space might introduce. The simplest thing to do is to 
not have any defaulting or referencing mechanism, so that everything in 
the feed has to be explicit; i.e., if you want entries to have an 
atom:author, each entry must have an atom:author.

Which of the motivations listed above is of enough concern to justify 
the added machinery?



On Jul 12, 2004, at 9:38 AM, Antone Roundy wrote:

>
> On Monday, July 12, 2004, at 09:35  AM, Ken MacLeod wrote:
>>> <feed>
>>>    <defaults>
>>>      <author name="person A">
>>>       ...
>>>    </defaults>
>>>    <entry />
>>>    <entry />
>>>    ...
>>>   </author>
>>
>> Is it your preference for a "defaulting" model rather than an
>> "explicit reference" model?
> Just for the record, we can have both.
>
> <feed>
> 	<referenceable>
> 		<person name="asdf">
> 			...
> 		</person>
> 	<referenceable>
> 	<defaults>
> 		<author>
> 			...
> 		</author>
> 	</defaults>
> 	<entry>
> 		<!--default author-->
> 	</entry>
> 	<entry>
> 		<author ref="asdf" />
> 	</entry>
> 	...
> </feed>
>

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Mon Jul 12 15: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 PAA04068
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 15: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 i6CJJ6sI056550;
	Mon, 12 Jul 2004 12:19: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 i6CJJ6Fa056549;
	Mon, 12 Jul 2004 12:19:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CJJ5aN056534;
	Mon, 12 Jul 2004 12:19:06 -0700 (PDT)
	(envelope-from jasnell@us.ibm.com)
Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32])
	by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i6CJJ410512154;
	Mon, 12 Jul 2004 15:19:04 -0400
Received: from d03nm122.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168])
	by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6CJJ333175528;
	Mon, 12 Jul 2004 13:19:03 -0600
In-Reply-To: <F50AABC6-D432-11D8-96D9-000A95A51C9E@sun.com>
To: Tim Bray <Tim.Bray@Sun.COM>
Cc: Atom Syntax <atom-syntax@imc.org>, owner-atom-syntax@mail.imc.org
MIME-Version: 1.0
Subject: Re: Version vs. Namespace
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
From: James M Snell <jasnell@us.ibm.com>
X-MIMETrack: S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 12:15:36 PM,
	Serialize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 12:15:36 PM,
	Serialize complete at 07/12/2004 12:15:36 PM,
	Itemize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 12:15:36 PM,
	S/MIME Sign complete at 07/12/2004 12:15:36 PM,
	S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 12:19:00 PM,
	S/MIME Sign complete at 07/12/2004 12:19:00 PM,
	Serialize by Router on D03NM122/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at
 07/12/2004 13:19:03,
	Serialize complete at 07/12/2004 13:19:03
Message-ID: <OF8D4D5D17.D15863A6-ON88256ECF.00698609-88256ECF.006A1C31@us.ibm.com>
Date: Mon, 12 Jul 2004 13:19:01 -0600
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z44626_boundary_sign
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>


This is an S/MIME signed message.

---------z44626_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 0069CCA488256ECF_="

This is a multipart message in MIME format.
--=_alternative 0069CCA488256ECF_=
Content-Type: text/plain; charset="US-ASCII"

+1 on this.  The base Atom specification is itself the "basic profile" and 
should be as minimal with as few optional components as possible.  The 
most that the basic specification should say about profiles is that 
profiles may be defined that detail how non core-elements (e.g. elements 
from other namespaces) should be used within given contexts (use cases) 
and specify that such profiles should be submitted as separate RFC's.


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

owner-atom-syntax@mail.imc.org wrote on 07/12/2004 11:40:33 AM:

> 
> On Jul 12, 2004, at 11:10 AM, Mark Nottingham wrote:
> 
> > Well, at least one profile needs to ship with the core spec, so that 
> > people have something to grab onto and get interop with. Whether that 
> > lives in the same document or somewhere else is just a packaging 
> > issue.
> 
> I would like Atom 1.0 to be minimal and finally tuned, to the extent 
> that it only includes things that basically everyone would use.  Done 
> that way, it would not need a profile.  I see a profile as an admission 
> of bloat.  I think that if, for any feature, you could say "that 
> wouldn't be in the basic profile", then it should be taken right out of 
> Atom. -Tim
> 

--=_alternative 0069CCA488256ECF_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">+1 on this. &nbsp;The base Atom specification
is itself the &quot;basic profile&quot; and should be as minimal with as
few optional components as possible. &nbsp;The most that the basic specification
should say about profiles is that profiles may be defined that detail how
non core-elements (e.g. elements from other namespaces) should be used
within given contexts (use cases) and specify that such profiles should
be submitted as separate RFC's.</font>
<br>
<br>
<br><font size=2 face="sans-serif">- James M Snell<br>
 &nbsp;jasnell@us.ibm.com<br>
 &nbsp;http://www.ibm.com<br>
 &nbsp;(877) 511-5082 / Office<br>
 &nbsp;930-1979 / Tie Line</font>
<br>
<br><font size=2><tt>owner-atom-syntax@mail.imc.org wrote on 07/12/2004
11:40:33 AM:<br>
<br>
&gt; <br>
&gt; On Jul 12, 2004, at 11:10 AM, Mark Nottingham wrote:<br>
&gt; <br>
&gt; &gt; Well, at least one profile needs to ship with the core spec,
so that <br>
&gt; &gt; people have something to grab onto and get interop with. Whether
that <br>
&gt; &gt; lives in the same document or somewhere else is just a packaging
<br>
&gt; &gt; issue.<br>
&gt; <br>
&gt; I would like Atom 1.0 to be minimal and finally tuned, to the extent
<br>
&gt; that it only includes things that basically everyone would use. &nbsp;Done
<br>
&gt; that way, it would not need a profile. &nbsp;I see a profile as an
admission <br>
&gt; of bloat. &nbsp;I think that if, for any feature, you could say &quot;that
<br>
&gt; wouldn't be in the basic profile&quot;, then it should be taken right
out of <br>
&gt; Atom. -Tim<br>
&gt; <br>
</tt></font>
--=_alternative 0069CCA488256ECF_=--

---------z44626_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIIUOAIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIISWDCCAtow
ggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1
aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAy
MDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA629xc49NpAPz
cAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7glzJKgPkPzlTZZfznznGbmAWVnNBQ
lyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnwNclOnnP2sKufuPzbTImQTTi5c8JZNZcM
J0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEEBAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1Ud
DgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAPBgNVHRMBAf8EBTADAQH/MDEGA1UdJQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUH
AwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvu
jQupk2oCScMd3FIHLE7hOfu8YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14ke
McF9ViNdewEoBGiAycUq8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIC2jCCAkOgAwIB
AgIDAxS2MA0GCSqGSIb3DQEBBAUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwMTE0MjIw
NzExWhcNMTExMjMxMjIwNzExWjBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25h
bCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrb3Fzj02kA/NwCy5KFMiY
tFgyTJ6kMSQLVSs9uwVHIAVkqy/enDQwZ9b/7uCXMkqA+Q/OVNll/OfOcZuYBZWc0FCXI9qw60KO
J/rTd65FdF4dwp8cw8si0qjOJtYg8cm46fA1yU6ec/awq5+4/NtMiZBNOLlzwlk1lwwnRgXNNwID
AQABo4GqMIGnMBEGCWCGSAGG+EIBAQQEAwIAhzAOBgNVHQ8BAf8EBAMCAcYwHQYDVR0OBBYEFK5U
DpLqqDOpKyQtx8hvMNze80pAMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMA8GA1Ud
EwEB/wQFMAMBAf8wMQYDVR0lBCowKAYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYB
BQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAMnJ7c2YLyrY/PKlFl+7sm8NENfWtFxqdm+6NC6mTagJJ
wx3cUgcsTuE5+7xh9+/G0tTfLzA1qZAQ5GNMPXvmoB9+vJfKnC2JWMFQpIOUEJDXiR4xwX1WI117
ASgEaIDJxSrxHcuuV/hMIO9bgZ6C41MUVmdLTKBgBOImTuIPK8QwggMgMIICiaADAgECAgQ13vTP
MA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQL
EyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0MTUxWhcN
MTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMk
RXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKKlQRkrPFr
U18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkwrFEeO68r
1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOgYaRfMF0x
CzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBD
ZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAxODA4MjIx
NjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAdBgNV
HQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0HQQAEDTAL
GwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwlMQ0AppJu
f7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn00DbOyZY
sih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMgMIICiaADAgEC
AgQ13vTPMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0
MTUxWhcNMTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsG
A1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKK
lQRkrPFrU18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkw
rFEeO68r1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOg
YaRfMF0xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNl
Y3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAx
ODA4MjIxNjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAdBgNVHQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0H
QQAEDTALGwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwl
MQ0AppJuf7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn
00DbOyZYsih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMmMIIC
j6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIxNjM2NTRaMIGFMQsw
CQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEXMBUGA1UEAxMOSmFt
ZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkqhkiG9w0BCQEWEmph
c25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwKpbDG3zMatEuuOT
FYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSyd+7nwqAvbBfPj+0S
vcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7tBJlLrwDRCMoNlPuQ
Kg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQW
BBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOgFAwSamFzbmVs
bEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pAMCcGA1UdJQQgMB4G
CCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAZMKevB7dFfb9
23OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY8BjwVHxiYgG4xkxf
B1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOIzj3lz3xd+uOzqRFg
/Wsg/VMwggMmMIICj6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAy
BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNV
BAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIx
NjM2NTRaMIGFMQswCQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEX
MBUGA1UEAxMOSmFtZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkq
hkiG9w0BCQEWEmphc25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
wKpbDG3zMatEuuOTFYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSy
d+7nwqAvbBfPj+0SvcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7t
BJlLrwDRCMoNlPuQKg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQD
AgXgMB0GA1UdDgQWBBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcU
AgOgFAwSamFzbmVsbEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA
MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQAD
gYEAZMKevB7dFfb923OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY
8BjwVHxiYgG4xkxfB1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOI
zj3lz3xd+uOzqRFg/Wsg/VMxggG7MIIBtwIBATBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJ
bnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0g
Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwF+kzAJBgUrDgMCGgUAoIGiMBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDcxMjE5MTUzNlowIwYJKoZIhvcNAQkEMRYE
FO8KaNqVwkXduWIBAakMB1D41Iv7MEMGCSqGSIb3DQEJDzE2MDQwBwYFKw4DAh0wDgYIKoZIhvcN
AwICAgCAMAoGCCqGSIb3DQMHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAjlOe8kma
SQdBSbkOmDWXJgPV12lCQ0ZqNoXPR18aEcpGakTgTmdJQTUG6ygto5ijsRPCtimoDrx25mEJ69en
QLa/fblcisyCdWsq3K1sw9CpnkoLU1SyC5iroGgGLEhPdHi/wUxVtUjcxmqnp4lJtsej7tx/vwwG
GWhjxQfgGrUAAAAA

---------z44626_boundary_sign--



From owner-atom-syntax@mail.imc.org  Mon Jul 12 15:29: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 PAA04134
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 15:29: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 i6CJCF8S055908;
	Mon, 12 Jul 2004 12:12: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 i6CJCFux055907;
	Mon, 12 Jul 2004 12:12:15 -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 i6CJCE7f055898
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 12:12:14 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.19] (unknown [63.96.165.149])
	by mail.mnot.net (Postfix) with ESMTP
	id 75396727D; Mon, 12 Jul 2004 12:12:18 -0700 (PDT)
In-Reply-To: <87r7rhh188.fsf@nwalsh.com>
References: <87smbymve3.fsf@nwalsh.com> <B40394C3-D356-11D8-9A61-000A95BD86C0@mnot.net> <87llhqjycb.fsf@nwalsh.com> <8725AB57-D39C-11D8-9A61-000A95BD86C0@mnot.net> <87r7rhh188.fsf@nwalsh.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <643E0744-D437-11D8-AFCB-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: Atom Syntax <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: Re: Version vs. Namespace
Date: Mon, 12 Jul 2004 12:12:17 -0700
To: Norman Walsh <ndw@nwalsh.com>
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>
Content-Transfer-Encoding: 7bit



On Jul 12, 2004, at 5:13 AM, Norman Walsh wrote:
>
> Extension metadata is already going to be in another namespace, so
> that's not really an issue. If I understand you, what you're proposing
> boils down to a namespace name for the atom:feed/atom:entry elements
> and a different namespace name for the atommeta:title, atommeta:author,
> etc. elements.

No; I'm proposing that whatever ships with Atom -- i.e., the container 
and any "core" metadata -- be associated with a single namespace. 
However, if we have to change the syntax or semantics of any of that 
core metadata, we'll have to change its name (either the namespace URI 
or the localname).

> I think
> keeping everything in a single namespace so that a vanilla feed can
> just use the default namespace for all elements is a feature we should
> not lose without compelling motivation.

Totally agreed.

> But I don't think you've covered the use case that I think is most 
> important.
> Suppose that a year from now, we all have Atom 1.0 under our belts and 
> we've
> been using it for a while. Discussion has continued after the 1.0 
> release and
> we're pretty sure we have the categorization problem solved (just to 
> pick an
> example, choose anything that isn't scheduled for the 1.0 release).
>
> Now we want to publish Atom 1.1 with a new, optional element, 
> atom:category.
>
> We could:
>
>  1. Add this in a new namespace
>  2. Add this in a new namespace and change *all* the elements to the 
> new namespace
>  3. Add this in the old namespace and change the version/profile 
> attribute.
>
> Choice 1 is "right" by some metrics, but won't feel like we're 
> integrating
> atom:category into Atom proper.
>
> Choice 2 is "right" by some metrics, but it really is a heck of a 
> cliff that
> everyone has to jump off. It will be *years* before everyone is ready 
> to change
> all their feeds and tools.
>
> Choice 3 is "right" by some metrics, and if its combined with a
> reasonable versioning policy in 1.0 offers the maximum bang for the
> minumum buck, IMHO.

This explains what I mean by 'profiling' very well -- thanks! :)

There are actually two issues at hand; what namespace to add the new 
metadata in, and how to identify if they're required parts of the 
profile.

I think that the WG can add new metadata into the existing Atom 
namespace, as long as we don't change existing semantics. I.e., we can 
add atom:Category later without revving the version/profile attribute.

The only reason we'd want to rev the version/profile attribute is if we 
change the requirements about the presence of the new metadata 
(atom:Category) in the feed; i.e., if we say "an entry MUST have an 
atom:Category element", a new version/profile id is required, so that 
software can recognise the difference.


--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Mon Jul 12 15:30: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 PAA04196
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 15:30: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 i6CJBcvG055867;
	Mon, 12 Jul 2004 12:11: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 i6CJBcYq055866;
	Mon, 12 Jul 2004 12:11:38 -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 i6CJBbkn055824
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 12:11:37 -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 i6CJBX53015583
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 14:11:34 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6CJBX19015579;
	Mon, 12 Jul 2004 14:11:33 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Q: modfied vs issued vs created
References: <BD191813.1F1F1%eric.scheid@ironclad.net.au>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 12 Jul 2004 14:11:33 -0500
In-Reply-To: <BD191813.1F1F1%eric.scheid@ironclad.net.au>
Message-ID: <m3vfgtm462.fsf@bitsko.slc.ut.us>
Lines: 25
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 i6CJBckn055861
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


Eric Scheid <eric.scheid@ironclad.net.au> writes:

> On 13/7/04 4:19 AM, "Asbjørn Ulsberg" <asbjorn@tigerstaden.no> wrote:
> 
> > The current Atom model just can't provide the information needed
> > to differ between minor and major updates.
> 
> Only if we assume <issued> can't change.
> 
> If it can change, then we have all the information we need to
> communicate minor change, major change, old news, and old news
> asserted to be still valid. Pretty handy that.

Based on empirical evidence from wikis that implement that feature, I
would say that this would only work for a very few feeds from
individuals or groups that have a relatively high level of discipline.

I can see us specifying "reissued" would be a purpose for changing
<issued>, but I would still expect clients to provide the user the
option of selecting either of <issued>, <modified>, or <modified>+diff
for determining redisplay on a feed-by-feed basis.

Is this consistent with your proposal?

  -- Ken



From owner-atom-syntax@mail.imc.org  Mon Jul 12 16: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 QAA07733
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 16:08: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 i6CJpbv5059286;
	Mon, 12 Jul 2004 12: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 i6CJpbFS059285;
	Mon, 12 Jul 2004 12:51:37 -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 i6CJpbYu059279
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 12:51:37 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.19] (unknown [63.96.165.149])
	by mail.mnot.net (Postfix) with ESMTP
	id 46167727D; Mon, 12 Jul 2004 12:51:41 -0700 (PDT)
In-Reply-To: <F50AABC6-D432-11D8-96D9-000A95A51C9E@sun.com>
References: <OFC66635FE.A2AF5F93-ON88256ECF.0060057C-88256ECF.0060668D@us.ibm.com> <C3C62D26-D42E-11D8-AFCB-000A95BD86C0@mnot.net> <F50AABC6-D432-11D8-96D9-000A95A51C9E@sun.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <E476C23E-D43C-11D8-AFCB-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: Atom Syntax <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: Re: Version vs. Namespace
Date: Mon, 12 Jul 2004 12:51:40 -0700
To: Tim Bray <Tim.Bray@Sun.COM>
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>
Content-Transfer-Encoding: 7bit



On Jul 12, 2004, at 11:40 AM, Tim Bray wrote:

>
> On Jul 12, 2004, at 11:10 AM, Mark Nottingham wrote:
>
>> Well, at least one profile needs to ship with the core spec, so that 
>> people have something to grab onto and get interop with. Whether that 
>> lives in the same document or somewhere else is just a packaging 
>> issue.
>
> I would like Atom 1.0 to be minimal and finally tuned, to the extent 
> that it only includes things that basically everyone would use.  Done 
> that way, it would not need a profile.  I see a profile as an 
> admission of bloat.  I think that if, for any feature, you could say 
> "that wouldn't be in the basic profile", then it should be taken right 
> out of Atom. -Tim

I agree that the metadata that ships with Atom should be minimal and 
finely-tuned.

I disagree that the requirements for the presence of that metadata 
(e.g., "MUST have a title") should be set in stone for all things 
called "Atom 1.0." There are other uses of the Atom format that won't 
care a whit about the title, and they shouldn't be forced to use it.

Perhaps you misunderstand what I mean when I say "profile." It's not an 
exclusive device (at least, in the core); it doesn't say "you don't use 
these extensions" or "you can only use this handful". Rather, it's a 
set that can be built upon; It's "you MUST have one of these and one of 
those, and you can have other stuff too."

I agree that an exclusive profile in Atom 1.0 would be an admission of 
bloat, but that's not what's on the table here. What's on the table is 
a way of factoring out the requirements pertaining to the presence of 
particular pieces of metadata in feeds and entries.

Moreover, much the same could be said about a "version" attribute; it 
allows the same kind of flexibility. Why don't you consider the version 
attribute bloat? All that calling this a profile does is allow us to 
organise the spec in a clearer, more helpful and extensible way; e.g.,

Atom Container Constructs
    atom:feed
    atom:entry

Atom Metadata Constructs
    atom:author
    atom:title
    atom:content
    ...

Atom Core Profile
    MUST have a title, etc.



--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Mon Jul 12 16:15: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 QAA08215
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 16:15: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 i6CK7RL9060232;
	Mon, 12 Jul 2004 13:07: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 i6CK7Rnx060231;
	Mon, 12 Jul 2004 13:07:27 -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 i6CK7QgT060206;
	Mon, 12 Jul 2004 13:07:26 -0700 (PDT)
	(envelope-from jasnell@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.2) with ESMTP id i6CK7Juc683488;
	Mon, 12 Jul 2004 16:07:19 -0400
Received: from d03nm122.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 i6CK7IMG367058;
	Mon, 12 Jul 2004 14:07:18 -0600
In-Reply-To: <643E0744-D437-11D8-AFCB-000A95BD86C0@mnot.net>
To: Mark Nottingham <mnot@mnot.net>
Cc: Atom Syntax <atom-syntax@imc.org>, Norman Walsh <ndw@nwalsh.com>,
        owner-atom-syntax@mail.imc.org
MIME-Version: 1.0
Subject: Re: Version vs. Namespace
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
From: James M Snell <jasnell@us.ibm.com>
X-MIMETrack: S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 01:02:00 PM,
	Serialize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 01:02:00 PM,
	Serialize complete at 07/12/2004 01:02:00 PM,
	Itemize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 01:02:00 PM,
	S/MIME Sign complete at 07/12/2004 01:02:00 PM,
	S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 01:07:13 PM,
	S/MIME Sign complete at 07/12/2004 01:07:13 PM,
	Serialize by Router on D03NM122/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at
 07/12/2004 14:07:17,
	Serialize complete at 07/12/2004 14:07:17
Message-ID: <OFB0A3A46F.712D84BB-ON88256ECF.006CEDDF-88256ECF.006E8628@us.ibm.com>
Date: Mon, 12 Jul 2004 14:07:13 -0600
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z18134_boundary_sign
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>


This is an S/MIME signed message.

---------z18134_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 006E0C3188256ECF_="

This is a multipart message in MIME format.
--=_alternative 006E0C3188256ECF_=
Content-Type: text/plain; charset="US-ASCII"

Comments inline...

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

owner-atom-syntax@mail.imc.org wrote on 07/12/2004 12:12:17 PM:

> 
> 
> On Jul 12, 2004, at 5:13 AM, Norman Walsh wrote:
> >
> > Extension metadata is already going to be in another namespace, so
> > that's not really an issue. If I understand you, what you're proposing
> > boils down to a namespace name for the atom:feed/atom:entry elements
> > and a different namespace name for the atommeta:title, 
atommeta:author,
> > etc. elements.
> 
> No; I'm proposing that whatever ships with Atom -- i.e., the container 
> and any "core" metadata -- be associated with a single namespace. 
> However, if we have to change the syntax or semantics of any of that 
> core metadata, we'll have to change its name (either the namespace URI 
> or the localname).
> 

+1 ... any change to syntax or semantics should require a version or 
namespace change.  I would argue, however, that the addition of even 
optional elements constitutes a syntax/semantics change.

> > I think
> > keeping everything in a single namespace so that a vanilla feed can
> > just use the default namespace for all elements is a feature we should
> > not lose without compelling motivation.
> 
> Totally agreed.
> 
> > But I don't think you've covered the use case that I think is most 
> > important.
> > Suppose that a year from now, we all have Atom 1.0 under our belts and 

> > we've
> > been using it for a while. Discussion has continued after the 1.0 
> > release and
> > we're pretty sure we have the categorization problem solved (just to 
> > pick an
> > example, choose anything that isn't scheduled for the 1.0 release).
> >
> > Now we want to publish Atom 1.1 with a new, optional element, 
> > atom:category.
> >
> > We could:
> >
> >  1. Add this in a new namespace
> >  2. Add this in a new namespace and change *all* the elements to the 
> > new namespace
> >  3. Add this in the old namespace and change the version/profile 
> > attribute.
> >
> > Choice 1 is "right" by some metrics, but won't feel like we're 
> > integrating
> > atom:category into Atom proper.
> >
> > Choice 2 is "right" by some metrics, but it really is a heck of a 
> > cliff that
> > everyone has to jump off. It will be *years* before everyone is ready 
> > to change
> > all their feeds and tools.
> >
> > Choice 3 is "right" by some metrics, and if its combined with a
> > reasonable versioning policy in 1.0 offers the maximum bang for the
> > minumum buck, IMHO.
> 
> This explains what I mean by 'profiling' very well -- thanks! :)
> 
> There are actually two issues at hand; what namespace to add the new 
> metadata in, and how to identify if they're required parts of the 
> profile.
> 
> I think that the WG can add new metadata into the existing Atom 
> namespace, as long as we don't change existing semantics. I.e., we can 
> add atom:Category later without revving the version/profile attribute.
> 

While I'm ok with this, I'd have to argue that the bar should be set 
rather high for the working group to consider such changes after Atom 1.0 
is out the door.  Even the addition of new optional elements within the 
same namespace could cause problems for various implementations. 

There is one other possibility.  It would be possible for this WG to 
define an "extension namespace" within which non-core new optional 
elements could be added.  e.g. <atomex:Category>.  The bar for adding 
elements to this extension namespace would be set much lower than the core 
atom namespace. The semantics, of course, would be that all elements in 
the atomex namespace would be always optional.  Once (and if) elements in 
the atomex namespace became popular/essential enough, this work group 
could decide on whether or not those elements should be moved to the core 
namespace, causing a rev in the version attribute value.

Each element added to the atomex namespace would need to be described in 
it's own RFC (meaning people would actually have to go through some work 
to define them rather than inventing them willy-nilly). 

It is, at least, an idea that *may* be worth considering. 

> The only reason we'd want to rev the version/profile attribute is if we 
> change the requirements about the presence of the new metadata 
> (atom:Category) in the feed; i.e., if we say "an entry MUST have an 
> atom:Category element", a new version/profile id is required, so that 
> software can recognise the difference.
> 
> 
> --
> Mark Nottingham     http://www.mnot.net/
> 

--=_alternative 006E0C3188256ECF_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">Comments inline...</font>
<br>
<br><font size=2 face="sans-serif">- James M Snell<br>
 &nbsp;jasnell@us.ibm.com<br>
 &nbsp;http://www.ibm.com<br>
 &nbsp;(877) 511-5082 / Office<br>
 &nbsp;930-1979 / Tie Line</font>
<br>
<br><font size=2><tt>owner-atom-syntax@mail.imc.org wrote on 07/12/2004
12:12:17 PM:<br>
<br>
&gt; <br>
&gt; <br>
&gt; On Jul 12, 2004, at 5:13 AM, Norman Walsh wrote:<br>
&gt; &gt;<br>
&gt; &gt; Extension metadata is already going to be in another namespace,
so<br>
&gt; &gt; that's not really an issue. If I understand you, what you're
proposing<br>
&gt; &gt; boils down to a namespace name for the atom:feed/atom:entry elements<br>
&gt; &gt; and a different namespace name for the atommeta:title, atommeta:author,<br>
&gt; &gt; etc. elements.<br>
&gt; <br>
&gt; No; I'm proposing that whatever ships with Atom -- i.e., the container
<br>
&gt; and any &quot;core&quot; metadata -- be associated with a single namespace.
<br>
&gt; However, if we have to change the syntax or semantics of any of that
<br>
&gt; core metadata, we'll have to change its name (either the namespace
URI <br>
&gt; or the localname).<br>
&gt; </tt></font>
<br>
<br><font size=2><tt>+1 ... any change to syntax or semantics should require
a version or namespace change. &nbsp;I would argue, however, that the addition
of even optional elements constitutes a syntax/semantics change.</tt></font>
<br><font size=2><tt><br>
&gt; &gt; I think<br>
&gt; &gt; keeping everything in a single namespace so that a vanilla feed
can<br>
&gt; &gt; just use the default namespace for all elements is a feature
we should<br>
&gt; &gt; not lose without compelling motivation.<br>
&gt; <br>
&gt; Totally agreed.<br>
&gt; <br>
&gt; &gt; But I don't think you've covered the use case that I think is
most <br>
&gt; &gt; important.<br>
&gt; &gt; Suppose that a year from now, we all have Atom 1.0 under our
belts and <br>
&gt; &gt; we've<br>
&gt; &gt; been using it for a while. Discussion has continued after the
1.0 <br>
&gt; &gt; release and<br>
&gt; &gt; we're pretty sure we have the categorization problem solved (just
to <br>
&gt; &gt; pick an<br>
&gt; &gt; example, choose anything that isn't scheduled for the 1.0 release).<br>
&gt; &gt;<br>
&gt; &gt; Now we want to publish Atom 1.1 with a new, optional element,
<br>
&gt; &gt; atom:category.<br>
&gt; &gt;<br>
&gt; &gt; We could:<br>
&gt; &gt;<br>
&gt; &gt; &nbsp;1. Add this in a new namespace<br>
&gt; &gt; &nbsp;2. Add this in a new namespace and change *all* the elements
to the <br>
&gt; &gt; new namespace<br>
&gt; &gt; &nbsp;3. Add this in the old namespace and change the version/profile
<br>
&gt; &gt; attribute.<br>
&gt; &gt;<br>
&gt; &gt; Choice 1 is &quot;right&quot; by some metrics, but won't feel
like we're <br>
&gt; &gt; integrating<br>
&gt; &gt; atom:category into Atom proper.<br>
&gt; &gt;<br>
&gt; &gt; Choice 2 is &quot;right&quot; by some metrics, but it really
is a heck of a <br>
&gt; &gt; cliff that<br>
&gt; &gt; everyone has to jump off. It will be *years* before everyone
is ready <br>
&gt; &gt; to change<br>
&gt; &gt; all their feeds and tools.<br>
&gt; &gt;<br>
&gt; &gt; Choice 3 is &quot;right&quot; by some metrics, and if its combined
with a<br>
&gt; &gt; reasonable versioning policy in 1.0 offers the maximum bang for
the<br>
&gt; &gt; minumum buck, IMHO.<br>
&gt; <br>
&gt; This explains what I mean by 'profiling' very well -- thanks! :)<br>
&gt; <br>
&gt; There are actually two issues at hand; what namespace to add the new
<br>
&gt; metadata in, and how to identify if they're required parts of the
<br>
&gt; profile.<br>
&gt; <br>
&gt; I think that the WG can add new metadata into the existing Atom <br>
&gt; namespace, as long as we don't change existing semantics. I.e., we
can <br>
&gt; add atom:Category later without revving the version/profile attribute.<br>
&gt; </tt></font>
<br>
<br><font size=2><tt>While I'm ok with this, I'd have to argue that the
bar should be set rather high for the working group to consider such changes
after Atom 1.0 is out the door. &nbsp;Even the addition of new optional
elements within the same namespace could cause problems for various implementations.
&nbsp;</tt></font>
<br>
<br><font size=2><tt>There is one other possibility. &nbsp;It would be
possible for this WG to define an &quot;extension namespace&quot; within
which non-core new optional elements could be added. &nbsp;e.g. &lt;atomex:Category&gt;.
&nbsp;The bar for adding elements to this extension namespace would be
set much lower than the core atom namespace. The semantics, of course,
would be that all elements in the atomex namespace would be always optional.
&nbsp;Once (and if) elements in the atomex namespace became popular/essential
enough, this work group could decide on whether or not those elements should
be moved to the core namespace, causing a rev in the version attribute
value.</tt></font>
<br>
<br><font size=2><tt>Each element added to the atomex namespace would need
to be described in it's own RFC (meaning people would actually have to
go through some work to define them rather than inventing them willy-nilly).
</tt></font>
<br>
<br><font size=2><tt>It is, at least, an idea that *may* be worth considering.
&nbsp;</tt></font>
<br><font size=2><tt><br>
&gt; The only reason we'd want to rev the version/profile attribute is
if we <br>
&gt; change the requirements about the presence of the new metadata <br>
&gt; (atom:Category) in the feed; i.e., if we say &quot;an entry MUST have
an <br>
&gt; atom:Category element&quot;, a new version/profile id is required,
so that <br>
&gt; software can recognise the difference.<br>
&gt; <br>
&gt; <br>
&gt; --<br>
&gt; Mark Nottingham &nbsp; &nbsp; http://www.mnot.net/<br>
&gt; <br>
</tt></font>
--=_alternative 006E0C3188256ECF_=--

---------z18134_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIIUOAIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIISWDCCAtow
ggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1
aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAy
MDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA629xc49NpAPz
cAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7glzJKgPkPzlTZZfznznGbmAWVnNBQ
lyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnwNclOnnP2sKufuPzbTImQTTi5c8JZNZcM
J0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEEBAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1Ud
DgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAPBgNVHRMBAf8EBTADAQH/MDEGA1UdJQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUH
AwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvu
jQupk2oCScMd3FIHLE7hOfu8YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14ke
McF9ViNdewEoBGiAycUq8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIC2jCCAkOgAwIB
AgIDAxS2MA0GCSqGSIb3DQEBBAUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwMTE0MjIw
NzExWhcNMTExMjMxMjIwNzExWjBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25h
bCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrb3Fzj02kA/NwCy5KFMiY
tFgyTJ6kMSQLVSs9uwVHIAVkqy/enDQwZ9b/7uCXMkqA+Q/OVNll/OfOcZuYBZWc0FCXI9qw60KO
J/rTd65FdF4dwp8cw8si0qjOJtYg8cm46fA1yU6ec/awq5+4/NtMiZBNOLlzwlk1lwwnRgXNNwID
AQABo4GqMIGnMBEGCWCGSAGG+EIBAQQEAwIAhzAOBgNVHQ8BAf8EBAMCAcYwHQYDVR0OBBYEFK5U
DpLqqDOpKyQtx8hvMNze80pAMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMA8GA1Ud
EwEB/wQFMAMBAf8wMQYDVR0lBCowKAYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYB
BQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAMnJ7c2YLyrY/PKlFl+7sm8NENfWtFxqdm+6NC6mTagJJ
wx3cUgcsTuE5+7xh9+/G0tTfLzA1qZAQ5GNMPXvmoB9+vJfKnC2JWMFQpIOUEJDXiR4xwX1WI117
ASgEaIDJxSrxHcuuV/hMIO9bgZ6C41MUVmdLTKBgBOImTuIPK8QwggMgMIICiaADAgECAgQ13vTP
MA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQL
EyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0MTUxWhcN
MTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMk
RXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKKlQRkrPFr
U18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkwrFEeO68r
1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOgYaRfMF0x
CzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBD
ZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAxODA4MjIx
NjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAdBgNV
HQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0HQQAEDTAL
GwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwlMQ0AppJu
f7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn00DbOyZY
sih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMgMIICiaADAgEC
AgQ13vTPMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0
MTUxWhcNMTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsG
A1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKK
lQRkrPFrU18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkw
rFEeO68r1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOg
YaRfMF0xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNl
Y3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAx
ODA4MjIxNjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAdBgNVHQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0H
QQAEDTALGwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwl
MQ0AppJuf7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn
00DbOyZYsih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMmMIIC
j6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIxNjM2NTRaMIGFMQsw
CQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEXMBUGA1UEAxMOSmFt
ZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkqhkiG9w0BCQEWEmph
c25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwKpbDG3zMatEuuOT
FYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSyd+7nwqAvbBfPj+0S
vcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7tBJlLrwDRCMoNlPuQ
Kg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQW
BBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOgFAwSamFzbmVs
bEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pAMCcGA1UdJQQgMB4G
CCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAZMKevB7dFfb9
23OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY8BjwVHxiYgG4xkxf
B1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOIzj3lz3xd+uOzqRFg
/Wsg/VMwggMmMIICj6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAy
BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNV
BAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIx
NjM2NTRaMIGFMQswCQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEX
MBUGA1UEAxMOSmFtZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkq
hkiG9w0BCQEWEmphc25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
wKpbDG3zMatEuuOTFYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSy
d+7nwqAvbBfPj+0SvcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7t
BJlLrwDRCMoNlPuQKg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQD
AgXgMB0GA1UdDgQWBBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcU
AgOgFAwSamFzbmVsbEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA
MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQAD
gYEAZMKevB7dFfb923OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY
8BjwVHxiYgG4xkxfB1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOI
zj3lz3xd+uOzqRFg/Wsg/VMxggG7MIIBtwIBATBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJ
bnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0g
Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwF+kzAJBgUrDgMCGgUAoIGiMBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDcxMjIwMDIwMFowIwYJKoZIhvcNAQkEMRYE
FKHz5RDbZ4N6VS347Ug+ZwnuG3k1MEMGCSqGSIb3DQEJDzE2MDQwBwYFKw4DAh0wDgYIKoZIhvcN
AwICAgCAMAoGCCqGSIb3DQMHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAAaDcqDf/
02Fm+/M5ukDZvCYLBiLNXmGUs3M3jY38vwO668qaRgh29VtYjEcvXfYrEzHElUIMQJAGUlZYDJ4I
E06iL/4OCuz+ZrGGWIjpXQVvWP7TFqk8PqBTJ/ioNli5bStegvqpXfgOnOzhVPfzYvEISDneTfSx
xGR93aIItW0AAAAA

---------z18134_boundary_sign--



From owner-atom-syntax@mail.imc.org  Mon Jul 12 16: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 QAA08636
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 16:21: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 i6CKDZDU060745;
	Mon, 12 Jul 2004 13:13: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 i6CKDZBU060744;
	Mon, 12 Jul 2004 13:13:35 -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 i6CKDYif060738
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 13:13:34 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.19] (unknown [63.96.165.149])
	by mail.mnot.net (Postfix) with ESMTP
	id D31BA727D; Mon, 12 Jul 2004 13:13:38 -0700 (PDT)
In-Reply-To: <OFB0A3A46F.712D84BB-ON88256ECF.006CEDDF-88256ECF.006E8628@us.ibm.com>
References: <OFB0A3A46F.712D84BB-ON88256ECF.006CEDDF-88256ECF.006E8628@us.ibm.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <F5CD2412-D43F-11D8-AFCB-000A95BD86C0@mnot.net>
Cc: Atom Syntax <atom-syntax@imc.org>, Norman Walsh <ndw@nwalsh.com>
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: Version vs. Namespace
Date: Mon, 12 Jul 2004 13:13:37 -0700
To: James M Snell <jasnell@us.ibm.com>
X-Mailer: Apple Mail (2.618)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6CKDYif060739
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 Jul 12, 2004, at 1:07 PM, James M Snell wrote:
> While I'm ok with this, I'd have to argue that the bar should be set 
> rather high for the working group to consider such changes after Atom 
> 1.0 is out the door.  Even the addition of new optional elements 
> within the same namespace could cause problems for various 
> implementations.  

How so?

> There is one other possibility.  It would be possible for this WG to 
> define an "extension namespace" within which non-core new optional 
> elements could be added.  e.g. <atomex:Category>.  The bar for adding 
> elements to this extension namespace would be set much lower than the 
> core atom namespace. The semantics, of course, would be that all 
> elements in the atomex namespace would be always optional.  Once (and 
> if) elements in the atomex namespace became popular/essential enough, 
> this work group could decide on whether or not those elements should 
> be moved to the core namespace, causing a rev in the version attribute 
> value.
>
> Each element added to the atomex namespace would need to be described 
> in it's own RFC (meaning people would actually have to go through some 
> work to define them rather than inventing them willy-nilly).

Hmm, this is interesting. I take it the atomex namespace would be only 
used for WG extensions, rather than anybody who wants to?

I imagine we'll end up doing this in any case, because we'll want to 
use in-development namespaces until any such extensions are final.

Cheers,


--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org  Mon Jul 12 16: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 QAA09650
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 16:31: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 i6CKOr6E061779;
	Mon, 12 Jul 2004 13: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 i6CKOrQE061778;
	Mon, 12 Jul 2004 13:24:53 -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.184])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CKOqFY061764
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 13:24:52 -0700 (PDT)
	(envelope-from sewe@rbg.informatik.tu-darmstadt.de)
Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de)
	by moutng.kundenserver.de with esmtp (Exim 3.35 #1)
	id 1Bk7M8-0006od-00
	for atom-syntax@imc.org; Mon, 12 Jul 2004 22:24:56 +0200
Received: from [62.224.60.117] (helo=baron)
	by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1)
	id 1Bk7M7-0006aN-00
	for atom-syntax@imc.org; Mon, 12 Jul 2004 22:24:55 +0200
Message-ID: <001001c4684e$65d03c20$753ce03e@baron>
From: "Andreas Sewe" <sewe@rbg.informatik.tu-darmstadt.de>
To: "[Atom]" <atom-syntax@imc.org>
References: <OFC66635FE.A2AF5F93-ON88256ECF.0060057C-88256ECF.0060668D@us.ibm.com> <C3C62D26-D42E-11D8-AFCB-000A95BD86C0@mnot.net>
Subject: Re: Version vs. Namespace
Date: Mon, 12 Jul 2004 22:25:21 +0200
Organization: Fachbereich Informatik, TU Darmstadt
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:275eb74a6eb9feb006a62452721ee94c
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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:
> 3) The "package" of metadata used in a feed is described by a "profile"
> or "version" attribute, e.g.,
>    <atom:feed profile="http://.../..."> ... </atom:feed>
>    Atom would ship with a "default" profile that says there MUST be an
> atom:title, etc. -- just as the spec currently does -- and that
> extensions are allowed on top of that. More specialised vertical uses
> of Atom can likewise describe their own profiles; if they can get tool
> support for them, good on them.

FYI, the "application/xhtml+xml" media type registers an optional profile too
[1] such that e.g. content negotiation can rely on the profile as well. And at
least for "application/smil+xml" there are plans to add a profile parameter to
the registered media type as well [2].

I hope this helps.

Regards,

Andreas Sewe

[1] <http://www.rfc-editor.org/rfc/rfc3236.txt>
[2] <http://www.w3.org/2002/06/registering-mediatype#Status>



From owner-atom-syntax@mail.imc.org  Mon Jul 12 16: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 QAA12293
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 16: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 i6CKhGL6063006;
	Mon, 12 Jul 2004 13:43: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 i6CKhGKP063005;
	Mon, 12 Jul 2004 13:43:16 -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 i6CKhGSH062996
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 13:43: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 (sccrmhc11) with SMTP
          id <20040712204313011009m8dte>; Mon, 12 Jul 2004 20:43:13 +0000
Date: Mon, 12 Jul 2004 14:43:12 -0600
Subject: Re: a methodical approach to defining what date  elements we need
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: <47071860-D42A-11D8-82B1-000A95DC3D90@mac.com>
Message-Id: <175C69EB-D444-11D8-9D0B-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 Monday, July 12, 2004, at 11:38  AM, Graham wrote:
> I think the list of dates is way too abstract to be useful.
Yes, I agree that the initial list of 8 contains a LOT more dates than 
we want in the feed.  The purpose of the list is merely to create a 
(hopefully) comprehensive list of POSSIBLE dates, where there's no 
ambiguity about what EXACTLY we mean when we refer to one of them, for 
us to whittle down to what we want.  For example, I think we have a 
pretty good idea of what the term "issued" means, but I don't think we 
have agreement on what the <issued> element should contain.

> 4) each objective publication date
> 8) any subjective publication date the author may wish to associate 
> with the entry
>
Is it the first #4, and cannot change?  Is it the last #4?  Is it #8?  
It COULD be any of them.  Let's decide which of those is/are useful and 
decide on an element to put it/them in.

>  As an aggregator author, I am only interested in one, maybe 2 dates:
> 1) The date I would have first found the entry had I been checking 
> once a minute
>> IV) Aggregators: Most interested in 2-4, perhaps including only the  
>> first, last, or first and last of each.
The first #4.
>> atom:first-issued or atom:first-published (first 4)
>>     An objective publication date. REQUIRED. MUST specify a timezone 
>> (which might be -00:00 if the timezone is unknown) which MUST be 
>> numeric.

> 2) A date to show the user, usually the same as above
Under what circumstances would you want to show a different date?  
Which date would that be?



From owner-atom-syntax@mail.imc.org  Mon Jul 12 17: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 RAA13686
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 17:03: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 i6CKlolh063332;
	Mon, 12 Jul 2004 13: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 i6CKloSi063331;
	Mon, 12 Jul 2004 13:47:50 -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 i6CKloud063315
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 13:47:50 -0700 (PDT)
	(envelope-from jasnell@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.2) with ESMTP id i6CKlnuc721706;
	Mon, 12 Jul 2004 16:47:49 -0400
Received: from d03nm122.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170])
	by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6CKldMI367096;
	Mon, 12 Jul 2004 14:47:49 -0600
In-Reply-To: <F5CD2412-D43F-11D8-AFCB-000A95BD86C0@mnot.net>
To: Mark Nottingham <mnot@mnot.net>
Cc: Atom Syntax <atom-syntax@imc.org>, Norman Walsh <ndw@nwalsh.com>
MIME-Version: 1.0
Subject: Re: Version vs. Namespace
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
From: James M Snell <jasnell@us.ibm.com>
X-MIMETrack: S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 01:45:49 PM,
	Serialize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 01:45:49 PM,
	Serialize complete at 07/12/2004 01:45:49 PM,
	Itemize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 01:45:49 PM,
	S/MIME Sign complete at 07/12/2004 01:45:49 PM,
	S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 01:47:43 PM,
	S/MIME Sign complete at 07/12/2004 01:47:43 PM,
	Serialize by Router on D03NM122/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at
 07/12/2004 14:47:49,
	Serialize complete at 07/12/2004 14:47:49
Message-ID: <OFB8CC0367.F21D1DAE-ON88256ECF.0070F567-88256ECF.00723B8C@us.ibm.com>
Date: Mon, 12 Jul 2004 14:47:45 -0600
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z12550_boundary_sign
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>


This is an S/MIME signed message.

---------z12550_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 00720EF588256ECF_="

This is a multipart message in MIME format.
--=_alternative 00720EF588256ECF_=
Content-Type: text/plain; charset="US-ASCII"

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

Mark Nottingham <mnot@mnot.net> wrote on 07/12/2004 01:13:37 PM:

> 
> On Jul 12, 2004, at 1:07 PM, James M Snell wrote:
> > While I'm ok with this, I'd have to argue that the bar should be set 
> > rather high for the working group to consider such changes after Atom 
> > 1.0 is out the door.  Even the addition of new optional elements 
> > within the same namespace could cause problems for various 
> > implementations.  
> 
> How so?
> 

More of an implementation issue really (as opposed to something that 
should be codified in the spec), but given an application that is 
programmed to expect certain known optional elements, the addition of a 
new unknown optional element that the application does not know how to 
handle could cause problems.  Look at the parallels in things like DNS as 
an example, where while the DNS spec supports new resource record types, 
for years the introduction of new types, regardless of their optional 
nature, was not supported by many implementations.  I am not saying that 
the WG should care if applications are written in such a brittle fashion, 
only that it should be recognized that such issues can occur.  It is 
possible to mitigate such issues by defining concise behavior/semantics 
and setting the bar high for changes to the core namespace (or extension 
namespaces).  For example, if we expect that new elements could be added 
at any time to the core namespace without much effort, then that should be 
captured in the spec so that implementors can plan their implementations 
accordingly.

> > There is one other possibility.  It would be possible for this WG to 
> > define an "extension namespace" within which non-core new optional 
> > elements could be added.  e.g. <atomex:Category>.  The bar for adding 
> > elements to this extension namespace would be set much lower than the 
> > core atom namespace. The semantics, of course, would be that all 
> > elements in the atomex namespace would be always optional.  Once (and 
> > if) elements in the atomex namespace became popular/essential enough, 
> > this work group could decide on whether or not those elements should 
> > be moved to the core namespace, causing a rev in the version attribute 

> > value.
> >
> > Each element added to the atomex namespace would need to be described 
> > in it's own RFC (meaning people would actually have to go through some 

> > work to define them rather than inventing them willy-nilly).
> 
> Hmm, this is interesting. I take it the atomex namespace would be only 
> used for WG extensions, rather than anybody who wants to?
> 

Correct.  If someone wishes to add a new element to the atomex namespace, 
they would be required to submit an RFC describing that element to this 
WG. 

> I imagine we'll end up doing this in any case, because we'll want to 
> use in-development namespaces until any such extensions are final.
> 

Correct, the use of the extension namespace raises the bar for things to 
be added/changed in the core namespace.

> Cheers,
> 
> 
> --
> Mark Nottingham     http://www.mnot.net/
> 

--=_alternative 00720EF588256ECF_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">- James M Snell<br>
 &nbsp;jasnell@us.ibm.com<br>
 &nbsp;http://www.ibm.com<br>
 &nbsp;(877) 511-5082 / Office<br>
 &nbsp;930-1979 / Tie Line</font>
<br>
<br><font size=2><tt>Mark Nottingham &lt;mnot@mnot.net&gt; wrote on 07/12/2004
01:13:37 PM:<br>
<br>
&gt; <br>
&gt; On Jul 12, 2004, at 1:07 PM, James M Snell wrote:<br>
&gt; &gt; While I'm ok with this, I'd have to argue that the bar should
be set <br>
&gt; &gt; rather high for the working group to consider such changes after
Atom <br>
&gt; &gt; 1.0 is out the door. &nbsp;Even the addition of new optional
elements <br>
&gt; &gt; within the same namespace could cause problems for various <br>
&gt; &gt; implementations. &nbsp;<br>
&gt; <br>
&gt; How so?<br>
&gt; </tt></font>
<br>
<br><font size=2><tt>More of an implementation issue really (as opposed
to something that should be codified in the spec), but given an application
that is programmed to expect certain known optional elements, the addition
of a new unknown optional element that the application does not know how
to handle could cause problems. &nbsp;Look at the parallels in things like
DNS as an example, where while the DNS spec supports new resource record
types, for years the introduction of new types, regardless of their optional
nature, was not supported by many implementations. &nbsp;I am not saying
that the WG should care if applications are written in such a brittle fashion,
only that it should be recognized that such issues can occur. &nbsp;It
is possible to mitigate such issues by defining concise behavior/semantics
and setting the bar high for changes to the core namespace (or extension
namespaces). &nbsp;For example, if we expect that new elements could be
added at any time to the core namespace without much effort, then that
should be captured in the spec so that implementors can plan their implementations
accordingly.</tt></font>
<br><font size=2><tt><br>
&gt; &gt; There is one other possibility. &nbsp;It would be possible for
this WG to <br>
&gt; &gt; define an &quot;extension namespace&quot; within which non-core
new optional <br>
&gt; &gt; elements could be added. &nbsp;e.g. &lt;atomex:Category&gt;.
&nbsp;The bar for adding <br>
&gt; &gt; elements to this extension namespace would be set much lower
than the <br>
&gt; &gt; core atom namespace. The semantics, of course, would be that
all <br>
&gt; &gt; elements in the atomex namespace would be always optional. &nbsp;Once
(and <br>
&gt; &gt; if) elements in the atomex namespace became popular/essential
enough, <br>
&gt; &gt; this work group could decide on whether or not those elements
should <br>
&gt; &gt; be moved to the core namespace, causing a rev in the version
attribute <br>
&gt; &gt; value.<br>
&gt; &gt;<br>
&gt; &gt; Each element added to the atomex namespace would need to be described
<br>
&gt; &gt; in it's own RFC (meaning people would actually have to go through
some <br>
&gt; &gt; work to define them rather than inventing them willy-nilly).<br>
&gt; <br>
&gt; Hmm, this is interesting. I take it the atomex namespace would be
only <br>
&gt; used for WG extensions, rather than anybody who wants to?<br>
&gt; </tt></font>
<br>
<br><font size=2><tt>Correct. &nbsp;If someone wishes to add a new element
to the atomex namespace, they would be required to submit an RFC describing
that element to this WG. &nbsp;</tt></font>
<br><font size=2><tt><br>
&gt; I imagine we'll end up doing this in any case, because we'll want
to <br>
&gt; use in-development namespaces until any such extensions are final.<br>
&gt; </tt></font>
<br>
<br><font size=2><tt>Correct, the use of the extension namespace raises
the bar for things to be added/changed in the core namespace.</tt></font>
<br><font size=2><tt><br>
&gt; Cheers,<br>
&gt; <br>
&gt; <br>
&gt; --<br>
&gt; Mark Nottingham &nbsp; &nbsp; http://www.mnot.net/<br>
&gt; <br>
</tt></font>
--=_alternative 00720EF588256ECF_=--

---------z12550_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIIUOAIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIISWDCCAtow
ggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1
aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAy
MDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA629xc49NpAPz
cAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7glzJKgPkPzlTZZfznznGbmAWVnNBQ
lyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnwNclOnnP2sKufuPzbTImQTTi5c8JZNZcM
J0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEEBAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1Ud
DgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAPBgNVHRMBAf8EBTADAQH/MDEGA1UdJQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUH
AwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvu
jQupk2oCScMd3FIHLE7hOfu8YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14ke
McF9ViNdewEoBGiAycUq8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIC2jCCAkOgAwIB
AgIDAxS2MA0GCSqGSIb3DQEBBAUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwMTE0MjIw
NzExWhcNMTExMjMxMjIwNzExWjBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25h
bCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrb3Fzj02kA/NwCy5KFMiY
tFgyTJ6kMSQLVSs9uwVHIAVkqy/enDQwZ9b/7uCXMkqA+Q/OVNll/OfOcZuYBZWc0FCXI9qw60KO
J/rTd65FdF4dwp8cw8si0qjOJtYg8cm46fA1yU6ec/awq5+4/NtMiZBNOLlzwlk1lwwnRgXNNwID
AQABo4GqMIGnMBEGCWCGSAGG+EIBAQQEAwIAhzAOBgNVHQ8BAf8EBAMCAcYwHQYDVR0OBBYEFK5U
DpLqqDOpKyQtx8hvMNze80pAMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMA8GA1Ud
EwEB/wQFMAMBAf8wMQYDVR0lBCowKAYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYB
BQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAMnJ7c2YLyrY/PKlFl+7sm8NENfWtFxqdm+6NC6mTagJJ
wx3cUgcsTuE5+7xh9+/G0tTfLzA1qZAQ5GNMPXvmoB9+vJfKnC2JWMFQpIOUEJDXiR4xwX1WI117
ASgEaIDJxSrxHcuuV/hMIO9bgZ6C41MUVmdLTKBgBOImTuIPK8QwggMgMIICiaADAgECAgQ13vTP
MA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQL
EyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0MTUxWhcN
MTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMk
RXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKKlQRkrPFr
U18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkwrFEeO68r
1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOgYaRfMF0x
CzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBD
ZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAxODA4MjIx
NjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAdBgNV
HQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0HQQAEDTAL
GwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwlMQ0AppJu
f7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn00DbOyZY
sih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMgMIICiaADAgEC
AgQ13vTPMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0
MTUxWhcNMTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsG
A1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKK
lQRkrPFrU18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkw
rFEeO68r1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOg
YaRfMF0xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNl
Y3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAx
ODA4MjIxNjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAdBgNVHQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0H
QQAEDTALGwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwl
MQ0AppJuf7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn
00DbOyZYsih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMmMIIC
j6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIxNjM2NTRaMIGFMQsw
CQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEXMBUGA1UEAxMOSmFt
ZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkqhkiG9w0BCQEWEmph
c25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwKpbDG3zMatEuuOT
FYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSyd+7nwqAvbBfPj+0S
vcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7tBJlLrwDRCMoNlPuQ
Kg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQW
BBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOgFAwSamFzbmVs
bEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pAMCcGA1UdJQQgMB4G
CCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAZMKevB7dFfb9
23OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY8BjwVHxiYgG4xkxf
B1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOIzj3lz3xd+uOzqRFg
/Wsg/VMwggMmMIICj6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAy
BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNV
BAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIx
NjM2NTRaMIGFMQswCQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEX
MBUGA1UEAxMOSmFtZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkq
hkiG9w0BCQEWEmphc25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
wKpbDG3zMatEuuOTFYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSy
d+7nwqAvbBfPj+0SvcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7t
BJlLrwDRCMoNlPuQKg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQD
AgXgMB0GA1UdDgQWBBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcU
AgOgFAwSamFzbmVsbEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA
MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQAD
gYEAZMKevB7dFfb923OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY
8BjwVHxiYgG4xkxfB1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOI
zj3lz3xd+uOzqRFg/Wsg/VMxggG7MIIBtwIBATBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJ
bnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0g
Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwF+kzAJBgUrDgMCGgUAoIGiMBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDcxMjIwNDU0OVowIwYJKoZIhvcNAQkEMRYE
FE2S2wYVyTP9H6UjbX9hjE9AhsjuMEMGCSqGSIb3DQEJDzE2MDQwBwYFKw4DAh0wDgYIKoZIhvcN
AwICAgCAMAoGCCqGSIb3DQMHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAValEekrX
HO/f6pYhutGr0PlEAhzrBa446qzQl+hLp1IUp9eO7UW78qNZq2/VCLfWOd3zVTjfMDQVKQh+YV3u
GJelZISSb0ZF1ac29NbUqmT/jH2q2bogL0KQgSW4wSibHlZnxR6V4nWIBcIO14Cr7DBSBJgnYnvP
M41X7NKipOcAAAAA

---------z12550_boundary_sign--



From owner-atom-syntax@mail.imc.org  Mon Jul 12 17:07: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 RAA14206
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 17:07: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 i6CKwIaQ064078;
	Mon, 12 Jul 2004 13:58: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 i6CKwIKk064077;
	Mon, 12 Jul 2004 13:58: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 (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CKwHb8064067
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 13:58: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 9303B7C112; Mon, 12 Jul 2004 23:56:31 +0200 (CEST)
Date: Mon, 12 Jul 2004 23:01:39 +0200
To: "Eric Scheid" <eric.scheid@ironclad.net.au>
Subject: Re: Q: modfied vs issued vs created
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <BD191813.1F1F1%eric.scheid@ironclad.net.au>
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: <opsa1l01mvuvpchu@quark>
In-Reply-To: <BD191813.1F1F1%eric.scheid@ironclad.net.au>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Tue, 13 Jul 2004 04:39:47 +1000, Eric Scheid  
<eric.scheid@ironclad.net.au> wrote:

>> The current Atom model just can't provide the information
>> needed to differ between minor and major updates.
>
> Only if we assume <issued> can't change.

Why would one assume anything else? From where did the idea that  
atom:issued could be randomly updated, surface?

> If it can change, then we have all the information we need to communicate
> minor change, major change, old news, and old news asserted to be still
> valid. Pretty handy that.

We then loose a mechanism to tell when that particular entry was first  
issued. It's not all gain. With PaceSupersede, however, you get  
«everything» we've talked about in regard to minor and major changes, but  
don't redefine the DC dates (as specified in Atom, or in general) at all.

With PaceSupersede one could say that if you want to re-issue an entry,  
use the mechanisms described here. If you want to indicate that a major  
update has been done, use the mechanisms described here. If not, don't  
care about what is written here. Most users can ignore PaceSupersede.

-- 
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 Jul 12 17:08: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 RAA14313
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 17:08: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 i6CL1X7c064302;
	Mon, 12 Jul 2004 14:01: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 i6CL1XFO064301;
	Mon, 12 Jul 2004 14:01:33 -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 i6CL1W8m064292
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 14:01:32 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040712210132.94383.qmail@web41215.mail.yahoo.com>
Received: from [207.46.238.133] by web41215.mail.yahoo.com via HTTP; Mon, 12 Jul 2004 14:01:32 PDT
Date: Mon, 12 Jul 2004 14:01:32 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Version vs. Namespace
To: atom-syntax@imc.org
In-Reply-To: <OF8D4D5D17.D15863A6-ON88256ECF.00698609-88256ECF.006A1C31@us.ibm.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>




--- James M Snell <jasnell@us.ibm.com> wrote:
> > I would like Atom 1.0 to be minimal and finally
> tuned, to the extent 
> > that it only includes things that basically
> everyone would use.
>
> +1 on this.  The base Atom specification is itself
> the "basic profile" and 
> should be as minimal with as few optional components
> as possible.  

+1 from me as well.

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail 



From owner-atom-syntax@mail.imc.org  Mon Jul 12 17:17: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 RAA15521
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 17: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 i6CL54Lr064540;
	Mon, 12 Jul 2004 14:05: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 i6CL54tk064539;
	Mon, 12 Jul 2004 14:05:04 -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 i6CL53Ij064533
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 14:05:03 -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 i6CL574Q024242;
	Mon, 12 Jul 2004 14:05:08 -0700
Received: from ussjex01.amer.bea.com ([172.16.120.50]) by ussjfe01.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 12 Jul 2004 14:05:08 -0700
x-mimeole: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Version vs. Namespace
Date: Mon, 12 Jul 2004 14:05:07 -0700
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF08D6B39E@ussjex01.amer.bea.com>
Thread-Topic: Version vs. Namespace
Thread-Index: AcRoNRNcig8JYaPnTq+wyxTVGjDtBAABB7IA
From: "David Orchard" <dorchard@bea.com>
To: "Tim Bray" <Tim.Bray@Sun.COM>, "Atom Syntax" <atom-syntax@imc.org>
X-OriginalArrivalTime: 12 Jul 2004 21:05:08.0061 (UTC) FILETIME=[E966A8D0:01C46853]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6CL53Ij064534
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


Excellent.  I've been writing up some of the usual mU/mustIgnore stuff.  We do have experience in that.  

I strongly disagree with the use of a version attribute for claiming major and minor versions.  I believe that QNames are the right way to go for identifying elements, not qnames+versions.  

Norm and I have written up material on why coarse grained version #s are bad [1] and even used RSS as an example.  We have implementation experience on using version #s, and it isn't that great.

Cheers,
Dave

[1] http://www.w3.org/2001/tag/doc/versioning#problems

> -----Original Message-----
> From: owner-atom-syntax@mail.imc.org
> [mailto:owner-atom-syntax@mail.imc.org]On Behalf Of Tim Bray
> Sent: Monday, July 12, 2004 10:24 AM
> To: Atom Syntax
> Subject: Re: Version vs. Namespace
> 
> 
> 
> On Jul 12, 2004, at 9:17 AM, David Orchard wrote:
> 
> > While Mark's proposal of a profile might appear to be 
> complicated, it 
> > ought to get a bit more air time and explanation than the very next 
> > message saying "no", especially with discussion of concrete use 
> > cases/scenarios.
> 
> OK.  I claim that a single fixed namespace plus a single version 
> attribute on the root element, plus an extensibility framework 
> involving the usual mustUnderstand/mustIgnore primitives, 
> will provide 
> a nice efficient framework for the long term.  I further claim that 
> there is now enough experience with this kind of versioning 
> architecture that we understand the implementation issues.  I further 
> express doubt that any further steps down the road to more complexity 
> will have positive ROI.
> 
> So...... those who want a more complex and abstract versioning set-up 
> should start, I think, from use-cases, so that we get a nice clean 
> clear sense of exactly what the complexity buys us.  -Tim
> 
> 



From owner-atom-syntax@mail.imc.org  Mon Jul 12 17:21: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 RAA16131
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 17:21: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 i6CLAH5k064896;
	Mon, 12 Jul 2004 14:10: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 i6CLAHae064895;
	Mon, 12 Jul 2004 14:10:17 -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 i6CLAG8v064889
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 14:10:17 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from phys-bur-1 ([129.148.9.72])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6CLALil011085
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 15:10:21 -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 <0I0R00G01C1M3N@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com)
 for atom-syntax@imc.org; Mon, 12 Jul 2004 17:10:21 -0400 (EDT)
Received: from mercury (vpn-129-159-0-65.EMEA.Sun.COM [129.159.0.65])
 by bur-mail1.east.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
 with ESMTP id <0I0R006BDC54U0@bur-mail1.east.sun.com> for atom-syntax@imc.org;
 Mon, 12 Jul 2004 17:10:21 -0400 (EDT)
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1Bk82Y-0001PO-00	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 17:08:46 -0400
X-URL: http://nwalsh.com/
Date: Mon, 12 Jul 2004 17:08:43 -0400
From: Norman Walsh <ndw@nwalsh.com>
Subject: Re: Rough consensus on PaceElementOrder?
In-reply-to: <A5F347BE-D42A-11D8-9DBF-000A95A51C9E@sun.com>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <87r7rhx7ac.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: <A5F347BE-D42A-11D8-9DBF-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-Type: text/plain

/ Tim Bray <Tim.Bray@Sun.COM> was heard to say:
| SO: I propose that rather than tear this one apart any further, we ask
| the editors to, in the -01 drafts, recast the data format with the
| <atom:feedinfo> element (anyone should feel free to suggest a better
| name than "feedinfo"), and that those who care about defaulting cook
| up a Pace or three outlining specifically what the options are.  -Tim

+1, with the suggestions of atom:head or atom:info.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Man is the only animal who causes pain
http://nwalsh.com/            | to others with no other object than
                              | wanting to do so.-- Schopenhauer

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA8v3dOyltUcwYWjsRAsSCAKCUEW0vFmVW7tkijOyv0UvgQINl9QCfcs3v
YzIdDwClh2Uzj7Dp+j8g4rA=
=6DQZ
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Mon Jul 12 17:24: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 RAA16488
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 17: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 i6CLFYuT065301;
	Mon, 12 Jul 2004 14:15:34 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6CLFYIV065300;
	Mon, 12 Jul 2004 14:15:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web41511.mail.yahoo.com (web41511.mail.yahoo.com [66.218.93.94])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6CLFY8P065292
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 14:15:34 -0700 (PDT)
	(envelope-from randymorin@yahoo.com)
Message-ID: <20040712211533.90350.qmail@web41511.mail.yahoo.com>
Received: from [66.46.139.106] by web41511.mail.yahoo.com via HTTP; Mon, 12 Jul 2004 14:15:33 PDT
Date: Mon, 12 Jul 2004 14:15:33 -0700 (PDT)
From: Randy Charles Morin <randymorin@yahoo.com>
Reply-To: randy@kbcafe.com
Subject: Re: PaceElementOrder: options 
To: Atomlist <atom-syntax@imc.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1640839520-1089666933=:90305"
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>


--0-1640839520-1089666933=:90305
Content-Type: text/plain; charset=us-ascii


Danny Ayers wrote:
>>Some questions, starting with the biggy:
>>Why order the elements? 
Bill de hÓra wrote:
>XML. Schemata. Clarity, Robustness.
>But really we should be asking why are we specifying disorder.
Danny Ayers wrote:
>>Would an order make any significant difference to an application? 
Bill de hÓra wrote:
>Again, I would instead ask what the value of no order is.

I like these question? Why disorder? What is the value of not specifying the order? I know that I have major pluses w/ my tools if we can just specify order. What's the counter argument?

Randy
http://www.kbcafe.com

 


		
---------------------------------
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
--0-1640839520-1089666933=:90305
Content-Type: text/html; charset=us-ascii

<DIV>
<P><FONT face="Courier New">Danny Ayers wrote:<BR>&gt;&gt;</FONT><TT>Some questions, starting with the biggy:</TT><BR>&gt;&gt;<TT>Why order the elements? <BR></TT><TT>Bill de hÓra wrote:<BR>&gt;XML. Schemata. Clarity, Robustness.<BR>&gt;</TT><TT>But really we should be asking why are we specifying disorder.<BR>Danny Ayers wrote:<BR>&gt;&gt;W</TT><TT>ould an order make any significant difference to an application? <BR>Bill de hÓra wrote:<BR>&gt;</TT><TT>Again, I would instead ask what the value of no order is.</TT></P>
<P><TT>I like these question? Why disorder? What is the value of not specifying the order? I know that I have major pluses w/ my tools if we can just specify order. What's the counter argument?</TT></P>
<P><TT>Randy<BR><A href="http://www.kbcafe.com/">http://www.kbcafe.com</A></TT></P>
<P><TT></TT>&nbsp;</P></DIV><p>
		<hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/mail_us/taglines/100/*http://promotions.yahoo.com/new_mail/static/efficiency.html">New and Improved Yahoo! Mail</a> - 100MB free storage!
--0-1640839520-1089666933=:90305--



From owner-atom-syntax@mail.imc.org  Mon Jul 12 17:40: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 RAA18032
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 17: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 i6CLWrQ1066446;
	Mon, 12 Jul 2004 14: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 i6CLWr3I066445;
	Mon, 12 Jul 2004 14:32:53 -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 i6CLWqTH066437
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 14:32:52 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040712213251.79119.qmail@web41203.mail.yahoo.com>
Received: from [131.107.3.70] by web41203.mail.yahoo.com via HTTP; Mon, 12 Jul 2004 14:32:51 PDT
Date: Mon, 12 Jul 2004 14:32:51 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Normative WSDL for Atom API (was Re: Created proposal: PaceProvideSchema)
To: Mark Nottingham <mnot@mnot.net>, randy@kbcafe.com
Cc: Atomlist <atom-syntax@imc.org>
In-Reply-To: <45249A2E-D3B1-11D8-9A61-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: <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> wrote:
>  
> Consider this - WSDL isn't specified in terms of XML
> Schema; it defines 
> a "component model." Neither does SOAP; that's
> right, the Schema isn't 
> normative, just informational.


Considering that at one time there was a claim that
Atom would support SOAP wouldn't it then be useful for
there to be a normative WSDL for Atom (which means
there will have to be a normative element declaration
for atom:entry at least)? The alternative would be for
every vendor that supports the Atom API to cook up
their own schemas for atom:entry which could lead to
incompatibility. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
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  Mon Jul 12 17:46:14 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18827
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 17:46: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 i6CLaxDN066633;
	Mon, 12 Jul 2004 14:36: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 i6CLaxEA066631;
	Mon, 12 Jul 2004 14:36:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CLawKw066624
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 14:36:58 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from phys-bur-1 ([129.148.9.72])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i6CLYu53009838
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 15:34:56 -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 <0I0R00L01DA50Z@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com)
 for atom-syntax@imc.org; Mon, 12 Jul 2004 17:37:02 -0400 (EDT)
Received: from mercury (vpn-129-159-0-65.EMEA.Sun.COM [129.159.0.65])
 by bur-mail1.east.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
 with ESMTP id <0I0R006L9DDLU0@bur-mail1.east.sun.com> for atom-syntax@imc.org;
 Mon, 12 Jul 2004 17:37:02 -0400 (EDT)
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1Bk8ST-0001to-00	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 17:35:33 -0400
X-URL: http://nwalsh.com/
Date: Mon, 12 Jul 2004 17:35:25 -0400
From: Norman Walsh <ndw@nwalsh.com>
Subject: Re: PaceElementOrder: options
In-reply-to: <20040712211533.90350.qmail@web41511.mail.yahoo.com>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <87fz7wykma.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: <20040712211533.90350.qmail@web41511.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-Type: text/plain

/ Randy Charles Morin <randymorin@yahoo.com> was heard to say:
| I like these question? Why disorder? What is the value of not
| specifying the order? I know that I have major pluses w/ my tools if
| we can just specify order. What's the counter argument?

Usability and flexibility. As a user, I don't want to remember which
comes first, atom:modified or atom:issued. And as an implementor, I
wouldn't want to be required to sort the metadata that came out of my
internal representation into some particular order.

Defining an order also encourages people to think that order is
significant; I predict that this will lead to confusion in the area of
extensions.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Is your cucumber bitter? Throw it away.
http://nwalsh.com/            | Are there briars in your path? Turn
                              | aside. That is enough. Do not go on to
                              | say, 'Why were things of this sort ever
                              | brought into the world?'--Marcus
                              | Aurelius

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA8wQfOyltUcwYWjsRApMhAJ9ox2XQjIf43TvxsyRt1exx75nOCgCeLuCQ
859JWL4Q0PKZygdrgEEgfHE=
=dbie
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Mon Jul 12 17:47: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 RAA18987
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 17:47: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 i6CLZakx066553;
	Mon, 12 Jul 2004 14:35: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 i6CLZale066552;
	Mon, 12 Jul 2004 14:35:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail46-s.fg.online.no (mail46-s.fg.online.no [148.122.161.46])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CLZZIQ066546
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 14:35:36 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Received: from mail.online.no (ti132110a080-3373.bb.online.no [80.212.221.45])
	by mail46.fg.online.no (8.12.11/8.12.11) with ESMTP id i6CLZXfK022028;
	Mon, 12 Jul 2004 23:35:35 +0200 (MEST)
Date: Mon, 12 Jul 2004 23:35:31 +0200
To: Graham <dtcd@mac.com>, Atom-syntax <atom-syntax@imc.org>
Subject: Re: a methodical approach to defining what date  elements we need
References: <14B72756-D419-11D8-9D0B-003065EA6144@geckotribe.com> <40F2C2CD.9020307@intertwingly.net> <47071860-D42A-11D8-82B1-000A95DC3D90@mac.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: <opsa1nlh1u6dxgxk@mail.online.no>
In-Reply-To: <47071860-D42A-11D8-82B1-000A95DC3D90@mac.com>
User-Agent: Opera M2/7.60 (Win32, build 7096)
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 Mon, 12 Jul 2004 13:38:25 -0400, Graham <dtcd@mac.com> wrote:

> 2) A date to show the user, usually the same as above

What a view date is, is by it's very nature not in a feed author's control  
[2]. You might be interested in the modified date. Your neighbour in the  
issued date. Your friends could want the issued date in UTC, I could want  
all three of the dates in +01:00 or +02:00 depending on time of year.   
Your boss could want the delta between created and issued, but only when  
written within your working hours.


___
[1] Those with a view differing from mine could read this as first-issued)
[2] A real example: Opera's aggregator/mail program by default displays  
"Monday 13:32:25" for entries from the current week, when that entry is  
 from the previous day or before.

-- 
Arve Bersvendsen

http://www.virtuelvis.com
http://www.bersvendsen.com



From owner-atom-syntax@mail.imc.org  Mon Jul 12 17: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 RAA19137
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 17: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 i6CLdYLG066821;
	Mon, 12 Jul 2004 14:39:34 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6CLdYcC066820;
	Mon, 12 Jul 2004 14:39: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 i6CLdXcS066784
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 14:39: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 OAA24888
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 14:39: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 OAA19850
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 14:39: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, 12 Jul 2004 14:39:30 -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 <0I0R00HXPDHTMZ@shazam.verity.com> for atom-syntax@imc.org; Mon,
 12 Jul 2004 14:39:30 -0700 (PDT)
Date: Mon, 12 Jul 2004 14:45:50 -0700
From: Walter Underwood <wunder@verity.com>
Subject: Re: PaceElementOrder: options
In-reply-to: <20040712211533.90350.qmail@web41511.mail.yahoo.com>
To: Atomlist <atom-syntax@imc.org>
Message-id: <A5343281AE2BD2A2B110E8AF@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: <20040712211533.90350.qmail@web41511.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 Monday, July 12, 2004 02:15:33 PM -0700 Randy Charles Morin 
<randymorin@yahoo.com> wrote:
>
> I like these question? Why disorder? What is the value of not specifying
> the order? I know that I have major pluses w/ my tools if we can just
> specify order. What's the counter argument?

Increased interoperability and minimal specification. The internet
robustness principle, specifically the "be generous in what you accept"
part, and avoid specifying things that don't really change the content
of the message.

Mail headers and HTTP headers do not have a required order. They
work fine.

A specified order means that we can have a completly legal message
except that the order of two elements is swapped. The content and
semantics are fine, except that the "issued" date is listed after
the "modified" date instead of before.

If we say that clients MUST NOT accept feeds with out of order
elements, then this will (probably) be caught. If we say SHOULD NOT,
then this might not be found until after it is deployed. That is
an interoperability problem.

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek



From owner-atom-syntax@mail.imc.org  Mon Jul 12 17:50: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 RAA19373
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 17: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 i6CLfDi6066886;
	Mon, 12 Jul 2004 14: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 i6CLfDXp066885;
	Mon, 12 Jul 2004 14:41:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CLfDwO066876
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 14:41:13 -0700 (PDT)
	(envelope-from jasnell@us.ibm.com)
Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32])
	by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i6CLfB10543212;
	Mon, 12 Jul 2004 17:41:12 -0400
Received: from d03nm122.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168])
	by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6CLfB33090822;
	Mon, 12 Jul 2004 15:41:11 -0600
In-Reply-To: <32D5845A745BFB429CBDBADA57CD41AF08D6B39E@ussjex01.amer.bea.com>
To: "David Orchard" <dorchard@bea.com>
Cc: "Atom Syntax" <atom-syntax@imc.org>, owner-atom-syntax@mail.imc.org,
        "Tim Bray" <Tim.Bray@Sun.COM>
MIME-Version: 1.0
Subject: RE: Version vs. Namespace
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
From: James M Snell <jasnell@us.ibm.com>
X-MIMETrack: S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 02:39:29 PM,
	Serialize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 02:39:29 PM,
	Serialize complete at 07/12/2004 02:39:29 PM,
	Itemize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 02:39:31 PM,
	S/MIME Sign complete at 07/12/2004 02:39:31 PM,
	S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 02:41:06 PM,
	S/MIME Sign complete at 07/12/2004 02:41:06 PM,
	Serialize by Router on D03NM122/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at
 07/12/2004 15:41:10,
	Serialize complete at 07/12/2004 15:41:10
Message-ID: <OFD6B4FC0F.25D0F7F0-ON88256ECF.0076E9B4-88256ECF.00771ECD@us.ibm.com>
Date: Mon, 12 Jul 2004 15:41:07 -0600
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z47252_boundary_sign
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>


This is an S/MIME signed message.

---------z47252_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 0076F8BF88256ECF_="

This is a multipart message in MIME format.
--=_alternative 0076F8BF88256ECF_=
Content-Type: text/plain; charset="US-ASCII"

+1 on the use of namespace to indicate version as opposed to a version 
attribute.

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



"David Orchard" <dorchard@bea.com> 
Sent by: owner-atom-syntax@mail.imc.org
07/12/2004 02:05 PM

To
"Tim Bray" <Tim.Bray@Sun.COM>, "Atom Syntax" <atom-syntax@imc.org>
cc

Subject
RE: Version vs. Namespace







Excellent.  I've been writing up some of the usual mU/mustIgnore stuff. We 
do have experience in that. 

I strongly disagree with the use of a version attribute for claiming major 
and minor versions.  I believe that QNames are the right way to go for 
identifying elements, not qnames+versions. 

Norm and I have written up material on why coarse grained version #s are 
bad [1] and even used RSS as an example.  We have implementation 
experience on using version #s, and it isn't that great.

Cheers,
Dave

[1] http://www.w3.org/2001/tag/doc/versioning#problems

> -----Original Message-----
> From: owner-atom-syntax@mail.imc.org
> [mailto:owner-atom-syntax@mail.imc.org]On Behalf Of Tim Bray
> Sent: Monday, July 12, 2004 10:24 AM
> To: Atom Syntax
> Subject: Re: Version vs. Namespace
> 
> 
> 
> On Jul 12, 2004, at 9:17 AM, David Orchard wrote:
> 
> > While Mark's proposal of a profile might appear to be 
> complicated, it 
> > ought to get a bit more air time and explanation than the very next 
> > message saying "no", especially with discussion of concrete use 
> > cases/scenarios.
> 
> OK.  I claim that a single fixed namespace plus a single version 
> attribute on the root element, plus an extensibility framework 
> involving the usual mustUnderstand/mustIgnore primitives, 
> will provide 
> a nice efficient framework for the long term.  I further claim that 
> there is now enough experience with this kind of versioning 
> architecture that we understand the implementation issues.  I further 
> express doubt that any further steps down the road to more complexity 
> will have positive ROI.
> 
> So...... those who want a more complex and abstract versioning set-up 
> should start, I think, from use-cases, so that we get a nice clean 
> clear sense of exactly what the complexity buys us.  -Tim
> 
> 



--=_alternative 0076F8BF88256ECF_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">+1 on the use of namespace to indicate
version as opposed to a version attribute.</font>
<br>
<br><font size=2 face="sans-serif">- James M Snell<br>
 &nbsp;jasnell@us.ibm.com<br>
 &nbsp;http://www.ibm.com<br>
 &nbsp;(877) 511-5082 / Office<br>
 &nbsp;930-1979 / Tie Line</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>&quot;David Orchard&quot;
&lt;dorchard@bea.com&gt;</b> </font>
<br><font size=1 face="sans-serif">Sent by: owner-atom-syntax@mail.imc.org</font>
<p><font size=1 face="sans-serif">07/12/2004 02:05 PM</font>
<td width=59%>
<table width=100%>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td valign=top><font size=1 face="sans-serif">&quot;Tim Bray&quot; &lt;Tim.Bray@Sun.COM&gt;,
&quot;Atom Syntax&quot; &lt;atom-syntax@imc.org&gt;</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td valign=top>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td valign=top><font size=1 face="sans-serif">RE: Version vs. Namespace</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2><tt><br>
Excellent. &nbsp;I've been writing up some of the usual mU/mustIgnore stuff.
&nbsp;We do have experience in that. &nbsp;<br>
<br>
I strongly disagree with the use of a version attribute for claiming major
and minor versions. &nbsp;I believe that QNames are the right way to go
for identifying elements, not qnames+versions. &nbsp;<br>
<br>
Norm and I have written up material on why coarse grained version #s are
bad [1] and even used RSS as an example. &nbsp;We have implementation experience
on using version #s, and it isn't that great.<br>
<br>
Cheers,<br>
Dave<br>
<br>
[1] http://www.w3.org/2001/tag/doc/versioning#problems<br>
<br>
&gt; -----Original Message-----<br>
&gt; From: owner-atom-syntax@mail.imc.org<br>
&gt; [mailto:owner-atom-syntax@mail.imc.org]On Behalf Of Tim Bray<br>
&gt; Sent: Monday, July 12, 2004 10:24 AM<br>
&gt; To: Atom Syntax<br>
&gt; Subject: Re: Version vs. Namespace<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; On Jul 12, 2004, at 9:17 AM, David Orchard wrote:<br>
&gt; <br>
&gt; &gt; While Mark's proposal of a profile might appear to be <br>
&gt; complicated, it <br>
&gt; &gt; ought to get a bit more air time and explanation than the very
next <br>
&gt; &gt; message saying &quot;no&quot;, especially with discussion of
concrete use <br>
&gt; &gt; cases/scenarios.<br>
&gt; <br>
&gt; OK. &nbsp;I claim that a single fixed namespace plus a single version
<br>
&gt; attribute on the root element, plus an extensibility framework <br>
&gt; involving the usual mustUnderstand/mustIgnore primitives, <br>
&gt; will provide <br>
&gt; a nice efficient framework for the long term. &nbsp;I further claim
that <br>
&gt; there is now enough experience with this kind of versioning <br>
&gt; architecture that we understand the implementation issues. &nbsp;I
further <br>
&gt; express doubt that any further steps down the road to more complexity
<br>
&gt; will have positive ROI.<br>
&gt; <br>
&gt; So...... those who want a more complex and abstract versioning set-up
<br>
&gt; should start, I think, from use-cases, so that we get a nice clean
<br>
&gt; clear sense of exactly what the complexity buys us. &nbsp;-Tim<br>
&gt; <br>
&gt; <br>
<br>
</tt></font>
<br>
--=_alternative 0076F8BF88256ECF_=--

---------z47252_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIIUOAIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIISWDCCAtow
ggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1
aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAy
MDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA629xc49NpAPz
cAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7glzJKgPkPzlTZZfznznGbmAWVnNBQ
lyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnwNclOnnP2sKufuPzbTImQTTi5c8JZNZcM
J0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEEBAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1Ud
DgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAPBgNVHRMBAf8EBTADAQH/MDEGA1UdJQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUH
AwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvu
jQupk2oCScMd3FIHLE7hOfu8YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14ke
McF9ViNdewEoBGiAycUq8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIC2jCCAkOgAwIB
AgIDAxS2MA0GCSqGSIb3DQEBBAUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwMTE0MjIw
NzExWhcNMTExMjMxMjIwNzExWjBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25h
bCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrb3Fzj02kA/NwCy5KFMiY
tFgyTJ6kMSQLVSs9uwVHIAVkqy/enDQwZ9b/7uCXMkqA+Q/OVNll/OfOcZuYBZWc0FCXI9qw60KO
J/rTd65FdF4dwp8cw8si0qjOJtYg8cm46fA1yU6ec/awq5+4/NtMiZBNOLlzwlk1lwwnRgXNNwID
AQABo4GqMIGnMBEGCWCGSAGG+EIBAQQEAwIAhzAOBgNVHQ8BAf8EBAMCAcYwHQYDVR0OBBYEFK5U
DpLqqDOpKyQtx8hvMNze80pAMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMA8GA1Ud
EwEB/wQFMAMBAf8wMQYDVR0lBCowKAYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYB
BQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAMnJ7c2YLyrY/PKlFl+7sm8NENfWtFxqdm+6NC6mTagJJ
wx3cUgcsTuE5+7xh9+/G0tTfLzA1qZAQ5GNMPXvmoB9+vJfKnC2JWMFQpIOUEJDXiR4xwX1WI117
ASgEaIDJxSrxHcuuV/hMIO9bgZ6C41MUVmdLTKBgBOImTuIPK8QwggMgMIICiaADAgECAgQ13vTP
MA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQL
EyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0MTUxWhcN
MTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMk
RXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKKlQRkrPFr
U18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkwrFEeO68r
1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOgYaRfMF0x
CzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBD
ZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAxODA4MjIx
NjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAdBgNV
HQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0HQQAEDTAL
GwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwlMQ0AppJu
f7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn00DbOyZY
sih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMgMIICiaADAgEC
AgQ13vTPMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0
MTUxWhcNMTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsG
A1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKK
lQRkrPFrU18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkw
rFEeO68r1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOg
YaRfMF0xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNl
Y3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAx
ODA4MjIxNjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAdBgNVHQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0H
QQAEDTALGwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwl
MQ0AppJuf7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn
00DbOyZYsih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMmMIIC
j6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIxNjM2NTRaMIGFMQsw
CQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEXMBUGA1UEAxMOSmFt
ZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkqhkiG9w0BCQEWEmph
c25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwKpbDG3zMatEuuOT
FYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSyd+7nwqAvbBfPj+0S
vcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7tBJlLrwDRCMoNlPuQ
Kg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQW
BBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOgFAwSamFzbmVs
bEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pAMCcGA1UdJQQgMB4G
CCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAZMKevB7dFfb9
23OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY8BjwVHxiYgG4xkxf
B1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOIzj3lz3xd+uOzqRFg
/Wsg/VMwggMmMIICj6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAy
BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNV
BAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIx
NjM2NTRaMIGFMQswCQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEX
MBUGA1UEAxMOSmFtZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkq
hkiG9w0BCQEWEmphc25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
wKpbDG3zMatEuuOTFYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSy
d+7nwqAvbBfPj+0SvcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7t
BJlLrwDRCMoNlPuQKg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQD
AgXgMB0GA1UdDgQWBBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcU
AgOgFAwSamFzbmVsbEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA
MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQAD
gYEAZMKevB7dFfb923OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY
8BjwVHxiYgG4xkxfB1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOI
zj3lz3xd+uOzqRFg/Wsg/VMxggG7MIIBtwIBATBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJ
bnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0g
Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwF+kzAJBgUrDgMCGgUAoIGiMBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDcxMjIxMzkzMFowIwYJKoZIhvcNAQkEMRYE
FNKsQ46PZS51/02TqUoUXW6yn9F+MEMGCSqGSIb3DQEJDzE2MDQwBwYFKw4DAh0wDgYIKoZIhvcN
AwICAgCAMAoGCCqGSIb3DQMHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAbX1/Rvch
rd2248JbSbvylXUTpP96Qwn99dgUbxzuMOWjTFnsdZDrTIZ5UAXFnm/kezRhVejpIcSb0IILfPbz
PfAla456YFWsiB8fbcdlQH5bfgZk+i//Mee6WUaFcA2KNi7QZthrCW99blkPw8nz6gm+hn5Ice6S
0C1ITsPOMRIAAAAA

---------z47252_boundary_sign--



From owner-atom-syntax@mail.imc.org  Mon Jul 12 17:55:26 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19780
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 17:55:25 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CLlRle067301;
	Mon, 12 Jul 2004 14: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 i6CLlRnZ067300;
	Mon, 12 Jul 2004 14:47:27 -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 i6CLlQEN067291
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 14:47:26 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040712214722.79750.qmail@web41212.mail.yahoo.com>
Received: from [207.46.238.133] by web41212.mail.yahoo.com via HTTP; Mon, 12 Jul 2004 14:47:22 PDT
Date: Mon, 12 Jul 2004 14:47:22 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Version vs. Namespace
To: Tim Bray <Tim.Bray@Sun.COM>, Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <36879593-D428-11D8-9DBF-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:
> 
> 
> OK.  I claim that a single fixed namespace plus a
> single version 
> attribute on the root element, plus an extensibility
> framework 
> involving the usual mustUnderstand/mustIgnore
> primitives, will provide 
> a nice efficient framework for the long term.  I
> further claim that 
> there is now enough experience with this kind of
> versioning 
> architecture that we understand the implementation
> issues.  

I tend to agree with you.

> 
> So...... those who want a more complex and abstract
> versioning set-up 
> should start, I think, from use-cases, so that we
> get a nice clean 
> clear sense of exactly what the complexity buys us. 
> -Tim

My primary use case for versioning is simple. How can
an aggregator which encounters a different version of
Atom from one its seen before know whether it is
backwards compatible or not? With RSS, the assumption
I use in RSS Bandit is that all feeds are RSS 2.0 and
the version attribute is ignored. I'd like Atom to
have something formal about what aggregators like RSS
Bandit should do to be able to distinguish Atom 0.3
from Atom 1.0 [for example]. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
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 Jul 12 17: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 RAA19959
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 17: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 i6CLm2GQ067349;
	Mon, 12 Jul 2004 14:48: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 i6CLm2DH067348;
	Mon, 12 Jul 2004 14:48:02 -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 i6CLm2fw067342
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 14:48:02 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.19] (unknown [63.96.165.149])
	by mail.mnot.net (Postfix) with ESMTP
	id C29457288; Mon, 12 Jul 2004 14:48:06 -0700 (PDT)
In-Reply-To: <20040712211533.90350.qmail@web41511.mail.yahoo.com>
References: <20040712211533.90350.qmail@web41511.mail.yahoo.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <286647B0-D44D-11D8-AFCB-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: Atomlist <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: Re: PaceElementOrder: options 
Date: Mon, 12 Jul 2004 14:48:06 -0700
To: randy@kbcafe.com
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>
Content-Transfer-Encoding: 7bit


How will extensions be ordered, in relation to the "core" metadata as 
well as themselves?

How do your tools benefit from ordering?


On Jul 12, 2004, at 2:15 PM, Randy Charles Morin wrote:

> I like these question? Why disorder? What is the value of not 
> specifying the order? I know that I have major pluses w/ my tools if 
> we can just specify order. What's the counter argument?

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Mon Jul 12 17:59: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 RAA20188
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 17:59:35 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CLhQls067029;
	Mon, 12 Jul 2004 14:43:26 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6CLhQf3067028;
	Mon, 12 Jul 2004 14:43:26 -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 i6CLhP7G067022
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 14:43:25 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.19] (unknown [63.96.165.149])
	by mail.mnot.net (Postfix) with ESMTP
	id 0C897727D; Mon, 12 Jul 2004 14:43:30 -0700 (PDT)
In-Reply-To: <20040712213251.79119.qmail@web41203.mail.yahoo.com>
References: <20040712213251.79119.qmail@web41203.mail.yahoo.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <8353B484-D44C-11D8-AFCB-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: randy@kbcafe.com, Atomlist <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: Re: Normative WSDL for Atom API (was Re: Created proposal: PaceProvideSchema)
Date: Mon, 12 Jul 2004 14:43:29 -0700
To: Dare Obasanjo <kpako@yahoo.com>
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>
Content-Transfer-Encoding: 7bit



On Jul 12, 2004, at 2:32 PM, Dare Obasanjo wrote:

> --- Mark Nottingham <mnot@mnot.net> wrote:
>>
>> Consider this - WSDL isn't specified in terms of XML
>> Schema; it defines
>> a "component model." Neither does SOAP; that's
>> right, the Schema isn't
>> normative, just informational.
>
>
> Considering that at one time there was a claim that
> Atom would support SOAP wouldn't it then be useful for
> there to be a normative WSDL for Atom (which means
> there will have to be a normative element declaration
> for atom:entry at least)? The alternative would be for
> every vendor that supports the Atom API to cook up
> their own schemas for atom:entry which could lead to
> incompatibility.

It doesn't have to be normative to be included in the spec, and for 
people to use it.

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Mon Jul 12 18: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 SAA20477
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 18:02: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 i6CLmwNl067450;
	Mon, 12 Jul 2004 14:48: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 i6CLmw3S067449;
	Mon, 12 Jul 2004 14:48:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web41501.mail.yahoo.com (web41501.mail.yahoo.com [66.218.93.84])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6CLmvoB067431
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 14:48:57 -0700 (PDT)
	(envelope-from randymorin@yahoo.com)
Message-ID: <20040712214857.85246.qmail@web41501.mail.yahoo.com>
Received: from [66.46.139.106] by web41501.mail.yahoo.com via HTTP; Mon, 12 Jul 2004 14:48:57 PDT
Date: Mon, 12 Jul 2004 14:48:57 -0700 (PDT)
From: Randy Charles Morin <randymorin@yahoo.com>
Reply-To: randy@kbcafe.com
Subject: Re: Normative WSDL for Atom API (was Re: Created proposal: PaceProvideSchema)
To: Dare Obasanjo <kpako@yahoo.com>, Mark Nottingham <mnot@mnot.net>,
        randy@kbcafe.com
Cc: Atomlist <atom-syntax@imc.org>
In-Reply-To: <20040712213251.79119.qmail@web41203.mail.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-2101340600-1089668937=:84533"
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>


--0-2101340600-1089668937=:84533
Content-Type: text/plain; charset=us-ascii

Actually, I would like more clarity here. Tim said that Atom will be SOAP friendly [1], but there's a proposal to remove the SOAP from Atom [2]. Can this be settled? Can I ask the IETF working group to do a straw poll and/or decide either way.
Thanks,
 
Randy
 
[1] - http://www.tbray.org/ongoing/When/200x/2004/06/10/AtomIETFYes
[2] - http://www.intertwingly.net/wiki/pie/PacePutDelete


Dare Obasanjo <kpako@yahoo.com> wrote:
--- Mark Nottingham wrote:
> 
> Consider this - WSDL isn't specified in terms of XML
> Schema; it defines 
> a "component model." Neither does SOAP; that's
> right, the Schema isn't 
> normative, just informational.


Considering that at one time there was a claim that
Atom would support SOAP wouldn't it then be useful for
there to be a normative WSDL for Atom (which means
there will have to be a normative element declaration
for atom:entry at least)? The alternative would be for
every vendor that supports the Atom API to cook up
their own schemas for atom:entry which could lead to
incompatibility. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.



__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

		
---------------------------------
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
--0-2101340600-1089668937=:84533
Content-Type: text/html; charset=us-ascii

<DIV>Actually, I would like more clarity here. Tim said that Atom will be SOAP friendly [1], but there's a proposal to remove the SOAP from Atom [2]. Can this be settled? Can I ask the IETF working group to do a straw poll and/or decide either way.</DIV>
<DIV>Thanks,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Randy</DIV>
<DIV>&nbsp;</DIV>
<DIV>[1] - <A href="http://www.tbray.org/ongoing/When/200x/2004/06/10/AtomIETFYes">http://www.tbray.org/ongoing/When/200x/2004/06/10/AtomIETFYes</A></DIV>
<DIV>[2] - <A href="http://www.intertwingly.net/wiki/pie/PacePutDelete">http://www.intertwingly.net/wiki/pie/PacePutDelete</A></DIV>
<DIV><BR><BR><B><I>Dare Obasanjo &lt;kpako@yahoo.com&gt;</I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">--- Mark Nottingham <MNOT@MNOT.NET>wrote:<BR>&gt; <BR>&gt; Consider this - WSDL isn't specified in terms of XML<BR>&gt; Schema; it defines <BR>&gt; a "component model." Neither does SOAP; that's<BR>&gt; right, the Schema isn't <BR>&gt; normative, just informational.<BR><BR><BR>Considering that at one time there was a claim that<BR>Atom would support SOAP wouldn't it then be useful for<BR>there to be a normative WSDL for Atom (which means<BR>there will have to be a normative element declaration<BR>for atom:entry at least)? The alternative would be for<BR>every vendor that supports the Atom API to cook up<BR>their own schemas for atom:entry which could lead to<BR>incompatibility. <BR><BR>=====<BR>THINGS TO DO IF I BECOME AN EVIL OVERLORD #95<BR>My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tel!
 ls the
 guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.<BR><BR><BR><BR>__________________________________<BR>Do you Yahoo!?<BR>Yahoo! Mail is new and improved - Check it out!<BR>http://promotions.yahoo.com/new_mail<BR></BLOCKQUOTE><p>
		<hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/mail_us/taglines/50x/*http://promotions.yahoo.com/new_mail/static/efficiency.html">Yahoo! Mail</a> - 50x more storage than other providers!
--0-2101340600-1089668937=:84533--



From owner-atom-syntax@mail.imc.org  Mon Jul 12 18:05: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 SAA21084
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 18: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 i6CLnCYS067480;
	Mon, 12 Jul 2004 14:49: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 i6CLnCpN067479;
	Mon, 12 Jul 2004 14:49:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CLnB6m067473
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 14:49: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 i6CLnGil001063
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 15:49:16 -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 <0I0R006W1DY4MU@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Mon, 12 Jul 2004 15:49:16 -0600 (MDT)
Received: from [192.168.1.9] ([154.20.133.9])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0R00KJKDY33Q@mail.sun.net> for atom-syntax@imc.org; Mon,
 12 Jul 2004 15:49:16 -0600 (MDT)
Date: Mon, 12 Jul 2004 14:49:17 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Version vs. Namespace
In-reply-to: <32D5845A745BFB429CBDBADA57CD41AF08D6B39E@ussjex01.amer.bea.com>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <52AC8A64-D44D-11D8-AE39-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: <32D5845A745BFB429CBDBADA57CD41AF08D6B39E@ussjex01.amer.bea.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 Jul 12, 2004, at 2:05 PM, David Orchard wrote:

> Norm and I have written up material on why coarse grained version #s 
> are bad [1] and even used RSS as an example.  We have implementation 
> experience on using version #s, and it isn't that great.

I just read that, and I certainly agree with its line of argument, but 
I'm not convinced about the version number.  The example of RSS doesn't 
work, RSS's "version numbers" (0.9*, 1.0, 2.0*) aren't anything like 
version numbers.  I propose the following policy:

1. Atom documents have a version number which identifies a version of 
the governing specification, and there is a clear ordering relationship 
among released versions.
2. Atom software implementations declare conformance to some version 
number
3. When Atom software encounters Atom-namespace markup from its own or 
an earlier version, and doesn't recognize that markup, i.e. it's not in 
the specification for its version, that's an error.
4. When Atom software encounters Atom-namespace markup from a later 
version than its own, by default it applies a MustIgnore policy unless 
the markup carries the attribute policy="mustUnderstand"
5. When Atom software encounters markup from namespaces other than 
Atom, it MAY ignore that markup (doesn't prevent people from agreeing 
on extensions).

Note:
- you could make MustUnderstand instead of MustIgnore the default
- you could imagine another way to signal the policy, i.e. a containing 
element or something
- you could put new stuff in a different namespace

  -Tim



From owner-atom-syntax@mail.imc.org  Mon Jul 12 18:08: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 SAA21456
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 18:08: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 i6CLkFxn067206;
	Mon, 12 Jul 2004 14:46: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 i6CLkF2E067205;
	Mon, 12 Jul 2004 14:46:15 -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 i6CLkEHl067198
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 14:46:14 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.19] (unknown [63.96.165.149])
	by mail.mnot.net (Postfix) with ESMTP
	id 3CEBA727D; Mon, 12 Jul 2004 14:46:19 -0700 (PDT)
In-Reply-To: <A5F347BE-D42A-11D8-9DBF-000A95A51C9E@sun.com>
References: <A5F347BE-D42A-11D8-9DBF-000A95A51C9E@sun.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <E82A9628-D44C-11D8-AFCB-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: Atom Syntax <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: Re: Rough consensus on PaceElementOrder?
Date: Mon, 12 Jul 2004 14:46:18 -0700
To: Tim Bray <Tim.Bray@Sun.COM>
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>
Content-Transfer-Encoding: 7bit


Sounds like a plan. I'm not crazy about "feedinfo", but can't think of 
something to replace it.



On Jul 12, 2004, at 10:41 AM, Tim Bray wrote:

>
> I think that we are approaching rough consensus on PaceElementOrder, 
> like so:
>
> 1. I think we clearly have consensus that the feed-level elements 
> should all appear before the <atom:entry> elements.
>
> 2. I think we have probably have good-enough rough consensus that it's 
> worthwhile grouping all the non-entry stuff in an <atom:feedinfo> or 
> some such, so that the content model for <atom:feed> is something like
>
>   atom:feedinfo, atom:entry*
>
> The cost of doing this seems effectively zero and there are some 
> detectable advantages.
>
> 3. There has been some discussion around the notion that there are 
> some feed-level things that are really mostly about providing defaults 
> for the <atom:entries>, with the consequent suggestion that maybe they 
> deserve their own top-level element, with further digressions into 
> doing defaulting by reference rather than by inheritance.  I do not 
> detect consensus in these discussions (in fact I'm not convinced that 
> it's been demonstrated that there things that are have pure 
> entry-default as opposed to feed-metadata semantics).
>
> SO: I propose that rather than tear this one apart any further, we ask 
> the editors to, in the -01 drafts, recast the data format with the 
> <atom:feedinfo> element (anyone should feel free to suggest a better 
> name than "feedinfo"), and that those who care about defaulting cook 
> up a Pace or three outlining specifically what the options are.  -Tim
>

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Mon Jul 12 18: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 SAA23471
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 18: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 i6CM6gex068686;
	Mon, 12 Jul 2004 15:06: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 i6CM6gBm068685;
	Mon, 12 Jul 2004 15:06: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 i6CM6g19068670
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 15:06: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 <2004071222064101300j2v31e>; Mon, 12 Jul 2004 22:06:41 +0000
Date: Mon, 12 Jul 2004 16:06:40 -0600
Subject: Re: a methodical approach to defining what date  elements we need
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: <opsa1nlh1u6dxgxk@mail.online.no>
Message-Id: <C056B7B2-D44F-11D8-9D0B-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 Monday, July 12, 2004, at 03:35  PM, Arve Bersvendsen wrote:
>> 2) A date to show the user, usually the same as above
> What a view date is, is by it's very nature not in a feed author's 
> control [2]. You might be interested in the modified date. Your 
> neighbour in the issued date. Your friends could want the issued date 
> in UTC, I could want all three of the dates in +01:00 or +02:00 
> depending on time of year.  Your boss could want the delta between 
> created and issued, but only when written within your working hours.

Yes, the way the dates are formatted for display is up to the user.  
The question for us in defining the format is which data needs to be in 
the feed in order for the user to be able to get their software to 
display what they want?  All but the boss's desired information could 
be covered by having the issued date in the author's local time (I 
presume that's what you mean by what your neighbour wants?) and the 
modified date (in which timezone?)  Your client software can convert 
the dates UTC if desired, so it doesn't need to be stored separately 
that way.  (BTW, as long as either of the two dates indicates the 
origin timezone, the other COULD be in UTC).

As for your boss wanting to know how long it took you to write and 
publish the entry, that probably doesn't need to be in the feed--your 
boss should be able to find that out from data stored in your 
publishing system.  I don't think this is going to be of general 
interest to readers of the feed.



From owner-atom-syntax@mail.imc.org  Mon Jul 12 18: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 SAA23958
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 18: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 i6CMCIHK069352;
	Mon, 12 Jul 2004 15:12:18 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6CMCIt8069351;
	Mon, 12 Jul 2004 15:12:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web41508.mail.yahoo.com (web41508.mail.yahoo.com [66.218.93.91])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6CMCHoO069337
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 15:12:17 -0700 (PDT)
	(envelope-from randymorin@yahoo.com)
Message-ID: <20040712221217.55674.qmail@web41508.mail.yahoo.com>
Received: from [66.46.139.106] by web41508.mail.yahoo.com via HTTP; Mon, 12 Jul 2004 15:12:17 PDT
Date: Mon, 12 Jul 2004 15:12:17 -0700 (PDT)
From: Randy Charles Morin <randymorin@yahoo.com>
Reply-To: randy@kbcafe.com
Subject: Re: PaceElementOrder: options 
To: Mark Nottingham <mnot@mnot.net>, randy@kbcafe.com
Cc: Atomlist <atom-syntax@imc.org>
In-Reply-To: <286647B0-D44D-11D8-AFCB-000A95BD86C0@mnot.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-2133865587-1089670337=:55470"
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>


--0-2133865587-1089670337=:55470
Content-Type: text/plain; charset=us-ascii

>How will extensions be ordered?
I suggest we use prior art, the same approach as HR-XML [1]. The HR-XML vocabulary and schemas indicate where the extensions should be located w/in the core elements, but does not impose an order on the extensions relative to other extensions.
 
>How do your tools benefit from ordering?
Example - If you generate C# using XSD.exe [2] from my Atom XSD [3] and the elements are not ordered, then the generated classes do not account for cardinality of the unordered elements. This is because XSD cannot describe cardinality of unordered elements. If the elements are ordered, then the generated class can account for cardinality of elements and can be made to exactly describe the Atom data model. So, by ordering elements, I can create perfectly matched syntax helper classes without writing one line of code (all generated code). I can do this w/ XSD to generate C# and VB and XMLSpy to generate Java, C# and C++ [4]. 
Thanks and now its your turn,
 
Randy
http://www.kbcafe.com
 
[1] - http://www.hr-xml.org/channels/home.htm
[2] - http://msdn.microsoft.com/library/en-us/cptools/html/cpconXMLSchemaDefinitionToolXsdexe.asp
[3] - http://www.kbcafe.com/rss/?guid=20040710135750
[4] - http://www.kbcafe.com/iBLOGthere4iM/?guid=20031215221537

Mark Nottingham <mnot@mnot.net> wrote:
How will extensions be ordered, in relation to the "core" metadata as 
well as themselves?

How do your tools benefit from ordering?


On Jul 12, 2004, at 2:15 PM, Randy Charles Morin wrote:

> I like these question? Why disorder? What is the value of not 
> specifying the order? I know that I have major pluses w/ my tools if 
> we can just specify order. What's the counter argument?

--
Mark Nottingham http://www.mnot.net/


		
---------------------------------
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
--0-2133865587-1089670337=:55470
Content-Type: text/html; charset=us-ascii

<DIV>&gt;How will extensions be ordered?</DIV>
<DIV>I suggest we use prior art, the same approach as HR-XML [1]. The HR-XML vocabulary and schemas indicate where the extensions&nbsp;should be&nbsp;located&nbsp;w/in the core elements, but does not impose an order on the extensions relative to other extensions.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&gt;How do your tools benefit from ordering?</DIV>
<DIV>Example - If you generate C# using XSD.exe [2]&nbsp;from my Atom XSD [3] and the elements are not ordered, then the generated classes&nbsp;do not&nbsp;account for cardinality of the unordered elements. This is because XSD cannot&nbsp;describe cardinality of unordered elements. If the elements are ordered, then the generated class can account for cardinality of elements and can be made to exactly describe the Atom data model. So, by ordering elements, I can create perfectly matched syntax helper classes without writing one line of code (all generated code). I can do this w/ XSD to generate C# and VB and XMLSpy to generate Java, C# and C++ [4]. </DIV>
<DIV>Thanks and now its your turn,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Randy</DIV>
<DIV><A href="http://www.kbcafe.com">http://www.kbcafe.com</A></DIV>
<DIV>&nbsp;</DIV>
<DIV>[1] - <A href="http://www.hr-xml.org/channels/home.htm">http://www.hr-xml.org/channels/home.htm</A></DIV>
<DIV>[2] - <A href="http://msdn.microsoft.com/library/en-us/cptools/html/cpconXMLSchemaDefinitionToolXsdexe.asp">http://msdn.microsoft.com/library/en-us/cptools/html/cpconXMLSchemaDefinitionToolXsdexe.asp</A></DIV>
<DIV>[3] - <A href="http://www.kbcafe.com/rss/?guid=20040710135750">http://www.kbcafe.com/rss/?guid=20040710135750</A></DIV>
<DIV>[4] - <A href="http://www.kbcafe.com/iBLOGthere4iM/?guid=20031215221537">http://www.kbcafe.com/iBLOGthere4iM/?guid=20031215221537</A><BR><BR><B><I>Mark Nottingham &lt;mnot@mnot.net&gt;</I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">How will extensions be ordered, in relation to the "core" metadata as <BR>well as themselves?<BR><BR>How do your tools benefit from ordering?<BR><BR><BR>On Jul 12, 2004, at 2:15 PM, Randy Charles Morin wrote:<BR><BR>&gt; I like these question? Why disorder? What is the value of not <BR>&gt; specifying the order? I know that I have major pluses w/ my tools if <BR>&gt; we can just specify order. What's the counter argument?<BR><BR>--<BR>Mark Nottingham http://www.mnot.net/<BR><BR></BLOCKQUOTE><p>
		<hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/mail_us/taglines/10/*http://promotions.yahoo.com/new_mail/static/efficiency.html">New and Improved Yahoo! Mail</a> - Send 10MB messages!
--0-2133865587-1089670337=:55470--



From owner-atom-syntax@mail.imc.org  Mon Jul 12 18: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 SAA24854
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 18: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 i6CMLCHT070208;
	Mon, 12 Jul 2004 15: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 i6CMLCtE070207;
	Mon, 12 Jul 2004 15:21:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CMLBLa070201
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 15:21: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 i6CMLGil018858
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 16:21:16 -0600 (MDT)
Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0I0R004H6FFGXK@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Mon, 12 Jul 2004 16:21:16 -0600 (MDT)
Received: from [192.168.1.9] ([154.20.133.9])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0R00EJ2FFDC4@mail.sun.net> for atom-syntax@imc.org; Mon,
 12 Jul 2004 16:21:16 -0600 (MDT)
Date: Mon, 12 Jul 2004 15:21:15 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Normative WSDL for Atom API (was Re: Created proposal:
 PaceProvideSchema)
In-reply-to: <20040712214857.85246.qmail@web41501.mail.yahoo.com>
To: Atomlist <atom-syntax@imc.org>
Message-id: <CA325596-D451-11D8-AE39-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: <20040712214857.85246.qmail@web41501.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 Jul 12, 2004, at 2:48 PM, Randy Charles Morin wrote:

> Actually, I would like more clarity here. Tim said that Atom will be 
> SOAP friendly [1], but there's a proposal to remove the SOAP from Atom 
> [2]. Can this be settled? Can I ask the IETF working group to do a 
> straw poll and/or decide either way.

No, but we'll make sure that issue is in our input queue. (Through 
which we're making good progress, thank you everyone!) Is there a Pace 
for it? [checks]  I don't think so.  Clearly PacePutDelete and 
PlaceWsdl are related.  Do we need a Unified Pace for all these related 
issues?  -Tim



From owner-atom-syntax@mail.imc.org  Mon Jul 12 18:35:25 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25159
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 18:35:25 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CMOAB3070386;
	Mon, 12 Jul 2004 15:24:10 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6CMOA19070385;
	Mon, 12 Jul 2004 15:24: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 i6CMOATb070368
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 15:24: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 esmtp (Exim 4.34)
	id 1Bk9DQ-0000wf-RX; Mon, 12 Jul 2004 22:24:05 +0000
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Mon, 12 Jul 2004 18:24:15 -0400
Subject: Re: Normative WSDL for Atom API 
From: Robert Sayre <mint@franklinmint.fm>
To: Dare Obasanjo <kpako@yahoo.com>, Mark Nottingham <mnot@mnot.net>,
        <randy@kbcafe.com>
CC: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD1887CF.12EE8%mint@franklinmint.fm>
In-Reply-To: <20040712213251.79119.qmail@web41203.mail.yahoo.com>
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: <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 7/12/04 5:32 PM, "Dare Obasanjo" <kpako@yahoo.com> wrote:

> 
> --- Mark Nottingham <mnot@mnot.net> wrote:
>>  
>> Consider this - WSDL isn't specified in terms of XML
>> Schema; it defines
>> a "component model." Neither does SOAP; that's
>> right, the Schema isn't
>> normative, just informational.
> 
> 
> Considering that at one time there was a claim that
> Atom would support SOAP

SOAP support is in the current protocol draft (Appendix A).

> wouldn't it then be useful for
> there to be a normative WSDL for Atom (which means
> there will have to be a normative element declaration
> for atom:entry at least)?

Given the introspection debates we've been having, I think a normative WSDL
for the protocol is worth considering.

Unfortunately, it appears the unfinished SOAP 1.2 and WSDL 1.2/2.0 bindings
working draft[1] would be a better fit for Atom, since it defines an HTTP
binding. 

Problems:
* only defines GET/POST, not sure if it allows others
* all endpoints must be on the same host, not sure why that is

Dave Orchard has written a WSDL 2.0 file for Atom 0.3:
http://www.pacificspirit.com/blog/2004/07/05/atom_03_wsdl_20

Robert Sayre

[1] http://www.w3.org/TR/wsdl12-bindings/#_http



From owner-atom-syntax@mail.imc.org  Mon Jul 12 18:37:09 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25373
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 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 i6CMU6nm070839;
	Mon, 12 Jul 2004 15:30:06 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6CMU6KZ070838;
	Mon, 12 Jul 2004 15:30:06 -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 i6CMU4MW070822
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 15:30:06 -0700 (PDT)
	(envelope-from djpowell@djpowell.net)
Received: from cpc2-stke1-5-0-cust190.bagu.cable.ntl.com ([81.111.201.190])
          by mta04-svc.ntlworld.com
          (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP
          id <20040712222850.QPX18251.mta04-svc.ntlworld.com@cpc2-stke1-5-0-cust190.bagu.cable.ntl.com>;
          Mon, 12 Jul 2004 23:28:50 +0100
Date: Mon, 12 Jul 2004 23:29:58 +0100
From: David Powell <djpowell@djpowell.net>
X-Mailer: The Bat! (v2.12 RC/4) Business
Reply-To: David Powell <djpowell@djpowell.net>
X-Priority: 3 (Normal)
Message-ID: <349258756.20040712232958@djpowell.net>
To: Ken MacLeod <ken@bitsko.slc.ut.us>
CC: atom-syntax@imc.org
Subject: Re: HTML fragments in content constructs
In-Reply-To: <m3n026pda3.fsf@bitsko.slc.ut.us>
References: <1901598504.20040711195219@djpowell.net>
 <m3n026pda3.fsf@bitsko.slc.ut.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


Sunday, July 11, 2004, 8:14:12 PM, ken@bitsko.slc.ut.us wrote:

>> It is usual for entry content to be labeled as @type="text/html",
>> but really contain HTML fragments - not full HTML.

> Dave, take a look at PaceSimpleContentType, particularly the "Content
> Profiles" section, and see if you agree with that.  That Pace was
> written to address this issue, among a couple others.

Yes, I agree with those changes to the text content model. I don't see
any loss in scrapping @type, because using it to label HTML fragments
as text/html seems like an abuse of MIME anyway. I was also finding
@mode confusing when applied to non-HTML content and this model seems
clearer about that too.

Handling multimedia looks like a more contentious problem, there are a
lot of proposals and the differences look fairly subtle so I haven't
got a preference for that aspect of the proposal yet.


-- 
Dave



From owner-atom-syntax@mail.imc.org  Mon Jul 12 18:37:50 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25458
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 18:37: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 i6CMPYrK070470;
	Mon, 12 Jul 2004 15: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 i6CMPYvh070469;
	Mon, 12 Jul 2004 15:25:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CMPYpe070460
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 15:25:34 -0700 (PDT)
	(envelope-from antone@geckotribe.com)
Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134])
          by comcast.net (rwcrmhc13) with SMTP
          id <2004071222253401500hdbibe>; Mon, 12 Jul 2004 22:25:34 +0000
Date: Mon, 12 Jul 2004 16:25:33 -0600
Subject: Re: a methodical approach to defining what date  elements we need
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: <C056B7B2-D44F-11D8-9D0B-003065EA6144@geckotribe.com>
Message-Id: <63E12F93-D452-11D8-9D0B-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 Monday, July 12, 2004, at 04:06  PM, Antone Roundy wrote:
> On Monday, July 12, 2004, at 03:35  PM, Arve Bersvendsen wrote:
>>> 2) A date to show the user, usually the same as above
>> What a view date is, is by it's very nature not in a feed author's 
>> control [2]. You might be interested in the modified date. Your 
>> neighbour in the issued date. Your friends could want the issued date 
>> in UTC, I could want all three of the dates in +01:00 or +02:00 
>> depending on time of year.  Your boss could want the delta between 
>> created and issued, but only when written within your working hours.
>
> Yes, the way the dates are formatted for display is up to the user.  
> The question for us in defining the format is which data needs to be 
> in the feed in order for the user to be able to get their software to 
> display what they want?  All but the boss's desired information could 
> be covered by having the issued date in the author's local time (I 
> presume that's what you mean by what your neighbour wants?) and the 
> modified date (in which timezone?)  Your client software can convert 
> the dates UTC if desired, so it doesn't need to be stored separately 
> that way.  (BTW, as long as either of the two dates indicates the 
> origin timezone, the other COULD be in UTC).

Oops, I abandoned my own rigor here.  Additional questions:

1) By "issued date" and "modified date" do you mean objective 
timestamps, or author-specifiable (subjective) timestamps? (2, 3, 4 or 
6, 7, 8)

2) By "issued" do you mean first issued or most recently issued (if the 
same entry was "issued" more than once)?  (first 4 or 8 or last 4 or 8)

3) By "modified", do you mean the last major change which changed or 
non-trivially augmented the meaning of the entry, or the last 
modification of any kind, including things like spelling fixes? (2|6 or 
3|7)

Yeah, it may be difficult to draw a perfect line between major and 
minor changes, but a lot of people, myself included, seem to WANT to be 
able to differentiate, and I for one would prefer the publisher's best 
effort to do so over not having any hope of differentiating.



From owner-atom-syntax@mail.imc.org  Mon Jul 12 18: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 SAA26347
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 18: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 i6CMbWJM071345;
	Mon, 12 Jul 2004 15:37: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 i6CMbW8G071344;
	Mon, 12 Jul 2004 15:37: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 i6CMbV1P071324
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 15:37:31 -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 289014F033;
	Mon, 12 Jul 2004 18:37:33 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040713073327.00b75078@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Tue, 13 Jul 2004 07:37:27 +0900
To: Tim Bray <Tim.Bray@Sun.COM>, Atom Syntax <atom-syntax@imc.org>
From: Martin Duerst <duerst@w3.org>
Subject: Re: Version vs. Namespace
In-Reply-To: <52AC8A64-D44D-11D8-AE39-000A95A51C9E@sun.com>
References: <32D5845A745BFB429CBDBADA57CD41AF08D6B39E@ussjex01.amer.bea.com>
 <32D5845A745BFB429CBDBADA57CD41AF08D6B39E@ussjex01.amer.bea.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 14:49 04/07/12 -0700, Tim Bray wrote:

>On Jul 12, 2004, at 2:05 PM, David Orchard wrote:
>
>>Norm and I have written up material on why coarse grained version #s are 
>>bad [1] and even used RSS as an example.  We have implementation 
>>experience on using version #s, and it isn't that great.
>
>I just read that, and I certainly agree with its line of argument, but I'm 
>not convinced about the version number.  The example of RSS doesn't work, 
>RSS's "version numbers" (0.9*, 1.0, 2.0*) aren't anything like version 
>numbers.  I propose the following policy:
>
>1. Atom documents have a version number which identifies a version of the 
>governing specification, and there is a clear ordering relationship among 
>released versions.
>2. Atom software implementations declare conformance to some version number
>3. When Atom software encounters Atom-namespace markup from its own or an 
>earlier version, and doesn't recognize that markup, i.e. it's not in the 
>specification for its version, that's an error.
>4. When Atom software encounters Atom-namespace markup from a later 
>version than its own, by default it applies a MustIgnore policy unless the 
>markup carries the attribute policy="mustUnderstand"

Big question:
How does an Atom implementation that is conformant e.g. to version
2.48 decide whether unknown Atom-namespace markup is 'from its own or
an earlier version but not in the specification' or 'from a later
version than its own'? Even more to the point, does it make sense to
speak about markup 'from its own or an earlier version but not in the
specification'? Sounds like a contradiction to me, unless I missed
something.

Regards,    Martin.


>5. When Atom software encounters markup from namespaces other than Atom, 
>it MAY ignore that markup (doesn't prevent people from agreeing on extensions).
>
>Note:
>- you could make MustUnderstand instead of MustIgnore the default
>- you could imagine another way to signal the policy, i.e. a containing 
>element or something
>- you could put new stuff in a different namespace
>
>  -Tim



From owner-atom-syntax@mail.imc.org  Mon Jul 12 18:58:34 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27924
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 18:58:34 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CMiPOj073040;
	Mon, 12 Jul 2004 15: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 i6CMiPj8073039;
	Mon, 12 Jul 2004 15:44:25 -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 i6CMiNaC073031
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 15:44:24 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p06110444bd18c4cb40c8@[10.20.30.249]>
In-Reply-To: <8353B484-D44C-11D8-AFCB-000A95BD86C0@mnot.net>
References: <20040712213251.79119.qmail@web41203.mail.yahoo.com>
 <8353B484-D44C-11D8-AFCB-000A95BD86C0@mnot.net>
Date: Mon, 12 Jul 2004 15:44:51 -0700
To: Atom WG <atom-syntax@imc.org>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: Normative WSDL for Atom API (was Re: Created proposal:
 PaceProvideSchema)
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:43 PM -0700 7/12/04, Mark Nottingham wrote:
>It doesn't have to be normative to be included in the spec, and for 
>people to use it.

+1 and +1

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Mon Jul 12 18:59: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 SAA28036
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 18:59: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 i6CMmtUk073355;
	Mon, 12 Jul 2004 15:48: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 i6CMmtCP073354;
	Mon, 12 Jul 2004 15:48:55 -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 i6CMms6I073334
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 15:48:54 -0700 (PDT)
	(envelope-from roger@agincourtmedia.com)
Received: from biggreen ([216.63.148.42]) by journurl.com with MailEnable ESMTP; Mon, 12 Jul 2004 17:48:04 -0500
From: "Roger B." <roger@agincourtmedia.com>
To: "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: RE: MUST be UTC?
Date: Mon, 12 Jul 2004 17:49:50 -0500
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: <opsa1c80qruvpchu@quark>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Thread-Index: AcRoOGEdaZnYLhWlTayiipcHKTtG1AAKB2BQ
Message-ID: <977FB0B08A6A43299D6B6F31BEE5FE.MAI@journurl.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


> Okay. I just have to ask. Is it consensus that Atom should:
> 
>    1. Only cater for the blogging community.
>    2. Only cater for existing blogging tools.
>    3. Just adopt current (bad) practices and not try to do anything to
>       improve the quality of service or data in the syndication sphere.

RE: 1 and 2... Only? No. Primarily? Yes. From the roadmap on down, blogging
has been the basis of Atom's existence.

RE: 3... Repeatedly claiming that something is bad practice does not make it
bad practice. Modified dates change. Publish dates change. That's the way it
is.

> This would take me less than two minutes to implement in my tool.

Uh oh. Once we've reached the point where we're violating the programmers'
corollary to Godwin's Law, it's probably time to move on.

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/ 







From owner-atom-syntax@mail.imc.org  Mon Jul 12 19:12: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 TAA29195
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 19:12: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 i6CMqWI1073653;
	Mon, 12 Jul 2004 15:52: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 i6CMqWUl073652;
	Mon, 12 Jul 2004 15:52:32 -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 i6CMqW8V073634
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 15:52:32 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040712225232.77296.qmail@web41204.mail.yahoo.com>
Received: from [207.46.228.16] by web41204.mail.yahoo.com via HTTP; Mon, 12 Jul 2004 15:52:31 PDT
Date: Mon, 12 Jul 2004 15:52:31 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: RE: Version vs. Namespace
To: James M Snell <jasnell@us.ibm.com>, David Orchard <dorchard@bea.com>
Cc: Atom Syntax <atom-syntax@imc.org>, owner-atom-syntax@mail.imc.org,
        Tim Bray <Tim.Bray@Sun.COM>
In-Reply-To: <OFD6B4FC0F.25D0F7F0-ON88256ECF.0076E9B4-88256ECF.00771ECD@us.ibm.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>


--- James M Snell <jasnell@us.ibm.com> wrote:
> 
> Norm and I have written up material on why coarse
> grained version #s are 
> bad [1] and even used RSS as an example.  We have
> implementation 
> experience on using version #s, and it isn't that
> great.
> 
> Cheers,
> Dave
> 
> [1]
> http://www.w3.org/2001/tag/doc/versioning#problems

I read the information in the TAG document and didn't
see a compelling argument against using version
numbers besides pointing to the RSS debacle whose
current state has little to do with the existence or
lack version attributes on root elements. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
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 Jul 12 19:15: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 TAA29709
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 19:15: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 i6CN4wHB074652;
	Mon, 12 Jul 2004 16:04: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 i6CN4wr3074651;
	Mon, 12 Jul 2004 16:04:58 -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 i6CN4wtG074645
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 16:04:58 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i6CN2u53023334
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 17:02:56 -0600 (MDT)
Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0I0R00LO5HGF2G@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Mon, 12 Jul 2004 17:05:03 -0600 (MDT)
Received: from [192.168.1.9] ([154.20.133.9])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0R00EW5HGE97@mail.sun.net> for atom-syntax@imc.org; Mon,
 12 Jul 2004 17:05:02 -0600 (MDT)
Date: Mon, 12 Jul 2004 16:05:04 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Version vs. Namespace
In-reply-to: <4.2.0.58.J.20040713073327.00b75078@localhost>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <E9405742-D457-11D8-AE39-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: <32D5845A745BFB429CBDBADA57CD41AF08D6B39E@ussjex01.amer.bea.com>
 <32D5845A745BFB429CBDBADA57CD41AF08D6B39E@ussjex01.amer.bea.com>
 <4.2.0.58.J.20040713073327.00b75078@localhost>
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 Jul 12, 2004, at 3:37 PM, Martin Duerst wrote:

> At 14:49 04/07/12 -0700, Tim Bray wrote:
>> 3. When Atom software encounters Atom-namespace markup from its own 
>> or an earlier version, and doesn't recognize that markup, i.e. it's 
>> not in the specification for its version, that's an error.
>
> Big question:
> How does an Atom implementation that is conformant e.g. to version
> 2.48 decide whether unknown Atom-namespace markup is 'from its own or
> an earlier version but not in the specification' or 'from a later
> version than its own'?

Because instances have version numbers.  I.e. it sees <atom:feed 
version="2.0">
as opposed to <atom:feed version="3.0">

> Even more to the point, does it make sense to
> speak about markup 'from its own or an earlier version but not in the
> specification'? Sounds like a contradiction to me, unless I missed
> something.

I mean, if the 2.0 code sees

<atom:feed version="2.0"><atom:frob />

and "frob" isn't in the specification, then that's an error. -Tim



From owner-atom-syntax@mail.imc.org  Mon Jul 12 19:29: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 TAA01565
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 19:29: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 i6CNHvRi075893;
	Mon, 12 Jul 2004 16:17: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 i6CNHvlf075892;
	Mon, 12 Jul 2004 16:17:57 -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 i6CNHvqB075883
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 16:17:57 -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 QAA02267
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 16:17:57 -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 QAA05291
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 16:17: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, 12 Jul 2004 16:17:56 -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 <0I0R00HLAI1UMZ@shazam.verity.com> for atom-syntax@imc.org; Mon,
 12 Jul 2004 16:17:55 -0700 (PDT)
Date: Mon, 12 Jul 2004 16:17:55 -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: a methodical approach to defining what date  elements we need
In-reply-to: <opsa1nlh1u6dxgxk@mail.online.no>
To: Atom-syntax <atom-syntax@imc.org>
Message-id: 
 <6C2098C54ED33AE163D3E2F5@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
MIME-version: 1.0
X-Mailer: Mulberry/3.1.5 (Mac OS X)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <14B72756-D419-11D8-9D0B-003065EA6144@geckotribe.com>
 <40F2C2CD.9020307@intertwingly.net>
 <47071860-D42A-11D8-82B1-000A95DC3D90@mac.com>
 <opsa1nlh1u6dxgxk@mail.online.no>
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 Monday, July 12, 2004 11:35 PM +0200 Arve Bersvendsen <arve@virtuelvis.com> wrote:
> On Mon, 12 Jul 2004 13:38:25 -0400, Graham <dtcd@mac.com> wrote:
>
>> 2) A date to show the user, usually the same as above
>
> What a view date is, is by it's very nature not in a feed author's
> control [2].

It is in the author's control if we allow the author to provide
a display date. When an author is posting at 3am local time, or
during Ramadan, the author's view of the date matters, and should
normally be preferred.

This is different from the normal localization approach, were all
dates are converted to local format.

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Mon Jul 12 20:25:16 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05114
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 20:25:16 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D0Eoce079855;
	Mon, 12 Jul 2004 17:14: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 i6D0Eow0079854;
	Mon, 12 Jul 2004 17:14:50 -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 i6D0Eox0079847
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 17:14:50 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.19] (unknown [63.96.165.149])
	by mail.mnot.net (Postfix) with ESMTP
	id 6B57E7288; Mon, 12 Jul 2004 17:14:55 -0700 (PDT)
In-Reply-To: <20040712214722.79750.qmail@web41212.mail.yahoo.com>
References: <20040712214722.79750.qmail@web41212.mail.yahoo.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <AA8D7D00-D461-11D8-AFCB-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: Atom Syntax <atom-syntax@imc.org>, Tim Bray <Tim.Bray@Sun.COM>
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: Usage Scenarios for Versioning and Extensibility
Date: Mon, 12 Jul 2004 17:14:54 -0700
To: Dare Obasanjo <kpako@yahoo.com>
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>
Content-Transfer-Encoding: 7bit



On Jul 12, 2004, at 2:47 PM, Dare Obasanjo wrote:

> My primary use case for versioning is simple. How can
> an aggregator which encounters a different version of
> Atom from one its seen before know whether it is
> backwards compatible or not? With RSS, the assumption
> I use in RSS Bandit is that all feeds are RSS 2.0 and
> the version attribute is ignored.

I'd like to make this a bit more concrete.

0) Let's imagine that Atom 1.0 has been released and finalised in all 
of its glory.

1) And it was good... except for that nasty atom:title element; after 
wide deployment experience, it's agreed we need a new version of it. 
So, a new version of Atom is introduced. The new one isn't 
backwards-compatible with the old one.

2) Then, we decide we want to add a new metadata element, let's call it 
"fog." So, a new version of Atom is introduced.

3) After a while, someone comes up with a souped-up version of 
atom:title that is backwards-compatible, just *better*. It gets really 
popular, and yet another version of Atom is born.

4) At the same time, a group of rogue Open Source Software programmers 
descends upon this idyllic scene and introduces its own extensions. Up 
until now, all of our extensions have been approved and incorporated by 
the WG, but these are destined to remain separate.

5) Finally, in 2010, we realise that the Atom feed and entry containers 
aren't really doing the job, and we need to change their model. Yet 
Another Version of Atom (YAVA) comes into being.

Any proposal for versioning should address at least these situations, 
show how the various extensions and changes are identified and 
disambiguated, and should explain how software is to handle them. They 
should also consider how combinations of these scenarios are handled.


> I'd like Atom to
> have something formal about what aggregators like RSS
> Bandit should do to be able to distinguish Atom 0.3
> from Atom 1.0 [for example].

That is a problem that we should not attempt to address; pre-draft 
versions of Atom are not for deployment, and anyone who does so in a 
non-experimental manner is taking all of the risk upon themselves. The 
final release of Atom will, at least, be identified by a different 
namespace URI, so that should be sufficient.


--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Mon Jul 12 20:27:07 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05190
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 20:27: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 i6D0FZOG079908;
	Mon, 12 Jul 2004 17: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 i6D0FZ2I079907;
	Mon, 12 Jul 2004 17:15:35 -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 i6D0FZOK079894
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 17:15:35 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040713001536.92460.qmail@web41207.mail.yahoo.com>
Received: from [207.46.238.137] by web41207.mail.yahoo.com via HTTP; Mon, 12 Jul 2004 17:15:36 PDT
Date: Mon, 12 Jul 2004 17:15:36 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Version vs. Namespace
To: Tim Bray <Tim.Bray@Sun.COM>, Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <E9405742-D457-11D8-AE39-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:
> 
> > Big question:
> > How does an Atom implementation that is conformant
> e.g. to version
> > 2.48 decide whether unknown Atom-namespace markup
> is 'from its own or
> > an earlier version but not in the specification'
> or 'from a later
> > version than its own'?
> 
> Because instances have version numbers.  I.e. it
> sees <atom:feed 
> version="2.0">
> as opposed to <atom:feed version="3.0">

So Atom will not be backwards compatible? Every time
Atom is revved and some early adopter blog vendor
decides to support it, my users will have to wait for
me to ship another version of RSS Bandit? 


=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



From owner-atom-syntax@mail.imc.org  Mon Jul 12 20:43: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 UAA06832
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 20:43: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 i6D0VxF2080818;
	Mon, 12 Jul 2004 17:31: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 i6D0Vx6G080817;
	Mon, 12 Jul 2004 17:31:59 -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 i6D0Vw2h080799
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 17:31:58 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 28700 messnum 5118127 invoked from network[83.70.39.115/83-70-39-115.bas2.prp.dublin.eircom.net]); 13 Jul 2004 00:31:58 -0000
Received: from 83-70-39-115.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.39.115)
  by mail13.svc.cra.dublin.eircom.net (qp 28700) with SMTP; 13 Jul 2004 00:31:58 -0000
Message-ID: <40F32D75.2070006@dehora.net>
Date: Tue, 13 Jul 2004 01:31: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: PaceElementOrder: options
References: <20040712211533.90350.qmail@web41511.mail.yahoo.com> <87fz7wykma.fsf@nwalsh.com>
In-Reply-To: <87fz7wykma.fsf@nwalsh.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


Norman Walsh wrote:

> / Randy Charles Morin <randymorin@yahoo.com> was heard to say:
> | I like these question? Why disorder? What is the value of not
> | specifying the order? I know that I have major pluses w/ my tools if
> | we can just specify order. What's the counter argument?
> 
> Usability and flexibility. As a user, I don't want to remember which
> comes first, atom:modified or atom:issued. 

Yet as a user I will have to remember which elements are optional, 
which have children, what attributes apply. Such concerns about the 
order of a handful of elements on the user seem misplaced compared 
to @rel, @type, atom:content or atom:author.


> And as an implementor, I
> wouldn't want to be required to sort the metadata that came out of my
> internal representation into some particular order.

Metadata's a red herring. We're talking about well known elements 
not arbitrary keyed stuff. If we were working with arbitrary keys, 
then I would claim RDF is yer only man, and not XML. [but see the 
last para below]

Perhaps I don't understand the sort burden beyond my own work - 
worst case in code this is an operation over a dictionary's keyset 
to emit a known order, no?


> Defining an order also encourages people to think that order is
> significant; I predict that this will lead to confusion in the area of
> extensions.

Ahh; well I predict it won't, at least until there's some specific 
extensions, usecases, or extensibility models to look at! Even then, 
ordering of extensions elements doesn't seem to be the same issue as 
ordering of core elements.

If the intention is to make this feedinfo thing an associative array 
to aid extensibility, that needs to be spec'd out *. 'Cos that's not 
what we have.

cheers
Bill

* 'atom:dict' maybe



From owner-atom-syntax@mail.imc.org  Mon Jul 12 20:45: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 UAA06892
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 20:45: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 i6D0NrsQ080298;
	Mon, 12 Jul 2004 17:23: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 i6D0NqHw080297;
	Mon, 12 Jul 2004 17:23:52 -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 i6D0NqfA080291
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 17:23:52 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6D0Nvil009995
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 18:23:57 -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 <0I0R00JMVL3XWH@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Mon, 12 Jul 2004 18:23:57 -0600 (MDT)
Received: from [192.168.1.9] ([154.20.133.9])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0R00CPKL3UE4@mail.sun.net> for atom-syntax@imc.org; Mon,
 12 Jul 2004 18:23:54 -0600 (MDT)
Date: Mon, 12 Jul 2004 17:23:57 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Version vs. Namespace
In-reply-to: <20040713001536.92460.qmail@web41207.mail.yahoo.com>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <EDE17545-D462-11D8-AE39-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: <20040713001536.92460.qmail@web41207.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 Jul 12, 2004, at 5:15 PM, Dare Obasanjo wrote:

>> Because instances have version numbers.  I.e. it
>> sees <atom:feed
>> version="2.0">
>> as opposed to <atom:feed version="3.0">
>
> So Atom will not be backwards compatible? Every time
> Atom is revved and some early adopter blog vendor
> decides to support it, my users will have to wait for
> me to ship another version of RSS Bandit?

Huh?  I thought I'd covered that in 
http://imc.org/atom-syntax/mail-archive/msg06762.html -  I proposed a 
default rule of MustIgnore if you see an element you don't recognize in 
a feed whose version is higher than the version the software knows.  
Shouldn't that cover it?  I mean, an <atom:title> is still an 
<atom:title> five years from now unless we foolishly change the 
namespace, the assumption should be exactly that you can process the 
markup you know from future versions unless it's explicitly marked 
MustUnderstand.  -Tim



From owner-atom-syntax@mail.imc.org  Mon Jul 12 20:46: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 UAA07027
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 20:46: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 i6D0aSMh081175;
	Mon, 12 Jul 2004 17:36: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 i6D0aSaQ081174;
	Mon, 12 Jul 2004 17:36: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 i6D0aRcE081167
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 17:36:28 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 28704 messnum 2597812 invoked from network[83.70.39.115/83-70-39-115.bas2.prp.dublin.eircom.net]); 13 Jul 2004 00:36:27 -0000
Received: from 83-70-39-115.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.39.115)
  by mail08.svc.cra.dublin.eircom.net (qp 28704) with SMTP; 13 Jul 2004 00:36:27 -0000
Message-ID: <40F32E81.4050508@dehora.net>
Date: Tue, 13 Jul 2004 01:36:17 +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: Atomlist <atom-syntax@imc.org>
Subject: Re: PaceElementOrder: options
References: <20040712211533.90350.qmail@web41511.mail.yahoo.com> <A5343281AE2BD2A2B110E8AF@diva.verity.com>
In-Reply-To: <A5343281AE2BD2A2B110E8AF@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: <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:
> Increased interoperability and minimal specification. The internet
> robustness principle, specifically the "be generous in what you accept"
> part, and avoid specifying things that don't really change the content
> of the message.

However this 'content' is inscribed in XML syntax, and normal use of 
said XML is to declare an element order.


> Mail headers and HTTP headers do not have a required order. They
> work fine.

Not the same thing. Those are defined pretty much to be extensible 
dictionaries. We don't appear to have such a definition, but people 
are talking as though we have - this is my point.


> If we say that clients MUST NOT accept feeds with out of order
> elements, then this will (probably) be caught. 

I don't see asking people to emit a list of XML elements in a given 
order to be a burden; in the scheme of things it's trivial compared 
to asking them to get the encoding straight.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Mon Jul 12 20: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 UAA07145
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 20:49:45 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D0fGiM081544;
	Mon, 12 Jul 2004 17:41: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 i6D0fGOj081543;
	Mon, 12 Jul 2004 17:41:16 -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 i6D0fFil081534
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 17:41:16 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Received: from mail.online.no (ti132110a080-3373.bb.online.no [80.212.221.45])
	by mail43.fg.online.no (8.12.11/8.12.11) with ESMTP id i6D0fDlF006299;
	Tue, 13 Jul 2004 02:41:13 +0200 (CEST)
Date: Tue, 13 Jul 2004 02:41:10 +0200
To: "Walter Underwood" <wunder@verity.com>, Atom-syntax <atom-syntax@imc.org>
Subject: Re: a methodical approach to defining what date  elements we need
References: <14B72756-D419-11D8-9D0B-003065EA6144@geckotribe.com> <40F2C2CD.9020307@intertwingly.net> <47071860-D42A-11D8-82B1-000A95DC3D90@mac.com> <opsa1nlh1u6dxgxk@mail.online.no> <6C2098C54ED33AE163D3E2F5@adsl-64-166-133-244.dsl.snfc21.pacbell.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: <opsa1v6wp46dxgxk@mail.online.no>
In-Reply-To: <6C2098C54ED33AE163D3E2F5@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
User-Agent: Opera M2/7.60 (Win32, build 7096)
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 Mon, 12 Jul 2004 16:17:55 -0700, Walter Underwood <wunder@verity.com>  
wrote:

> It is in the author's control if we allow the author to provide
> a display date. When an author is posting at 3am local time, or
> during Ramadan, the author's view of the date matters, and should
> normally be preferred.

No. A reader might reformat this date anyway she/he/it pleases, no matter  
what the author's preferenced display format is. That however does not  
mean that we should prevent the author from providing a default date  
preference, based on location, religion and culture. That information is  
however, in my view, best kept out of the date element;

<entry>
   ...
   <author>
     <name>James T. Kirk</name>
     <timezone>-00:00</timezone>
     <calendar type="x-stardates" />
   </author>
   <title>Personal Log Entry</title>
   <created>2287-12-25T13:33:37Z</created>
   <modified>2287-12-25T15:42:22Z</modified>
   <issued>2287-12-25T16:00:00Z</issued>
   ...
</entry>

-- 
Arve Bersvendsen

http://www.virtuelvis.com
http://www.bersvendsen.com



From owner-atom-syntax@mail.imc.org  Mon Jul 12 20:51: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 UAA07226
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 20:51: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 i6D0iXfM081858;
	Mon, 12 Jul 2004 17:44: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 i6D0iXx1081857;
	Mon, 12 Jul 2004 17:44:33 -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 i6D0iWOE081839
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 17:44:32 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Received: from mail.online.no (ti132110a080-3373.bb.online.no [80.212.221.45])
	by mail43.fg.online.no (8.12.11/8.12.11) with ESMTP id i6D0iOiN009763;
	Tue, 13 Jul 2004 02:44:25 +0200 (CEST)
Date: Tue, 13 Jul 2004 02:44:22 +0200
To: "Antone Roundy" <antone@geckotribe.com>, Atom-syntax <atom-syntax@imc.org>
Subject: Re: a methodical approach to defining what date  elements we need
References: <63E12F93-D452-11D8-9D0B-003065EA6144@geckotribe.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: <opsa1wb8jm6dxgxk@mail.online.no>
In-Reply-To: <63E12F93-D452-11D8-9D0B-003065EA6144@geckotribe.com>
User-Agent: Opera M2/7.60 (Win32, build 7096)
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 Mon, 12 Jul 2004 16:25:33 -0600, Antone Roundy <antone@geckotribe.com>  
wrote:

> 1) By "issued date" and "modified date" do you mean objective  
> timestamps, or author-specifiable (subjective) timestamps? (2, 3, 4 or  
> 6, 7, 8)

Objective. Modified would/should normally be generated by the author's CMS.

The user needs to be able to set atom:issued, if any CMS should be able to  
schedule publishing in the future. If the interface between the author and  
the CMS allows for "subjective" dates, that is fine by me. If you want to  
provide, "Noon, tomorrow" or "midnight, monday in two weeks" as "issued",  
that's a deal between you and your CMS. Externally, however, the date  
should be converted to an "objective" date, in the closest sense a  
user-provided can be.  Meaning: Convert it to a RFC3339 date.

Also: Keep in mind that any date can be wrong or falsified,  
machine-generated or not.

> 2) By "issued" do you mean first issued or most recently issued (if the  
> same entry was "issued" more than once)?  (first 4 or 8 or last 4 or 8)

I firmly believe that "issued" should be set in stone. To me, it simply  
doesn't make sense that an entry issued three weeks ago suddenly gets this  
date changed. The entry is three weeks old. Period.

> 3) By "modified", do you mean the last major change which changed or  
> non-trivially augmented the meaning of the entry, or the last  
> modification of any kind, including things like spelling fixes? (2|6 or  
> 3|7)

"Modified" = The last time this entry was touched/saved - no matter how  
small the change.




Note: the rest of this mail is only partly relevant to the date issue,  
feel free to modify subject when answering.

> Yeah, it may be difficult to draw a perfect line between major and minor  
> changes, but a lot of people, myself included, seem to WANT to be able  
> to differentiate, and I for one would prefer the publisher's best effort  
> to do so over not having any hope of differentiating.

I believe differentiating is best exposed externally through a different  
mechanism than messing around with dates. See PaceSuperesede for a  
starting point; <URL:http://www.intertwingly.net/wiki/pie/PaceSupersede>  
[1]

A major change, in my view, is a new entry, that supersedes a previous  
version. I just asked someone with experience from dead-tree publishing:

1. For a straight reprints, the ISBN doesn't change.
2. When a book is revisioned, the ISBN changes.
3. If the publisher changes, the ISBN changes.
4. If the cover changes, the ISBN changes.

I couldn't get an answer as to what happens to dates attached to these  
books.

If we relate Atom to dead-tree-publishing, could we make the following  
assumptions?

(0. The ISBN is (the closest) equivalent we have to entry:id)
1. This is equivalent to republishing in a different feed than the  
original. Nothing changes, including dates
2. This is a re-issue, with a new issued date, a new modification date, a  
new ID. In effect: a "new entry" that supersedes the former revision.
3. Same as for 2.
4. The title changes, which in effect makes this a new entry

___
[1] Supersede is a mechanism that has worked "sufficiently well" [2] for  
Usenet for many years. If there is a better mechanism, I'm open to  
suggestions.
[2] People have abused the mechanisms, hence the quotes.
-- 
Arve Bersvendsen

http://www.virtuelvis.com
http://www.bersvendsen.com



From owner-atom-syntax@mail.imc.org  Mon Jul 12 20:58: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 UAA07529
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 20:58: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 i6D0oW70082271;
	Mon, 12 Jul 2004 17:50:32 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6D0oWh1082270;
	Mon, 12 Jul 2004 17:50:32 -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 i6D0oV5C082263
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 17:50:31 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.19] (unknown [63.96.165.149])
	by mail.mnot.net (Postfix) with ESMTP
	id F32267288; Mon, 12 Jul 2004 17:50:36 -0700 (PDT)
In-Reply-To: <OFB8CC0367.F21D1DAE-ON88256ECF.0070F567-88256ECF.00723B8C@us.ibm.com>
References: <OFB8CC0367.F21D1DAE-ON88256ECF.0070F567-88256ECF.00723B8C@us.ibm.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <A7390D5E-D466-11D8-AFCB-000A95BD86C0@mnot.net>
Cc: Atom Syntax <atom-syntax@imc.org>, Norman Walsh <ndw@nwalsh.com>
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: Version vs. Namespace
Date: Mon, 12 Jul 2004 17:50:36 -0700
To: James M Snell <jasnell@us.ibm.com>
X-Mailer: Apple Mail (2.618)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6D0oV5C082265
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 Jul 12, 2004, at 1:47 PM, James M Snell wrote:
> > On Jul 12, 2004, at 1:07 PM, James M Snell wrote:
>  > > While I'm ok with this, I'd have to argue that the bar should be 
> set
>  > > rather high for the working group to consider such changes after 
> Atom
>  > > 1.0 is out the door.  Even the addition of new optional elements
>  > > within the same namespace could cause problems for various
>  > > implementations.  
>  >
>  > How so?
>
> More of an implementation issue really (as opposed to something that 
> should be codified in the spec), but given an application that is 
> programmed to expect certain known optional elements, the addition of 
> a new unknown optional element that the application does not know how 
> to handle could cause problems.  Look at the parallels in things like 
> DNS as an example, where while the DNS spec supports new resource 
> record types, for years the introduction of new types, regardless of 
> their optional nature, was not supported by many implementations.  I 
> am not saying that the WG should care if applications are written in 
> such a brittle fashion, only that it should be recognized that such 
> issues can occur.  It is possible to mitigate such issues by defining 
> concise behavior/semantics and setting the bar high for changes to the 
> core namespace (or extension namespaces).  For example, if we expect 
> that new elements could be added at any time to the core namespace 
> without much effort, then that should be captured in the spec so that 
> implementors can plan their implementations accordingly.

No. One of the big reasons I'm involved in Atom is to allow new 
extensions to be introduced without this kind of barrier; without that, 
Atom is frankly not very interesting at all.

Much better to make an explicit "must ignore" rule (as DavidO has 
documented) in the spec, so implementations know what the expectations 
upon them are in these situations.

--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org  Mon Jul 12 21:04: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 VAA07809
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 21: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 i6D0sqMK082577;
	Mon, 12 Jul 2004 17:54: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 i6D0sqHs082576;
	Mon, 12 Jul 2004 17:54: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.84])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D0spdg082570
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 17:54:51 -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 i6D0sv97003086;
	Mon, 12 Jul 2004 17:54:57 -0700 (PDT)
Received: from [192.168.1.100] (h00080d858303.ne.client2.attbi.com [24.61.1.243])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id i6D0shLG014600;
	Mon, 12 Jul 2004 17:54:54 -0700 (PDT)
In-Reply-To: <EDE17545-D462-11D8-AE39-000A95A51C9E@sun.com>
References: <20040713001536.92460.qmail@web41207.mail.yahoo.com> <EDE17545-D462-11D8-AE39-000A95A51C9E@sun.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-11--296271197; protocol="application/pkcs7-signature"
Message-Id: <377338FE-D467-11D8-82B1-000A95DC3D90@mac.com>
Cc: Atom Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: Version vs. Namespace
Date: Mon, 12 Jul 2004 20:54:38 -0400
To: Tim Bray <Tim.Bray@Sun.COM>
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-11--296271197
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit


On 12 Jul 2004, at 8:23 pm, Tim Bray wrote:

> Huh?  I thought I'd covered that in 
> http://imc.org/atom-syntax/mail-archive/msg06762.html -  I proposed a 
> default rule of MustIgnore if you see an element you don't recognize 
> in a feed whose version is higher than the version the software knows. 
>  Shouldn't that cover it?  I mean, an <atom:title> is still an 
> <atom:title> five years from now unless we foolishly change the 
> namespace, the assumption should be exactly that you can process the 
> markup you know from future versions unless it's explicitly marked 
> MustUnderstand.

If a version n atom:title has to be 100% compatible with a version m 
atom:title, what's the version attribute for? According to that last 
message, the only difference is enforcement of mustUnderstand in later 
versions - but shouldn't mustUnderstand be enforced in all versions? ie 
If the software doesn't understand any mustUnderstand element, even one 
from a version it is familiar with?

Graham



--Apple-Mail-11--296271197
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
9w0BCQUxDxcNMDQwNzEzMDA1NDM4WjAjBgkqhkiG9w0BCQQxFgQU74UqnWoFTHmj5cBpXaIITsGi
Bf4weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAlL2FlTfM6BwVXjW25dm0b6f8
+C/CtEfXIpOJGn06l1keTfpkEzz51cZysiGaGmyfVSN1m5n7Mkvfb0sY5JqLTbnTs4mCB27lIS/l
z1wEhzzMEABWpztHNugx/zyixn5C3WJTU979FOEFZD/+FqXXO3YfhtfahhV9yiVPiS0W24p5TQ/l
n9Q+SXoef50SzcC0WRX5RjT5qodxME7wLjl545R7Kffw7iJYkwdSMGXG29xh+ryIKRiPJBwwo5vR
oLAXLUHtA83Wo2l7fwSMV2At4P4R6Zhb/kv2rKmk/lESoCTRpairnkhB/E/6sxGCUbscv6R+dEM0
KTvq4746wQRosQAAAAAAAA==

--Apple-Mail-11--296271197--



From owner-atom-syntax@mail.imc.org  Mon Jul 12 21:10:59 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08201
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 21:10:58 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D12wYf083437;
	Mon, 12 Jul 2004 18:02:58 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6D12whZ083436;
	Mon, 12 Jul 2004 18:02:58 -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 i6D12vF5083430
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 18:02:57 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p0611044ebd18e502cd8b@[10.20.30.249]>
In-Reply-To: <AA8D7D00-D461-11D8-AFCB-000A95BD86C0@mnot.net>
References: <20040712214722.79750.qmail@web41212.mail.yahoo.com>
 <AA8D7D00-D461-11D8-AFCB-000A95BD86C0@mnot.net>
Date: Mon, 12 Jul 2004 18:03:25 -0700
To: Atom WG <atom-syntax@imc.org>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: Usage Scenarios for Versioning and Extensibility
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 5:14 PM -0700 7/12/04, Mark Nottingham wrote:
>0) Let's imagine that Atom 1.0 has been released and finalised in 
>all of its glory.
>
>1) And it was good... except for that nasty atom:title element; 
>after wide deployment experience, it's agreed we need a new version 
>of it. So, a new version of Atom is introduced. The new one isn't 
>backwards-compatible with the old one.
>
>2) Then, we decide we want to add a new metadata element, let's call 
>it "fog." So, a new version of Atom is introduced.
>
>3) After a while, someone comes up with a souped-up version of 
>atom:title that is backwards-compatible, just *better*. It gets 
>really popular, and yet another version of Atom is born.
>
>4) At the same time, a group of rogue Open Source Software 
>programmers descends upon this idyllic scene and introduces its own 
>extensions. Up until now, all of our extensions have been approved 
>and incorporated by the WG, but these are destined to remain 
>separate.
>
>5) Finally, in 2010, we realise that the Atom feed and entry 
>containers aren't really doing the job, and we need to change their 
>model. Yet Another Version of Atom (YAVA) comes into being.
>
>Any proposal for versioning should address at least these 
>situations, show how the various extensions and changes are 
>identified and disambiguated, and should explain how software is to 
>handle them. They should also consider how combinations of these 
>scenarios are handled.

+1 or more. This is an excellent mix and not at all far-fetched. It 
should help us focus on what we need for versioning and extensibility.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Mon Jul 12 21:26: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 VAA09269
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 21:26:20 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D1AarP084186;
	Mon, 12 Jul 2004 18:10: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 i6D1AaiU084185;
	Mon, 12 Jul 2004 18:10:36 -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 i6D1Aaec084179
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 18:10:36 -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 i6D1ATGQ016763;
	Mon, 12 Jul 2004 18:10:29 -0700 (PDT)
Received: from [192.168.1.100] (h00080d858303.ne.client2.attbi.com [24.61.1.243])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id i6D1AJZt013199;
	Mon, 12 Jul 2004 18:10:23 -0700 (PDT)
In-Reply-To: <opsa1wb8jm6dxgxk@mail.online.no>
References: <63E12F93-D452-11D8-9D0B-003065EA6144@geckotribe.com> <opsa1wb8jm6dxgxk@mail.online.no>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-12--295333998; protocol="application/pkcs7-signature"
Message-Id: <66107F6A-D469-11D8-82B1-000A95DC3D90@mac.com>
Cc: Atom-syntax <atom-syntax@imc.org>, Antone Roundy <antone@geckotribe.com>
From: Graham <dtcd@mac.com>
Subject: Re: a methodical approach to defining what date  elements we need
Date: Mon, 12 Jul 2004 21:10:15 -0400
To: Arve Bersvendsen <arve@virtuelvis.com>
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-12--295333998
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 12 Jul 2004, at 8:44 pm, Arve Bersvendsen wrote:

> Also: Keep in mind that any date can be wrong or falsified, 
> machine-generated or not.

Yes.

> I firmly believe that "issued" should be set in stone. To me, it 
> simply doesn't make sense that an entry issued three weeks ago 
> suddenly gets this date changed. The entry is three weeks old. Period.

This is a single entry that has been modified over time:

  http://www.tbray.org/ongoing/When/200x/2004/02/20/GenxStatus

What is its issued date? (NB Suggesting it be broken into multiple 
entries is not an option)

> 1. This is equivalent to republishing in a different feed than the 
> original. Nothing changes, including dates
> 2. This is a re-issue, with a new issued date, a new modification 
> date, a new ID. In effect: a "new entry" that supersedes the former 
> revision.

The ID should never change, otherwise the element is useless (we might 
as well just generate a hash of the content) and we should forget it 
entirely, and Atom for that matter.

Graham
--Apple-Mail-12--295333998
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
9w0BCQUxDxcNMDQwNzEzMDExMDE1WjAjBgkqhkiG9w0BCQQxFgQUP52mDkrYHEWjdTsZNHmORk11
7fYweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEARnQSsti57CeXdW11++dqJXRh
XAUYeRAsH1Eq8RwSKBMVk1tSZHdcR5JFOiKLhddOqSDqhr+AWSfqIfCHRCdamggCZdmP/nlxxhe/
kiy3xREiFuiV6MoNlSA84D6OPJFQ5BzhoQ9q1udoQrRj9wiLG2Y57CSSBEKD6WXyPAyflG8fWxuu
4nznsVd6kneqcJ1dGvc7Uq0NaZJo0wlxjQRo/G4ABESn0LQOyc3/5kBVLWYV/EwDung9FZPS3p5q
Jx38dq29r1c4nWYOoKMYMzltUMNUItTeJ+jQ1iUE/G2e36hZPIwcF/+ELl8lG6dlRRw0I5XLzzMy
eWqhJDg4KTblewAAAAAAAA==

--Apple-Mail-12--295333998--



From owner-atom-syntax@mail.imc.org  Mon Jul 12 21:30: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 VAA09793
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 21:30: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 i6D1FO3N084657;
	Mon, 12 Jul 2004 18:15:24 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6D1FOhx084656;
	Mon, 12 Jul 2004 18:15:24 -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 i6D1FOJd084648
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 18:15:24 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040713011524.45752.qmail@web41210.mail.yahoo.com>
Received: from [131.107.3.74] by web41210.mail.yahoo.com via HTTP; Mon, 12 Jul 2004 18:15:24 PDT
Date: Mon, 12 Jul 2004 18:15:24 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Version vs. Namespace
To: Tim Bray <Tim.Bray@Sun.COM>, Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <EDE17545-D462-11D8-AE39-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:
> 
> > So Atom will not be backwards compatible? Every
> time
> > Atom is revved and some early adopter blog vendor
> > decides to support it, my users will have to wait
> for
> > me to ship another version of RSS Bandit?
> 
> Huh?  I thought I'd covered that in 
>
http://imc.org/atom-syntax/mail-archive/msg06762.html

Oops I missed that message. There's a lot of traffic
on the list. :) 

Those rules seem fine with me except they don't
account for backwards incompatible changes. This is a
key part of any versioning story. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
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 Jul 12 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 VAA10347
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 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 i6D1LH5Y085099;
	Mon, 12 Jul 2004 18:21: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 i6D1LHML085098;
	Mon, 12 Jul 2004 18:21: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] (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 i6D1LFH4085090
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 18:21:16 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p0611044fbd18e903bdd9@[10.20.30.249]>
In-Reply-To: <3f1451f504070810296ca252e7@mail.gmail.com>
References: <40E16215.6070507@intertwingly.net>
 <40EC9915.4050406@intertwingly.net>
 <3f1451f504070718267c5526b4@mail.gmail.com>
 <40ED6392.2000107@franklinmint.fm>
 <3f1451f504070810104a5122e7@mail.gmail.com>
 <3f1451f504070810296ca252e7@mail.gmail.com>
Date: Mon, 12 Jul 2004 18:21:45 -0700
To: Atom WG <atom-syntax@imc.org>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: PaceSecurityServices
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>


OK, I'm seeing a trend here and want to check. It sounds like people 
agree that we want Digest Auth as a SHOULD (not a MUST), not to give 
a SHOULD for the WSSE-like mechanism, and not to describe it in the 
core protocol document. Does that sound right?

If so, I'll update the Pace and add text that implementers should 
also assume that there will be other authentication mechanisms 
needed, some text about why Digest Auth isn't universal, and 
suggestions for folks who will create new auth mechanisms.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Mon Jul 12 21:34: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 VAA10435
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 21: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 i6D1P5Tg085354;
	Mon, 12 Jul 2004 18: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 i6D1P5r6085353;
	Mon, 12 Jul 2004 18:25:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web41510.mail.yahoo.com (web41510.mail.yahoo.com [66.218.93.93])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6D1P43X085342
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 18:25:04 -0700 (PDT)
	(envelope-from randymorin@yahoo.com)
Message-ID: <20040713012505.21328.qmail@web41510.mail.yahoo.com>
Received: from [24.43.182.164] by web41510.mail.yahoo.com via HTTP; Mon, 12 Jul 2004 18:25:05 PDT
Date: Mon, 12 Jul 2004 18:25:05 -0700 (PDT)
From: Randy Charles Morin <randymorin@yahoo.com>
Reply-To: randy@kbcafe.com
Subject: Re: RELAX NG Grammar for draft-...-00.txt
To: Atomlist <atom-syntax@imc.org>, ndw@nwalsh.com
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-836385230-1089681905=:21034"
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>


--0-836385230-1089681905=:21034
Content-Type: text/plain; charset=us-ascii

Norman Walsh wrote: 
| atomDateConstruct =
|    atomCommonAttributes,
|    (xsd:date | xsd:dateTime | xsd:gYearMonth | xsd:gYear)
>Urk. This is a cut-and-paste bug. I think we mean xsd:dateTime *only* here.
 
I think all four date formats are acceptable. As per section 3.3 Date Construct of the format spec [1]. 

3.3  Date Constructs

   A Date construct is an element whose child content is a W3C Date-Time
   string [W3C.NOTE-datetime-19980827].

That spec [2] indicates all four date formats are acceptable.
Thanks and please clarify if I missed something,
 
Randy
http://www.kbcafe.com
 
[1] - http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-00.txt
[2] - http://www.w3.org/TR/1998/NOTE-datetime-19980827
 

		
---------------------------------
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
--0-836385230-1089681905=:21034
Content-Type: text/html; charset=us-ascii

<DIV>Norman Walsh wrote: </DIV>
<DIV>| atomDateConstruct =<BR>|&nbsp;&nbsp;&nbsp; atomCommonAttributes,<BR>|&nbsp;&nbsp;&nbsp; (xsd:date | xsd:dateTime | xsd:gYearMonth | xsd:gYear)<BR>&gt;Urk. This is a cut-and-paste bug. I think we mean xsd:dateTime *only* here.</DIV>
<DIV>&nbsp;</DIV>
<DIV>I think all four date formats are acceptable. As per section 3.3 Date Construct of the format spec [1]. </DIV>
<DIV><BR>3.3&nbsp; Date Constructs<BR><BR>&nbsp;&nbsp; A Date construct is an element whose child content is a W3C Date-Time<BR>&nbsp;&nbsp; string [W3C.NOTE-datetime-19980827].<BR></DIV>
<DIV>That spec [2] indicates all four date formats are acceptable.</DIV>
<DIV>Thanks and please clarify if I missed something,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Randy</DIV>
<DIV><A href="http://www.kbcafe.com">http://www.kbcafe.com</A></DIV>
<DIV>&nbsp;</DIV>
<DIV>[1] - <A href="http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-00.txt">http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-00.txt</A></DIV>
<DIV>[2] - <A href="http://www.w3.org/TR/1998/NOTE-datetime-19980827">http://www.w3.org/TR/1998/NOTE-datetime-19980827</A></DIV>
<DIV>&nbsp;</DIV><p>
		<hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/mail_us/taglines/virus/*http://promotions.yahoo.com/new_mail/static/protection.html">Yahoo! Mail</a> - Helps protect you from nasty viruses.
--0-836385230-1089681905=:21034--



From owner-atom-syntax@mail.imc.org  Mon Jul 12 21:47: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 VAA12015
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 21:47: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 i6D1eWJF086645;
	Mon, 12 Jul 2004 18:40: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 i6D1eWsS086644;
	Mon, 12 Jul 2004 18:40: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 (mproxy.gmail.com [216.239.56.241])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6D1eW1m086626
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 18:40:32 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so10920346cwc
        for <atom-syntax@imc.org>; Mon, 12 Jul 2004 18:40:35 -0700 (PDT)
Received: by 10.11.118.39 with SMTP id q39mr129830cwc;
        Mon, 12 Jul 2004 18:40:35 -0700 (PDT)
Message-ID: <3f1451f50407121840185cce4d@mail.gmail.com>
Date: Mon, 12 Jul 2004 21:40:35 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: PaceSecurityServices
Cc: Atom WG <atom-syntax@imc.org>
In-Reply-To: <p0611044fbd18e903bdd9@10.20.30.249>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <40E16215.6070507@intertwingly.net>
 <40EC9915.4050406@intertwingly.net>
 <3f1451f504070718267c5526b4@mail.gmail.com>
 <40ED6392.2000107@franklinmint.fm>
 <3f1451f504070810104a5122e7@mail.gmail.com>
 <3f1451f504070810296ca252e7@mail.gmail.com> <p0611044fbd18e903bdd9@10.20.30.249>
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 Mon, 12 Jul 2004 18:21:45 -0700, Paul Hoffman / IMC <phoffman@imc.org> wrote:
> 
> OK, I'm seeing a trend here and want to check. It sounds like people
> agree that we want Digest Auth as a SHOULD (not a MUST), not to give
> a SHOULD for the WSSE-like mechanism, and not to describe it in the
> core protocol document. Does that sound right?

+1

    -joe



From owner-atom-syntax@mail.imc.org  Mon Jul 12 21:48: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 VAA12090
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 21:48: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 i6D1akeK086358;
	Mon, 12 Jul 2004 18:36: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 i6D1akpU086357;
	Mon, 12 Jul 2004 18:36: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 (mproxy.gmail.com [216.239.56.244])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6D1ajDw086338
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 18:36:45 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so10918871cwc
        for <atom-syntax@imc.org>; Mon, 12 Jul 2004 18:36:44 -0700 (PDT)
Received: by 10.11.118.46 with SMTP id q46mr130879cwc;
        Mon, 12 Jul 2004 18:36:43 -0700 (PDT)
Message-ID: <3f1451f504071218365f8ebf05@mail.gmail.com>
Date: Mon, 12 Jul 2004 21:36:43 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Atom Syntax <atom-syntax@imc.org>
Subject: PacePutDelete Withdrawn
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


I initially proposed PacePutDelete[1] 
and now I would like to withdraw it. 

This does *not* mean I support SOAP. I would in the
long run rather have the section on SOAP removed
or broken off into a separate RFC. Regardless of that
I don't believe this Pace offers any advantages over 
what the protocol is today and it has some distinct 
disadvantages.

[1] http://www.imc.org/atom-syntax/mail-archive/msg03048.html

   Thanks,
   -joe



From owner-atom-syntax@mail.imc.org  Mon Jul 12 21:54: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 VAA12342
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 21:54: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 i6D1lDID087072;
	Mon, 12 Jul 2004 18:47: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 i6D1lDxK087071;
	Mon, 12 Jul 2004 18:47:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web41511.mail.yahoo.com (web41511.mail.yahoo.com [66.218.93.94])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6D1lCqN087055
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 18:47:12 -0700 (PDT)
	(envelope-from randymorin@yahoo.com)
Message-ID: <20040713014713.52101.qmail@web41511.mail.yahoo.com>
Received: from [24.43.182.164] by web41511.mail.yahoo.com via HTTP; Mon, 12 Jul 2004 18:47:13 PDT
Date: Mon, 12 Jul 2004 18:47:13 -0700 (PDT)
From: Randy Charles Morin <randymorin@yahoo.com>
Reply-To: randy@kbcafe.com
Subject: Re: PaceElementOrder: options 
To: Atomlist <atom-syntax@imc.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1866542749-1089683233=:51312"
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>


--0-1866542749-1089683233=:51312
Content-Type: text/plain; charset=us-ascii


Bill de hÓra wrote:
>I don't see asking people to emit a list of XML elements in a 
>given order to be a burden; in the scheme of things it's 
>trivial compared to asking them to get the encoding straight.

+2 (one for each post)
The argument that ordering XML elements is difficult doesn't seem valid.
Thanks,

Randy
http://www.kbcafe.com
 

		
---------------------------------
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
--0-1866542749-1089683233=:51312
Content-Type: text/html; charset=us-ascii

<P>Bill de hÓra wrote:<BR><FONT face="Courier New">&gt;I don't see asking people to emit a list of XML elements in a <BR>&gt;</FONT><FONT face="Courier New">given order to be a burden; in the scheme of things it's <BR>&gt;trivial compared to asking them to get the encoding straight.</FONT></P>
<P>+2 (one for each post)<BR>The argument that ordering XML elements is difficult doesn't seem valid.<BR>Thanks,</P>
<P>Randy<BR><A href="http://www.kbcafe.com">http://www.kbcafe.com</A></P>
<DIV>&nbsp;</DIV><p>
		<hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/mail_us/taglines/10/*http://promotions.yahoo.com/new_mail/static/efficiency.html">New and Improved Yahoo! Mail</a> - Send 10MB messages!
--0-1866542749-1089683233=:51312--



From owner-atom-syntax@mail.imc.org  Mon Jul 12 22:08: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 WAA14712
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 22:08: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 i6D1xBvP088017;
	Mon, 12 Jul 2004 18:59:11 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6D1xBhP088016;
	Mon, 12 Jul 2004 18:59: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.45])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D1x8rd088009
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 18:59:10 -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 i6D1xEAv001222;
	Mon, 12 Jul 2004 18:59:15 -0700 (PDT)
Received: from [192.168.1.100] (h00080d858303.ne.client2.attbi.com [24.61.1.243])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id i6D1x3Zt025773;
	Mon, 12 Jul 2004 18:59:14 -0700 (PDT)
In-Reply-To: <20040713014713.52101.qmail@web41511.mail.yahoo.com>
References: <20040713014713.52101.qmail@web41511.mail.yahoo.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-13--292408535; protocol="application/pkcs7-signature"
Message-Id: <35C6B124-D470-11D8-82B1-000A95DC3D90@mac.com>
Cc: Atomlist <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: PaceElementOrder: options
Date: Mon, 12 Jul 2004 21:59:00 -0400
To: randy@kbcafe.com
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-13--292408535
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 12 Jul 2004, at 9:47 pm, Randy Charles Morin wrote:

> The argument that ordering XML elements is difficult doesn't seem 
> valid.

The argument that element order is enforceable doesn't seem realistic 
(though it might encourage people who wouldn't otherwise to use the 
validator and/or look at the spec more closely, which I suppose might 
sway me)

Graham
--Apple-Mail-13--292408535
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
9w0BCQUxDxcNMDQwNzEzMDE1OTAxWjAjBgkqhkiG9w0BCQQxFgQUfj6z1LknvTcxY+FhO5kUHBGe
hwYweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAogeD+7e12dDTk1QZgALzvQm2
vw1pJ81jnrElV/wWHTKtzk87lP1LYx91WY4RyVFZF0Liztfj+dDw0GALee2rff32U57r95hvsc6a
uA4kW9IAqqObrFN2B2jzf0t+D+yFe6zSLkl7ViuW45acKPfDnBp6YaTB9CboDFKWxpG/N4EiRarv
RraOkG/uDixe65zcrNGmIjXzCxIC5XyBKVA9TEnxvBnGQSjhUnUwMLeUHlO9t7U3J9RlyPF63yHe
dkpBwROXKRAopc9S03SmHQVj+CEDMkgAIDsRuW72Ww3Ot2Jrur+EMEJu5OcvMf1qRgkEcWjqzezb
i2EjzPkCWvWXugAAAAAAAA==

--Apple-Mail-13--292408535--



From owner-atom-syntax@mail.imc.org  Mon Jul 12 22:09: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 WAA14752
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 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 i6D1rHDA087581;
	Mon, 12 Jul 2004 18:53: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 i6D1rHYB087580;
	Mon, 12 Jul 2004 18:53:17 -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 i6D1rGkC087564
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 18:53:16 -0700 (PDT)
	(envelope-from distobj@acm.org)
Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian))
	id 1BkCU4-000398-00; Mon, 12 Jul 2004 21:53:28 -0400
Date: Mon, 12 Jul 2004 21:53:23 -0400
To: Andreas Sewe <sewe@rbg.informatik.tu-darmstadt.de>
Cc: "[Atom]" <atom-syntax@imc.org>
Subject: Re: Version vs. Namespace
Message-ID: <20040713015323.GS30868@markbaker.ca>
References: <OFC66635FE.A2AF5F93-ON88256ECF.0060057C-88256ECF.0060668D@us.ibm.com> <C3C62D26-D42E-11D8-AFCB-000A95BD86C0@mnot.net> <001001c4684e$65d03c20$753ce03e@baron>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <001001c4684e$65d03c20$753ce03e@baron>
User-Agent: Mutt/1.3.28i
From: Mark Baker <distobj@acm.org>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


On Mon, Jul 12, 2004 at 10:25:21PM +0200, Andreas Sewe wrote:
> FYI, the "application/xhtml+xml" media type registers an optional profile too
> [1] such that e.g. content negotiation can rely on the profile as well. And at

FWIW, that was just a hack to handle the explicit case mentioned in
there (negotiation for XHTML Basic), and because at the time of the
registration, there were competing wireless negotiation specs, neither
of which had reached critical mass and could therefore not be counted
on to handle this form of negotiation.

Profiling HTML was generally acknowledged to be a waste of time in most
cases.  Consider that text/html used to have two different parameters
for this purpose ("level" and "version") and both were dropped because
nobody used them; developers simply preferred to make use of the
(mustIgnore-laden) extensibility model associated with the media type,
and that worked just fine.  I fully expect that to be the case for Atom.

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

  Seeking work on large scale application/data integration projects
  and/or the enabling infrastructure for same.



From owner-atom-syntax@mail.imc.org  Mon Jul 12 22:10: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 WAA14907
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 22:10: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 i6D21RP7088232;
	Mon, 12 Jul 2004 19:01:27 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6D21RKd088231;
	Mon, 12 Jul 2004 19:01: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 i6D21Qq5088218;
	Mon, 12 Jul 2004 19:01:27 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i6D1xQ53029923;
	Mon, 12 Jul 2004 19:59:26 -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 <0I0R006XDPMKMU@edgemail1.Central.Sun.COM>; Mon,
 12 Jul 2004 20:01:33 -0600 (MDT)
Received: from [192.168.1.100] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0R00FNYPMK46@mail.sun.net>; Mon,
 12 Jul 2004 20:01:32 -0600 (MDT)
Date: Mon, 12 Jul 2004 19:01:35 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceSecurityServices
In-reply-to: <p0611044fbd18e903bdd9@[10.20.30.249]>
To: Paul Hoffman / IMC <phoffman@imc.org>
Cc: Atom WG <atom-syntax@imc.org>
Message-id: <91B4B188-D470-11D8-AE39-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: <40E16215.6070507@intertwingly.net>
 <40EC9915.4050406@intertwingly.net>
 <3f1451f504070718267c5526b4@mail.gmail.com> <40ED6392.2000107@franklinmint.fm>
 <3f1451f504070810104a5122e7@mail.gmail.com>
 <3f1451f504070810296ca252e7@mail.gmail.com>
 <p0611044fbd18e903bdd9@[10.20.30.249]>
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 Jul 12, 2004, at 6:21 PM, Paul Hoffman / IMC wrote:

> OK, I'm seeing a trend here and want to check. It sounds like people 
> agree that we want Digest Auth as a SHOULD (not a MUST), not to give a 
> SHOULD for the WSSE-like mechanism, and not to describe it in the core 
> protocol document. Does that sound right?

I'm a little surprised not to see more people standing up for WSSE, but 
I don't see them.  So +1 I guess. -Tim



From owner-atom-syntax@mail.imc.org  Mon Jul 12 22:22: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 WAA15803
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 22: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 i6D23per088378;
	Mon, 12 Jul 2004 19:03: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 i6D23pQG088377;
	Mon, 12 Jul 2004 19:03: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 i6D23pOm088371
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 19:03:51 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6D23vil015764
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 20:03:57 -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 <0I0R0040QPQKXK@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Mon, 12 Jul 2004 20:03:57 -0600 (MDT)
Received: from [192.168.1.100] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0R00C69PQKE4@mail.sun.net> for atom-syntax@imc.org; Mon,
 12 Jul 2004 20:03:56 -0600 (MDT)
Date: Mon, 12 Jul 2004 19:03:57 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Version vs. Namespace
In-reply-to: <20040713011524.45752.qmail@web41210.mail.yahoo.com>
To: Dare Obasanjo <kpako@yahoo.com>
Cc: Atom Syntax <atom-syntax@imc.org>
Message-id: <E68F6C54-D470-11D8-AE39-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: <20040713011524.45752.qmail@web41210.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 Jul 12, 2004, at 6:15 PM, Dare Obasanjo wrote:

> Those rules seem fine with me except they don't
> account for backwards incompatible changes. This is a
> key part of any versioning story.

For incompatible changes, I really only see two options:

1. Provide a way to signal MustUnderstand so that back-rev software can 
fail gracefully.
2. Use a different namespace.

Are there any other options? -Tim



From owner-atom-syntax@mail.imc.org  Mon Jul 12 22:30: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 WAA16340
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 22:30: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 i6D2BbIt089207;
	Mon, 12 Jul 2004 19: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 i6D2Bb4Z089206;
	Mon, 12 Jul 2004 19:11: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] (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 i6D2BYJd089198;
	Mon, 12 Jul 2004 19:11:35 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p06110453bd18f534995d@[10.20.30.249]>
In-Reply-To: <91B4B188-D470-11D8-AE39-000A95A51C9E@sun.com>
References: <40E16215.6070507@intertwingly.net>
 <40EC9915.4050406@intertwingly.net>
 <3f1451f504070718267c5526b4@mail.gmail.com>
 <40ED6392.2000107@franklinmint.fm>
 <3f1451f504070810104a5122e7@mail.gmail.com>
 <3f1451f504070810296ca252e7@mail.gmail.com>
 <p0611044fbd18e903bdd9@[10.20.30.249]>
 <91B4B188-D470-11D8-AE39-000A95A51C9E@sun.com>
Date: Mon, 12 Jul 2004 19:12:04 -0700
To: Tim Bray <Tim.Bray@Sun.COM>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: PaceSecurityServices
Cc: Atom WG <atom-syntax@imc.org>
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:01 PM -0700 7/12/04, Tim Bray wrote:
>I'm a little surprised not to see more people standing up for WSSE, 
>but I don't see them.  So +1 I guess. -Tim

If someone wants WSSE-like, they can easily write a short Internet 
Draft on it. If they do so before we're done with the protocol 
document, we might even refer to it as a MAY, and as a suggestion for 
a good way of doing auth for Atom.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Mon Jul 12 22:31: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 WAA16401
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 22:31: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 i6D2Hs1A089682;
	Mon, 12 Jul 2004 19:17: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 i6D2HsUu089681;
	Mon, 12 Jul 2004 19:17: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 i6D2Hrw5089667;
	Mon, 12 Jul 2004 19:17: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 esmtp (Exim 4.34)
	id 1BkCrn-0003sQ-JE; Tue, 13 Jul 2004 02:17:59 +0000
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Mon, 12 Jul 2004 22:18:05 -0400
Subject: Re: PaceSecurityServices
From: Robert Sayre <mint@franklinmint.fm>
To: Paul Hoffman / IMC <phoffman@imc.org>, Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD18BE9D.1386E%mint@franklinmint.fm>
In-Reply-To: <p0611044fbd18e903bdd9@[10.20.30.249]>
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: <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 7/12/04 9:21 PM, "Paul Hoffman / IMC" <phoffman@imc.org> wrote:

> 
> OK, I'm seeing a trend here and want to check. It sounds like people
> agree that we want Digest Auth as a SHOULD (not a MUST), not to give
> a SHOULD for the WSSE-like mechanism, and not to describe it in the
> core protocol document. Does that sound right?
> 

-1. You are correct that no one is enthusiastic about WSSE. However, many
have spoken in favor of a Digest workalike with different header names, so
Apache doesn't eat them. I think the spec should reference or define one
such mechanism.

Robert Sayre



From owner-atom-syntax@mail.imc.org  Mon Jul 12 22:31: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 WAA16419
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 22:31: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 i6D2CrDf089280;
	Mon, 12 Jul 2004 19:12: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 i6D2Cr8m089279;
	Mon, 12 Jul 2004 19:12: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 i6D2CphM089266
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 19:12:51 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040713021252.71955.qmail@web41211.mail.yahoo.com>
Received: from [131.107.3.85] by web41211.mail.yahoo.com via HTTP; Mon, 12 Jul 2004 19:12:52 PDT
Date: Mon, 12 Jul 2004 19:12:52 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Version vs. Namespace
To: Tim Bray <Tim.Bray@Sun.COM>
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <E68F6C54-D470-11D8-AE39-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:
>
> For incompatible changes, I really only see two
> options:
> 
> 1. Provide a way to signal MustUnderstand so that
> back-rev software can 
> fail gracefully.
> 2. Use a different namespace.
> 
> Are there any other options? -Tim

None that I know of. The MustUnderstand mechanism can
vary (e.g. semantics of major version number in
version attribute, mustunderstand attribute, etc) but
that's about it. 


=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
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 Jul 12 22:40: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 WAA17079
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 22:40: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 i6D2VIdJ090429;
	Mon, 12 Jul 2004 19: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 i6D2VImx090428;
	Mon, 12 Jul 2004 19:31: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 i6D2VIkb090422
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 19:31:18 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.19] (unknown [63.96.165.149])
	by mail.mnot.net (Postfix) with ESMTP
	id 3EA08727D; Mon, 12 Jul 2004 19:31:24 -0700 (PDT)
In-Reply-To: <20040713015323.GS30868@markbaker.ca>
References: <OFC66635FE.A2AF5F93-ON88256ECF.0060057C-88256ECF.0060668D@us.ibm.com> <C3C62D26-D42E-11D8-AFCB-000A95BD86C0@mnot.net> <001001c4684e$65d03c20$753ce03e@baron> <20040713015323.GS30868@markbaker.ca>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <BBAD355E-D474-11D8-AFCB-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: Andreas Sewe <sewe@rbg.informatik.tu-darmstadt.de>,
        "[Atom]" <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: Re: Version vs. Namespace
Date: Mon, 12 Jul 2004 19:31:23 -0700
To: Mark Baker <distobj@acm.org>
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>
Content-Transfer-Encoding: 7bit



On Jul 12, 2004, at 6:53 PM, Mark Baker wrote:

> Profiling HTML was generally acknowledged to be a waste of time in most
> cases.  Consider that text/html used to have two different parameters
> for this purpose ("level" and "version") and both were dropped because
> nobody used them; developers simply preferred to make use of the
> (mustIgnore-laden) extensibility model associated with the media type,
> and that worked just fine.  I fully expect that to be the case for 
> Atom.

I don't share your conviction; the use cases for Atom are quite 
different. Atom is not a presentation format, it's a metadata 
container, and something that allows people to group together different 
types of metadata into a single package will engender interoperability 
and functionality.

We already have one profile of Atom -- the blog/newsfeed profile that 
is the direct successor to RSS. That's great, but part of the reason I 
find Atom so exciting is that it can enable other profiles too; for 
example, stock price feeds, weather feeds, CVS changes, etc. ad 
infinitum. Individual extensions aren't enough to enable these uses 
because it ignores the combination of extensions that characterises a 
particular application.

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Mon Jul 12 22: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 WAA17288
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 22:45: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 i6D2UW6P090410;
	Mon, 12 Jul 2004 19:30: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 i6D2UWhK090409;
	Mon, 12 Jul 2004 19:30: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 (mproxy.gmail.com [216.239.56.251])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6D2UWQw090400
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 19:30:32 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so10946072cwc
        for <atom-syntax@imc.org>; Mon, 12 Jul 2004 19:30:33 -0700 (PDT)
Received: by 10.11.116.4 with SMTP id o4mr131607cwc;
        Mon, 12 Jul 2004 19:30:33 -0700 (PDT)
Message-ID: <3f1451f504071219302c2f1f98@mail.gmail.com>
Date: Mon, 12 Jul 2004 22:30:33 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Tim Bray <tim.bray@sun.com>
Subject: Re: Version vs. Namespace
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <52AC8A64-D44D-11D8-AE39-000A95A51C9E@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <32D5845A745BFB429CBDBADA57CD41AF08D6B39E@ussjex01.amer.bea.com> <52AC8A64-D44D-11D8-AE39-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 Mon, 12 Jul 2004 14:49:17 -0700, Tim Bray <tim.bray@sun.com> wrote:
> 
> On Jul 12, 2004, at 2:05 PM, David Orchard wrote:
> 
> > Norm and I have written up material on why coarse grained version #s
> > are bad [1] and even used RSS as an example.  We have implementation
> > experience on using version #s, and it isn't that great.
> 
> I just read that, and I certainly agree with its line of argument, but
> I'm not convinced about the version number.  The example of RSS doesn't
> work, RSS's "version numbers" (0.9*, 1.0, 2.0*) aren't anything like
> version numbers.  I propose the following policy:
> 
> 1. Atom documents have a version number which identifies a version of
> the governing specification, and there is a clear ordering relationship
> among released versions.


While I like this proposal in general, I believe the 
'clear ordering relationship among released versions'
is where this might break down. Consider for example
the XHMTL 1.1 + MathML 2.0 + SVG 1.1 Profile [1].

This isn't XHTML 2.0, nor is it XHTML 1.2, it is
a leaf on what could become a very full tree of
profiles. This doesn't fall into the category of 
monotonically increasing version numbers.

XHTML is also a poor example of monotonically
increasing version numbers since XHTML 2.0 
has no compatibility with XHTML 1.1.

If we have a clear extension mechanism for 
Atom, given the level of activity we are seeing on the list
these days, after the 1.0 release I could 
well imagine several groups
breaking off to pursure 'modules' for Atom, say for
syndicating large multimedia objects, or calendar
data, etc. I believe it would be helpful to have a 
profiling mechanism that allows those modules
to be blended back into an Atom 1.0 feed and
not require a new Atom format spec with a bumped up
version number. It would also be useful
to indicate what version of Atom a module
could be used with.

In short, I believe we need to define
an extension mechanism that allows
new 'modules' to be created, a profiling 
mechanism that indicates which 'modules'
are being combined, and an indication of 
which version of the core Atom syntax is being
used. 

Given the experience of XHTML and RSS
I don't believe a version number would be any 
clearer than a version 'string' or a change in
the namespace URI.


[1] http://www.w3.org/TR/2002/WD-XHTMLplusMathMLplusSVG-20020809/

    Thanks,
    -joe



From owner-atom-syntax@mail.imc.org  Mon Jul 12 22: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 WAA17315
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 22: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 i6D2XbRP090638;
	Mon, 12 Jul 2004 19:33: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 i6D2Xbie090637;
	Mon, 12 Jul 2004 19:33:37 -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 i6D2XaxB090631
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 19:33:36 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.19] (unknown [63.96.165.149])
	by mail.mnot.net (Postfix) with ESMTP
	id BA601727D; Mon, 12 Jul 2004 19:33:42 -0700 (PDT)
In-Reply-To: <E68F6C54-D470-11D8-AE39-000A95A51C9E@sun.com>
References: <20040713011524.45752.qmail@web41210.mail.yahoo.com> <E68F6C54-D470-11D8-AE39-000A95A51C9E@sun.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <0E4C6EEF-D475-11D8-AFCB-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: Dare Obasanjo <kpako@yahoo.com>, Atom Syntax <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: Re: Version vs. Namespace
Date: Mon, 12 Jul 2004 19:33:42 -0700
To: Tim Bray <Tim.Bray@Sun.COM>
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>
Content-Transfer-Encoding: 7bit



On Jul 12, 2004, at 7:03 PM, Tim Bray wrote:

>
> On Jul 12, 2004, at 6:15 PM, Dare Obasanjo wrote:
>
>> Those rules seem fine with me except they don't
>> account for backwards incompatible changes. This is a
>> key part of any versioning story.
>
> For incompatible changes, I really only see two options:
>
> 1. Provide a way to signal MustUnderstand so that back-rev software 
> can fail gracefully.
> 2. Use a different namespace.

Can you spell out option #1 (or give a reference into this sea of bits 
we call the mailing list)? On the face of it, I don't see how a mU bit 
is adequate on its own (it makes a lot of sense in conjunction with a 
different namespace).

Thanks,


--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Mon Jul 12 23:02: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 XAA18568
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 23:02: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 i6D2q8xe092079;
	Mon, 12 Jul 2004 19:52:08 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6D2q8vV092078;
	Mon, 12 Jul 2004 19:52:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D2q2qW092054
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 19:52:06 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 13 Jul 2004 12:56:44 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Tue, 13 Jul 2004 12:45:56 +1000
Subject: Re: Version vs. Namespace
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD198A04.1F32F%eric.scheid@ironclad.net.au>
In-Reply-To: <EDE17545-D462-11D8-AE39-000A95A51C9E@sun.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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 13/7/04 10:23 AM, "Tim Bray" <Tim.Bray@Sun.COM> wrote:

> Huh?  I thought I'd covered that in
> http://imc.org/atom-syntax/mail-archive/msg06762.html -  I proposed a
> default rule of MustIgnore if you see an element you don't recognize in
> a feed whose version is higher than the version the software knows.
> Shouldn't that cover it?  I mean, an <atom:title> is still an
> <atom:title> five years from now unless we foolishly change the
> namespace, the assumption should be exactly that you can process the
> markup you know from future versions unless it's explicitly marked
> MustUnderstand.  -Tim

what happens when there is another rev? how far back does MustUnderstand
apply? more importantly, how far forward will MustUnderstand flags be
carried forward ... will we see a future version where nearly everything is
encrusted because at some various point it needed MustUnderstand? We can't
ever take it off an element, because what happens when a 2.0 code encounters
a 4.0 document (where the 3.0 revved it with MustUnderstand)?

could we not have, effectively, two version numbers -- the version this feed
is in, and the minimum version it is backwardly compatible with? or does
that not provide enough granularity?

e.



From owner-atom-syntax@mail.imc.org  Mon Jul 12 23: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 XAA18769
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 23:05: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 i6D2seN4092350;
	Mon, 12 Jul 2004 19:54: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 i6D2seql092349;
	Mon, 12 Jul 2004 19:54:40 -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 i6D2sdOr092342
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 19:54:39 -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 i6D2sk9L026430;
	Mon, 12 Jul 2004 19:54:46 -0700 (PDT)
Received: from [192.168.1.100] (h00080d858303.ne.client2.attbi.com [24.61.1.243])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin01/MantshX 4.0) with ESMTP id i6D2sR6G028899;
	Mon, 12 Jul 2004 19:54:45 -0700 (PDT)
In-Reply-To: <BBAD355E-D474-11D8-AFCB-000A95BD86C0@mnot.net>
References: <OFC66635FE.A2AF5F93-ON88256ECF.0060057C-88256ECF.0060668D@us.ibm.com> <C3C62D26-D42E-11D8-AFCB-000A95BD86C0@mnot.net> <001001c4684e$65d03c20$753ce03e@baron> <20040713015323.GS30868@markbaker.ca> <BBAD355E-D474-11D8-AFCB-000A95BD86C0@mnot.net>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-14--289083216; protocol="application/pkcs7-signature"
Message-Id: <F3D255F6-D477-11D8-82B1-000A95DC3D90@mac.com>
Cc: "[Atom]" <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: Version vs. Namespace
Date: Mon, 12 Jul 2004 22:54:26 -0400
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-14--289083216
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit


On 12 Jul 2004, at 10:31 pm, Mark Nottingham wrote:

> I don't share your conviction; the use cases for Atom are quite 
> different. Atom is not a presentation format, it's a metadata 
> container, and something that allows people to group together 
> different types of metadata into a single package will engender 
> interoperability and functionality.
>
> We already have one profile of Atom -- the blog/newsfeed profile that 
> is the direct successor to RSS. That's great, but part of the reason I 
> find Atom so exciting is that it can enable other profiles too; for 
> example, stock price feeds, weather feeds, CVS changes, etc. ad 
> infinitum. Individual extensions aren't enough to enable these uses 
> because it ignores the combination of extensions that characterises a 
> particular application.

I'm not liking this profile talk. Are you suggesting a newsreader would 
have to explicitly support the stock price profile or the weather 
profile, to be able to show it? As I've said before, I thing the 
content/summary elements should be presentation-orientated, with 
machine readable versions in extensions. That way you don't need 
profiles.

Graham
--Apple-Mail-14--289083216
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
9w0BCQUxDxcNMDQwNzEzMDI1NDI2WjAjBgkqhkiG9w0BCQQxFgQUaitJXbZXuQ/vgN31+5JnZ73P
RwEweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAmRfkEC2U/EZDJlvt0FJP/igw
jIhc6YfbwLpas6nDeTg0qJp75pIQesAJB/psCphMCCiydTNXRiAQr120gw2IWwnG3xExEg3opQCQ
qRNFCxUvYZkUkIrGcEw3DsIh1DybUC61E8SbpFS7+ISSvEr9EpqYX8alIO3LTKeOFjnkvUCeG9qW
p/aO3Zjfu0dlQV9VV7UUcsIoZ6pz0unIwbuyc8ogLsHGVtsu9WAeWwlp0EyeEqkcB4uW9Qodn0W3
tT4zbRxyNJSh0ChbprdKNZVprQX6CRnyn+0OMEJXjKkC/6O1YgIpSTqfuLTVzIXUZXZwzZyLxivs
zujJYPUXfvEHGgAAAAAAAA==

--Apple-Mail-14--289083216--



From owner-atom-syntax@mail.imc.org  Mon Jul 12 23:08:32 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18923
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 23:08: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 i6D2wrQA092522;
	Mon, 12 Jul 2004 19:58: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 i6D2wrne092521;
	Mon, 12 Jul 2004 19:58: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 i6D2wqbl092514
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 19:58:52 -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 i6D2xZlx006368;
	Mon, 12 Jul 2004 22:59:36 -0400
Message-ID: <40F34FF2.2010608@intertwingly.net>
Date: Mon, 12 Jul 2004 22:58:58 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <dtcd@mac.com>
CC: Atom-syntax <atom-syntax@imc.org>
Subject: Re: a methodical approach to defining what date  elements we need
References: <63E12F93-D452-11D8-9D0B-003065EA6144@geckotribe.com> <opsa1wb8jm6dxgxk@mail.online.no> <66107F6A-D469-11D8-82B1-000A95DC3D90@mac.com>
In-Reply-To: <66107F6A-D469-11D8-82B1-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: <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:

>> I firmly believe that "issued" should be set in stone. To me, it 
>> simply doesn't make sense that an entry issued three weeks ago 
>> suddenly gets this date changed. The entry is three weeks old. Period.
> 
> This is a single entry that has been modified over time:
> 
>  http://www.tbray.org/ongoing/When/200x/2004/02/20/GenxStatus
> 
> What is its issued date? (NB Suggesting it be broken into multiple 
> entries is not an option)

Based on the text and the URL, this page appears to have been originally 
created on 2004-02-17, issued on 2004-02-20, and last modified on 
2004-06-13.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Mon Jul 12 23:08: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 XAA18929
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 23:08: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 i6D2w5dl092500;
	Mon, 12 Jul 2004 19:58: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 i6D2w5Le092499;
	Mon, 12 Jul 2004 19:58:05 -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 i6D2w4FG092493
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 19:58:04 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.19] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id 5D58E727D; Mon, 12 Jul 2004 19:58:11 -0700 (PDT)
In-Reply-To: <20040712221217.55674.qmail@web41508.mail.yahoo.com>
References: <20040712221217.55674.qmail@web41508.mail.yahoo.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <79B7857D-D478-11D8-AFCB-000A95BD86C0@mnot.net>
Cc: Atomlist <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: Re: PaceElementOrder: options 
Date: Mon, 12 Jul 2004 19:58:11 -0700
To: randy@kbcafe.com
X-Mailer: Apple Mail (2.618)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6D2w4FG092494
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 Jul 12, 2004, at 3:12 PM, Randy Charles Morin wrote:

> Example - If you generate C# using XSD.exe [2] from my Atom XSD [3] 
> and the elements are not ordered, then the generated classes do 
> not account for cardinality of the unordered elements. This is because 
> XSD cannot describe cardinality of unordered elements. If the elements 
> are ordered, then the generated class can account for cardinality of 
> elements and can be made to exactly describe the Atom data model. So, 
> by ordering elements, I can create perfectly matched syntax helper 
> classes without writing one line of code (all generated code). I can 
> do this w/ XSD to generate C# and VB and XMLSpy to generate Java, C# 
> and C++ [4].

In other words, there are a minority of XML tools that rely upon a 
quirky, very limited and problematic expression of constraints upon XML 
-- i.e., XML Schema -- and therefore you'd like to constrain the syntax 
of Atom to accommodate its limitations and thereby enable a few 
implementors to save some time doing code generation. If I read you 
right, it still won't be possible to describe the cardinality of 
extensions; only the core metadata will have this feature. Furthermore, 
it sounds like it will still be possible to do code generation; people 
will just have to go back and tweak their implementation to account for 
cardinality.

Keeping this in perspective, those same implementers will be writing 
GUIs, integrating network stacks, presentation engines, etc. and there 
will be many orders of magnitude fewer such implementers than there 
will be Atom authors, who will have to remember the proper ordering of 
these elements and have one more reason why their feeds are broken. 
Even more so, the ordering of metadata has absolutely no semantic 
relevance; it doesn't carry any information at all.

Can you understand why the need to enable this scenario doesn't 
overwhelm me?


--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org  Mon Jul 12 23:10: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 XAA19038
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 23:10: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 i6D302AU092660;
	Mon, 12 Jul 2004 20: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 i6D302ix092659;
	Mon, 12 Jul 2004 20:00: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-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 i6D302vM092653
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 20:00:02 -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 i6D2w153020874
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 20:58: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 <0I0R004SBSC8XK@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Mon, 12 Jul 2004 21:00:08 -0600 (MDT)
Received: from [192.168.1.100] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0R003CCSC5L2@mail.sun.net> for atom-syntax@imc.org; Mon,
 12 Jul 2004 21:00:06 -0600 (MDT)
Date: Mon, 12 Jul 2004 20:00:07 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Version vs. Namespace
In-reply-to: <3f1451f504071219302c2f1f98@mail.gmail.com>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <BF01C6BC-D478-11D8-AE39-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: <32D5845A745BFB429CBDBADA57CD41AF08D6B39E@ussjex01.amer.bea.com>
 <52AC8A64-D44D-11D8-AE39-000A95A51C9E@sun.com>
 <3f1451f504071219302c2f1f98@mail.gmail.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 Jul 12, 2004, at 7:30 PM, Joe Gregorio wrote:

> While I like this proposal in general, I believe the
> 'clear ordering relationship among released versions'
> is where this might break down. Consider for example
> the XHMTL 1.1 + MathML 2.0 + SVG 1.1 Profile [1].
>
> This isn't XHTML 2.0, nor is it XHTML 1.2, it is
> a leaf on what could become a very full tree of
> profiles. This doesn't fall into the category of
> monotonically increasing version numbers.

"Doctor, it hurts when I do this."  "Don't do that."

I think that having a clear, simple versioning policy is worth a lot; 
and nobody would want to emulate the process by which the various 
flavors of HTML were produced.  If we write Atom 1.0 with a clear 
guideline that the versioning policy depends on future versions being 
well-ordered, it will be clear to anyone who produces a later version 
that isn't that they will be breaking Atom versioning.  Whereas nobody 
can prevent future stupidity, it would seem a fairly unlikely scenario.

> If we have a clear extension mechanism for
> Atom, given the level of activity we are seeing on the list
> these days, after the 1.0 release I could
> well imagine several groups
> breaking off to pursure 'modules' for Atom, say for
> syndicating large multimedia objects, or calendar
> data, etc. I believe it would be helpful to have a
> profiling mechanism that allows those modules
> to be blended back into an Atom 1.0 feed and
> not require a new Atom format spec with a bumped up
> version number. It would also be useful
> to indicate what version of Atom a module
> could be used with.

I would argue that they should be done in different namespaces.  The 
goal you set, while worthy, is going to be very difficult to achieve.  
As a veteran of some years in the publishing-technology industries, I 
don't recall ever seeing a versioning/extensibility framework that was 
as general as what you describe and still comprehensible by mere 
mortals.

I think that linear version numbers plus MustIgnore hits a huge 80/20 
point. -Tim



From owner-atom-syntax@mail.imc.org  Mon Jul 12 23: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 XAA19175
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 23:12:01 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D2s7Xj092221;
	Mon, 12 Jul 2004 19:54:07 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6D2s7MF092220;
	Mon, 12 Jul 2004 19:54:07 -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 i6D2s2bm092167;
	Mon, 12 Jul 2004 19:54:03 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p06110455bd18ff07e6da@[10.20.30.249]>
In-Reply-To: <BD18BE9D.1386E%mint@franklinmint.fm>
References: <BD18BE9D.1386E%mint@franklinmint.fm>
Date: Mon, 12 Jul 2004 19:54:31 -0700
To: Robert Sayre <mint@franklinmint.fm>, Atom Syntax <atom-syntax@imc.org>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: PaceSecurityServices
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 10:18 PM -0400 7/12/04, Robert Sayre wrote:
>-1. You are correct that no one is enthusiastic about WSSE. However, many
>have spoken in favor of a Digest workalike with different header names, so
>Apache doesn't eat them. I think the spec should reference or define one
>such mechanism.

I heard folks now wanting the spec to define new ones. Assuming 
someone else creates such a mechanism, I'm fine with the base spec 
referencing it as a MAY. Is that what you were thinking, or did you 
want a SHOULD that is parallel to Digest Auth?

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Mon Jul 12 23: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 XAA19773
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 23: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 i6D365qV092993;
	Mon, 12 Jul 2004 20:06: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 i6D365Vf092992;
	Mon, 12 Jul 2004 20:06:05 -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 i6D3653L092986
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 20:06:05 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.19] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id D3A60727D; Mon, 12 Jul 2004 20:06:10 -0700 (PDT)
In-Reply-To: <F3D255F6-D477-11D8-82B1-000A95DC3D90@mac.com>
References: <OFC66635FE.A2AF5F93-ON88256ECF.0060057C-88256ECF.0060668D@us.ibm.com> <C3C62D26-D42E-11D8-AFCB-000A95BD86C0@mnot.net> <001001c4684e$65d03c20$753ce03e@baron> <20040713015323.GS30868@markbaker.ca> <BBAD355E-D474-11D8-AFCB-000A95BD86C0@mnot.net> <F3D255F6-D477-11D8-82B1-000A95DC3D90@mac.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <9799B5EE-D479-11D8-AFCB-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: "[Atom]" <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: Re: Version vs. Namespace
Date: Mon, 12 Jul 2004 20:06:10 -0700
To: Graham <dtcd@mac.com>
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>
Content-Transfer-Encoding: 7bit


On Jul 12, 2004, at 7:54 PM, Graham wrote:

> Are you suggesting a newsreader would have to explicitly support the 
> stock price profile or the weather profile, to be able to show it?

Not at all; it's just a mechanism to allow people to identify packages 
of metadata to code to and write feeds to.


--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Mon Jul 12 23:29:22 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20141
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 23:29:22 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D3L1rM093984;
	Mon, 12 Jul 2004 20: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 i6D3L1UH093983;
	Mon, 12 Jul 2004 20:21: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.83])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D3L0u2093977
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 20:21:00 -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 i6D3L7kN025391;
	Mon, 12 Jul 2004 20:21:07 -0700 (PDT)
Received: from [192.168.1.100] (h00080d858303.ne.client2.attbi.com [24.61.1.243])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id i6D3L6LG024648;
	Mon, 12 Jul 2004 20:21:06 -0700 (PDT)
In-Reply-To: <40F34FF2.2010608@intertwingly.net>
References: <63E12F93-D452-11D8-9D0B-003065EA6144@geckotribe.com> <opsa1wb8jm6dxgxk@mail.online.no> <66107F6A-D469-11D8-82B1-000A95DC3D90@mac.com> <40F34FF2.2010608@intertwingly.net>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-15--287487764; protocol="application/pkcs7-signature"
Message-Id: <AAC8F79E-D47B-11D8-82B1-000A95DC3D90@mac.com>
Cc: Atom-syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: a methodical approach to defining what date  elements we need
Date: Mon, 12 Jul 2004 23:21:01 -0400
To: Sam Ruby <rubys@intertwingly.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-15--287487764
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 12 Jul 2004, at 10:58 pm, Sam Ruby wrote:

> Graham wrote:
>
>>> I firmly believe that "issued" should be set in stone. To me, it 
>>> simply doesn't make sense that an entry issued three weeks ago 
>>> suddenly gets this date changed. The entry is three weeks old. 
>>> Period.
>> This is a single entry that has been modified over time:
>>  http://www.tbray.org/ongoing/When/200x/2004/02/20/GenxStatus
>> What is its issued date? (NB Suggesting it be broken into multiple 
>> entries is not an option)
>
> Based on the text and the URL, this page appears to have been 
> originally created on 2004-02-17, issued on 2004-02-20, and last 
> modified on 2004-06-13.

But that's useless to me. I can't sort by modified (Tim's is the only 
blog in the universe that is), and if I sort by issued, that post is 
going to be right at the bottom, even though Tim's written the 
equivalent of a new entry.

Try again.

Graham
--Apple-Mail-15--287487764
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
9w0BCQUxDxcNMDQwNzEzMDMyMTAyWjAjBgkqhkiG9w0BCQQxFgQUv4UYRCxNw/sV65uh/k2n2EDX
04IweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAAluss4iD6Q5bKmJvoaTjvzAW
6iInLiHg1A/ZM4r0+VrLtKGrv175YLaCt5BIuIhl3DnJoBLhRk0JgLGjdVlF/sb+wGclpgHpzu9j
KvxU8IFpuCGoJLKpSqWxD1VXWKs9611f3ErOAEZN545RJB3BKj1ha6q+cwUeEWM3qF5ego8Ho1U+
XYL+Ew3faAmCRjg/OnTbVommAPYon0BOshAmDbCBqcgUtgAzOEloKii6j8nz9VRVn6yIOFoTpyUx
tPoaMkSFPYN6V4P+gk6yQLIwLTyGj+jNO4tze7tfIiAKBMGQc/kpWqxFnzEy6lyJOgXxD1DnqeG4
7Hgf0CI3IFT7ngAAAAAAAA==

--Apple-Mail-15--287487764--



From owner-atom-syntax@mail.imc.org  Mon Jul 12 23:29: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 XAA20160
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 23:29:47 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D3MAv0094052;
	Mon, 12 Jul 2004 20:22: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 i6D3MAHs094051;
	Mon, 12 Jul 2004 20:22: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 i6D3M9hq094042
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 20:22:10 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 86253 messnum 15262527 invoked from network[83.70.39.115/83-70-39-115.bas2.prp.dublin.eircom.net]); 13 Jul 2004 03:22:10 -0000
Received: from 83-70-39-115.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.39.115)
  by mail11.svc.cra.dublin.eircom.net (qp 86253) with SMTP; 13 Jul 2004 03:22:10 -0000
Message-ID: <40F35558.2000104@dehora.net>
Date: Tue, 13 Jul 2004 04:22: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: Mark Nottingham <mnot@mnot.net>
CC: Mark Baker <distobj@acm.org>,
        Andreas Sewe <sewe@rbg.informatik.tu-darmstadt.de>,
        "[Atom]" <atom-syntax@imc.org>
Subject: Re: Version vs. Namespace
References: <OFC66635FE.A2AF5F93-ON88256ECF.0060057C-88256ECF.0060668D@us.ibm.com> <C3C62D26-D42E-11D8-AFCB-000A95BD86C0@mnot.net> <001001c4684e$65d03c20$753ce03e@baron> <20040713015323.GS30868@markbaker.ca> <BBAD355E-D474-11D8-AFCB-000A95BD86C0@mnot.net>
In-Reply-To: <BBAD355E-D474-11D8-AFCB-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: <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:

> We already have one profile of Atom -- the blog/newsfeed profile that is 
> the direct successor to RSS. 

I thought that *was* Atom.


> That's great, but part of the reason I find 
> Atom so exciting is that it can enable other profiles too; [snip].

RDF/XML already enables this.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Mon Jul 12 23: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 XAA20572
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 23: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 i6D3WnGl094669;
	Mon, 12 Jul 2004 20:32: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 i6D3Wnvl094668;
	Mon, 12 Jul 2004 20:32: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 i6D3Wm8G094661
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 20:32:48 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.19] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id 81437727D; Mon, 12 Jul 2004 20:32:55 -0700 (PDT)
In-Reply-To: <40F35558.2000104@dehora.net>
References: <OFC66635FE.A2AF5F93-ON88256ECF.0060057C-88256ECF.0060668D@us.ibm.com> <C3C62D26-D42E-11D8-AFCB-000A95BD86C0@mnot.net> <001001c4684e$65d03c20$753ce03e@baron> <20040713015323.GS30868@markbaker.ca> <BBAD355E-D474-11D8-AFCB-000A95BD86C0@mnot.net> <40F35558.2000104@dehora.net>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <4789E38B-D47D-11D8-AFCB-000A95BD86C0@mnot.net>
Cc: Andreas Sewe <sewe@rbg.informatik.tu-darmstadt.de>,
        Mark Baker <distobj@acm.org>, "[Atom]" <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: Re: Version vs. Namespace
Date: Mon, 12 Jul 2004 20:32:34 -0700
To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>
X-Mailer: Apple Mail (2.618)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6D3Wm8G094663
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 Jul 12, 2004, at 8:22 PM, Bill de hÓra wrote:

> RDF/XML already enables this.

RDF/XML is nearly universally abhorred; even the Semantic Web's most 
starry-eyed promoter would have a hard time loving it.

I have no quarrel with the RDF model (actually, I love it to death), 
but please, don't hold up the RDF/XML syntax as something to emulate or 
consider as an alternative. "Worst of both worlds" pops into the mind, 
as does "DOA."

Just my .02, of course.

--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org  Mon Jul 12 23:47: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 XAA20929
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 23:47: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 i6D3bUio094925;
	Mon, 12 Jul 2004 20: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 i6D3bUUA094924;
	Mon, 12 Jul 2004 20:37: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 i6D3bMad094898
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 20:37:24 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 13 Jul 2004 13:42:15 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Tue, 13 Jul 2004 13:36:02 +1000
Subject: Re: a methodical approach to defining what date  elements we need
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD1995C2.1F3C6%eric.scheid@ironclad.net.au>
In-Reply-To: <66107F6A-D469-11D8-82B1-000A95DC3D90@mac.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


On 13/7/04 11:10 AM, "Graham" <dtcd@mac.com> wrote:

> This is a single entry that has been modified over time:
> 
>   http://www.tbray.org/ongoing/When/200x/2004/02/20/GenxStatus
> 
> What is its issued date? (NB Suggesting it be broken into multiple
> entries is not an option)

+1 example

Note too that at the time of it's original publishing (IIRC) it was
explicitly stated that that entry will be updated often, and that that entry
is the canonical place to read all about GenxStatus.

Having permalinks is a good thing.

Can someone explain if PaceSupercedes expects the new-id entry to be
published at the superceded permalink? [1] Alternatively, will it (the
published permalink) be updated with a pointer to the superceding version,
(and that with a pointer when it too is superceded, and then that too again,
and again, and ...)?

e.

[1] effectively overwriting it, while leaving the original atom:entry
not-overwritten, if that makes any sense



From owner-atom-syntax@mail.imc.org  Mon Jul 12 23:53: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 XAA21070
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 23:53: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 i6D3iPlj095397;
	Mon, 12 Jul 2004 20: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 i6D3iPha095396;
	Mon, 12 Jul 2004 20:44:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D3iPvP095390
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 20:44:25 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i6D3gO53005916
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 21:42:24 -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 <0I0R004XBUE7XK@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Mon, 12 Jul 2004 21:44:31 -0600 (MDT)
Received: from [192.168.1.100] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0R00EGUUE61J@mail.sun.net> for atom-syntax@imc.org; Mon,
 12 Jul 2004 21:44:31 -0600 (MDT)
Date: Mon, 12 Jul 2004 20:44:33 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Version vs. Namespace
In-reply-to: <BD198A04.1F32F%eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <F45A2956-D47E-11D8-AE39-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: <BD198A04.1F32F%eric.scheid@ironclad.net.au>
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 Jul 12, 2004, at 7:45 PM, Eric Scheid wrote:

>
> On 13/7/04 10:23 AM, "Tim Bray" <Tim.Bray@Sun.COM> wrote:
>
>> Huh?  I thought I'd covered that in
>> http://imc.org/atom-syntax/mail-archive/msg06762.html
>
> what happens when there is another rev? how far back does 
> MustUnderstand
> apply? more importantly, how far forward will MustUnderstand flags be
> carried forward ... will we see a future version where nearly 
> everything is
> encrusted because at some various point it needed MustUnderstand? We 
> can't
> ever take it off an element, because what happens when a 2.0 code 
> encounters
> a 4.0 document (where the 3.0 revved it with MustUnderstand)?

Please read the proposal again, it's much simpler than what you're 
describing.  There are only two possible relationships between software 
and Atom instances: (1) I should understand this, its version number is 
<= than mine, or (2) it postdates me, its version # is > mine.  In case 
(1), atom markup I don't know is an error.  In case (2) Atom markup I 
don't know is to be ignored, unless it's labeled MustUnderstand *right 
there in the instance*, in which case I report an error.  -Tim



From owner-atom-syntax@mail.imc.org  Mon Jul 12 23:53: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 XAA21090
	for <atompub-archive@lists.ietf.org>; Mon, 12 Jul 2004 23:53: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 i6D3bNuq094905;
	Mon, 12 Jul 2004 20:37: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 i6D3bNR8094904;
	Mon, 12 Jul 2004 20:37: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 i6D3bJor094897
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 20:37:22 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 13 Jul 2004 13:42:12 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Tue, 13 Jul 2004 13:14:47 +1000
Subject: Re: Q: modfied vs issued vs created
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD1990C7.1F3B9%eric.scheid@ironclad.net.au>
In-Reply-To: <m3vfgtm462.fsf@bitsko.slc.ut.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


On 13/7/04 5:11 AM, "Ken MacLeod" <ken@bitsko.slc.ut.us> wrote:

> Based on empirical evidence from wikis that implement that feature

wikis are not the best example to model blogging behaviour.

That is to say, if blogging tools had a checkbox for "this is a minor
change" then I'd expect to see more accuracy than you would on a wiki.

Come to that, I'd expect to see more accuracy if the default was minor
change and the author had to select an option to "re-issue" it. That is, if
the option said "this is a major change" instead of "this is a trivial
change". Afterall, who wants to fuss with setting flags and stuff when
you're only doing a trivial change? Good defaults make good practice.

> I can see us specifying "reissued" would be a purpose for changing
> <issued>, but I would still expect clients to provide the user the
> option of selecting either of <issued>, <modified>, or <modified>+diff
> for determining redisplay on a feed-by-feed basis.

what is <modified>+diff? oh ... you're talking about the feed-reading user
:-)

> Is this consistent with your proposal?

Yes. Similar to how the feed-reading user may want to select local-time vs
author-time for display on a feed-by-feed basis.

e.



From owner-atom-syntax@mail.imc.org  Tue Jul 13 00: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 AAA21417
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 00: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 i6D3pZvD095917;
	Mon, 12 Jul 2004 20:51: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 i6D3pZ9l095916;
	Mon, 12 Jul 2004 20:51:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D3pZch095910
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 20:51:35 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6D3pfil023874
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 21:51:41 -0600 (MDT)
Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0I0R006JHUQ5MU@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Mon, 12 Jul 2004 21:51:41 -0600 (MDT)
Received: from [192.168.1.100] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0R00EDRUQ4C4@mail.sun.net> for atom-syntax@imc.org; Mon,
 12 Jul 2004 21:51:41 -0600 (MDT)
Date: Mon, 12 Jul 2004 20:51:43 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceElementOrder: options
In-reply-to: <79B7857D-D478-11D8-AFCB-000A95BD86C0@mnot.net>
To: Atomlist <atom-syntax@imc.org>
Message-id: <F4660158-D47F-11D8-AE39-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: <20040712221217.55674.qmail@web41508.mail.yahoo.com>
 <79B7857D-D478-11D8-AFCB-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 Jul 12, 2004, at 7:58 PM, Mark Nottingham wrote:

> Can you understand why the need to enable this scenario doesn't 
> overwhelm me?

Mark, climb down.  What they're saying is that IF you require strict 
ordering of elements, THEN a substantial class of software tools will 
find Atom easier to deal with.  I think we're looking at a straight 
cost-benefit trade-off here.

Basically, do we
1) think that the benefits of enabling XML Schema use exceed the costs 
of strict ordering, or
2) think that the benefits of loose ordering exceed the costs of making 
life harder for the schema-dependent, or
3) are we missing the point because the trade-off isn't real or there's 
a way to dodge it or something?

These seem like reasonable open questions that we should discuss 
reasonably. -Tim



From owner-atom-syntax@mail.imc.org  Tue Jul 13 00:03: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 AAA21583
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 00:03: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 i6D3u8b6096205;
	Mon, 12 Jul 2004 20:56: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 i6D3u8XP096204;
	Mon, 12 Jul 2004 20:56:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D3u6Ac096198
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 20:56:07 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 13 Jul 2004 14:01:18 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Tue, 13 Jul 2004 13:56:04 +1000
Subject: Re: a methodical approach to defining what date  elements we need
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD199A74.1F3DE%eric.scheid@ironclad.net.au>
In-Reply-To: <opsa1wb8jm6dxgxk@mail.online.no>
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 13/7/04 10:44 AM, "Arve Bersvendsen" <arve@virtuelvis.com> wrote:

> A major change, in my view, is a new entry, that supersedes a previous
> version. I just asked someone with experience from dead-tree publishing:
> 
> 1. For a straight reprints, the ISBN doesn't change.
> 2. When a book is revisioned, the ISBN changes.
> 3. If the publisher changes, the ISBN changes.
> 4. If the cover changes, the ISBN changes.

What happens to the LOC or Dewey Decimal numbers in those situations?

Are ISBNs more like non-serial version identifiers? After all, when the vast
majority of users of books refer to "The Tao of Pooh" they don't say "the
publication with ISBN xxx". They say "The Tao of Pooh". The various editions
and revisions and covers are simply *versions* of the *same* thing. They are
not *different* things in the sense that "The Tao of Pooh" is different from
"100 things to do with a dead cat".

So far, blogs don't usually provide ongoing life support for previous
versions (something I expect to continue) ... it is only wikis that do so
(for their own reasons), and with them the page-id very usually stays the
same, providing access to previous versions with some additional linking
cruft.

e.



From owner-atom-syntax@mail.imc.org  Tue Jul 13 00:03: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 AAA21607
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 00:03: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 i6D3vB35096287;
	Mon, 12 Jul 2004 20: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 i6D3vBAa096286;
	Mon, 12 Jul 2004 20:57:11 -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 i6D3vAp7096279
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 20:57:11 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 49058 messnum 2580801 invoked from network[83.70.39.115/83-70-39-115.bas2.prp.dublin.eircom.net]); 13 Jul 2004 03:57:12 -0000
Received: from 83-70-39-115.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.39.115)
  by mail08.svc.cra.dublin.eircom.net (qp 49058) with SMTP; 13 Jul 2004 03:57:12 -0000
Message-ID: <40F35D8F.6050106@dehora.net>
Date: Tue, 13 Jul 2004 04:57:03 +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: Atomlist <atom-syntax@imc.org>
Subject: Re: PaceElementOrder: options
References: <20040712221217.55674.qmail@web41508.mail.yahoo.com> <79B7857D-D478-11D8-AFCB-000A95BD86C0@mnot.net>
In-Reply-To: <79B7857D-D478-11D8-AFCB-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: <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:


> If I read you 
> right, it still won't be possible to describe the cardinality of 
> extensions; only the core metadata will have this feature. 

Red herring. I'm only interested in the elements we have to hand.


> Keeping this in perspective, those same implementers will be writing 
> GUIs, integrating network stacks, presentation engines, etc. and there 
> will be many orders of magnitude fewer such implementers than there will 
> be Atom authors, who will have to remember the proper ordering of these 
> elements 

This is the least of anyone's current comprehension worries.


> Even more 
> so, the ordering of metadata has absolutely no semantic relevance; it 
> doesn't carry any information at all.

Not the point; order of elements in XML syntax is significant. Going 
against that seems to based on some notion that something might 
break somewhere because the effort to order elements is alledged to 
be too much. Woe betide us perhaps, but I'm utterly unconvinced. 
Perhaps this will make sense to me when we have an extensibility model.

And what's with with all this metadata talk anyway? Sounds dangerous ;)

cheers
Bill



From owner-atom-syntax@mail.imc.org  Tue Jul 13 00: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 AAA21705
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 00: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 i6D3qVjR095964;
	Mon, 12 Jul 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 i6D3qVHs095963;
	Mon, 12 Jul 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 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 i6D3qUpD095954
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 20:52:30 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 77529 messnum 9267275 invoked from network[83.70.39.115/83-70-39-115.bas2.prp.dublin.eircom.net]); 13 Jul 2004 03:52:31 -0000
Received: from 83-70-39-115.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.39.115)
  by mail10.svc.cra.dublin.eircom.net (qp 77529) with SMTP; 13 Jul 2004 03:52:31 -0000
Message-ID: <40F35C76.5020607@dehora.net>
Date: Tue, 13 Jul 2004 04:52:22 +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: Mark Nottingham <mnot@mnot.net>
CC: Andreas Sewe <sewe@rbg.informatik.tu-darmstadt.de>,
        Mark Baker <distobj@acm.org>, "[Atom]" <atom-syntax@imc.org>
Subject: Re: Version vs. Namespace
References: <OFC66635FE.A2AF5F93-ON88256ECF.0060057C-88256ECF.0060668D@us.ibm.com> <C3C62D26-D42E-11D8-AFCB-000A95BD86C0@mnot.net> <001001c4684e$65d03c20$753ce03e@baron> <20040713015323.GS30868@markbaker.ca> <BBAD355E-D474-11D8-AFCB-000A95BD86C0@mnot.net> <40F35558.2000104@dehora.net> <4789E38B-D47D-11D8-AFCB-000A95BD86C0@mnot.net>
In-Reply-To: <4789E38B-D47D-11D8-AFCB-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: <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:

> I have no quarrel with the RDF model (actually, I love it to death), but 
> please, don't hold up the RDF/XML syntax as something to emulate or 
> consider as an alternative. "Worst of both worlds" pops into the mind, 
> as does "DOA."

Well, thanks, but you're preaching to the choir. I have a history of 
objection to RDF/XML.

But it remains a fact that RDF/XML enables this; and Atom does not.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Tue Jul 13 00:10: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 AAA21911
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 00:10: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 i6D3tWKK096155;
	Mon, 12 Jul 2004 20:55: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 i6D3tWYX096154;
	Mon, 12 Jul 2004 20:55:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web41504.mail.yahoo.com (web41504.mail.yahoo.com [66.218.93.87])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6D3tVfF096143
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 20:55:31 -0700 (PDT)
	(envelope-from randymorin@yahoo.com)
Message-ID: <20040713035528.87615.qmail@web41504.mail.yahoo.com>
Received: from [24.43.182.164] by web41504.mail.yahoo.com via HTTP; Mon, 12 Jul 2004 20:55:28 PDT
Date: Mon, 12 Jul 2004 20:55:28 -0700 (PDT)
From: Randy Charles Morin <randymorin@yahoo.com>
Reply-To: randy@kbcafe.com
Subject: Re: PaceElementOrder: options 
To: Mark Nottingham <mnot@mnot.net>, randy@kbcafe.com
Cc: Atomlist <atom-syntax@imc.org>
In-Reply-To: <79B7857D-D478-11D8-AFCB-000A95BD86C0@mnot.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1780852818-1089690928=:87462"
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>


--0-1780852818-1089690928=:87462
Content-Type: text/plain; charset=us-ascii

But the argument that order is too difficult is overwhelming? Statements like "minority of XML tools" indicate to me that you are not prepared to be reasonable. VS.NET and XMLSpy are two of the most popular XML tools, if not the two most popular XML tools.
Thanks,
 
Randy
http://www.kbcafe.com


Mark Nottingham <mnot@mnot.net> wrote:

Can you understand why the need to enable this scenario doesn't 
overwhelm me?

		
---------------------------------
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
--0-1780852818-1089690928=:87462
Content-Type: text/html; charset=us-ascii

<DIV>But the argument that order is too difficult is overwhelming? Statements like "minority of XML tools" indicate to me that you are not prepared to be reasonable.&nbsp;VS.NET&nbsp;and XMLSpy are two of the most&nbsp;popular XML tools, if not the two most popular XML tools.</DIV>
<DIV>Thanks,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Randy</DIV>
<DIV><A href="http://www.kbcafe.com">http://www.kbcafe.com</A></DIV>
<DIV><BR><BR><B><I>Mark Nottingham &lt;mnot@mnot.net&gt;</I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid"><BR>Can you understand why the need to enable this scenario doesn't <BR>overwhelm me?<BR></BLOCKQUOTE><p>
		<hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/mail_us/taglines/10/*http://promotions.yahoo.com/new_mail/static/efficiency.html">New and Improved Yahoo! Mail</a> - Send 10MB messages!
--0-1780852818-1089690928=:87462--



From owner-atom-syntax@mail.imc.org  Tue Jul 13 00: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 AAA23036
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 00: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 i6D42aov096698;
	Mon, 12 Jul 2004 21:02: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 i6D42a9O096697;
	Mon, 12 Jul 2004 21:02:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D42a9S096680;
	Mon, 12 Jul 2004 21:02:36 -0700 (PDT)
	(envelope-from jasnell@us.ibm.com)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11])
	by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i6D42Xko332266;
	Tue, 13 Jul 2004 00:02:33 -0400
Received: from d03nm122.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170])
	by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6D42RMH408516;
	Mon, 12 Jul 2004 22:02:33 -0600
In-Reply-To: <p0611044ebd18e502cd8b@[10.20.30.249]>
To: Paul Hoffman / IMC <phoffman@imc.org>
Cc: Atom WG <atom-syntax@imc.org>, owner-atom-syntax@mail.imc.org
MIME-Version: 1.0
Subject: Re: Usage Scenarios for Versioning and Extensibility
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
From: James M Snell <jasnell@us.ibm.com>
X-MIMETrack: S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 09:00:50 PM,
	Serialize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 09:00:50 PM,
	Serialize complete at 07/12/2004 09:00:50 PM,
	Itemize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 09:00:50 PM,
	S/MIME Sign complete at 07/12/2004 09:00:50 PM,
	S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 09:01:47 PM,
	S/MIME Sign complete at 07/12/2004 09:01:47 PM,
	Serialize by Router on D03NM122/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at
 07/12/2004 22:02:32,
	Serialize complete at 07/12/2004 22:02:32
Message-ID: <OF4F886155.F631270A-ON88256ED0.001525E6-88256ED0.001622F9@us.ibm.com>
Date: Mon, 12 Jul 2004 22:01:49 -0600
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z17371_boundary_sign
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>


This is an S/MIME signed message.

---------z17371_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 00160CA788256ED0_="

This is a multipart message in MIME format.
--=_alternative 00160CA788256ED0_=
Content-Type: text/plain; charset="US-ASCII"

owner-atom-syntax@mail.imc.org wrote on 07/12/2004 06:03:25 PM:

> 
> At 5:14 PM -0700 7/12/04, Mark Nottingham wrote:
> >0) Let's imagine that Atom 1.0 has been released and finalised in 
> >all of its glory.
> >
> >1) And it was good... except for that nasty atom:title element; 
> >after wide deployment experience, it's agreed we need a new version 
> >of it. So, a new version of Atom is introduced. The new one isn't 
> >backwards-compatible with the old one.
> >
> >2) Then, we decide we want to add a new metadata element, let's call 
> >it "fog." So, a new version of Atom is introduced.
> >
> >3) After a while, someone comes up with a souped-up version of 
> >atom:title that is backwards-compatible, just *better*. It gets 
> >really popular, and yet another version of Atom is born.
> >
> >4) At the same time, a group of rogue Open Source Software 
> >programmers descends upon this idyllic scene and introduces its own 
> >extensions. Up until now, all of our extensions have been approved 
> >and incorporated by the WG, but these are destined to remain 
> >separate.
> >
> >5) Finally, in 2010, we realise that the Atom feed and entry 
> >containers aren't really doing the job, and we need to change their 
> >model. Yet Another Version of Atom (YAVA) comes into being.
> >
> >Any proposal for versioning should address at least these 
> >situations, show how the various extensions and changes are 
> >identified and disambiguated, and should explain how software is to 
> >handle them. They should also consider how combinations of these 
> >scenarios are handled.
> 
> +1 or more. This is an excellent mix and not at all far-fetched. It 
> should help us focus on what we need for versioning and extensibility.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
> 

Agreed.  Fundamentally, the first and foremost thing that we should focus 
on is determining how difficult this WG wants to make it to allow such 
changes to occur and whether or not changes should be defined so that they 
are backwards compatible.  I do not believe it would be too far fetched 
for this group to assert that changes should be absolutely backwards 
compatible unless it can be demonstrated that the a breaking change is 
absolutely required.  Let's set the bar high right from the beginning.

Regarding #2, introducing an "extension namespace" where such new elements 
can be defined, experimented with, implementation practice/experience 
gained, etc, would greatly enhance the process.  When a new element is 
proposed, it would be put into the extension namespace initially.  Only 
after it has been implemented and folks agree that it is essential to have 
as part of the core would it be placed under the core namespace.

Regarding #4, allow people to come up with whatever extension elements 
they wish in their own namespace and define that all elements in unknown 
namespaces are to be summarily ignored and dismissed.  If the creators of 
those extensions wish to define a profile for their use, let them go 
through the work of writing up an RFC that describes the appropriate 
semantics.  Once the RFC is published, Aggregators and other apps can 
choose whether or not to support that RFC.

Whether or not Atom's versioning of the core spec gets out of control is 
more a function of this groups philosophy towards accepting changes of 
dubious or unproven utility.


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

--=_alternative 00160CA788256ED0_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>owner-atom-syntax@mail.imc.org wrote on 07/12/2004
06:03:25 PM:<br>
<br>
&gt; <br>
&gt; At 5:14 PM -0700 7/12/04, Mark Nottingham wrote:<br>
&gt; &gt;0) Let's imagine that Atom 1.0 has been released and finalised
in <br>
&gt; &gt;all of its glory.<br>
&gt; &gt;<br>
&gt; &gt;1) And it was good... except for that nasty atom:title element;
<br>
&gt; &gt;after wide deployment experience, it's agreed we need a new version
<br>
&gt; &gt;of it. So, a new version of Atom is introduced. The new one isn't
<br>
&gt; &gt;backwards-compatible with the old one.<br>
&gt; &gt;<br>
&gt; &gt;2) Then, we decide we want to add a new metadata element, let's
call <br>
&gt; &gt;it &quot;fog.&quot; So, a new version of Atom is introduced.<br>
&gt; &gt;<br>
&gt; &gt;3) After a while, someone comes up with a souped-up version of
<br>
&gt; &gt;atom:title that is backwards-compatible, just *better*. It gets
<br>
&gt; &gt;really popular, and yet another version of Atom is born.<br>
&gt; &gt;<br>
&gt; &gt;4) At the same time, a group of rogue Open Source Software <br>
&gt; &gt;programmers descends upon this idyllic scene and introduces its
own <br>
&gt; &gt;extensions. Up until now, all of our extensions have been approved
<br>
&gt; &gt;and incorporated by the WG, but these are destined to remain <br>
&gt; &gt;separate.<br>
&gt; &gt;<br>
&gt; &gt;5) Finally, in 2010, we realise that the Atom feed and entry <br>
&gt; &gt;containers aren't really doing the job, and we need to change
their <br>
&gt; &gt;model. Yet Another Version of Atom (YAVA) comes into being.<br>
&gt; &gt;<br>
&gt; &gt;Any proposal for versioning should address at least these <br>
&gt; &gt;situations, show how the various extensions and changes are <br>
&gt; &gt;identified and disambiguated, and should explain how software
is to <br>
&gt; &gt;handle them. They should also consider how combinations of these
<br>
&gt; &gt;scenarios are handled.<br>
&gt; <br>
&gt; +1 or more. This is an excellent mix and not at all far-fetched. It
<br>
&gt; should help us focus on what we need for versioning and extensibility.<br>
&gt; <br>
&gt; --Paul Hoffman, Director<br>
&gt; --Internet Mail Consortium<br>
&gt; <br>
</tt></font>
<br><font size=2><tt>Agreed. &nbsp;Fundamentally, the first and foremost
thing that we should focus on is determining how difficult this WG wants
to make it to allow such changes to occur and whether or not changes should
be defined so that they are backwards compatible. &nbsp;I do not believe
it would be too far fetched for this group to assert that changes should
be absolutely backwards compatible unless it can be demonstrated that the
a breaking change is absolutely required. &nbsp;Let's set the bar high
right from the beginning.</tt></font>
<br>
<br><font size=2><tt>Regarding #2, introducing an &quot;extension namespace&quot;
where such new elements can be defined, experimented with, implementation
practice/experience gained, etc, would greatly enhance the process. &nbsp;When
a new element is proposed, it would be put into the extension namespace
initially. &nbsp;Only after it has been implemented and folks agree that
it is essential to have as part of the core would it be placed under the
core namespace.</tt></font>
<br>
<br><font size=2><tt>Regarding #4, allow people to come up with whatever
extension elements they wish in their own namespace and define that all
elements in unknown namespaces are to be summarily ignored and dismissed.
&nbsp;If the creators of those extensions wish to define a profile for
their use, let them go through the work of writing up an RFC that describes
the appropriate semantics. &nbsp;Once the RFC is published, Aggregators
and other apps can choose whether or not to support that RFC.</tt></font>
<br>
<br><font size=2><tt>Whether or not Atom's versioning of the core spec
gets out of control is more a function of this groups philosophy towards
accepting changes of dubious or unproven utility.</tt></font>
<br>
<br>
<br><font size=2 face="sans-serif">- James M Snell<br>
 &nbsp;jasnell@us.ibm.com<br>
 &nbsp;http://www.ibm.com<br>
 &nbsp;(877) 511-5082 / Office<br>
 &nbsp;930-1979 / Tie Line</font>
<br>
--=_alternative 00160CA788256ED0_=--

---------z17371_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIIUOAIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIISWDCCAtow
ggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1
aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAy
MDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA629xc49NpAPz
cAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7glzJKgPkPzlTZZfznznGbmAWVnNBQ
lyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnwNclOnnP2sKufuPzbTImQTTi5c8JZNZcM
J0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEEBAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1Ud
DgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAPBgNVHRMBAf8EBTADAQH/MDEGA1UdJQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUH
AwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvu
jQupk2oCScMd3FIHLE7hOfu8YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14ke
McF9ViNdewEoBGiAycUq8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIC2jCCAkOgAwIB
AgIDAxS2MA0GCSqGSIb3DQEBBAUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwMTE0MjIw
NzExWhcNMTExMjMxMjIwNzExWjBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25h
bCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrb3Fzj02kA/NwCy5KFMiY
tFgyTJ6kMSQLVSs9uwVHIAVkqy/enDQwZ9b/7uCXMkqA+Q/OVNll/OfOcZuYBZWc0FCXI9qw60KO
J/rTd65FdF4dwp8cw8si0qjOJtYg8cm46fA1yU6ec/awq5+4/NtMiZBNOLlzwlk1lwwnRgXNNwID
AQABo4GqMIGnMBEGCWCGSAGG+EIBAQQEAwIAhzAOBgNVHQ8BAf8EBAMCAcYwHQYDVR0OBBYEFK5U
DpLqqDOpKyQtx8hvMNze80pAMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMA8GA1Ud
EwEB/wQFMAMBAf8wMQYDVR0lBCowKAYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYB
BQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAMnJ7c2YLyrY/PKlFl+7sm8NENfWtFxqdm+6NC6mTagJJ
wx3cUgcsTuE5+7xh9+/G0tTfLzA1qZAQ5GNMPXvmoB9+vJfKnC2JWMFQpIOUEJDXiR4xwX1WI117
ASgEaIDJxSrxHcuuV/hMIO9bgZ6C41MUVmdLTKBgBOImTuIPK8QwggMgMIICiaADAgECAgQ13vTP
MA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQL
EyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0MTUxWhcN
MTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMk
RXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKKlQRkrPFr
U18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkwrFEeO68r
1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOgYaRfMF0x
CzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBD
ZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAxODA4MjIx
NjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAdBgNV
HQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0HQQAEDTAL
GwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwlMQ0AppJu
f7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn00DbOyZY
sih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMgMIICiaADAgEC
AgQ13vTPMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0
MTUxWhcNMTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsG
A1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKK
lQRkrPFrU18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkw
rFEeO68r1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOg
YaRfMF0xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNl
Y3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAx
ODA4MjIxNjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAdBgNVHQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0H
QQAEDTALGwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwl
MQ0AppJuf7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn
00DbOyZYsih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMmMIIC
j6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIxNjM2NTRaMIGFMQsw
CQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEXMBUGA1UEAxMOSmFt
ZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkqhkiG9w0BCQEWEmph
c25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwKpbDG3zMatEuuOT
FYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSyd+7nwqAvbBfPj+0S
vcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7tBJlLrwDRCMoNlPuQ
Kg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQW
BBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOgFAwSamFzbmVs
bEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pAMCcGA1UdJQQgMB4G
CCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAZMKevB7dFfb9
23OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY8BjwVHxiYgG4xkxf
B1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOIzj3lz3xd+uOzqRFg
/Wsg/VMwggMmMIICj6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAy
BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNV
BAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIx
NjM2NTRaMIGFMQswCQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEX
MBUGA1UEAxMOSmFtZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkq
hkiG9w0BCQEWEmphc25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
wKpbDG3zMatEuuOTFYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSy
d+7nwqAvbBfPj+0SvcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7t
BJlLrwDRCMoNlPuQKg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQD
AgXgMB0GA1UdDgQWBBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcU
AgOgFAwSamFzbmVsbEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA
MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQAD
gYEAZMKevB7dFfb923OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY
8BjwVHxiYgG4xkxfB1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOI
zj3lz3xd+uOzqRFg/Wsg/VMxggG7MIIBtwIBATBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJ
bnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0g
Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwF+kzAJBgUrDgMCGgUAoIGiMBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDcxMzA0MDA1MFowIwYJKoZIhvcNAQkEMRYE
FG9gKvHySGVJuXtBqlI3rwU8WCK5MEMGCSqGSIb3DQEJDzE2MDQwBwYFKw4DAh0wDgYIKoZIhvcN
AwICAgCAMAoGCCqGSIb3DQMHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAgd6ulB1O
1rWmzcl55emE3TSMaRF9Qlb63+KfaonNToVushpyhi9LKZb2nBQ7kid1egjVIED0FgLeErH18fdz
RLIBpANGLj1R4+1snKwGilGkjZ1M746f6d0CTc1kgGUHKOz15QIeHTD2ZypMBYWjrsci0fcHyOAc
FPde/9hS8qsAAAAA

---------z17371_boundary_sign--



From owner-atom-syntax@mail.imc.org  Tue Jul 13 00:20: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 AAA24135
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 00: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 i6D4BLfd097646;
	Mon, 12 Jul 2004 21: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 i6D4BLH8097645;
	Mon, 12 Jul 2004 21:11:21 -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 i6D4BKft097639
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 21:11:20 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.19] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id A20C2727D; Mon, 12 Jul 2004 21:11:26 -0700 (PDT)
In-Reply-To: <40F35C76.5020607@dehora.net>
References: <OFC66635FE.A2AF5F93-ON88256ECF.0060057C-88256ECF.0060668D@us.ibm.com> <C3C62D26-D42E-11D8-AFCB-000A95BD86C0@mnot.net> <001001c4684e$65d03c20$753ce03e@baron> <20040713015323.GS30868@markbaker.ca> <BBAD355E-D474-11D8-AFCB-000A95BD86C0@mnot.net> <40F35558.2000104@dehora.net> <4789E38B-D47D-11D8-AFCB-000A95BD86C0@mnot.net> <40F35C76.5020607@dehora.net>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <B55F9DFD-D482-11D8-9691-000A95BD86C0@mnot.net>
Cc: Andreas Sewe <sewe@rbg.informatik.tu-darmstadt.de>,
        Mark Baker <distobj@acm.org>, "[Atom]" <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: Re: Version vs. Namespace
Date: Mon, 12 Jul 2004 21:11:26 -0700
To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>
X-Mailer: Apple Mail (2.618)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6D4BKft097640
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 Jul 12, 2004, at 8:52 PM, Bill de hÓra wrote:

> Well, thanks, but you're preaching to the choir. I have a history of 
> objection to RDF/XML.

Always good to add to the multitude -- must be quite a sound by now!  ;)

> But it remains a fact that RDF/XML enables this; and Atom does not.

Aha; I see your point. Atom isn't final, so I don't think we can make 
such statements about it yet. If people seriously want to make Atom a 
one-shot, one-scenario spec (i.e., blogging/news feeds), we need to get 
consensus around that. I, for one, would object violently.

Cheers,

--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org  Tue Jul 13 00: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 AAA24565
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 00: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 i6D4ESFY097798;
	Mon, 12 Jul 2004 21:14: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 i6D4ESK1097797;
	Mon, 12 Jul 2004 21:14:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D4ERov097783;
	Mon, 12 Jul 2004 21:14:27 -0700 (PDT)
	(envelope-from jasnell@us.ibm.com)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11])
	by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i6D4EP10546208;
	Tue, 13 Jul 2004 00:14:25 -0400
Received: from d03nm122.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 i6D4EOMG414242;
	Mon, 12 Jul 2004 22:14:25 -0600
In-Reply-To: <A7390D5E-D466-11D8-AFCB-000A95BD86C0@mnot.net>
To: Mark Nottingham <mnot@mnot.net>
Cc: Atom Syntax <atom-syntax@imc.org>, Norman Walsh <ndw@nwalsh.com>,
        owner-atom-syntax@mail.imc.org
MIME-Version: 1.0
Subject: Re: Version vs. Namespace
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
From: James M Snell <jasnell@us.ibm.com>
X-MIMETrack: S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 09:13:20 PM,
	Serialize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 09:13:20 PM,
	Serialize complete at 07/12/2004 09:13:20 PM,
	Itemize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 09:13:20 PM,
	S/MIME Sign complete at 07/12/2004 09:13:20 PM,
	S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 09:14:19 PM,
	S/MIME Sign complete at 07/12/2004 09:14:19 PM,
	Serialize by Router on D03NM122/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at
 07/12/2004 22:14:24,
	Serialize complete at 07/12/2004 22:14:24
Message-ID: <OF3AD386E0.E58B109C-ON88256ED0.0016F9E5-88256ED0.001748DA@us.ibm.com>
Date: Mon, 12 Jul 2004 22:14:21 -0600
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z56986_boundary_sign
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>


This is an S/MIME signed message.

---------z56986_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 001731CA88256ED0_="

This is a multipart message in MIME format.
--=_alternative 001731CA88256ED0_=
Content-Type: text/plain; charset="US-ASCII"

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

owner-atom-syntax@mail.imc.org wrote on 07/12/2004 05:50:36 PM:

> 
> 
> On Jul 12, 2004, at 1:47 PM, James M Snell wrote:
> > > On Jul 12, 2004, at 1:07 PM, James M Snell wrote:
> >  > > While I'm ok with this, I'd have to argue that the bar should be 
> > set
> >  > > rather high for the working group to consider such changes after 
> > Atom
> >  > > 1.0 is out the door.  Even the addition of new optional elements
> >  > > within the same namespace could cause problems for various
> >  > > implementations.  
> >  >
> >  > How so?
> >
> > More of an implementation issue really (as opposed to something that 
> > should be codified in the spec), but given an application that is 
> > programmed to expect certain known optional elements, the addition of 
> > a new unknown optional element that the application does not know how 
> > to handle could cause problems.  Look at the parallels in things like 
> > DNS as an example, where while the DNS spec supports new resource 
> > record types, for years the introduction of new types, regardless of 
> > their optional nature, was not supported by many implementations.  I 
> > am not saying that the WG should care if applications are written in 
> > such a brittle fashion, only that it should be recognized that such 
> > issues can occur.  It is possible to mitigate such issues by defining 
> > concise behavior/semantics and setting the bar high for changes to the 

> > core namespace (or extension namespaces).  For example, if we expect 
> > that new elements could be added at any time to the core namespace 
> > without much effort, then that should be captured in the spec so that 
> > implementors can plan their implementations accordingly.
> 
> No. One of the big reasons I'm involved in Atom is to allow new 
> extensions to be introduced without this kind of barrier; without that, 
> Atom is frankly not very interesting at all.
> 
> Much better to make an explicit "must ignore" rule (as DavidO has 
> documented) in the spec, so implementations know what the expectations 
> upon them are in these situations.
> 

By all means, create all the extensions you want... *in their own 
namespace or in an extension namespace*.  I'm all for that and defining a 
"MustUnderstand" attribute for these elements.  What I draw the line at, 
however, is changes being made willy-nilly within the core namespace.  The 
core should only rarely ever be changed.

> --
> Mark Nottingham     http://www.mnot.net/
> 
> 

--=_alternative 001731CA88256ED0_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">- James M Snell<br>
 &nbsp;jasnell@us.ibm.com<br>
 &nbsp;http://www.ibm.com<br>
 &nbsp;(877) 511-5082 / Office<br>
 &nbsp;930-1979 / Tie Line</font>
<br>
<br><font size=2><tt>owner-atom-syntax@mail.imc.org wrote on 07/12/2004
05:50:36 PM:<br>
<br>
&gt; <br>
&gt; <br>
&gt; On Jul 12, 2004, at 1:47 PM, James M Snell wrote:<br>
&gt; &gt; &gt; On Jul 12, 2004, at 1:07 PM, James M Snell wrote:<br>
&gt; &gt; &nbsp;&gt; &gt; While I'm ok with this, I'd have to argue that
the bar should be <br>
&gt; &gt; set<br>
&gt; &gt; &nbsp;&gt; &gt; rather high for the working group to consider
such changes after <br>
&gt; &gt; Atom<br>
&gt; &gt; &nbsp;&gt; &gt; 1.0 is out the door. &nbsp;Even the addition
of new optional elements<br>
&gt; &gt; &nbsp;&gt; &gt; within the same namespace could cause problems
for various<br>
&gt; &gt; &nbsp;&gt; &gt; implementations. &nbsp;<br>
&gt; &gt; &nbsp;&gt;<br>
&gt; &gt; &nbsp;&gt; How so?<br>
&gt; &gt;<br>
&gt; &gt; More of an implementation issue really (as opposed to something
that <br>
&gt; &gt; should be codified in the spec), but given an application that
is <br>
&gt; &gt; programmed to expect certain known optional elements, the addition
of <br>
&gt; &gt; a new unknown optional element that the application does not
know how <br>
&gt; &gt; to handle could cause problems. &nbsp;Look at the parallels in
things like <br>
&gt; &gt; DNS as an example, where while the DNS spec supports new resource
<br>
&gt; &gt; record types, for years the introduction of new types, regardless
of <br>
&gt; &gt; their optional nature, was not supported by many implementations.
&nbsp;I <br>
&gt; &gt; am not saying that the WG should care if applications are written
in <br>
&gt; &gt; such a brittle fashion, only that it should be recognized that
such <br>
&gt; &gt; issues can occur. &nbsp;It is possible to mitigate such issues
by defining <br>
&gt; &gt; concise behavior/semantics and setting the bar high for changes
to the <br>
&gt; &gt; core namespace (or extension namespaces). &nbsp;For example,
if we expect <br>
&gt; &gt; that new elements could be added at any time to the core namespace
<br>
&gt; &gt; without much effort, then that should be captured in the spec
so that <br>
&gt; &gt; implementors can plan their implementations accordingly.<br>
&gt; <br>
&gt; No. One of the big reasons I'm involved in Atom is to allow new <br>
&gt; extensions to be introduced without this kind of barrier; without
that, <br>
&gt; Atom is frankly not very interesting at all.<br>
&gt; <br>
&gt; Much better to make an explicit &quot;must ignore&quot; rule (as DavidO
has <br>
&gt; documented) in the spec, so implementations know what the expectations
<br>
&gt; upon them are in these situations.<br>
&gt; </tt></font>
<br>
<br><font size=2><tt>By all means, create all the extensions you want...
*in their own namespace or in an extension namespace*. &nbsp;I'm all for
that and defining a &quot;MustUnderstand&quot; attribute for these elements.
&nbsp;What I draw the line at, however, is changes being made willy-nilly
within the core namespace. &nbsp;The core should only rarely ever be changed.</tt></font>
<br><font size=2><tt><br>
&gt; --<br>
&gt; Mark Nottingham &nbsp; &nbsp; http://www.mnot.net/<br>
&gt; <br>
&gt; <br>
</tt></font>
--=_alternative 001731CA88256ED0_=--

---------z56986_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIIUOAIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIISWDCCAtow
ggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1
aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAy
MDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA629xc49NpAPz
cAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7glzJKgPkPzlTZZfznznGbmAWVnNBQ
lyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnwNclOnnP2sKufuPzbTImQTTi5c8JZNZcM
J0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEEBAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1Ud
DgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAPBgNVHRMBAf8EBTADAQH/MDEGA1UdJQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUH
AwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvu
jQupk2oCScMd3FIHLE7hOfu8YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14ke
McF9ViNdewEoBGiAycUq8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIC2jCCAkOgAwIB
AgIDAxS2MA0GCSqGSIb3DQEBBAUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwMTE0MjIw
NzExWhcNMTExMjMxMjIwNzExWjBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25h
bCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrb3Fzj02kA/NwCy5KFMiY
tFgyTJ6kMSQLVSs9uwVHIAVkqy/enDQwZ9b/7uCXMkqA+Q/OVNll/OfOcZuYBZWc0FCXI9qw60KO
J/rTd65FdF4dwp8cw8si0qjOJtYg8cm46fA1yU6ec/awq5+4/NtMiZBNOLlzwlk1lwwnRgXNNwID
AQABo4GqMIGnMBEGCWCGSAGG+EIBAQQEAwIAhzAOBgNVHQ8BAf8EBAMCAcYwHQYDVR0OBBYEFK5U
DpLqqDOpKyQtx8hvMNze80pAMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMA8GA1Ud
EwEB/wQFMAMBAf8wMQYDVR0lBCowKAYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYB
BQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAMnJ7c2YLyrY/PKlFl+7sm8NENfWtFxqdm+6NC6mTagJJ
wx3cUgcsTuE5+7xh9+/G0tTfLzA1qZAQ5GNMPXvmoB9+vJfKnC2JWMFQpIOUEJDXiR4xwX1WI117
ASgEaIDJxSrxHcuuV/hMIO9bgZ6C41MUVmdLTKBgBOImTuIPK8QwggMgMIICiaADAgECAgQ13vTP
MA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQL
EyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0MTUxWhcN
MTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMk
RXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKKlQRkrPFr
U18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkwrFEeO68r
1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOgYaRfMF0x
CzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBD
ZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAxODA4MjIx
NjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAdBgNV
HQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0HQQAEDTAL
GwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwlMQ0AppJu
f7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn00DbOyZY
sih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMgMIICiaADAgEC
AgQ13vTPMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0
MTUxWhcNMTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsG
A1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKK
lQRkrPFrU18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkw
rFEeO68r1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOg
YaRfMF0xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNl
Y3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAx
ODA4MjIxNjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAdBgNVHQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0H
QQAEDTALGwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwl
MQ0AppJuf7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn
00DbOyZYsih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMmMIIC
j6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIxNjM2NTRaMIGFMQsw
CQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEXMBUGA1UEAxMOSmFt
ZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkqhkiG9w0BCQEWEmph
c25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwKpbDG3zMatEuuOT
FYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSyd+7nwqAvbBfPj+0S
vcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7tBJlLrwDRCMoNlPuQ
Kg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQW
BBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOgFAwSamFzbmVs
bEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pAMCcGA1UdJQQgMB4G
CCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAZMKevB7dFfb9
23OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY8BjwVHxiYgG4xkxf
B1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOIzj3lz3xd+uOzqRFg
/Wsg/VMwggMmMIICj6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAy
BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNV
BAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIx
NjM2NTRaMIGFMQswCQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEX
MBUGA1UEAxMOSmFtZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkq
hkiG9w0BCQEWEmphc25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
wKpbDG3zMatEuuOTFYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSy
d+7nwqAvbBfPj+0SvcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7t
BJlLrwDRCMoNlPuQKg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQD
AgXgMB0GA1UdDgQWBBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcU
AgOgFAwSamFzbmVsbEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA
MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQAD
gYEAZMKevB7dFfb923OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY
8BjwVHxiYgG4xkxfB1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOI
zj3lz3xd+uOzqRFg/Wsg/VMxggG7MIIBtwIBATBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJ
bnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0g
Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwF+kzAJBgUrDgMCGgUAoIGiMBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDcxMzA0MTMyMFowIwYJKoZIhvcNAQkEMRYE
FBXEnQ/80FCpESr2MTy84zaJE6+1MEMGCSqGSIb3DQEJDzE2MDQwBwYFKw4DAh0wDgYIKoZIhvcN
AwICAgCAMAoGCCqGSIb3DQMHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAm17JKzVC
KGWKcvUBG2Xy9rCvcCHBS0aDjmCmn7xv4n8OuAgAsi7QHhRvU0RrOn9We9VNG7wbyFI7CENVwWJc
pAsBQZGiOqC2yM/Q2m+Wi+3irdIoIngMexLnfDNzXp7jJcx1zoKb27kUAK6azIg8Padv/tyos1s+
NBgv9a/HdwoAAAAA

---------z56986_boundary_sign--



From owner-atom-syntax@mail.imc.org  Tue Jul 13 00: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 AAA24718
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 00:26: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 i6D4IYNK098199;
	Mon, 12 Jul 2004 21:18: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 i6D4IYcT098198;
	Mon, 12 Jul 2004 21:18:34 -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 i6D4IXp0098192
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 21:18:34 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.19] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id 1ABF9727D; Mon, 12 Jul 2004 21:18:41 -0700 (PDT)
In-Reply-To: <20040713035528.87615.qmail@web41504.mail.yahoo.com>
References: <20040713035528.87615.qmail@web41504.mail.yahoo.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <B8486408-D483-11D8-9691-000A95BD86C0@mnot.net>
Cc: Atomlist <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: Re: PaceElementOrder: options 
Date: Mon, 12 Jul 2004 21:18:40 -0700
To: randy@kbcafe.com
X-Mailer: Apple Mail (2.618)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6D4IYp0098193
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 Jul 12, 2004, at 8:55 PM, Randy Charles Morin wrote:

> But the argument that order is too difficult is overwhelming?

No, the argument is that the benefits are minimal and diminishing, and 
the costs are high.


> Statements like "minority of XML tools" indicate to me that you are 
> not prepared to be reasonable. VS.NET and XMLSpy are two of the 
> most popular XML tools, if not the two most popular XML tools.

XML Spy is so broken it hurts. Seriously; if I had a dollar for every 
time I heard someone say "But XML Spy said it was valid" I'd be flying 
business a lot more than I do.

Besides, as soon as there's ONE decent Atom library for Java and one 
for C#, this argument will be completely without base.

Cheers,


--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org  Tue Jul 13 00: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 AAA25016
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 00:29: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 i6D4D3om097722;
	Mon, 12 Jul 2004 21: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 i6D4D37O097721;
	Mon, 12 Jul 2004 21:13:03 -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 i6D4D2X8097714
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 21:13:02 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 13 Jul 2004 14:18:18 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Tue, 13 Jul 2004 14:13:04 +1000
Subject: Re: Q: modfied vs issued vs created
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD199E70.1F3EB%eric.scheid@ironclad.net.au>
In-Reply-To: <opsa1l01mvuvpchu@quark>
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 i6D4D3X8097716
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 13/7/04 7:01 AM, "Asbjørn Ulsberg" <asbjorn@tigerstaden.no> wrote:

>> Only if we assume <issued> can't change.
> 
> Why would one assume anything else? From where did the idea that
> atom:issued could be randomly updated, surface?

The spec was silent on the matter. It is observable practice (good or bad)
that people do "re-issue" entries with updated content. It is also
observable that most people don¹t ever re-issue the vast majority of their
entries, so the question is moot for most cases.

>> If it can change, then we have all the information we need to communicate
>> minor change, major change, old news, and old news asserted to be still
>> valid. Pretty handy that.
> 
> We then lose a mechanism to tell when that particular entry was first
> issued.

If we need a tighter/narrower definition, then perhaps we need a new element
specifically for that purpose. It makes more sense to have a [generic]
<issued> and a [specific] <first-issued> than to have a [specific/narrow]
<issued> and a [wider] <latest-issued>.

Alternatively, we could simply have <issued>+ in the spec. That is, "one or
more", which shows not only the first issuance, but any subsequent major
re-publishings. When I look in the frontspiece of a dead-tree book I can
usually find a list of prior editions.

e.




From owner-atom-syntax@mail.imc.org  Tue Jul 13 00:34:21 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25326
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 00: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 i6D4Pp2j098750;
	Mon, 12 Jul 2004 21:25: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 i6D4Pp23098749;
	Mon, 12 Jul 2004 21:25:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web41502.mail.yahoo.com (web41502.mail.yahoo.com [66.218.93.85])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6D4PowL098739
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 21:25:50 -0700 (PDT)
	(envelope-from randymorin@yahoo.com)
Message-ID: <20040713042552.55133.qmail@web41502.mail.yahoo.com>
Received: from [24.43.182.164] by web41502.mail.yahoo.com via HTTP; Mon, 12 Jul 2004 21:25:52 PDT
Date: Mon, 12 Jul 2004 21:25:52 -0700 (PDT)
From: Randy Charles Morin <randymorin@yahoo.com>
Reply-To: randy@kbcafe.com
Subject: Re: PaceElementOrder: options 
To: Mark Nottingham <mnot@mnot.net>, randy@kbcafe.com
Cc: Atomlist <atom-syntax@imc.org>
In-Reply-To: <79B7857D-D478-11D8-AFCB-000A95BD86C0@mnot.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-602170767-1089692752=:53669"
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>


--0-602170767-1089692752=:53669
Content-Type: text/plain; charset=us-ascii


More complete list of tools that behave better if XML is ordered in the XSD.

Ones that I've used...

   XSD.exe - http://msdn.microsoft.com/library/en-us/cptools/html/cpconXMLSchemaDefinitionToolXsdexe.asp
   WSDL.exe - http://msdn.microsoft.com/library/en-us/cptools/html/cpgrfWebServicesDescriptionLanguageToolWsdlexe.asp
   XMLSpy - http://www.altova.com/products_ide.html
   VS.NET - http://msdn.microsoft.com/vstudio/
   Apache Axis - http://ws.apache.org/axis/
   MSSOAP SDK - http://www.microsoft.com/downloads/details.aspx?FamilyId=C943C0DD-CEEC-4088-9753-86F052EC8450&displaylang=en
   IBM SOAP4J - http://www.alphaworks.ibm.com/tech/soap4j/

And others that I haven't used.

   Code Generation Extensions - http://www.gotdotnet.com/Community/Workspaces/Workspace.aspx?id=80258a8c-bb4c-48e6-948b-05f6da568f55
   Castor Eclipse plugins - http://xdoclipse.sourceforge.net/
   WSDL2Java Eclipse plugin - http://www.myspotter.com/wsdl2java.shtml
   Novell's jBroker - http://www.novell.com/documentation/workbench41/docs/jbroker-web/docs/reference/tools/wsdl2java.html
   Webmethods - http://www.webmethods.com/docs/glue/api/electric/wsdl/tools/WSDL2Java.html

Thanks and sorry about that last one,

Randy
http://www.kbcafe.com


Mark Nottingham <mnot@mnot.net> wrote:

In other words, there are a minority of XML tools that rely upon a 
quirky, very limited and problematic expression of constraints upon XML 
-- i.e., XML Schema -- and therefore you'd like to constrain the syntax 
of Atom to accommodate its limitations and thereby enable a few 
implementors to save some time doing code generation. 
		
---------------------------------
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
--0-602170767-1089692752=:53669
Content-Type: text/html; charset=us-ascii

<P>More complete list of tools that behave better if XML is ordered in the XSD.</P>
<P>Ones that I've used...</P>
<OL>
<LI>XSD.exe - <A href="http://msdn.microsoft.com/library/en-us/cptools/html/cpconXMLSchemaDefinitionToolXsdexe.asp">http://msdn.microsoft.com/library/en-us/cptools/html/cpconXMLSchemaDefinitionToolXsdexe.asp</A></LI>
<LI>WSDL.exe - <A href="http://msdn.microsoft.com/library/en-us/cptools/html/cpgrfWebServicesDescriptionLanguageToolWsdlexe.asp">http://msdn.microsoft.com/library/en-us/cptools/html/cpgrfWebServicesDescriptionLanguageToolWsdlexe.asp</A></LI>
<LI>XMLSpy - <A href="http://www.altova.com/products_ide.html">http://www.altova.com/products_ide.html</A></LI>
<LI>VS.NET - <A href="http://msdn.microsoft.com/vstudio/">http://msdn.microsoft.com/vstudio/</A></LI>
<LI>Apache Axis - <A href="http://ws.apache.org/axis/">http://ws.apache.org/axis/</A></LI>
<LI>MSSOAP SDK - <A href="http://www.microsoft.com/downloads/details.aspx?FamilyId=C943C0DD-CEEC-4088-9753-86F052EC8450&amp;displaylang=en">http://www.microsoft.com/downloads/details.aspx?FamilyId=C943C0DD-CEEC-4088-9753-86F052EC8450&amp;displaylang=en</A></LI>
<LI>IBM SOAP4J - <A href="http://www.alphaworks.ibm.com/tech/soap4j/">http://www.alphaworks.ibm.com/tech/soap4j/</A></LI></OL>
<P>And others that I haven't used.</P>
<OL>
<LI>Code Generation Extensions - <A href="http://www.gotdotnet.com/Community/Workspaces/Workspace.aspx?id=80258a8c-bb4c-48e6-948b-05f6da568f55">http://www.gotdotnet.com/Community/Workspaces/Workspace.aspx?id=80258a8c-bb4c-48e6-948b-05f6da568f55</A></LI>
<LI>Castor&nbsp;Eclipse plugins - <A href="http://xdoclipse.sourceforge.net/">http://xdoclipse.sourceforge.net/</A></LI>
<LI>WSDL2Java Eclipse plugin - <A href="http://www.myspotter.com/wsdl2java.shtml">http://www.myspotter.com/wsdl2java.shtml</A></LI>
<LI>Novell's jBroker - <A href="http://www.novell.com/documentation/workbench41/docs/jbroker-web/docs/reference/tools/wsdl2java.html">http://www.novell.com/documentation/workbench41/docs/jbroker-web/docs/reference/tools/wsdl2java.html</A></LI>
<LI>Webmethods - <A href="http://www.webmethods.com/docs/glue/api/electric/wsdl/tools/WSDL2Java.html">http://www.webmethods.com/docs/glue/api/electric/wsdl/tools/WSDL2Java.html</A></LI></OL>
<P>Thanks and sorry about that last one,</P>
<P>Randy<BR><A href="http://www.kbcafe.com">http://www.kbcafe.com</A></P>
<P><BR><B><I>Mark Nottingham &lt;mnot@mnot.net&gt;</I></B> wrote:</P>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid"><BR>In other words, there are a minority of XML tools that rely upon a <BR>quirky, very limited and problematic expression of constraints upon XML <BR>-- i.e., XML Schema -- and therefore you'd like to constrain the syntax <BR>of Atom to accommodate its limitations and thereby enable a few <BR>implementors to save some time doing code generation. </BLOCKQUOTE><p>
		<hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/mail_us/taglines/aac/*http://promotions.yahoo.com/new_mail/static/ease.html">Yahoo! Mail Address AutoComplete</a> - You start. We finish.
--0-602170767-1089692752=:53669--



From owner-atom-syntax@mail.imc.org  Tue Jul 13 00:41: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 AAA25723
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 00:41: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 i6D4RgOl098873;
	Mon, 12 Jul 2004 21:27: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 i6D4RgH2098872;
	Mon, 12 Jul 2004 21:27:42 -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 i6D4Rf31098864
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 21:27:42 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p0611045dbd191470eb7d@[10.20.30.249]>
In-Reply-To: <BF01C6BC-D478-11D8-AE39-000A95A51C9E@sun.com>
References: 
 <32D5845A745BFB429CBDBADA57CD41AF08D6B39E@ussjex01.amer.bea.com>
 <52AC8A64-D44D-11D8-AE39-000A95A51C9E@sun.com>
 <3f1451f504071219302c2f1f98@mail.gmail.com>
 <BF01C6BC-D478-11D8-AE39-000A95A51C9E@sun.com>
Date: Mon, 12 Jul 2004 21:26:43 -0700
To: Atom Syntax <atom-syntax@imc.org>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: Version vs. Namespace
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:00 PM -0700 7/12/04, Tim Bray wrote:
>If we write Atom 1.0 with a clear guideline that the versioning 
>policy depends on future versions being well-ordered, it will be 
>clear to anyone who produces a later version that isn't that they 
>will be breaking Atom versioning.  Whereas nobody can prevent future 
>stupidity, it would seem a fairly unlikely scenario.

Lots of experience in the IETF reflects this reality. The better the 
version policy is described in the 1.0, the less likely it is that 
someone will do it wrong. The converse has even more examples, 
unfortunately.

>I think that linear version numbers plus MustIgnore hits a huge 
>80/20 point. -Tim

I would like to see this specifically shown against Mark's scenario 
list from earlier today.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Tue Jul 13 00:42: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 AAA25795
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 00:42: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 i6D4VOhZ099144;
	Mon, 12 Jul 2004 21:31: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 i6D4VOGS099143;
	Mon, 12 Jul 2004 21:31:24 -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 i6D4VN9W099124
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 21:31:23 -0700 (PDT)
	(envelope-from jasnell@us.ibm.com)
Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32])
	by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i6D4VNuc722358;
	Tue, 13 Jul 2004 00:31:23 -0400
Received: from d03nm122.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168])
	by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6D4VM33192034;
	Mon, 12 Jul 2004 22:31:22 -0600
In-Reply-To: <B55F9DFD-D482-11D8-9691-000A95BD86C0@mnot.net>
To: Mark Nottingham <mnot@mnot.net>
Cc: "[Atom]" <atom-syntax@imc.org>,
        Bill de =?ISO-8859-1?Q?h=D3ra?= <bill@dehora.net>,
        Mark Baker <distobj@acm.org>, owner-atom-syntax@mail.imc.org,
        Andreas Sewe <sewe@rbg.informatik.tu-darmstadt.de>
MIME-Version: 1.0
Subject: Re: Version vs. Namespace
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
From: James M Snell <jasnell@us.ibm.com>
X-MIMETrack: S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 09:31:04 PM,
	Serialize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 09:31:04 PM,
	Serialize complete at 07/12/2004 09:31:04 PM,
	Itemize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 09:31:04 PM,
	S/MIME Sign complete at 07/12/2004 09:31:04 PM,
	S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 09:31:17 PM,
	S/MIME Sign complete at 07/12/2004 09:31:17 PM,
	Serialize by Router on D03NM122/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at
 07/12/2004 22:31:22,
	Serialize complete at 07/12/2004 22:31:22
Message-ID: <OFE5434690.8209DC2F-ON88256ED0.0018BD94-88256ED0.0018D682@us.ibm.com>
Date: Mon, 12 Jul 2004 22:31:20 -0600
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z62067_boundary_sign
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>


This is an S/MIME signed message.

---------z62067_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 0018D12988256ED0_="

This is a multipart message in MIME format.
--=_alternative 0018D12988256ED0_=
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

owner-atom-syntax@mail.imc.org wrote on 07/12/2004 09:11:26 PM:

>=20
>=20
> On Jul 12, 2004, at 8:52 PM, Bill de h=D3ra wrote:
>=20
> > Well, thanks, but you're preaching to the choir. I have a history of=20
> > objection to RDF/XML.
>=20
> Always good to add to the multitude -- must be quite a sound by now!  ;)
>=20
> > But it remains a fact that RDF/XML enables this; and Atom does not.
>=20
> Aha; I see your point. Atom isn't final, so I don't think we can make=20
> such statements about it yet. If people seriously want to make Atom a=20
> one-shot, one-scenario spec (i.e., blogging/news feeds), we need to get=20
> consensus around that. I, for one, would object violently.
>

+1.  Atom needs to be usable across many different syndication apps
=20
> Cheers,
>=20
> --
> Mark Nottingham     http://www.mnot.net/
>=20
>=20


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

--=_alternative 0018D12988256ED0_=
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable


<br><font size=3D2><tt>owner-atom-syntax@mail.imc.org wrote on 07/12/2004
09:11:26 PM:<br>
<br>
&gt; <br>
&gt; <br>
&gt; On Jul 12, 2004, at 8:52 PM, Bill de h=D3ra wrote:<br>
&gt; <br>
&gt; &gt; Well, thanks, but you're preaching to the choir. I have a history
of <br>
&gt; &gt; objection to RDF/XML.<br>
&gt; <br>
&gt; Always good to add to the multitude -- must be quite a sound by now!
&nbsp;;)<br>
&gt; <br>
&gt; &gt; But it remains a fact that RDF/XML enables this; and Atom does
not.<br>
&gt; <br>
&gt; Aha; I see your point. Atom isn't final, so I don't think we can make
<br>
&gt; such statements about it yet. If people seriously want to make Atom
a <br>
&gt; one-shot, one-scenario spec (i.e., blogging/news feeds), we need to
get <br>
&gt; consensus around that. I, for one, would object violently.<br>
&gt;</tt></font>
<br>
<br><font size=3D2><tt>+1. &nbsp;Atom needs to be usable across many differ=
ent
syndication apps</tt></font>
<br><font size=3D2><tt>&nbsp;<br>
&gt; Cheers,<br>
&gt; <br>
&gt; --<br>
&gt; Mark Nottingham &nbsp; &nbsp; http://www.mnot.net/<br>
&gt; <br>
&gt; <br>
</tt></font>
<br>
<br><font size=3D2 face=3D"sans-serif">- James M Snell<br>
 &nbsp;jasnell@us.ibm.com<br>
 &nbsp;http://www.ibm.com<br>
 &nbsp;(877) 511-5082 / Office<br>
 &nbsp;930-1979 / Tie Line</font>
<br>
--=_alternative 0018D12988256ED0_=--

---------z62067_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIIUOAIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIISWDCCAtow
ggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1
aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAy
MDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA629xc49NpAPz
cAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7glzJKgPkPzlTZZfznznGbmAWVnNBQ
lyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnwNclOnnP2sKufuPzbTImQTTi5c8JZNZcM
J0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEEBAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1Ud
DgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAPBgNVHRMBAf8EBTADAQH/MDEGA1UdJQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUH
AwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvu
jQupk2oCScMd3FIHLE7hOfu8YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14ke
McF9ViNdewEoBGiAycUq8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIC2jCCAkOgAwIB
AgIDAxS2MA0GCSqGSIb3DQEBBAUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwMTE0MjIw
NzExWhcNMTExMjMxMjIwNzExWjBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25h
bCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrb3Fzj02kA/NwCy5KFMiY
tFgyTJ6kMSQLVSs9uwVHIAVkqy/enDQwZ9b/7uCXMkqA+Q/OVNll/OfOcZuYBZWc0FCXI9qw60KO
J/rTd65FdF4dwp8cw8si0qjOJtYg8cm46fA1yU6ec/awq5+4/NtMiZBNOLlzwlk1lwwnRgXNNwID
AQABo4GqMIGnMBEGCWCGSAGG+EIBAQQEAwIAhzAOBgNVHQ8BAf8EBAMCAcYwHQYDVR0OBBYEFK5U
DpLqqDOpKyQtx8hvMNze80pAMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMA8GA1Ud
EwEB/wQFMAMBAf8wMQYDVR0lBCowKAYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYB
BQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAMnJ7c2YLyrY/PKlFl+7sm8NENfWtFxqdm+6NC6mTagJJ
wx3cUgcsTuE5+7xh9+/G0tTfLzA1qZAQ5GNMPXvmoB9+vJfKnC2JWMFQpIOUEJDXiR4xwX1WI117
ASgEaIDJxSrxHcuuV/hMIO9bgZ6C41MUVmdLTKBgBOImTuIPK8QwggMgMIICiaADAgECAgQ13vTP
MA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQL
EyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0MTUxWhcN
MTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMk
RXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKKlQRkrPFr
U18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkwrFEeO68r
1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOgYaRfMF0x
CzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBD
ZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAxODA4MjIx
NjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAdBgNV
HQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0HQQAEDTAL
GwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwlMQ0AppJu
f7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn00DbOyZY
sih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMgMIICiaADAgEC
AgQ13vTPMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0
MTUxWhcNMTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsG
A1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKK
lQRkrPFrU18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkw
rFEeO68r1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOg
YaRfMF0xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNl
Y3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAx
ODA4MjIxNjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAdBgNVHQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0H
QQAEDTALGwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwl
MQ0AppJuf7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn
00DbOyZYsih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMmMIIC
j6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIxNjM2NTRaMIGFMQsw
CQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEXMBUGA1UEAxMOSmFt
ZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkqhkiG9w0BCQEWEmph
c25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwKpbDG3zMatEuuOT
FYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSyd+7nwqAvbBfPj+0S
vcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7tBJlLrwDRCMoNlPuQ
Kg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQW
BBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOgFAwSamFzbmVs
bEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pAMCcGA1UdJQQgMB4G
CCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAZMKevB7dFfb9
23OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY8BjwVHxiYgG4xkxf
B1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOIzj3lz3xd+uOzqRFg
/Wsg/VMwggMmMIICj6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAy
BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNV
BAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIx
NjM2NTRaMIGFMQswCQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEX
MBUGA1UEAxMOSmFtZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkq
hkiG9w0BCQEWEmphc25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
wKpbDG3zMatEuuOTFYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSy
d+7nwqAvbBfPj+0SvcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7t
BJlLrwDRCMoNlPuQKg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQD
AgXgMB0GA1UdDgQWBBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcU
AgOgFAwSamFzbmVsbEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA
MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQAD
gYEAZMKevB7dFfb923OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY
8BjwVHxiYgG4xkxfB1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOI
zj3lz3xd+uOzqRFg/Wsg/VMxggG7MIIBtwIBATBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJ
bnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0g
Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwF+kzAJBgUrDgMCGgUAoIGiMBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDcxMzA0MzEwNFowIwYJKoZIhvcNAQkEMRYE
FHc9QbTF+BTaIivQcUsGHHAKptVsMEMGCSqGSIb3DQEJDzE2MDQwBwYFKw4DAh0wDgYIKoZIhvcN
AwICAgCAMAoGCCqGSIb3DQMHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAa8KU+MvU
u6mgoFcP4pqrEG9CzUDu152A+/94p5q9MJgzEe2P59rGjichzXOignS3nV2Hsy6MBraXrpO/lo8m
+ekylWR0U54PDVA0FPZoq8yuMc5mZnVC7OMbJEY6P1nci++Ysjvrk6VBBHueUEREec1cHjxgB4yY
ta7EoxerRMAAAAAA

---------z62067_boundary_sign--



From owner-atom-syntax@mail.imc.org  Tue Jul 13 00: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 AAA25815
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 00:42: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 i6D4aq8M099990;
	Mon, 12 Jul 2004 21:36: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 i6D4aqeZ099989;
	Mon, 12 Jul 2004 21:36:52 -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 i6D4apD7099978
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 21:36:51 -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 i6D4ar53022225
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 23:36:53 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6D4aqRG022221;
	Mon, 12 Jul 2004 23:36:52 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: atom-syntax@imc.org
Subject: PaceFeedSignature: not cooked
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 12 Jul 2004 23:36:52 -0500
Message-ID: <m3n024mskb.fsf@bitsko.slc.ut.us>
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: <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.

Reviewing PaceFeedSignature[1] and rereading its thread[2], I believe
this Pace should not be incorporated, it's not cooked.

The thread never really discussed PaceFeedSignature (atom:security),
as it quickly moved into authentication issues and
PaceSecurityServices.

In <OF751A5D22.13EA3617-ON88256EBE.00539905-88256EBE.00542856@us.ibm.com>[3],
James Snell wrote:
> Atom security in general is something that needs to be discussed as
> part of the core.  If nothing else, in the core the security issues
> need to be covered and a plan for addressing those issues discussed.

The Atom specs do need Security Considerations sections, but
atom:security doesn't seem to propose or address anything that might
appear in such a section, largely because it makes no concrete
proposal for its use.

James followed up later in
<OF12626D58.C597B6FA-ON88256EBE.0057E1FF-88256EBE.00585720@us.ibm.com>[4]:
> I have no problem, however, with content encryption and integrity
> being pushed off into a separate RFC as long as it is as least
> discussed and considered as a requirement.

I agree with this in principle and would suggest a new Pace for it.

I believe PaceFeedSignature should be closed (incomplete) or should go
back into the pile until it contains something that specs or
references some use(s) that are implementable and testable.

  -- Ken

[1] http://intertwingly.net/wiki/pie/PaceFeedSignature
[2] http://imc.org/atom-syntax/mail-archive/msg05684.html
  Currently contained wholly on the "second" by-thread index page, if
  that helps scanning the messages.
[3] http://imc.org/atom-syntax/mail-archive/msg05723.html
[4] http://imc.org/atom-syntax/mail-archive/msg05726.html



From owner-atom-syntax@mail.imc.org  Tue Jul 13 00:43:09 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25856
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 00: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 i6D4STJN098934;
	Mon, 12 Jul 2004 21:28: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 i6D4STMZ098933;
	Mon, 12 Jul 2004 21:28:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D4ST6B098914;
	Mon, 12 Jul 2004 21:28:29 -0700 (PDT)
	(envelope-from jasnell@us.ibm.com)
Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32])
	by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i6D4SUtf377336;
	Tue, 13 Jul 2004 00:28:30 -0400
Received: from d03nm122.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168])
	by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6D4ST33170828;
	Mon, 12 Jul 2004 22:28:30 -0600
In-Reply-To: <OF4F886155.F631270A-ON88256ED0.001525E6-88256ED0.001622F9@us.ibm.com>
To: James M Snell <jasnell@us.ibm.com>
Cc: Atom WG <atom-syntax@imc.org>, owner-atom-syntax@mail.imc.org,
        Paul Hoffman / IMC <phoffman@imc.org>
MIME-Version: 1.0
Subject: Re: Usage Scenarios for Versioning and Extensibility
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
From: James M Snell <jasnell@us.ibm.com>
X-MIMETrack: S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 09:28:14 PM,
	Serialize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 09:28:14 PM,
	Serialize complete at 07/12/2004 09:28:14 PM,
	Itemize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 09:28:14 PM,
	S/MIME Sign complete at 07/12/2004 09:28:14 PM,
	S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/12/2004 09:28:25 PM,
	S/MIME Sign complete at 07/12/2004 09:28:25 PM,
	Serialize by Router on D03NM122/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at
 07/12/2004 22:28:30,
	Serialize complete at 07/12/2004 22:28:30
Message-ID: <OF2173B8AB.E4DB185F-ON88256ED0.0018149D-88256ED0.00189309@us.ibm.com>
Date: Mon, 12 Jul 2004 22:28:27 -0600
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z34996_boundary_sign
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>


This is an S/MIME signed message.

---------z34996_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 00188EE588256ED0_="

This is a multipart message in MIME format.
--=_alternative 00188EE588256ED0_=
Content-Type: text/plain; charset="US-ASCII"

owner-atom-syntax@mail.imc.org wrote on 07/12/2004 09:01:49 PM:

> 
> owner-atom-syntax@mail.imc.org wrote on 07/12/2004 06:03:25 PM:
> 
> > 
> > At 5:14 PM -0700 7/12/04, Mark Nottingham wrote:
> > >0) Let's imagine that Atom 1.0 has been released and finalised in 
> > >all of its glory.
> > >
> > >1) And it was good... except for that nasty atom:title element; 
> > >after wide deployment experience, it's agreed we need a new version 
> > >of it. So, a new version of Atom is introduced. The new one isn't 
> > >backwards-compatible with the old one.
> > >
> > >2) Then, we decide we want to add a new metadata element, let's call 
> > >it "fog." So, a new version of Atom is introduced.
> > >
> > >3) After a while, someone comes up with a souped-up version of 
> > >atom:title that is backwards-compatible, just *better*. It gets 
> > >really popular, and yet another version of Atom is born.
> > >
> > >4) At the same time, a group of rogue Open Source Software 
> > >programmers descends upon this idyllic scene and introduces its own 
> > >extensions. Up until now, all of our extensions have been approved 
> > >and incorporated by the WG, but these are destined to remain 
> > >separate.
> > >
> > >5) Finally, in 2010, we realise that the Atom feed and entry 
> > >containers aren't really doing the job, and we need to change their 
> > >model. Yet Another Version of Atom (YAVA) comes into being.
> > >
> > >Any proposal for versioning should address at least these 
> > >situations, show how the various extensions and changes are 
> > >identified and disambiguated, and should explain how software is to 
> > >handle them. They should also consider how combinations of these 
> > >scenarios are handled.
> > 
> > +1 or more. This is an excellent mix and not at all far-fetched. It 
> > should help us focus on what we need for versioning and extensibility.
> > 
> > --Paul Hoffman, Director
> > --Internet Mail Consortium
> > 
> 
> Agreed.  Fundamentally, the first and foremost thing that we should 
> focus on is determining how difficult this WG wants to make it to 
> allow such changes to occur and whether or not changes should be 
> defined so that they are backwards compatible.  I do not believe it 
> would be too far fetched for this group to assert that changes 
> should be absolutely backwards compatible unless it can be 
> demonstrated that the a breaking change is absolutely required. 
> Let's set the bar high right from the beginning. 
> 
> Regarding #2, introducing an "extension namespace" where such new 
> elements can be defined, experimented with, implementation 
> practice/experience gained, etc, would greatly enhance the process. 
> When a new element is proposed, it would be put into the extension 
> namespace initially.  Only after it has been implemented and folks 
> agree that it is essential to have as part of the core would it be 
> placed under the core namespace. 
> 
> Regarding #4, allow people to come up with whatever extension 
> elements they wish in their own namespace and define that all 
> elements in unknown namespaces are to be summarily ignored and 
> dismissed.  If the creators of those extensions wish to define a 
> profile for their use, let them go through the work of writing up an
> RFC that describes the appropriate semantics.  Once the RFC is 
> published, Aggregators and other apps can choose whether or not to 
> support that RFC. 
> 

You know, after going back and reading this and reading the rest of the 
thread, I retract part of this.  The use of the MustUnderstand attribute 
is a far better approach.  I would, however, definitely like to see a 
tiered approach to changes made to the core namespace.

<atom:feed xmlns:atom="..." xmlns:atomex="...">
  <atom:title>...</atom:title>
  <atomex:core-extension atom:MustUnderstand="true" />
  <abc:other-extension atom:MustUnderstand="false" />
</atom:feed>

The creation and modification of elements in the abc namespace are 
arbitrary.  Anybody can do that any time they wish.

The creation and modification of elements in the atomex namespace would 
require that an RFC be submitted to this working group.  As long as the 
RFC has been published and is available for discussion, the element can 
automatically go into the atomex namespace.

The creation and modification of elements in the atom namespace would 
require first that the changes be defined within the atomex namespace 
(e.g. have an RFC submitted) and have achieved consensus within this WG 
that the changes are critical to the core spec.

Following this approach *should* help to mitigate the types of issues 
enumerated above.

> Whether or not Atom's versioning of the core spec gets out of 
> control is more a function of this groups philosophy towards 
> accepting changes of dubious or unproven utility. 
> 
> 
> - James M Snell
>  jasnell@us.ibm.com
>  http://www.ibm.com
>  (877) 511-5082 / Office
>  930-1979 / Tie Line 
--=_alternative 00188EE588256ED0_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>owner-atom-syntax@mail.imc.org wrote on 07/12/2004
09:01:49 PM:<br>
<br>
&gt; <br>
&gt; owner-atom-syntax@mail.imc.org wrote on 07/12/2004 06:03:25 PM:<br>
&gt; <br>
&gt; &gt; <br>
&gt; &gt; At 5:14 PM -0700 7/12/04, Mark Nottingham wrote:<br>
&gt; &gt; &gt;0) Let's imagine that Atom 1.0 has been released and finalised
in <br>
&gt; &gt; &gt;all of its glory.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;1) And it was good... except for that nasty atom:title element;
<br>
&gt; &gt; &gt;after wide deployment experience, it's agreed we need a new
version <br>
&gt; &gt; &gt;of it. So, a new version of Atom is introduced. The new one
isn't <br>
&gt; &gt; &gt;backwards-compatible with the old one.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;2) Then, we decide we want to add a new metadata element,
let's call <br>
&gt; &gt; &gt;it &quot;fog.&quot; So, a new version of Atom is introduced.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;3) After a while, someone comes up with a souped-up version
of <br>
&gt; &gt; &gt;atom:title that is backwards-compatible, just *better*. It
gets <br>
&gt; &gt; &gt;really popular, and yet another version of Atom is born.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;4) At the same time, a group of rogue Open Source Software
<br>
&gt; &gt; &gt;programmers descends upon this idyllic scene and introduces
its own <br>
&gt; &gt; &gt;extensions. Up until now, all of our extensions have been
approved <br>
&gt; &gt; &gt;and incorporated by the WG, but these are destined to remain
<br>
&gt; &gt; &gt;separate.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;5) Finally, in 2010, we realise that the Atom feed and entry
<br>
&gt; &gt; &gt;containers aren't really doing the job, and we need to change
their <br>
&gt; &gt; &gt;model. Yet Another Version of Atom (YAVA) comes into being.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;Any proposal for versioning should address at least these
<br>
&gt; &gt; &gt;situations, show how the various extensions and changes are
<br>
&gt; &gt; &gt;identified and disambiguated, and should explain how software
is to <br>
&gt; &gt; &gt;handle them. They should also consider how combinations of
these <br>
&gt; &gt; &gt;scenarios are handled.<br>
&gt; &gt; <br>
&gt; &gt; +1 or more. This is an excellent mix and not at all far-fetched.
It <br>
&gt; &gt; should help us focus on what we need for versioning and extensibility.<br>
&gt; &gt; <br>
&gt; &gt; --Paul Hoffman, Director<br>
&gt; &gt; --Internet Mail Consortium<br>
&gt; &gt; <br>
&gt; <br>
&gt; Agreed. &nbsp;Fundamentally, the first and foremost thing that we
should <br>
&gt; focus on is determining how difficult this WG wants to make it to
<br>
&gt; allow such changes to occur and whether or not changes should be <br>
&gt; defined so that they are backwards compatible. &nbsp;I do not believe
it <br>
&gt; would be too far fetched for this group to assert that changes <br>
&gt; should be absolutely backwards compatible unless it can be <br>
&gt; demonstrated that the a breaking change is absolutely required. &nbsp;<br>
&gt; Let's set the bar high right from the beginning. <br>
&gt; <br>
&gt; Regarding #2, introducing an &quot;extension namespace&quot; where
such new <br>
&gt; elements can be defined, experimented with, implementation <br>
&gt; practice/experience gained, etc, would greatly enhance the process.
<br>
&gt; When a new element is proposed, it would be put into the extension
<br>
&gt; namespace initially. &nbsp;Only after it has been implemented and
folks <br>
&gt; agree that it is essential to have as part of the core would it be
<br>
&gt; placed under the core namespace. <br>
&gt; <br>
&gt; Regarding #4, allow people to come up with whatever extension <br>
&gt; elements they wish in their own namespace and define that all <br>
&gt; elements in unknown namespaces are to be summarily ignored and <br>
&gt; dismissed. &nbsp;If the creators of those extensions wish to define
a <br>
&gt; profile for their use, let them go through the work of writing up
an<br>
&gt; RFC that describes the appropriate semantics. &nbsp;Once the RFC is
<br>
&gt; published, Aggregators and other apps can choose whether or not to
<br>
&gt; support that RFC. <br>
&gt; </tt></font>
<br>
<br><font size=2><tt>You know, after going back and reading this and reading
the rest of the thread, I retract part of this. &nbsp;The use of the MustUnderstand
attribute is a far better approach. &nbsp;I would, however, definitely
like to see a tiered approach to changes made to the core namespace.</tt></font>
<br>
<br><font size=2><tt>&lt;atom:feed xmlns:atom=&quot;...&quot; xmlns:atomex=&quot;...&quot;&gt;</tt></font>
<br><font size=2><tt>&nbsp; &lt;atom:title&gt;...&lt;/atom:title&gt;</tt></font>
<br><font size=2><tt>&nbsp; &lt;atomex:core-extension atom:MustUnderstand=&quot;true&quot;
/&gt;</tt></font>
<br><font size=2><tt>&nbsp; &lt;abc:other-extension atom:MustUnderstand=&quot;false&quot;
/&gt;</tt></font>
<br><font size=2><tt>&lt;/atom:feed&gt;</tt></font>
<br>
<br><font size=2><tt>The creation and modification of elements in the abc
namespace are arbitrary. &nbsp;Anybody can do that any time they wish.</tt></font>
<br>
<br><font size=2><tt>The creation and modification of elements in the atomex
namespace would require that an RFC be submitted to this working group.
&nbsp;As long as the RFC has been published and is available for discussion,
the element can automatically go into the atomex namespace.</tt></font>
<br>
<br><font size=2><tt>The creation and modification of elements in the atom
namespace would require first that the changes be defined within the atomex
namespace (e.g. have an RFC submitted) and have achieved consensus within
this WG that the changes are critical to the core spec.</tt></font>
<br>
<br><font size=2><tt>Following this approach *should* help to mitigate
the types of issues enumerated above.</tt></font>
<br><font size=2><tt><br>
&gt; Whether or not Atom's versioning of the core spec gets out of <br>
&gt; control is more a function of this groups philosophy towards <br>
&gt; accepting changes of dubious or unproven utility. <br>
&gt; <br>
&gt; <br>
&gt; - James M Snell<br>
&gt; &nbsp;jasnell@us.ibm.com<br>
&gt; &nbsp;http://www.ibm.com<br>
&gt; &nbsp;(877) 511-5082 / Office<br>
&gt; &nbsp;930-1979 / Tie Line </tt></font>
--=_alternative 00188EE588256ED0_=--

---------z34996_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIIUOAIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIISWDCCAtow
ggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1
aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAy
MDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA629xc49NpAPz
cAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7glzJKgPkPzlTZZfznznGbmAWVnNBQ
lyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnwNclOnnP2sKufuPzbTImQTTi5c8JZNZcM
J0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEEBAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1Ud
DgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAPBgNVHRMBAf8EBTADAQH/MDEGA1UdJQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUH
AwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvu
jQupk2oCScMd3FIHLE7hOfu8YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14ke
McF9ViNdewEoBGiAycUq8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIC2jCCAkOgAwIB
AgIDAxS2MA0GCSqGSIb3DQEBBAUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwMTE0MjIw
NzExWhcNMTExMjMxMjIwNzExWjBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25h
bCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrb3Fzj02kA/NwCy5KFMiY
tFgyTJ6kMSQLVSs9uwVHIAVkqy/enDQwZ9b/7uCXMkqA+Q/OVNll/OfOcZuYBZWc0FCXI9qw60KO
J/rTd65FdF4dwp8cw8si0qjOJtYg8cm46fA1yU6ec/awq5+4/NtMiZBNOLlzwlk1lwwnRgXNNwID
AQABo4GqMIGnMBEGCWCGSAGG+EIBAQQEAwIAhzAOBgNVHQ8BAf8EBAMCAcYwHQYDVR0OBBYEFK5U
DpLqqDOpKyQtx8hvMNze80pAMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMA8GA1Ud
EwEB/wQFMAMBAf8wMQYDVR0lBCowKAYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYB
BQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAMnJ7c2YLyrY/PKlFl+7sm8NENfWtFxqdm+6NC6mTagJJ
wx3cUgcsTuE5+7xh9+/G0tTfLzA1qZAQ5GNMPXvmoB9+vJfKnC2JWMFQpIOUEJDXiR4xwX1WI117
ASgEaIDJxSrxHcuuV/hMIO9bgZ6C41MUVmdLTKBgBOImTuIPK8QwggMgMIICiaADAgECAgQ13vTP
MA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQL
EyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0MTUxWhcN
MTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMk
RXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKKlQRkrPFr
U18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkwrFEeO68r
1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOgYaRfMF0x
CzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBD
ZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAxODA4MjIx
NjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAdBgNV
HQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0HQQAEDTAL
GwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwlMQ0AppJu
f7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn00DbOyZY
sih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMgMIICiaADAgEC
AgQ13vTPMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0
MTUxWhcNMTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsG
A1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKK
lQRkrPFrU18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkw
rFEeO68r1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOg
YaRfMF0xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNl
Y3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAx
ODA4MjIxNjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAdBgNVHQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0H
QQAEDTALGwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwl
MQ0AppJuf7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn
00DbOyZYsih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMmMIIC
j6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIxNjM2NTRaMIGFMQsw
CQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEXMBUGA1UEAxMOSmFt
ZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkqhkiG9w0BCQEWEmph
c25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwKpbDG3zMatEuuOT
FYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSyd+7nwqAvbBfPj+0S
vcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7tBJlLrwDRCMoNlPuQ
Kg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQW
BBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOgFAwSamFzbmVs
bEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pAMCcGA1UdJQQgMB4G
CCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAZMKevB7dFfb9
23OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY8BjwVHxiYgG4xkxf
B1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOIzj3lz3xd+uOzqRFg
/Wsg/VMwggMmMIICj6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAy
BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNV
BAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIx
NjM2NTRaMIGFMQswCQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEX
MBUGA1UEAxMOSmFtZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkq
hkiG9w0BCQEWEmphc25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
wKpbDG3zMatEuuOTFYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSy
d+7nwqAvbBfPj+0SvcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7t
BJlLrwDRCMoNlPuQKg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQD
AgXgMB0GA1UdDgQWBBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcU
AgOgFAwSamFzbmVsbEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA
MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQAD
gYEAZMKevB7dFfb923OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY
8BjwVHxiYgG4xkxfB1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOI
zj3lz3xd+uOzqRFg/Wsg/VMxggG7MIIBtwIBATBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJ
bnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0g
Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwF+kzAJBgUrDgMCGgUAoIGiMBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDcxMzA0MjgxNFowIwYJKoZIhvcNAQkEMRYE
FNwxAgt8zzuUTBc+KfXdejQyTTw3MEMGCSqGSIb3DQEJDzE2MDQwBwYFKw4DAh0wDgYIKoZIhvcN
AwICAgCAMAoGCCqGSIb3DQMHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAEZGMktSS
7qSa1EiWzmpOtfO3KdQOgKz8ZfbmHgT686FJW4WXKTRngok7K1nc5SCgm7f1roUNgQD5jJlvxRf1
4+SN9i8I249SpUBkWwfBBv4UAu/jv/TkkCj/uM3IydCbqmTlFOUoRw4ucqxSBQRFbXa+/fwGJUzD
0dywvBeUb/sAAAAA

---------z34996_boundary_sign--



From owner-atom-syntax@mail.imc.org  Tue Jul 13 00:44:36 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25944
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 00:44: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 i6D4ZlnI099908;
	Mon, 12 Jul 2004 21:35:47 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6D4ZlcD099907;
	Mon, 12 Jul 2004 21:35:47 -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 i6D4Zl7f099898
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 21:35:47 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.19] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id 78CB4727D; Mon, 12 Jul 2004 21:35:52 -0700 (PDT)
In-Reply-To: <OF3AD386E0.E58B109C-ON88256ED0.0016F9E5-88256ED0.001748DA@us.ibm.com>
References: <OF3AD386E0.E58B109C-ON88256ED0.0016F9E5-88256ED0.001748DA@us.ibm.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <1F2F492A-D486-11D8-9691-000A95BD86C0@mnot.net>
Cc: Atom Syntax <atom-syntax@imc.org>, Norman Walsh <ndw@nwalsh.com>
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: Version vs. Namespace
Date: Mon, 12 Jul 2004 21:35:52 -0700
To: James M Snell <jasnell@us.ibm.com>
X-Mailer: Apple Mail (2.618)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6D4Zl7f099902
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 Jul 12, 2004, at 9:14 PM, James M Snell wrote:
>
> By all means, create all the extensions you want... *in their own 
> namespace or in an extension namespace*.  I'm all for that and 
> defining a "MustUnderstand" attribute for these elements.  What I draw 
> the line at, however, is changes being made willy-nilly within the 
> core namespace.  The core should only rarely ever be changed.

Totally agreed; the WG owns the Atom NS, and is the only entity that 
can change it or introduce new things into it.

I had taken this for granted; apologies if it wasn't explicit. The 
question I've been revolving around is what mechanisms/stubs we give to 
people who are designing their own extensions (e.g., mustUnderstand) 
and usage scenarios (e.g., profiling).

Cheers,

--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org  Tue Jul 13 01:06: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 BAA27220
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 01:06: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 i6D4tgGO001294;
	Mon, 12 Jul 2004 21: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 i6D4tgfe001293;
	Mon, 12 Jul 2004 21:55:42 -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 i6D4tejX001286
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 21:55:41 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p0611045fbd191ba69c0b@[10.20.30.249]>
In-Reply-To: <m3n024mskb.fsf@bitsko.slc.ut.us>
References: <m3n024mskb.fsf@bitsko.slc.ut.us>
Date: Mon, 12 Jul 2004 21:56:10 -0700
To: atom-syntax@imc.org
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: PaceFeedSignature: not cooked
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>


-1 (or +1 to not cooked)

I think we would be better off re-using XMLDigSig on whole root 
objects than inventing our own signature mechanism or trying to allow 
little bits to be signed.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Tue Jul 13 01:13: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 BAA27636
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 01:13: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 i6D4uNkH001336;
	Mon, 12 Jul 2004 21: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 i6D4uNju001335;
	Mon, 12 Jul 2004 21:56:23 -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 i6D4uNGL001329
	for <atom-syntax@imc.org>; Mon, 12 Jul 2004 21:56:23 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.19] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id 658D3727D; Mon, 12 Jul 2004 21:56:30 -0700 (PDT)
In-Reply-To: <20040713042552.55133.qmail@web41502.mail.yahoo.com>
References: <20040713042552.55133.qmail@web41502.mail.yahoo.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
Message-Id: <00DADF42-D489-11D8-9691-000A95BD86C0@mnot.net>
Cc: Atomlist <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: Re: PaceElementOrder: options 
Date: Mon, 12 Jul 2004 21:56:29 -0700
To: randy@kbcafe.com
X-Mailer: Apple Mail (2.618)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6D4uNGL001330
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 Jul 12, 2004, at 9:25 PM, Randy Charles Morin wrote:

> 	1.  	XSD.exe -  
> http://msdn.microsoft.com/library/en-us/cptools/html/ 
> cpconXMLSchemaDefinitionToolXsdexe.asp
> 	2.  	WSDL.exe -  
> http://msdn.microsoft.com/library/en-us/cptools/html/ 
> cpgrfWebServicesDescriptionLanguageToolWsdlexe.asp
> 	3.  	XMLSpy - http://www.altova.com/products_ide.html
> 	4.  	VS.NET - http://msdn.microsoft.com/vstudio/
> 	5.  	Apache Axis - http://ws.apache.org/axis/
> 	6.  	MSSOAP SDK -  
> http://www.microsoft.com/downloads/details.aspx?FamilyId=C943C0DD- 
> CEEC-4088-9753-86F052EC8450&displaylang=en
> 	7.  	IBM SOAP4J - http://www.alphaworks.ibm.com/tech/soap4j/
>
> And others that I haven't used.
> 	1.  	Code Generation Extensions -  
> http://www.gotdotnet.com/Community/Workspaces/Workspace.aspx? 
> id=80258a8c-bb4c-48e6-948b-05f6da568f55
> 	2.  	Castor Eclipse plugins - http://xdoclipse.sourceforge.net/
> 	3.  	WSDL2Java Eclipse plugin -  
> http://www.myspotter.com/wsdl2java.shtml
> 	4.  	Novell's jBroker -  
> http://www.novell.com/documentation/workbench41/docs/jbroker-web/docs/ 
> reference/tools/wsdl2java.html
> 	5.  	Webmethods -  
> http://www.webmethods.com/docs/glue/api/electric/wsdl/tools/ 
> WSDL2Java.html

OK, that's a good list.

Tell me if I've got this right -- if we don't have any ordering, these  
tools will not be able to automatically generate code that understands  
the cardinality of atom elements; e.g., "MUST have only one title,"  
"MAY have up to three content sections" (I made these up). However,  
they will still be able to generate some code; it's just that any  
consideration of cardinality will have to be hand-coded in.

Are there any other semantically significant things that such a  
decision would disable Schema from describing?

Looking at that case, how would an implementation use that information,  
except through validation? I.e., would the cardinality information from  
the schema ever actually get used by an aggregator? If so, how?

 From the other side, the major problem I've heard is that ordering is  
hard to remember, and may cause more instances to be invalid. From my  
experience, this is true; it's annoying when a metadata-oriented  
application requires you to put elements in an order, even though it  
isn't meaningful. It isn't the end of the world, of course, because  
people will have references, validators, etc.

Are there any other downsides to ordering? I will grant that part of my  
motivation is a) a visceral and growing dislike of XML Schema and b) a  
perhaps-too-pedantic belief that ordering, when required, should be  
semantically significant. Let's leave those to the side.

My take is this: it's about programmer efficiency -- not capability --  
vs. ease *and* correctness of authoring. Considering that programmers  
are a) a smaller and more knowledgeable population, and b) they program  
it once, while authoring is a continual process, my leaning is towards  
unordered elements in Atom.

The fact that a good, solid Atom library that handles this stuff  
automagically will remove the burden from the programmer is what  
cemented it for me. That does require such a library to be built, while  
the libraries above are already existant, but I suspect people are  
going to build some good Atom libraries anyway, because there's a lot  
that Schema can't capture, no matter what we do.

> Thanks and sorry about that last one,

Not at all - there's heat here (on all sides, I think), but light as  
well (ditto), and I for one don't mind a bit of give-and-take if it  
gets us closer to the answer. I assumed you were of a like mind -- a  
complement, I hope :)

--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org  Tue Jul 13 02:12: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 CAA11798
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 02:12: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 i6D5wiCG013347;
	Mon, 12 Jul 2004 22:58: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 i6D5wiZ2013346;
	Mon, 12 Jul 2004 22:58:44 -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 i6D5whJ1013298;
	Mon, 12 Jul 2004 22:58:43 -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 i6D5wh413503;
	Mon, 12 Jul 2004 22:58:43 -0700 (PDT)
Received: from aol.net ([10.169.192.58]) by judge.mcom.com
          (Netscape Messaging Server 4.15) with ESMTP id I0S0LV03.20O;
          Mon, 12 Jul 2004 22:58:43 -0700 
Message-ID: <40F37A14.6040908@aol.net>
Date: Mon, 12 Jul 2004 22:58:44 -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: Paul Hoffman / IMC <phoffman@imc.org>
CC: Atom WG <atom-syntax@imc.org>
Subject: Re: PaceSecurityServices
References: <40E16215.6070507@intertwingly.net> <40EC9915.4050406@intertwingly.net> <3f1451f504070718267c5526b4@mail.gmail.com> <40ED6392.2000107@franklinmint.fm> <3f1451f504070810104a5122e7@mail.gmail.com> <3f1451f504070810296ca252e7@mail.gmail.com> <p0611044fbd18e903bdd9@[10.20.30.249]>
In-Reply-To: <p0611044fbd18e903bdd9@[10.20.30.249]>
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


Paul Hoffman / IMC wrote:

>
> OK, I'm seeing a trend here and want to check. It sounds like people 
> agree that we want Digest Auth as a SHOULD (not a MUST), not to give a 
> SHOULD for the WSSE-like mechanism, and not to describe it in the core 
> protocol document. Does that sound right?

PaceSecurityServices says currently that one of {HTTP Digest, WSSE-style 
authentication} MUST be supported.

I'm neutral on WSSE, so +1 to removing WSSE on grounds of reduced 
complexity.

I am uncertain about making Digest Auth a SHOULD rather than a MUST.  
What's the reason for leaving the wriggle room?

-John Panzer






From owner-atom-syntax@mail.imc.org  Tue Jul 13 04:26: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 EAA21069
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 04:26:39 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D7xuuI043944;
	Tue, 13 Jul 2004 00:59: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 i6D7xus6043942;
	Tue, 13 Jul 2004 00:59:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web41506.mail.yahoo.com (web41506.mail.yahoo.com [66.218.93.89])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6D7xtKt043908
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 00:59:55 -0700 (PDT)
	(envelope-from randymorin@yahoo.com)
Message-ID: <20040713075950.79777.qmail@web41506.mail.yahoo.com>
Received: from [24.43.182.164] by web41506.mail.yahoo.com via HTTP; Tue, 13 Jul 2004 00:59:50 PDT
Date: Tue, 13 Jul 2004 00:59:50 -0700 (PDT)
From: Randy Charles Morin <randymorin@yahoo.com>
Reply-To: randy@kbcafe.com
Subject: Re: PaceElementOrder: options 
To: Mark Nottingham <mnot@mnot.net>, randy@kbcafe.com
Cc: Atomlist <atom-syntax@imc.org>
In-Reply-To: <00DADF42-D489-11D8-9691-000A95BD86C0@mnot.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-2039816877-1089705590=:78210"
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>


--0-2039816877-1089705590=:78210
Content-Type: text/plain; charset=us-ascii

I think we've put all the cards on the table and we come to a choice. Not that this choice isn't already made or needs to be made.

   Order the elements because it will help some tools do a better job.
   Don't order the elements because it's more difficult.

Agreed? Everything else seems to be just argumentative.
Thanks,

Randy
http://www.kbcafe.com

 

Mark Nottingham <mnot@mnot.net> wrote:

On Jul 12, 2004, at 9:25 PM, Randy Charles Morin wrote:

> 1. XSD.exe - 
> http://msdn.microsoft.com/library/en-us/cptools/html/ 
> cpconXMLSchemaDefinitionToolXsdexe.asp
> 2. WSDL.exe - 
> http://msdn.microsoft.com/library/en-us/cptools/html/ 
> cpgrfWebServicesDescriptionLanguageToolWsdlexe.asp
> 3. XMLSpy - http://www.altova.com/products_ide.html
> 4. VS.NET - http://msdn.microsoft.com/vstudio/
> 5. Apache Axis - http://ws.apache.org/axis/
> 6. MSSOAP SDK - 
> http://www.microsoft.com/downloads/details.aspx?FamilyId=C943C0DD- 
> CEEC-4088-9753-86F052EC8450&displaylang=en
> 7. IBM SOAP4J - http://www.alphaworks.ibm.com/tech/soap4j/
>
> And others that I haven't used.
> 1. Code Generation Extensions - 
> http://www.gotdotnet.com/Community/Workspaces/Workspace.aspx? 
> id=80258a8c-bb4c-48e6-948b-05f6da568f55
> 2. Castor Eclipse plugins - http://xdoclipse.sourceforge.net/
> 3. WSDL2Java Eclipse plugin - 
> http://www.myspotter.com/wsdl2java.shtml
> 4. Novell's jBroker - 
> http://www.novell.com/documentation/workbench41/docs/jbroker-web/docs/ 
> reference/tools/wsdl2java.html
> 5. Webmethods - 
> http://www.webmethods.com/docs/glue/api/electric/wsdl/tools/ 
> WSDL2Java.html

OK, that's a good list.

Tell me if I've got this right -- if we don't have any ordering, these 
tools will not be able to automatically generate code that understands 
the cardinality of atom elements; e.g., "MUST have only one title," 
"MAY have up to three content sections" (I made these up). However, 
they will still be able to generate some code; it's just that any 
consideration of cardinality will have to be hand-coded in.

Are there any other semantically significant things that such a 
decision would disable Schema from describing?

Looking at that case, how would an implementation use that information, 
except through validation? I.e., would the cardinality information from 
the schema ever actually get used by an aggregator? If so, how?

From the other side, the major problem I've heard is that ordering is 
hard to remember, and may cause more instances to be invalid. From my 
experience, this is true; it's annoying when a metadata-oriented 
application requires you to put elements in an order, even though it 
isn't meaningful. It isn't the end of the world, of course, because 
people will have references, validators, etc.

Are there any other downsides to ordering? I will grant that part of my 
motivation is a) a visceral and growing dislike of XML Schema and b) a 
perhaps-too-pedantic belief that ordering, when required, should be 
semantically significant. Let's leave those to the side.

My take is this: it's about programmer efficiency -- not capability -- 
vs. ease *and* correctness of authoring. Considering that programmers 
are a) a smaller and more knowledgeable population, and b) they program 
it once, while authoring is a continual process, my leaning is towards 
unordered elements in Atom.

The fact that a good, solid Atom library that handles this stuff 
automagically will remove the burden from the programmer is what 
cemented it for me. That does require such a library to be built, while 
the libraries above are already existant, but I suspect people are 
going to build some good Atom libraries anyway, because there's a lot 
that Schema can't capture, no matter what we do.

> Thanks and sorry about that last one,

Not at all - there's heat here (on all sides, I think), but light as 
well (ditto), and I for one don't mind a bit of give-and-take if it 
gets us closer to the answer. I assumed you were of a like mind -- a 
complement, I hope :)

--
Mark Nottingham http://www.mnot.net/


		
---------------------------------
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
--0-2039816877-1089705590=:78210
Content-Type: text/html; charset=us-ascii

<DIV>I think we've put all the cards on the table and we come to a choice. Not that this choice isn't already made or needs to be made.</DIV>
<UL>
<LI>Order the elements because it will help some tools do a better job.</LI>
<LI>Don't order the elements because it's more difficult.</LI></UL>
<P>Agreed? Everything else seems to be just argumentative.<BR>Thanks,</P>
<P>Randy<BR><A href="http://www.kbcafe.com">http://www.kbcafe.com</A></P>
<P>&nbsp;</P>
<P><B><I>Mark Nottingham &lt;mnot@mnot.net&gt;</I></B> wrote:</P>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid"><BR>On Jul 12, 2004, at 9:25 PM, Randy Charles Morin wrote:<BR><BR>&gt; 1. XSD.exe - <BR>&gt; http://msdn.microsoft.com/library/en-us/cptools/html/ <BR>&gt; cpconXMLSchemaDefinitionToolXsdexe.asp<BR>&gt; 2. WSDL.exe - <BR>&gt; http://msdn.microsoft.com/library/en-us/cptools/html/ <BR>&gt; cpgrfWebServicesDescriptionLanguageToolWsdlexe.asp<BR>&gt; 3. XMLSpy - http://www.altova.com/products_ide.html<BR>&gt; 4. VS.NET - http://msdn.microsoft.com/vstudio/<BR>&gt; 5. Apache Axis - http://ws.apache.org/axis/<BR>&gt; 6. MSSOAP SDK - <BR>&gt; http://www.microsoft.com/downloads/details.aspx?FamilyId=C943C0DD- <BR>&gt; CEEC-4088-9753-86F052EC8450&amp;displaylang=en<BR>&gt; 7. IBM SOAP4J - http://www.alphaworks.ibm.com/tech/soap4j/<BR>&gt;<BR>&gt; And others that I haven't used.<BR>&gt; 1. Code Generation Extensions - <BR>&gt; http://www.gotdotnet.com/Community/Workspaces/Workspace.aspx?
 <BR>&gt; id=80258a8c-bb4c-48e6-948b-05f6da568f55<BR>&gt; 2. Castor&nbsp;Eclipse plugins - http://xdoclipse.sourceforge.net/<BR>&gt; 3. WSDL2Java Eclipse plugin - <BR>&gt; http://www.myspotter.com/wsdl2java.shtml<BR>&gt; 4. Novell's jBroker - <BR>&gt; http://www.novell.com/documentation/workbench41/docs/jbroker-web/docs/ <BR>&gt; reference/tools/wsdl2java.html<BR>&gt; 5. Webmethods - <BR>&gt; http://www.webmethods.com/docs/glue/api/electric/wsdl/tools/ <BR>&gt; WSDL2Java.html<BR><BR>OK, that's a good list.<BR><BR>Tell me if I've got this right -- if we don't have any ordering, these <BR>tools will not be able to automatically generate code that understands <BR>the cardinality of atom elements; e.g., "MUST have only one title," <BR>"MAY have up to three content sections" (I made these up). However, <BR>they will still be able to generate some code; it's just that any <BR>consideration of cardinality will have to be hand-coded in.<BR><BR>Are there any other semantically signif!
 icant
 things that such a <BR>decision would disable Schema from describing?<BR><BR>Looking at that case, how would an implementation use that information, <BR>except through validation? I.e., would the cardinality information from <BR>the schema ever actually get used by an aggregator? If so, how?<BR><BR>From the other side, the major problem I've heard is that ordering is <BR>hard to remember, and may cause more instances to be invalid. From my <BR>experience, this is true; it's annoying when a metadata-oriented <BR>application requires you to put elements in an order, even though it <BR>isn't meaningful. It isn't the end of the world, of course, because <BR>people will have references, validators, etc.<BR><BR>Are there any other downsides to ordering? I will grant that part of my <BR>motivation is a) a visceral and growing dislike of XML Schema and b) a <BR>perhaps-too-pedantic belief that ordering, when required, should be <BR>semantically significant. Let's leave those to the
 side.<BR><BR>My take is this: it's about programmer efficiency -- not capability -- <BR>vs. ease *and* correctness of authoring. Considering that programmers <BR>are a) a smaller and more knowledgeable population, and b) they program <BR>it once, while authoring is a continual process, my leaning is towards <BR>unordered elements in Atom.<BR><BR>The fact that a good, solid Atom library that handles this stuff <BR>automagically will remove the burden from the programmer is what <BR>cemented it for me. That does require such a library to be built, while <BR>the libraries above are already existant, but I suspect people are <BR>going to build some good Atom libraries anyway, because there's a lot <BR>that Schema can't capture, no matter what we do.<BR><BR>&gt; Thanks and sorry about that last one,<BR><BR>Not at all - there's heat here (on all sides, I think), but light as <BR>well (ditto), and I for one don't mind a bit of give-and-take if it <BR>gets us closer to the answer. !
 I assumed
 you were of a like mind -- a <BR>complement, I hope :)<BR><BR>--<BR>Mark Nottingham http://www.mnot.net/<BR><BR></BLOCKQUOTE><p>
		<hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/mail_us/taglines/virus/*http://promotions.yahoo.com/new_mail/static/protection.html">Yahoo! Mail</a> - Helps protect you from nasty viruses.
--0-2039816877-1089705590=:78210--



From owner-atom-syntax@mail.imc.org  Tue Jul 13 04: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 EAA21646
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 04:37: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 i6D8JZeP049799;
	Tue, 13 Jul 2004 01:19:35 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6D8JZD6049798;
	Tue, 13 Jul 2004 01:19:35 -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 i6D8JYpX049787
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 01:19:34 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.19] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id EC4E3727D; Tue, 13 Jul 2004 01:19:34 -0700 (PDT)
In-Reply-To: <20040713075950.79777.qmail@web41506.mail.yahoo.com>
References: <20040713075950.79777.qmail@web41506.mail.yahoo.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed
Message-Id: <5FBE7B64-D4A5-11D8-9691-000A95BD86C0@mnot.net>
Cc: Atomlist <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: Re: PaceElementOrder: options 
Date: Tue, 13 Jul 2004 01:19:34 -0700
To: randy@kbcafe.com
X-Mailer: Apple Mail (2.618)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6D8JZpX049792
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


OK by me; I take it my characterisation of the benefits of ordering 
were on-target? I want to make sure I understand the pros.

Cheers,

On Jul 13, 2004, at 12:59 AM, Randy Charles Morin wrote:

> I think we've put all the cards on the table and we come to a choice. 
> Not that this choice isn't already made or needs to be made.
> 	• 	Order the elements because it will help some tools do a better job.
> 	• 	Don't order the elements because it's more difficult.
>
> Agreed? Everything else seems to be just argumentative.
> Thanks,
>
> Randy
> http://www.kbcafe.com
>
>  
>
> Mark Nottingham <mnot@mnot.net> wrote:
>
> On Jul 12, 2004, at 9:25 PM, Randy Charles Morin wrote:
>
> > 1. XSD.exe -
> > http://msdn.microsoft.com/library/en-us/cptools/html/
>  > cpconXMLSchemaDefinitionToolXsdexe.asp
> > 2. WSDL.exe -
> > http://msdn.microsoft.com/library/en-us/cptools/html/
>  > cpgrfWebServicesDescriptionLanguageToolWsdlexe.asp
> > 3. XMLSpy - http://www.altova.com/products_ide.html
> > 4. VS.NET - http://msdn.microsoft.com/vstudio/
> > 5. Apache Axis - http://ws.apache.org/axis/
> > 6. MSSOAP SDK -
> > http://www.microsoft.com/downloads/details.aspx?FamilyId=C943C0DD-
>  > CEEC-4088-9753-86F052EC8450&displaylang=en
> > 7. IBM SOAP4J - http://www.alphaworks.ibm.com/tech/soap4j/
> >
> > And others that I haven't used.
> > 1. Code Generation Extensions -
> > http://www.gotdotnet.com/Community/Workspaces/Workspace.aspx?
>  > id=80258a8c-bb4c-48e6-948b-05f6da568f55
> > 2. Castor Eclipse plugins - http://xdoclipse.sourceforge.net/
> > 3. WSDL2Java Eclipse plugin -
> > http://www.myspotter.com/wsdl2java.shtml
> > 4. Novell's jBroker -
> > 
> http://www.novell.com/documentation/workbench41/docs/jbroker-web/docs/
>  > reference/tools/wsdl2java.html
> > 5. Webmethods -
> > http://www.webmethods.com/docs/glue/api/electric/wsdl/tools/
>  > WSDL2Java.html
>
> OK, that's a good list.
>
> Tell me if I've got this right -- if we don't have any ordering, these
>  tools will not be able to automatically generate code that understands
>  the cardinality of atom elements; e.g., "MUST have only one title,"
>  "MAY have up to three content sections" (I made these up). However,
>  they will still be able to generate some code; it's just that any
>  consideration of cardinality will have to be hand-coded in.
>
> Are there any other semantically significant things that such a
> decision would disable Schema from describing?
>
> Looking at that case, how would an implementation use that information,
>  except through validation? I.e., would the cardinality information 
> from
>  the schema ever actually get used by an aggregator? If so, how?
>
> From the other side, the major problem I've heard is that ordering is
> hard to remember, and may cause more instances to be invalid. From my
>  experience, this is true; it's annoying when a metadata-oriented
>  application requires you to put elements in an order, even though it
> isn't meaningful. It isn't the end of the world, of course, because
>  people will have references, validators, etc.
>
> Are there any other downsides to ordering? I will grant that part of my
>  motivation is a) a visceral and growing dislike of XML Schema and b) a
> perhaps-too-pedantic belief that ordering, when required, should be
> semantically significant. Let's leave those to the side.
>
> My take is this: it's about programmer efficiency -- not capability --
> vs. ease *and* correctness of authoring. Considering that programmers
>  are a) a smaller and more knowledgeable population, and b) they 
> program
>  it once, while authoring is a continual process, my leaning is towards
>  unordered elements in Atom.
>
> The fact that a good, solid Atom library that handles this stuff
>  automagically will remove the burden from the programmer is what
>  cemented it for me. That does require such a library to be built, 
> while
>  the libraries above are already existant, but I suspect people are
>  going to build some good Atom libraries anyway, because there's a lot
> that Schema can't capture, no matter what we do.
>
> > Thanks and sorry about that last one,
>
> Not at all - there's heat here (on all sides, I think), but light as
> well (ditto), and I for one don't mind a bit of give-and-take if it
>  gets us closer to the answer. I assumed you were of a like mind -- a
> complement, I hope :)
>
> --
> Mark Nottingham http://www.mnot.net/
>
>
> Do you Yahoo!?
> Yahoo! Mail - Helps protect you from nasty viruses.

--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org  Tue Jul 13 05:32: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 FAA25111
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 05:32: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 i6D9CEgB065295;
	Tue, 13 Jul 2004 02:12: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 i6D9CElP065294;
	Tue, 13 Jul 2004 02:12:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail46-s.fg.online.no (mail46-s.fg.online.no [148.122.161.46])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6D9CDe1065275
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 02:12:14 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Received: from mail.online.no (ti132110a080-3373.bb.online.no [80.212.221.45])
	by mail46.fg.online.no (8.12.11/8.12.11) with ESMTP id i6D9C8mG010438;
	Tue, 13 Jul 2004 11:12:09 +0200 (MEST)
Date: Tue, 13 Jul 2004 11:12:07 +0200
To: "Eric Scheid" <eric.scheid@ironclad.net.au>,
        Atom-syntax <atom-syntax@imc.org>
Subject: Re: a methodical approach to defining what date  elements we need
References: <BD199A74.1F3DE%eric.scheid@ironclad.net.au>
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: <opsa2juhb06dxgxk@mail.online.no>
In-Reply-To: <BD199A74.1F3DE%eric.scheid@ironclad.net.au>
User-Agent: Opera M2/7.60 (Win32, build 7096)
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 Tue, 13 Jul 2004 13:56:04 +1000, Eric Scheid  
<eric.scheid@ironclad.net.au> wrote:

> What happens to the LOC or Dewey Decimal numbers in those situations?

Dewey is a classification system, and, unless the subject of the book  
changes between the editions, a new revision of a book should be  
unaffected.

> Are ISBNs more like non-serial version identifiers?

ISBN does not identify version information. It identifies the  
country/language, publisher, and the [publisher's] item number.

Furthermore, the publisher number, is only an identifer for a block of  
item numbers which in turn is assigned to one publisher. When the  
publisher has used all of it's assigned item numbers, they are given a new  
publisher number.

For a quick intro on how ISBN works, look at Wikipedia's explanation,  
<URL:http://en.wikipedia.org/wiki/ISBN>.

> After all, when the vast majority of users of books refer to "The Tao of  
> Pooh" they don't say "the publication with ISBN xxx". They say "The Tao  
> of Pooh".

So do the vast majority of users when refering to blog entries; "Did you  
see Mark's hilarious entry on 'Pink numbers'?".  We only revert to using a  
unique identifers such as ISBNs when there is absolutely no other way to  
identify the entry.

- Did you see Mark's entry on 'Pink Numbers'?
  - Which Mark?  There are 3123153 Mark's
- Oh. Mark Pilgrim. At diveintomark.org
  - Which 'Pink Numbers' entry? He has 37 'Pink Numbers' entries.
- Oh, the one on May 30.
  - Ok. Thanks.

Only if there had been any more than three 'Pink numbers' stories on May  
30, people would have started asking for information precisely locating  
the entry, either in form of the permalink, or the ID.

> The various editions and revisions and covers are simply *versions* of  
> the *same* thing. They are not *different* things in the sense that "The  
> Tao of Pooh" is different from "100 things to do with a dead cat".

Yet, they have different unique identifiers. Humans use common sense when  
recognizing that "The Tao of Pooh, second edition" supersedes "The Tao of  
Pooh, first edition".

> So far, blogs don't usually provide ongoing life support for previous
> versions (something I expect to continue) ...

I'd like to propose that we try to forget that Atom originated from blogs,  
bloggers and their needs for a moment.  While the early adopters of RSS  
mostly were bloggers, RSS is in very widespread use outside the  
blogosphere. So will Atom be. I'll

When we expand the context from 'Blogs', there are CMSes with revision  
control.

I'm also quite confident that there will be CMSes suitable for bloggers  
that lets the user revert to previous versions of an entry for further  
editing.

-- 
Arve Bersvendsen

http://www.virtuelvis.com
http://www.bersvendsen.com



From owner-atom-syntax@mail.imc.org  Tue Jul 13 05:57: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 FAA27079
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 05: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 i6D9a4gR072234;
	Tue, 13 Jul 2004 02:36:04 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6D9a4Hr072233;
	Tue, 13 Jul 2004 02:36:04 -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 i6D9a4iT072225
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 02:36:04 -0700 (PDT)
	(envelope-from danbri@w3.org)
Received: by homer.w3.org (Postfix, from userid 13522)
	id 31C674F0A6; Tue, 13 Jul 2004 05:36:04 -0400 (EDT)
Date: Tue, 13 Jul 2004 05:36:04 -0400
From: Dan Brickley <danbri@w3.org>
To: Mark Nottingham <mnot@mnot.net>
Cc: Mark Baker <distobj@acm.org>,
        Andreas Sewe <sewe@rbg.informatik.tu-darmstadt.de>,
        "[Atom]" <atom-syntax@imc.org>
Subject: Re: Version vs. Namespace
Message-ID: <20040713093555.GA8409@homer.w3.org>
References: <OFC66635FE.A2AF5F93-ON88256ECF.0060057C-88256ECF.0060668D@us.ibm.com> <C3C62D26-D42E-11D8-AFCB-000A95BD86C0@mnot.net> <001001c4684e$65d03c20$753ce03e@baron> <20040713015323.GS30868@markbaker.ca> <BBAD355E-D474-11D8-AFCB-000A95BD86C0@mnot.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BBAD355E-D474-11D8-AFCB-000A95BD86C0@mnot.net>
User-Agent: Mutt/1.5.6+20040523i
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-07-12 19:31-0700]
> 
> 
> On Jul 12, 2004, at 6:53 PM, Mark Baker wrote:  

> I don't share your conviction; the use cases for Atom are quite 
> different. Atom is not a presentation format, it's a metadata 
> container, and something that allows people to group together different 
> types of metadata into a single package will engender interoperability 
> and functionality.
> 
> We already have one profile of Atom -- the blog/newsfeed profile that 
> is the direct successor to RSS. That's great, but part of the reason I 
> find Atom so exciting is that it can enable other profiles too; for 
> example, stock price feeds, weather feeds, CVS changes, etc. ad 
> infinitum. Individual extensions aren't enough to enable these uses 
> because it ignores the combination of extensions that characterises a 
> particular application.

I took this particular extensibility discussion to be about the
evolution of the core Atom namespace, ie the rules for interpretation of 
incrementally added atom:* XML elements and attributes. I share your
excitement about stock prices, job listings, movie locations etc
appearing in feeds, although to date Atom is a technical step backwards
from what we had in RSS 1.0 in that regard: Atom optimises for the
blogging use case (very nicely) but doesn't yet have anything that
gives rules for the sane combination of independent extension vocabs.

It does seem reasonable to deal with internal-to-Atom extensions before
attempting to deal with the bigger problem spaces of namespace-extended
Atom extensibility.

On that front, I'm still trying to figure out what "must ignore" means;
to an Atom2XHTML XSLT filter, "must ignore" might mean "pass it through", 
to an Atom search engine, "must ignore" might mean "don't match against user
searches". In other words "must ignore" doesn't make much sense to me
without a taxonomy of Atom implementation types. FWIW when we were
discussing this in the RDF design, we backed away from that approach
(except, to some extent, re parsers) and talked instead about 
extensions being "additive" (or monotonic [1]). This is just a mathsy
way of saying that extensions only add information, and don't interact
with each other in fiddly and hard to predict ways. But then RDF has a
very passive-voice, declarative perspective on things; Atom markup (at
least in the core Atom namespace) might have more operational aspects.
Which is why splitting things out into core-Atom extensibility versus
other-namespace extensibility seems useful to me here. 

Dan
 


[1] http://www.w3.org/TR/rdf-mt/#MonSemExt




From owner-atom-syntax@mail.imc.org  Tue Jul 13 06:00:34 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27325
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 06:00: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 i6D9g8rm074322;
	Tue, 13 Jul 2004 02:42: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 i6D9g8jv074321;
	Tue, 13 Jul 2004 02:42:08 -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 i6D9g7cB074275
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 02:42:08 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Received: from mail.online.no (ti132110a080-3373.bb.online.no [80.212.221.45])
	by mail47.fg.online.no (8.12.11/8.12.11) with ESMTP id i6D9fv7Q011476;
	Tue, 13 Jul 2004 11:41:59 +0200 (MEST)
Date: Tue, 13 Jul 2004 11:41:55 +0200
To: "Eric Scheid" <eric.scheid@ironclad.net.au>,
        Atom-syntax <atom-syntax@imc.org>
Subject: Re: a methodical approach to defining what date  elements we need
References: <BD1995C2.1F3C6%eric.scheid@ironclad.net.au>
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: <opsa2k75lz6dxgxk@mail.online.no>
In-Reply-To: <BD1995C2.1F3C6%eric.scheid@ironclad.net.au>
User-Agent: Opera M2/7.60 (Win32, build 7096)
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 Tue, 13 Jul 2004 13:36:02 +1000, Eric Scheid  
<eric.scheid@ironclad.net.au> wrote:

> On 13/7/04 11:10 AM, "Graham" <dtcd@mac.com> wrote:
>
>> This is a single entry that has been modified over time:
>>
>>   http://www.tbray.org/ongoing/When/200x/2004/02/20/GenxStatus
>>
>> What is its issued date? (NB Suggesting it be broken into multiple
>> entries is not an option)
>
> +1 example

-0.5 example.  While I do agree with Sam's assessment of the dates, this  
example more shows the limitations of a particular publishing system than  
it shows the need to avoid (simple) revisioning support in Atom.

> Having permalinks is a good thing.

If permalinks really were permanent, we wouldn't really need entry:id.

> Can someone explain if PaceSupercedes expects the new-id entry to be
> published at the superceded permalink? [1] Alternatively, will it (the
> published permalink) be updated with a pointer to the superceding  
> version, (and that with a pointer when it too is superceded, and then  
> that too again, and again, and ...)?

This is a policy matter with the CMS in question. Possible solutions are:

1. The new revision (with it's new id), will continue to exist at the  
location of the previous entry. Pretty equivalent to the Genx example (if  
we assume that the Genx status page is "one entry"). An alternative access  
mechanism may be provided to access previous versions.
2. If the permalink changes, the previous version is updated with a  
pointer to the superseding version.
3. If the permalink changes, the CMS automatically uses HTTP redirects  
 from the previous version to the new version.

CMSes without any revisioning mechanisms would simply continue to work the  
way they always have, updating the modified timestamp.

Also note that, even if I co-authored PaceSupersede with Asbjørn Ulsberg,  
I think this particular line should be changed:

* atom:entry MAY contain an atom:supersedes element, but MUST NOT contain  
more than one.

Perhaps to:

* atom:entry MAY contain an atom:supersedes element, and MAY contain more  
than one. If several revisions of an atom:entry exists, there SHOULD be  
atom:supersedes referencing at least the initial revision and the last  
revision before the current.

(This is quite equivalent to having to keep a reference to at the very  
least both the top entry and last entry in a discussion thread, in case  
the last message in the threadgoes AWOL. Usenet newsreaders tries to  
preserve as much as possible in the References header)

-- 
Arve Bersvendsen

http://www.virtuelvis.com
http://www.bersvendsen.com



From owner-atom-syntax@mail.imc.org  Tue Jul 13 06:09: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 GAA27765
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 06: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 i6D9oNGn077342;
	Tue, 13 Jul 2004 02:50:23 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6D9oNQ9077341;
	Tue, 13 Jul 2004 02:50:23 -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 i6D9oM66077331
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 02:50:22 -0700 (PDT)
	(envelope-from danbri@w3.org)
Received: by homer.w3.org (Postfix, from userid 13522)
	id 47B084F5BF; Tue, 13 Jul 2004 05:50:23 -0400 (EDT)
Date: Tue, 13 Jul 2004 05:50:23 -0400
From: Dan Brickley <danbri@w3.org>
To: Mark Nottingham <mnot@mnot.net>
Cc: Bill de =?iso-8859-15?Q?h=D3ra?= <bill@dehora.net>,
        Andreas Sewe <sewe@rbg.informatik.tu-darmstadt.de>,
        Mark Baker <distobj@acm.org>, "[Atom]" <atom-syntax@imc.org>
Subject: Re: Version vs. Namespace
Message-ID: <20040713095010.GB8409@homer.w3.org>
References: <OFC66635FE.A2AF5F93-ON88256ECF.0060057C-88256ECF.0060668D@us.ibm.com> <C3C62D26-D42E-11D8-AFCB-000A95BD86C0@mnot.net> <001001c4684e$65d03c20$753ce03e@baron> <20040713015323.GS30868@markbaker.ca> <BBAD355E-D474-11D8-AFCB-000A95BD86C0@mnot.net> <40F35558.2000104@dehora.net> <4789E38B-D47D-11D8-AFCB-000A95BD86C0@mnot.net> <40F35C76.5020607@dehora.net> <B55F9DFD-D482-11D8-9691-000A95BD86C0@mnot.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <B55F9DFD-D482-11D8-9691-000A95BD86C0@mnot.net>
User-Agent: Mutt/1.5.6+20040523i
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 Nottingham <mnot@mnot.net> [2004-07-12 21:11-0700]
> 
> 
> On Jul 12, 2004, at 8:52 PM, Bill de hÓra wrote:
> 
> >Well, thanks, but you're preaching to the choir. I have a history of 
> >objection to RDF/XML.
> 
> Always good to add to the multitude -- must be quite a sound by now!  ;)

To be clear, the objection is to RDF's XML syntax, rather than to the
RDF effort as a whole?

A while ago, some of us sketched out what Atom feeds might look like in
an alternative, unstriped, XML encoding of RDF. Actually we used the 
SOAP Encoding syntax; jumping from one unloved XML graph notation to another ;)

http://esw.w3.org/topic/SpotOfDrama
http://esw.w3.org/topic/AtomJobExample

This is an "unstriped" RDF syntax in the sense of
http://www.w3.org/2001/10/stripes/ ie. that XML elements always stand
for edges in the RDF graph (ie. properties, relations), rather than
sometimes that, and sometimes for classes/categories.

I'm circulating it not as a concrete suggestion for adoption, just to
show that RDF can be used to support a namespace extension model for
Atom without necessarily adopting the RDF/XML syntax rules.

cheers,

Dan



From owner-atom-syntax@mail.imc.org  Tue Jul 13 06:17: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 GAA28655
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 06:17: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 i6DA0YJ6080475;
	Tue, 13 Jul 2004 03:00: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 i6DA0Y1h080474;
	Tue, 13 Jul 2004 03:00:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DA0Won080452
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 03:00:33 -0700 (PDT)
	(envelope-from Janne.Jalkanen@nokia.com)
Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121])
	by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6DA0Tb22717;
	Tue, 13 Jul 2004 13:00:30 +0300 (EET DST)
X-Scanned: Tue, 13 Jul 2004 13:00:23 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost)
	by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i6DA0NSe022226;
	Tue, 13 Jul 2004 13:00:23 +0300
Received: from mgw-int1.ntc.nokia.com (172.21.143.96)
	by esdks002.ntc.nokia.com 00vp6CVH; Tue, 13 Jul 2004 13:00:22 EEST
Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77])
	by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6DA0Ln07102;
	Tue, 13 Jul 2004 13:00:21 +0300 (EET DST)
Received: from nokia.com ([172.21.60.114]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Tue, 13 Jul 2004 13:00:20 +0300
Message-ID: <40F3B2B2.9060803@nokia.com>
Date: Tue, 13 Jul 2004 13:00:18 +0300
From: Janne Jalkanen <Janne.Jalkanen@nokia.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040122
X-Accept-Language: fi, en-us, en
MIME-Version: 1.0
To: mint@franklinmint.fm
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Pace409Response
References: <BD1497CA.1205C%mint@franklinmint.fm> <40F2A8C1.60103@nokia.com> <40F2DBAB.7080101@franklinmint.fm>
In-Reply-To: <40F2DBAB.7080101@franklinmint.fm>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 13 Jul 2004 10:00:20.0157 (UTC) FILETIME=[34C546D0:01C468C0]
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'm a wiki ignoramus, so you're losing me here. Could you show me an 
> example client/server exchange? 

JSPWiki (and most other wikis, I'd assume) does things the following way:

1. GET the editor page, which inserts the contents of the page in a 
<textarea> element.  Also, a hidden parameter is added within the FORM, 
which contains the last-modified date of the page.
2. Upon save, i.e. POST, the server checks the hidden parameter against 
the real last-modified date of the page.  If they differ, someone must 
have changed the page contents while you were editing.
3. Show a conflict-message to the user, with a new hidden timestamp
4. The user edits the page to resolve the conflict, and saves again.  If 
the timestamps again differ, the conflict process is repeated.  If not, 
the page gets saved.

Typically, most wikis also are smart enough to show a "someone is 
already editing this page, are you sure you want to edit this page", but 
rarely do they have exclusive locking.  This is because spambots and 
random users tend to just click on the edit-link, then leave it using 
the "back" -key and leave the lock hanging.  This could probably be 
circumvented with Javascript, but that tends to bring more problems than 
not. :)

The hidden parameter can also be a hash code against the page contents 
or something, but in general a timestamp is used.

/Janne



From owner-atom-syntax@mail.imc.org  Tue Jul 13 06:45:35 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00308
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 06:45:34 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DARVrn089137;
	Tue, 13 Jul 2004 03:27:31 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6DARVqk089136;
	Tue, 13 Jul 2004 03:27:31 -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 i6DARUrB089110
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 03:27:31 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 6110 messnum 15326838 invoked from network[83.70.39.115/83-70-39-115.bas2.prp.dublin.eircom.net]); 13 Jul 2004 10:27:26 -0000
Received: from 83-70-39-115.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.39.115)
  by mail11.svc.cra.dublin.eircom.net (qp 6110) with SMTP; 13 Jul 2004 10:27:26 -0000
Message-ID: <40F3B90B.6070100@dehora.net>
Date: Tue, 13 Jul 2004 11:27:23 +0100
From: =?ISO-8859-15?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]" <atom-syntax@imc.org>
Subject: Re: Version vs. Namespace
References: <OFC66635FE.A2AF5F93-ON88256ECF.0060057C-88256ECF.0060668D@us.ibm.com> <C3C62D26-D42E-11D8-AFCB-000A95BD86C0@mnot.net> <001001c4684e$65d03c20$753ce03e@baron> <20040713015323.GS30868@markbaker.ca> <BBAD355E-D474-11D8-AFCB-000A95BD86C0@mnot.net> <40F35558.2000104@dehora.net> <4789E38B-D47D-11D8-AFCB-000A95BD86C0@mnot.net> <40F35C76.5020607@dehora.net> <B55F9DFD-D482-11D8-9691-000A95BD86C0@mnot.net> <20040713095010.GB8409@homer.w3.org>
In-Reply-To: <20040713095010.GB8409@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:


> To be clear, the objection is to RDF's XML syntax, rather than to the
> RDF effort as a whole?

Objection to RDF's XML syntax. There are a number of mappings of 
Atom onto RDF - the one I did required some 'extra' inference around 
author and relating entries to a feed, but hasn't dealt with content 
yet.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Tue Jul 13 07: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 HAA01537
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 07: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 i6DAr4Ok096117;
	Tue, 13 Jul 2004 03:53: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 i6DAr4YS096116;
	Tue, 13 Jul 2004 03:53:04 -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 i6DAr3dT096108
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 03:53:03 -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 i6DAr42G005410;
	Tue, 13 Jul 2004 03:53:05 -0700 (PDT)
Received: from [192.168.1.100] (h00080d858303.ne.client2.attbi.com [24.61.1.243])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id i6DAr3Zt021688;
	Tue, 13 Jul 2004 03:53:04 -0700 (PDT)
In-Reply-To: <opsa2k75lz6dxgxk@mail.online.no>
References: <BD1995C2.1F3C6%eric.scheid@ironclad.net.au> <opsa2k75lz6dxgxk@mail.online.no>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-16--260367366; protocol="application/pkcs7-signature"
Message-Id: <CFCD3EC6-D4BA-11D8-82B1-000A95DC3D90@mac.com>
Cc: Atom-syntax Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: a methodical approach to defining what date  elements we need
Date: Tue, 13 Jul 2004 06:53:01 -0400
To: Arve Bersvendsen <arve@virtuelvis.com>
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-16--260367366
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed
Content-Transfer-Encoding: 7bit

On 13 Jul 2004, at 5:41 am, Arve Bersvendsen wrote:

> On Tue, 13 Jul 2004 13:36:02 +1000, Eric Scheid  
> <eric.scheid@ironclad.net.au> wrote:
>
>> On 13/7/04 11:10 AM, "Graham" <dtcd@mac.com> wrote:
>>
>>> This is a single entry that has been modified over time:
>>>
>>>   http://www.tbray.org/ongoing/When/200x/2004/02/20/GenxStatus
>>>
>>> What is its issued date? (NB Suggesting it be broken into multiple
>>> entries is not an option)
>>
>> +1 example
>
> -0.5 example.  While I do agree with Sam's assessment of the dates,  
> this example more shows the limitations of a particular publishing  
> system than it shows the need to avoid (simple) revisioning support in  
> Atom.

Piss off. It's a real, perfectly valid blog entry on a popular blog  
that already has a syndication feed, and that I've already shown a  
simple example of how to support it properly within the elements we  
already have. It might be an extreme example, but what it represents is  
a valid general case (re-issuing) that we need to support.

> If permalinks really were permanent, we wouldn't really need entry:id.

If atom:id were permanent we wouldn't need this atom:supercedes  
nonsense.

(If anyone can't guess, -1,000,000 on PaceSupercedes. Stuff like it has  
been suggested before and has gone nowhere, as will this)

> * atom:entry MAY contain an atom:supersedes element, and MAY contain  
> more than one. If several revisions of an atom:entry exists, there  
> SHOULD be atom:supersedes referencing at least the initial revision  
> and the last revision before the current.

A reference to the initial version is important, isn't it? Why, if it  
didn't seem too obvious to work, I'd suggest we create an element that  
doesn't change through all revisions of the same entry [1] . No,  
scratch that, I'm being stupid.

[1]  
http://www.mnot.net/drafts/draft-nottingham-atom-format 
-02.html#rfc.section.4.13.5

Graham
--Apple-Mail-16--260367366
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
9w0BCQUxDxcNMDQwNzEzMTA1MzAyWjAjBgkqhkiG9w0BCQQxFgQUPP9u18BbmMi5UmzUnuh+LSq5
nHsweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEARhkJdyzItCBlnVTWXtBAF+YK
jjqOyGEGv4v7FV9g7bSRWkSmQOJFt0I0w1vIiHIBw3fVf+B1n2uY/3R9ZsjMMrnRn2dL/r5ZDaKG
2kN06OPYiJxY8tPoIZnXZxtihpDTWkD+0QXdL2QcaKQ62J+6u/YTjW8pM2D5Sp1+xsvMQ7jblL0y
1aDJC7wGMaLKK/wnQO969o1PFRoj7iLfuH0Jch8I/tjJfw498h6RamJb4UoVcYOGrbRSz6tWMz8C
IVdGODtHw7ov7aGhNBNpKBPWXLIsKEN+dLy2bqTMTKdY4jCzjiUHNW3grN9iu0aRf3sI84CcgKJU
xy94JlY7zFjOoAAAAAAAAA==

--Apple-Mail-16--260367366--



From owner-atom-syntax@mail.imc.org  Tue Jul 13 07: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 HAA01896
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 07: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 i6DB2Hc1098616;
	Tue, 13 Jul 2004 04: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 i6DB2HjJ098615;
	Tue, 13 Jul 2004 04:02: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 i6DB2F3B098599
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 04:02:16 -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 i6DB2sUN031211;
	Tue, 13 Jul 2004 07:02:54 -0400
Message-ID: <40F3C139.4030003@intertwingly.net>
Date: Tue, 13 Jul 2004 07:02:17 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <dtcd@mac.com>
CC: Atom-syntax <atom-syntax@imc.org>
Subject: Re: a methodical approach to defining what date  elements we need
References: <63E12F93-D452-11D8-9D0B-003065EA6144@geckotribe.com> <opsa1wb8jm6dxgxk@mail.online.no> <66107F6A-D469-11D8-82B1-000A95DC3D90@mac.com> <40F34FF2.2010608@intertwingly.net> <AAC8F79E-D47B-11D8-82B1-000A95DC3D90@mac.com>
In-Reply-To: <AAC8F79E-D47B-11D8-82B1-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: <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 12 Jul 2004, at 10:58 pm, Sam Ruby wrote:
> 
>> Graham wrote:
>>
>>>> I firmly believe that "issued" should be set in stone. To me, it 
>>>> simply doesn't make sense that an entry issued three weeks ago 
>>>> suddenly gets this date changed. The entry is three weeks old. Period.
>>>
>>> This is a single entry that has been modified over time:
>>>  http://www.tbray.org/ongoing/When/200x/2004/02/20/GenxStatus
>>> What is its issued date? (NB Suggesting it be broken into multiple 
>>> entries is not an option)
>>
>> Based on the text and the URL, this page appears to have been 
>> originally created on 2004-02-17, issued on 2004-02-20, and last 
>> modified on 2004-06-13.
> 
> But that's useless to me. I can't sort by modified 

Why not?

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Tue Jul 13 07:40: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 HAA02766
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 07:40: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 i6DBM5W6004695;
	Tue, 13 Jul 2004 04:22:05 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6DBM5WT004694;
	Tue, 13 Jul 2004 04:22: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.87])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DBM5Fd004685
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 04:22:05 -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 i6DBM6BC003828;
	Tue, 13 Jul 2004 04:22:06 -0700 (PDT)
Received: from [192.168.1.100] (h00080d858303.ne.client2.attbi.com [24.61.1.243])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id i6DBLe0t012087;
	Tue, 13 Jul 2004 04:21:40 -0700 (PDT)
In-Reply-To: <40F3C139.4030003@intertwingly.net>
References: <63E12F93-D452-11D8-9D0B-003065EA6144@geckotribe.com> <opsa1wb8jm6dxgxk@mail.online.no> <66107F6A-D469-11D8-82B1-000A95DC3D90@mac.com> <40F34FF2.2010608@intertwingly.net> <AAC8F79E-D47B-11D8-82B1-000A95DC3D90@mac.com> <40F3C139.4030003@intertwingly.net>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-17--258697322; protocol="application/pkcs7-signature"
Message-Id: <B339B426-D4BE-11D8-82B1-000A95DC3D90@mac.com>
Cc: Atom-syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: a methodical approach to defining what date  elements we need
Date: Tue, 13 Jul 2004 07:20:52 -0400
To: Sam Ruby <rubys@intertwingly.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-17--258697322
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 13 Jul 2004, at 7:02 am, Sam Ruby wrote:

> Graham wrote:
>
>> On 12 Jul 2004, at 10:58 pm, Sam Ruby wrote:
>>> Graham wrote:
>>>
>>>>> I firmly believe that "issued" should be set in stone. To me, it 
>>>>> simply doesn't make sense that an entry issued three weeks ago 
>>>>> suddenly gets this date changed. The entry is three weeks old. 
>>>>> Period.
>>>>
>>>> This is a single entry that has been modified over time:
>>>>  http://www.tbray.org/ongoing/When/200x/2004/02/20/GenxStatus
>>>> What is its issued date? (NB Suggesting it be broken into multiple 
>>>> entries is not an option)
>>>
>>> Based on the text and the URL, this page appears to have been 
>>> originally created on 2004-02-17, issued on 2004-02-20, and last 
>>> modified on 2004-06-13.
>> But that's useless to me. I can't sort by modified
>
> Why not?

Read again what you deleted:
"I can't sort by modified (Tim's is the only blog in the universe that 
is)"

No other blog in the wild is sorted by the modified date of the 
entries. Entries stay in the order they were originally published. I 
need a date to sort on that works in the general case (which I've 
already demonstrated how to do).

Graham
--Apple-Mail-17--258697322
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
9w0BCQUxDxcNMDQwNzEzMTEyMDUyWjAjBgkqhkiG9w0BCQQxFgQUHvVUiSyFSAe0YDSudbq+87x0
aYYweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEA1vOQPXe0G39L9madseJugbG+
1+JlVqDRSPFSm+My59ADKWhOL2onN1Mo6s09636vKmDGsfLf0OD4XNnsC17kCqKE0Sk2hmaSQulp
A9Mch89kMFZmjkkL42JCUIBpJMiJmYNkdUOnPyiVW92Qp3kNhYsP6hAkUpq+AvKR0nbIUpuxvDkS
rgkahSEyLQOCLFtZPzf0TGXPuf4i0FkFuxNzlWI9XKnYHV1j4meicQc5DbdahPf68tz9ISVTEF6q
g/GPPY+BT0J5ghmsc/PAAmBEQVZTX1UHIl1vmEnhyM5EX5pdNlW1mZj30VM2q3FGVbkvrfzt6kGR
rf5XplrBA/wZhwAAAAAAAA==

--Apple-Mail-17--258697322--



From owner-atom-syntax@mail.imc.org  Tue Jul 13 08:07:01 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03882
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 08:07:01 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DBnAiG012243;
	Tue, 13 Jul 2004 04:49:10 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6DBnAbc012242;
	Tue, 13 Jul 2004 04:49: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 i6DBn9S3012223;
	Tue, 13 Jul 2004 04:49:10 -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 i6DBnmDU000843;
	Tue, 13 Jul 2004 07:49:48 -0400
Message-ID: <40F3CC36.9080001@intertwingly.net>
Date: Tue, 13 Jul 2004 07:49:10 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <dtcd@mac.com>
CC: Atom-syntax Syntax <atom-syntax@imc.org>
Subject: Re: a methodical approach to defining what date  elements we need
References: <BD1995C2.1F3C6%eric.scheid@ironclad.net.au> <opsa2k75lz6dxgxk@mail.online.no> <CFCD3EC6-D4BA-11D8-82B1-000A95DC3D90@mac.com>
In-Reply-To: <CFCD3EC6-D4BA-11D8-82B1-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: <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 13 Jul 2004, at 5:41 am, Arve Bersvendsen wrote:
> 
>> On Tue, 13 Jul 2004 13:36:02 +1000, Eric Scheid  
>> <eric.scheid@ironclad.net.au> wrote:
>>
>>> On 13/7/04 11:10 AM, "Graham" <dtcd@mac.com> wrote:
>>>
>>>> This is a single entry that has been modified over time:
>>>>
>>>>   http://www.tbray.org/ongoing/When/200x/2004/02/20/GenxStatus
>>>>
>>>> What is its issued date? (NB Suggesting it be broken into multiple
>>>> entries is not an option)
>>>
>>>
>>> +1 example
>>
>> -0.5 example.  While I do agree with Sam's assessment of the dates,  
>> this example more shows the limitations of a particular publishing  
>> system than it shows the need to avoid (simple) revisioning support 
>> in  Atom.
> 
> Piss off. 

Please at least *TRY* to be civil.

> It's a real, perfectly valid blog entry on a popular blog  
> that already has a syndication feed, and that I've already shown a  
> simple example of how to support it properly within the elements we  
> already have. It might be an extreme example, but what it represents is  
> a valid general case (re-issuing) that we need to support.

You are also simultaneously maintaining that "(Tim's is the only blog in 
the universe that is)", which tends to argue against this being a 
representive sample that one should use to base decisions off of.

Let's proceed with the assumption for the moment that this is a 
representative sample.

max(date-on-page) = 2004-06-13
min(date-on-pate) = 2004-02-17

There also is a significant date which is reflected both in the URL and 
in a special sidebar "Around February 20, 2004".

These are three dates that appear significant.  What tags should be used 
for these?

Or, would you rather say that this example is not representative?

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Tue Jul 13 08:15: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 IAA04896
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 08:15: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 i6DBtk9Q014199;
	Tue, 13 Jul 2004 04:55: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 i6DBtk47014198;
	Tue, 13 Jul 2004 04:55:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf15.cluster1.charter.net (mxsf15.cluster1.charter.net [209.225.28.215])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DBtkF8014174
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 04:55:46 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip18.cluster1.charter.net (mxip18a.cluster1.charter.net [209.225.28.148])
	by mxsf15.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6DC0c96022748
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 08:00:38 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip18.cluster1.charter.net with ESMTP; 13 Jul 2004 07:55:41 -0400
X-Ironport-AV: i="3.81R,163,1083556800"; 
   d="scan'208"; a="114875483:sNHT14707340"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BkLsk-0001On-00
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 07:55:34 -0400
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: RELAX NG Grammar for draft-...-00.txt
References: <20040713012505.21328.qmail@web41510.mail.yahoo.com>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Tue, 13 Jul 2004 07:55:26 -0400
In-Reply-To: <20040713012505.21328.qmail@web41510.mail.yahoo.com> (Randy
 Charles Morin's message of "Mon, 12 Jul 2004 18:25:05 -0700 (PDT)")
Message-ID: <87658s6s0h.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: <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-Type: text/plain

/ Randy Charles Morin <randymorin@yahoo.com> was heard to say:
| Norman Walsh wrote: 
| | atomDateConstruct =
| |    atomCommonAttributes,
| |    (xsd:date | xsd:dateTime | xsd:gYearMonth | xsd:gYear)
|>Urk. This is a cut-and-paste bug. I think we mean xsd:dateTime *only* here.
|
| I think all four date formats are acceptable. As per section 3.3 Date Construct of the format spec [1]. 
|
| 3.3  Date Constructs
|
|    A Date construct is an element whose child content is a W3C Date-Time
|    string [W3C.NOTE-datetime-19980827].
|
| That spec [2] indicates all four date formats are acceptable.
| Thanks and please clarify if I missed something,

I think you're right, but saying that date constructs should have a time zone
(or must in one case), doesn't square very well with allowing "1994" as the
content.

I lean towards adopting the RFC for timestamps, myself.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | "Abstraction, abstraction and
http://nwalsh.com/            | abstraction." This is the answer to the
                              | question, "What are the three most
                              | important words in programming?"--Paul
                              | Hudak

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA882xOyltUcwYWjsRAtpKAKCvaRxYKIkbl+m36zNY9t0wJQP3EwCgl/JT
ZZHk30Kal/e2BDdCsh8im7s=
=HiD7
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Tue Jul 13 08:27: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 IAA05362
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 08:27: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 i6DC6qRq017190;
	Tue, 13 Jul 2004 05:06:52 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6DC6qU7017189;
	Tue, 13 Jul 2004 05:06:52 -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 i6DC6qt3017154
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 05:06:52 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip13.cluster1.charter.net (mxip13a.cluster1.charter.net [209.225.28.143])
	by mxsf09.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6DCA1RU026246
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 08:10:02 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip13.cluster1.charter.net with ESMTP; 13 Jul 2004 08:06:45 -0400
X-Ironport-AV: i="3.81R,163,1083556800"; 
   d="scan'208"; a="113316310:sNHT15450704"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BkM3N-0002wC-00
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 08:06:33 -0400
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceElementOrder: options
References: <20040712211533.90350.qmail@web41511.mail.yahoo.com>
	<A5343281AE2BD2A2B110E8AF@diva.verity.com>
	<40F32E81.4050508@dehora.net>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Tue, 13 Jul 2004 08:06:33 -0400
In-Reply-To: <40F32E81.4050508@dehora.net> (Bill de
 =?iso-8859-1?q?h=D3ra's?= message of "Tue, 13 Jul 2004 01:36:17 +0100")
Message-ID: <871xjg6rhy.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: <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-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

/ Bill de h=D3ra <bill@dehora.net> was heard to say:
| Walter Underwood wrote:
|> Increased interoperability and minimal specification. The internet
|> robustness principle, specifically the "be generous in what you accept"
|> part, and avoid specifying things that don't really change the content
|> of the message.
|
| However this 'content' is inscribed in XML syntax, and normal use of
| said XML is to declare an element order.

I think any appeal to "normal use of XML" is a stretch. For example,
my normal XML vocabulary is DocBook and of the 400 or so elements in
DocBook, I'd guess that only a small handful declare an order.

|> Mail headers and HTTP headers do not have a required order. They
|> work fine.
|
| Not the same thing. Those are defined pretty much to be extensible
| dictionaries. We don't appear to have such a definition, but people

Uhm, well, I thought the statement that any namespace qualfied element
was allowed basically *did* give us such a definition.

| are talking as though we have - this is my point.

Hmm. Ok, maybe we should say that's what we have then. Feeds and
entries aren't dictionaries in the strict sense because they would
allow duplicate keys, but I expect to be able to write:

  <atom:entry>
    <atom:title>...</atom:title>
    <dc:subject>Some subject</dc:subject>
    <dc:subject>Another subject</dc:subject>
    <atom:author><atom:name>Norman Walsh</atom:name></atom:author>
    <geo:lat>42.4</geo:lat>
    <geo:long>-72.2</geo:long>
    <dc:subject>Yet one more subject</dc:subject>
    <atom:modified>2004-07-12T08:38:44Z</atom:modified>
    <atom:link rel=3D"alternate"
               href=3D"http://norman.walsh.name/2004/07/12/someEssay"/>
  </atom:entry>

| I don't see asking people to emit a list of XML elements in a given
| order to be a burden; in the scheme of things it's trivial compared to
| asking them to get the encoding straight.

Fair enough. My preference is for a content model that allows
arbitrary order, but I won't stand in the way of consensus if I'm in
the minority.

                                        Be seeing you,
                                          norm

=2D-=20
Norman Walsh <ndw@nwalsh.com> | Words--so innocent and powerless they
http://nwalsh.com/            | are, as standing in a dictionary, how
                              | potent for good and evil they become,
                              | in the hands of one who knows how to
                              | use them!--Nathaniel Hawthorne

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA89BJOyltUcwYWjsRAjjSAKCCWGwrBiuvVKaPqsc8ULSL5X9vBwCgqKiG
yIJxAeJJa+88tX4/lOvLoQs=
=ohc4
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Tue Jul 13 08:47: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 IAA06993
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 08:47: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 i6DCUbC0023997;
	Tue, 13 Jul 2004 05:30: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 i6DCUbR5023996;
	Tue, 13 Jul 2004 05:30:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.193])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6DCUaRA023973
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 05:30:36 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d78so240092rnf
        for <atom-syntax@imc.org>; Tue, 13 Jul 2004 05:30:26 -0700 (PDT)
Received: by 10.38.72.47 with SMTP id u47mr50902rna;
        Tue, 13 Jul 2004 05:30:26 -0700 (PDT)
Message-ID: <14be96d3040713053039dbde91@mail.gmail.com>
Date: Tue, 13 Jul 2004 08:30:26 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: John Panzer <jpanzer@aol.net>
Subject: Re: PaceSecurityServices
Cc: Paul Hoffman / IMC <phoffman@imc.org>, Atom WG <atom-syntax@imc.org>
In-Reply-To: <40F37A14.6040908@aol.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <40E16215.6070507@intertwingly.net> <40EC9915.4050406@intertwingly.net> <3f1451f504070718267c5526b4@mail.gmail.com> <40ED6392.2000107@franklinmint.fm> <3f1451f504070810104a5122e7@mail.gmail.com> <3f1451f504070810296ca252e7@mail.gmail.com> <p0611044fbd18e903bdd9@[10.20.30.249]> <40F37A14.6040908@aol.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 Mon, 12 Jul 2004 22:58:44 -0700, John Panzer <jpanzer@aol.net> wrote:
> I am uncertain about making Digest Auth a SHOULD rather than a MUST.
> What's the reason for leaving the wriggle room?

Some implementations (most wikis, some comment systems) have no need
for authentication of any kind.

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Tue Jul 13 08: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 IAA07458
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 08:58: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 i6DCewCj026818;
	Tue, 13 Jul 2004 05:40: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 i6DCewxq026817;
	Tue, 13 Jul 2004 05:40:58 -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 i6DCewdM026811
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 05:40:58 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from phys-bur-1 ([129.148.9.72])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6DCexil025739
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 06:40:59 -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 <0I0S00L01J13CW@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com)
 for atom-syntax@imc.org; Tue, 13 Jul 2004 08:40:59 -0400 (EDT)
Received: from mercury (vpn-129-150-32-132.Central.Sun.COM [129.150.32.132])
 by bur-mail1.east.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
 with ESMTP id <0I0S00L5KJ86SZ@bur-mail1.east.sun.com> for atom-syntax@imc.org;
 Tue, 13 Jul 2004 08:40:59 -0400 (EDT)
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BkMaW-0004bj-00	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 08:40:48 -0400
X-URL: http://nwalsh.com/
Date: Tue, 13 Jul 2004 08:40:46 -0400
From: Norman Walsh <ndw@nwalsh.com>
Subject: Re: Usage Scenarios for Versioning and Extensibility
In-reply-to: <AA8D7D00-D461-11D8-AFCB-000A95BD86C0@mnot.net>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <87acy45bch.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: <20040712214722.79750.qmail@web41212.mail.yahoo.com>
 <AA8D7D00-D461-11D8-AFCB-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-Type: text/plain

/ Mark Nottingham <mnot@mnot.net> was heard to say:

My two cents. I'm aiming here for short, simple, easy to understand
answers.

But in order to be *able* to answer these questions, you have to have
a versioning policy *in place* in V1.0. So here's my suggestion for a
versioning policy for V1.0. My answers below are based on this policy:

- No element in a namespace other than the Atom namespace is allowed
  to change the semantics of any element in the Atom namespace.
  (You can't introduce an extension element that means ignore the
  atom:title and use the atom:summary for the title instead.)

- Any element may have an atom:mustUnderstand attribute. If
  atom:mustUnderstand=true and the element is unrecognized,
  that's an error. Halt and catch fire.

- If you're reading an Atom document with a version identifier that
  you recognize:

  - Unrecognized elements in the Atom namespace are an error.
    Recovery behavior is to ignore them.

  - Unrecognized elements in any other namespace are ignored.

- If you are reading an Atom document with a version identifier that
  you don't recognize:

  - Unrecognized elements in the Atom namespace or any other
    namespace are ignored.

This policy is not sufficient to get the sort of distributed
backwards/forwards compatible processing that DaveO and I describe in
the versioning finding, but I think it's right conceptually. (What I
haven't specified are some ugly details that you need to work out in
order to get around XSD's problems with ambiguity.)

| 1) And it was good... except for that nasty atom:title element; after
| wide deployment experience, it's agreed we need a new version of it.
| So, a new version of Atom is introduced. The new one isn't
| backwards-compatible with the old one.

A backwards-incompatible change tips over the apple cart. This version
of Atom goes in a new namespace; it's a different document type.

This is really painful, so let's plan not to do this, ok? :-)

| 2) Then, we decide we want to add a new metadata element, let's call
| it "fog." So, a new version of Atom is introduced.

One answer is to put this element in a different namespace. Then
there's no problem.

Another answer is to put this element in the Atom namespace and bump
the version identifier. That's no problem either as long as fog doesn't
change the semantics of any other Atom element.

| 3) After a while, someone comes up with a souped-up version of
| atom:title that is backwards-compatible, just *better*. It gets really
| popular, and yet another version of Atom is born.

Bump the version identifier. No problem.

| 4) At the same time, a group of rogue Open Source Software programmers
| descends upon this idyllic scene and introduces its own extensions. Up
| until now, all of our extensions have been approved and incorporated
| by the WG, but these are destined to remain separate.

They get left in a separate namespace. Applications that recognize them,
do, and applications that don't, don't.

If they get put in the Atom namespace then they fall into either
cateogry 1 or category 2.

| 5) Finally, in 2010, we realise that the Atom feed and entry
| containers aren't really doing the job, and we need to change their
| model. Yet Another Version of Atom (YAVA) comes into being.

That's just 1 or 2 again, depending on whether or not the change is
backwards compatible.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Most human beings have an almost
http://nwalsh.com/            | infinite capacity for taking things for
                              | granted.--Aldous Huxley

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA89hPOyltUcwYWjsRAglkAJ4mkEnmjYHpprDUr94p5EODtNIH8ACfS9ZA
U1nCtpKjAZfgX/x80IUq578=
=g9YK
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Tue Jul 13 09: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 JAA07809
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 09:05:12 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DCjshS028199;
	Tue, 13 Jul 2004 05:45:54 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6DCjse8028198;
	Tue, 13 Jul 2004 05:45:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DCjsEB028189
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 05:45:54 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from phys-bur-1 ([129.148.9.72])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6DCjuil028051
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 06:45:56 -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 <0I0S00M01JDVGM@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com)
 for atom-syntax@imc.org; Tue, 13 Jul 2004 08:45:55 -0400 (EDT)
Received: from mercury (vpn-129-150-32-132.Central.Sun.COM [129.150.32.132])
 by bur-mail1.east.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
 with ESMTP id <0I0S00LPNJGJSZ@bur-mail1.east.sun.com> for atom-syntax@imc.org;
 Tue, 13 Jul 2004 08:45:55 -0400 (EDT)
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BkMfN-0004mD-00	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 08:45:49 -0400
X-URL: http://nwalsh.com/
Date: Tue, 13 Jul 2004 08:45:46 -0400
From: Norman Walsh <ndw@nwalsh.com>
Subject: Re: Version vs. Namespace
In-reply-to: <0E4C6EEF-D475-11D8-AFCB-000A95BD86C0@mnot.net>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <87658s5b45.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: <20040713011524.45752.qmail@web41210.mail.yahoo.com>
 <E68F6C54-D470-11D8-AE39-000A95A51C9E@sun.com>
 <0E4C6EEF-D475-11D8-AFCB-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-Type: text/plain

/ Mark Nottingham <mnot@mnot.net> was heard to say:
| On Jul 12, 2004, at 7:03 PM, Tim Bray wrote:
|
|>
|> On Jul 12, 2004, at 6:15 PM, Dare Obasanjo wrote:
|>
|>> Those rules seem fine with me except they don't
|>> account for backwards incompatible changes. This is a
|>> key part of any versioning story.
|>
|> For incompatible changes, I really only see two options:
|>
|> 1. Provide a way to signal MustUnderstand so that back-rev software
|> can fail gracefully.
|> 2. Use a different namespace.
|
| Can you spell out option #1 (or give a reference into this sea of bits
| we call the mailing list)? On the face of it, I don't see how a mU bit
| is adequate on its own (it makes a lot of sense in conjunction with a
| different namespace).

In a nutshell, if an application sees:

  <atom:undefinedName atom:mustUnderstand="true">xxx</atom:undefinedName>

then it must halt and catch fire. If it sees:

  <atom:undefinedName atom:mustUnderstand="false">xxx</atom:undefinedName>

it just ignores the element. I feel pretty strongly that the default
value of atom:mustUnderstand should be "false", but it's an open
question.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Endurance is frequently a form of
http://nwalsh.com/            | indecision.--Elizabeth Bibesco

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA89l6OyltUcwYWjsRAlXIAJ9z5R9NppXfT1V5x8tAOIl8AX+Q3QCfUm3V
uEA6xHR8mGzZHBNCYrNxm6Q=
=0Vub
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Tue Jul 13 09:11: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 JAA08264
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 09:11:44 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DCrlF5030372;
	Tue, 13 Jul 2004 05: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 i6DCrlji030371;
	Tue, 13 Jul 2004 05: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-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 i6DCrklv030365
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 05:53:46 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from phys-bur-1 ([129.148.9.72])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i6DCpf53016634
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 06:51:41 -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 <0I0S00001JPZFU@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com)
 for atom-syntax@imc.org; Tue, 13 Jul 2004 08:53:47 -0400 (EDT)
Received: from mercury (vpn-129-150-32-132.Central.Sun.COM [129.150.32.132])
 by bur-mail1.east.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
 with ESMTP id <0I0S00LHDJTESZ@bur-mail1.east.sun.com> for atom-syntax@imc.org;
 Tue, 13 Jul 2004 08:53:47 -0400 (EDT)
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BkMmv-0004qj-00	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 08:53:37 -0400
X-URL: http://nwalsh.com/
Date: Tue, 13 Jul 2004 08:53:37 -0400
From: Norman Walsh <ndw@nwalsh.com>
Subject: Re: PaceElementOrder: options
In-reply-to: <F4660158-D47F-11D8-AE39-000A95A51C9E@sun.com>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <871xjg5ar2.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: <20040712221217.55674.qmail@web41508.mail.yahoo.com>
 <79B7857D-D478-11D8-AFCB-000A95BD86C0@mnot.net>
 <F4660158-D47F-11D8-AE39-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-Type: text/plain

/ Tim Bray <Tim.Bray@Sun.COM> was heard to say:
| Basically, do we
| 1) think that the benefits of enabling XML Schema use exceed the costs
| of strict ordering, or
| 2) think that the benefits of loose ordering exceed the costs of
| making life harder for the schema-dependent, or
| 3) are we missing the point because the trade-off isn't real or
| there's a way to dodge it or something?
|
| These seem like reasonable open questions that we should discuss
| reasonably. -Tim

I've already said I won't stand in the way of consensus on this issue,
but let me make one more point: if we decide that the elements should
be in an order, we then have to decide *what* order. I'd be just as
happy to avoid having that discussion :-)

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Until death, it is all life.-- Cervantes
http://nwalsh.com/            | 

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA89tROyltUcwYWjsRAusQAJ9PFDiJS9mOfrsSgcS+EzxYPUcoCgCdEi98
EUok0WXRiyJyS66nnpTM6GM=
=+2zo
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Tue Jul 13 09:12:11 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08286
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 09:12: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 i6DCuWYh031128;
	Tue, 13 Jul 2004 05:56: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 i6DCuWHn031127;
	Tue, 13 Jul 2004 05:56:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web41507.mail.yahoo.com (web41507.mail.yahoo.com [66.218.93.90])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6DCuVuM031093
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 05:56:31 -0700 (PDT)
	(envelope-from randymorin@yahoo.com)
Message-ID: <20040713125623.8817.qmail@web41507.mail.yahoo.com>
Received: from [24.43.182.164] by web41507.mail.yahoo.com via HTTP; Tue, 13 Jul 2004 05:56:23 PDT
Date: Tue, 13 Jul 2004 05:56:23 -0700 (PDT)
From: Randy Charles Morin <randymorin@yahoo.com>
Reply-To: randy@kbcafe.com
Subject: Re: PaceElementOrder: options 
To: Mark Nottingham <mnot@mnot.net>, randy@kbcafe.com
Cc: Atomlist <atom-syntax@imc.org>
In-Reply-To: <5FBE7B64-D4A5-11D8-9691-000A95BD86C0@mnot.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-2087829775-1089723383=:6945"
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>


--0-2087829775-1089723383=:6945
Content-Type: text/plain; charset=us-ascii

Your understanding is accurate, but argumentative. The tools can be made to work w/ an XSD unfriendly vocabulary, but they will be much more difficult to use. Assigning the title of an entry goes from this
   entry.title = "Hello";
to this
   entry.Items = new XmlNode[1];
   entry.Items[x] = "Hello";
   entry.ItemTypes[x] = entryItemTypes.title;
Thanks,
 
Randy
http://www.kbcafe.com


Mark Nottingham <mnot@mnot.net> wrote:
OK by me; I take it my characterisation of the benefits of ordering 
were on-target? I want to make sure I understand the pros.

Cheers,

On Jul 13, 2004, at 12:59 AM, Randy Charles Morin wrote:

> I think we've put all the cards on the table and we come to a choice. 
> Not that this choice isn't already made or needs to be made.
> • Order the elements because it will help some tools do a better job.
> • Don't order the elements because it's more difficult.
>
> Agreed? Everything else seems to be just argumentative.
> Thanks,
>
> Randy
> http://www.kbcafe.com
>
>  
>
> Mark Nottingham wrote:
>
> On Jul 12, 2004, at 9:25 PM, Randy Charles Morin wrote:
>
> > 1. XSD.exe -
> > http://msdn.microsoft.com/library/en-us/cptools/html/
> > cpconXMLSchemaDefinitionToolXsdexe.asp
> > 2. WSDL.exe -
> > http://msdn.microsoft.com/library/en-us/cptools/html/
> > cpgrfWebServicesDescriptionLanguageToolWsdlexe.asp
> > 3. XMLSpy - http://www.altova.com/products_ide.html
> > 4. VS.NET - http://msdn.microsoft.com/vstudio/
> > 5. Apache Axis - http://ws.apache.org/axis/
> > 6. MSSOAP SDK -
> > http://www.microsoft.com/downloads/details.aspx?FamilyId=C943C0DD-
> > CEEC-4088-9753-86F052EC8450&displaylang=en
> > 7. IBM SOAP4J - http://www.alphaworks.ibm.com/tech/soap4j/
> >
> > And others that I haven't used.
> > 1. Code Generation Extensions -
> > http://www.gotdotnet.com/Community/Workspaces/Workspace.aspx?
> > id=80258a8c-bb4c-48e6-948b-05f6da568f55
> > 2. Castor Eclipse plugins - http://xdoclipse.sourceforge.net/
> > 3. WSDL2Java Eclipse plugin -
> > http://www.myspotter.com/wsdl2java.shtml
> > 4. Novell's jBroker -
> > 
> http://www.novell.com/documentation/workbench41/docs/jbroker-web/docs/
> > reference/tools/wsdl2java.html
> > 5. Webmethods -
> > http://www.webmethods.com/docs/glue/api/electric/wsdl/tools/
> > WSDL2Java.html
>
> OK, that's a good list.
>
> Tell me if I've got this right -- if we don't have any ordering, these
> tools will not be able to automatically generate code that understands
> the cardinality of atom elements; e.g., "MUST have only one title,"
> "MAY have up to three content sections" (I made these up). However,
> they will still be able to generate some code; it's just that any
> consideration of cardinality will have to be hand-coded in.
>
> Are there any other semantically significant things that such a
> decision would disable Schema from describing?
>
> Looking at that case, how would an implementation use that information,
> except through validation? I.e., would the cardinality information 
> from
> the schema ever actually get used by an aggregator? If so, how?
>
> From the other side, the major problem I've heard is that ordering is
> hard to remember, and may cause more instances to be invalid. From my
> experience, this is true; it's annoying when a metadata-oriented
> application requires you to put elements in an order, even though it
> isn't meaningful. It isn't the end of the world, of course, because
> people will have references, validators, etc.
>
> Are there any other downsides to ordering? I will grant that part of my
> motivation is a) a visceral and growing dislike of XML Schema and b) a
> perhaps-too-pedantic belief that ordering, when required, should be
> semantically significant. Let's leave those to the side.
>
> My take is this: it's about programmer efficiency -- not capability --
> vs. ease *and* correctness of authoring. Considering that programmers
> are a) a smaller and more knowledgeable population, and b) they 
> program
> it once, while authoring is a continual process, my leaning is towards
> unordered elements in Atom.
>
> The fact that a good, solid Atom library that handles this stuff
> automagically will remove the burden from the programmer is what
> cemented it for me. That does require such a library to be built, 
> while
> the libraries above are already existant, but I suspect people are
> going to build some good Atom libraries anyway, because there's a lot
> that Schema can't capture, no matter what we do.
>
> > Thanks and sorry about that last one,
>
> Not at all - there's heat here (on all sides, I think), but light as
> well (ditto), and I for one don't mind a bit of give-and-take if it
> gets us closer to the answer. I assumed you were of a like mind -- a
> complement, I hope :)
>
> --
> Mark Nottingham http://www.mnot.net/
>
>
> Do you Yahoo!?
> Yahoo! Mail - Helps protect you from nasty viruses.

--
Mark Nottingham http://www.mnot.net/



		
---------------------------------
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
--0-2087829775-1089723383=:6945
Content-Type: text/html; charset=us-ascii

<DIV>
<DIV>Your understanding is accurate, but argumentative. The tools can be made to work w/ an XSD unfriendly vocabulary, but they will be much more difficult to use. Assigning the title of an entry goes from this</DIV>
<DIV>&nbsp;&nbsp; entry.title = "Hello";</DIV>
<DIV>to this</DIV>
<DIV>&nbsp;&nbsp; entry.Items = new XmlNode[1];</DIV>
<DIV>&nbsp;&nbsp;&nbsp;entry.Items[x] = "Hello";</DIV>
<DIV>&nbsp;&nbsp; entry.ItemTypes[x] = entryItemTypes.title;</DIV>
<DIV>Thanks,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Randy</DIV>
<DIV><A href="http://www.kbcafe.com/">http://www.kbcafe.com</A></DIV>
<DIV><BR><BR><B><I>Mark Nottingham &lt;mnot@mnot.net&gt;</I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">OK by me; I take it my characterisation of the benefits of ordering <BR>were on-target? I want to make sure I understand the pros.<BR><BR>Cheers,<BR><BR>On Jul 13, 2004, at 12:59 AM, Randy Charles Morin wrote:<BR><BR>&gt; I think we've put all the cards on the table and we come to a choice. <BR>&gt; Not that this choice isn't already made or needs to be made.<BR>&gt; • Order the elements because it will help some tools do a better job.<BR>&gt; • Don't order the elements because it's more difficult.<BR>&gt;<BR>&gt; Agreed? Everything else seems to be just argumentative.<BR>&gt; Thanks,<BR>&gt;<BR>&gt; Randy<BR>&gt; http://www.kbcafe.com<BR>&gt;<BR>&gt; &nbsp;<BR>&gt;<BR>&gt; Mark Nottingham <MNOT@MNOT.NET>wrote:<BR>&gt;<BR>&gt; On Jul 12, 2004, at 9:25 PM, Randy Charles Morin wrote:<BR>&gt;<BR>&gt; &gt; 1. XSD.exe -<BR>&gt; &gt;
 http://msdn.microsoft.com/library/en-us/cptools/html/<BR>&gt; &gt; cpconXMLSchemaDefinitionToolXsdexe.asp<BR>&gt; &gt; 2. WSDL.exe -<BR>&gt; &gt; http://msdn.microsoft.com/library/en-us/cptools/html/<BR>&gt; &gt; cpgrfWebServicesDescriptionLanguageToolWsdlexe.asp<BR>&gt; &gt; 3. XMLSpy - http://www.altova.com/products_ide.html<BR>&gt; &gt; 4. VS.NET - http://msdn.microsoft.com/vstudio/<BR>&gt; &gt; 5. Apache Axis - http://ws.apache.org/axis/<BR>&gt; &gt; 6. MSSOAP SDK -<BR>&gt; &gt; http://www.microsoft.com/downloads/details.aspx?FamilyId=C943C0DD-<BR>&gt; &gt; CEEC-4088-9753-86F052EC8450&amp;displaylang=en<BR>&gt; &gt; 7. IBM SOAP4J - http://www.alphaworks.ibm.com/tech/soap4j/<BR>&gt; &gt;<BR>&gt; &gt; And others that I haven't used.<BR>&gt; &gt; 1. Code Generation Extensions -<BR>&gt; &gt; http://www.gotdotnet.com/Community/Workspaces/Workspace.aspx?<BR>&gt; &gt; id=80258a8c-bb4c-48e6-948b-05f6da568f55<BR>&gt; &gt; 2. Castor&nbsp;Eclipse plugins -
 http://xdoclipse.sourceforge.net/<BR>&gt; &gt; 3. WSDL2Java Eclipse plugin -<BR>&gt; &gt; http://www.myspotter.com/wsdl2java.shtml<BR>&gt; &gt; 4. Novell's jBroker -<BR>&gt; &gt; <BR>&gt; http://www.novell.com/documentation/workbench41/docs/jbroker-web/docs/<BR>&gt; &gt; reference/tools/wsdl2java.html<BR>&gt; &gt; 5. Webmethods -<BR>&gt; &gt; http://www.webmethods.com/docs/glue/api/electric/wsdl/tools/<BR>&gt; &gt; WSDL2Java.html<BR>&gt;<BR>&gt; OK, that's a good list.<BR>&gt;<BR>&gt; Tell me if I've got this right -- if we don't have any ordering, these<BR>&gt; tools will not be able to automatically generate code that understands<BR>&gt; the cardinality of atom elements; e.g., "MUST have only one title,"<BR>&gt; "MAY have up to three content sections" (I made these up). However,<BR>&gt; they will still be able to generate some code; it's just that any<BR>&gt; consideration of cardinality will have to be hand-coded in.<BR>&gt;<BR>&gt; Are there any other semantically signi!
 ficant
 things that such a<BR>&gt; decision would disable Schema from describing?<BR>&gt;<BR>&gt; Looking at that case, how would an implementation use that information,<BR>&gt; except through validation? I.e., would the cardinality information <BR>&gt; from<BR>&gt; the schema ever actually get used by an aggregator? If so, how?<BR>&gt;<BR>&gt; From the other side, the major problem I've heard is that ordering is<BR>&gt; hard to remember, and may cause more instances to be invalid. From my<BR>&gt; experience, this is true; it's annoying when a metadata-oriented<BR>&gt; application requires you to put elements in an order, even though it<BR>&gt; isn't meaningful. It isn't the end of the world, of course, because<BR>&gt; people will have references, validators, etc.<BR>&gt;<BR>&gt; Are there any other downsides to ordering? I will grant that part of my<BR>&gt; motivation is a) a visceral and growing dislike of XML Schema and b) a<BR>&gt; perhaps-too-pedantic belief that ordering, when
 required, should be<BR>&gt; semantically significant. Let's leave those to the side.<BR>&gt;<BR>&gt; My take is this: it's about programmer efficiency -- not capability --<BR>&gt; vs. ease *and* correctness of authoring. Considering that programmers<BR>&gt; are a) a smaller and more knowledgeable population, and b) they <BR>&gt; program<BR>&gt; it once, while authoring is a continual process, my leaning is towards<BR>&gt; unordered elements in Atom.<BR>&gt;<BR>&gt; The fact that a good, solid Atom library that handles this stuff<BR>&gt; automagically will remove the burden from the programmer is what<BR>&gt; cemented it for me. That does require such a library to be built, <BR>&gt; while<BR>&gt; the libraries above are already existant, but I suspect people are<BR>&gt; going to build some good Atom libraries anyway, because there's a lot<BR>&gt; that Schema can't capture, no matter what we do.<BR>&gt;<BR>&gt; &gt; Thanks and sorry about that last one,<BR>&gt;<BR>&gt; Not at!
  all -
 there's heat here (on all sides, I think), but light as<BR>&gt; well (ditto), and I for one don't mind a bit of give-and-take if it<BR>&gt; gets us closer to the answer. I assumed you were of a like mind -- a<BR>&gt; complement, I hope :)<BR>&gt;<BR>&gt; --<BR>&gt; Mark Nottingham http://www.mnot.net/<BR>&gt;<BR>&gt;<BR>&gt; Do you Yahoo!?<BR>&gt; Yahoo! Mail - Helps protect you from nasty viruses.<BR><BR>--<BR>Mark Nottingham http://www.mnot.net/<BR><BR></BLOCKQUOTE></DIV><p>
		<hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/mail_us/taglines/100/*http://promotions.yahoo.com/new_mail/static/efficiency.html">New and Improved Yahoo! Mail</a> - 100MB free storage!
--0-2087829775-1089723383=:6945--



From owner-atom-syntax@mail.imc.org  Tue Jul 13 09:36: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 JAA09879
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 09:35: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 i6DDHmRl039015;
	Tue, 13 Jul 2004 06: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 i6DDHmRb039013;
	Tue, 13 Jul 2004 06:17:48 -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 i6DDHlve038969
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 06:17:47 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 43398 messnum 6490395 invoked from network[83.70.39.115/83-70-39-115.bas2.prp.dublin.eircom.net]); 13 Jul 2004 13:17:44 -0000
Received: from 83-70-39-115.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.39.115)
  by mail12.svc.cra.dublin.eircom.net (qp 43398) with SMTP; 13 Jul 2004 13:17:44 -0000
Message-ID: <40F3E0F5.80105@dehora.net>
Date: Tue, 13 Jul 2004 14:17:41 +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: PaceElementOrder: options
References: <20040712211533.90350.qmail@web41511.mail.yahoo.com>	<A5343281AE2BD2A2B110E8AF@diva.verity.com>	<40F32E81.4050508@dehora.net> <871xjg6rhy.fsf@nwalsh.com>
In-Reply-To: <871xjg6rhy.fsf@nwalsh.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


Norman Walsh wrote:


> I think any appeal to "normal use of XML" is a stretch.

I don't.

> Hmm. Ok, maybe we should say that's what we have then. Feeds and
> entries aren't dictionaries in the strict sense because they would
> allow duplicate keys, but I expect to be able to write:
> 
>   <atom:entry>
>     <atom:title>...</atom:title>
>     <dc:subject>Some subject</dc:subject>
>     <dc:subject>Another subject</dc:subject>
>     <atom:author><atom:name>Norman Walsh</atom:name></atom:author>
>     <geo:lat>42.4</geo:lat>
>     <geo:long>-72.2</geo:long>
>     <dc:subject>Yet one more subject</dc:subject>
>     <atom:modified>2004-07-12T08:38:44Z</atom:modified>
>     <atom:link rel="alternate"
>                href="http://norman.walsh.name/2004/07/12/someEssay"/>
>   </atom:entry>

"Yuck", would be my technical assessment :) however... the pace 
we're talking about (explicitly) doen't deal with order of entry 
children just feed children (I punted). Going by your rnc, can I 
assume you expect to write:

<feed>
   <entry>
     ...
   </entry>
   <tagline>FD85 1117 1888 1681 7689 B5DF </tagline>
   <entry>
       ...
   </entry>
   <entry>
       ...
   </entry>
   <entry>
       ...
   </entry>
   <entry>
       ...
   </entry>
   <entry>
       ...
   </entry>
   <title>Bill de hÓra</title>

   <entry>
     ...
   </entry>
   <modified>2004-07-12T18:56:24Z</modified>
   <entry>
     ...
   </entry>

   <generator
        url="http://www.movabletype.org/"
        version="2.64">Movable Type</generator>
   <entry>
     ...
   </entry>
   <copyright>Copyright (c) 2004, dehora</copyright>
   <entry>
     ...
   </entry>
   <entry>
     ...
   </entry>
   <id>tag:www.dehora.net,2004:/journal//2</id>
   <link
     rel="alternate"
     type="text/html"
     href="http://www.dehora.net/journal/" />
</feed>

?

cheers
Bill



From owner-atom-syntax@mail.imc.org  Tue Jul 13 09: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 JAA09949
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 09: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 i6DDGtSJ038687;
	Tue, 13 Jul 2004 06:16: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 i6DDGt7m038686;
	Tue, 13 Jul 2004 06:16:55 -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 i6DDGsw4038658
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 06:16:55 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 67964 messnum 1914065 invoked from network[83.70.39.115/83-70-39-115.bas2.prp.dublin.eircom.net]); 13 Jul 2004 13:16:51 -0000
Received: from 83-70-39-115.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.39.115)
  by mail02.svc.cra.dublin.eircom.net (qp 67964) with SMTP; 13 Jul 2004 13:16:51 -0000
Message-ID: <40F3E0C0.5060508@dehora.net>
Date: Tue, 13 Jul 2004 14:16:48 +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: RELAX NG Grammar for draft-...-00.txt
References: <87eknkow28.fsf@nwalsh.com> <877jtaldla.fsf@nwalsh.com>
In-Reply-To: <877jtaldla.fsf@nwalsh.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


Norman Walsh wrote:

> # atom:feed
> # TODO: Test for multiple atom:link/@rel='alternate' with the same @type
> # The following tests are simple to do, but my validator is giving me trouble.
> # TODO: Debug and add them back
> #       Test for at least one atom:link/@rel='alternate'
> #       Test for atom:author or all atom:entry have atom:author
> 
> atomFeed =
>    element atom:feed {
>    atomCommonAttributes,
>    atomVersionAttribute,
>    (atomTitle
>     & atomLink+
>     & atomAuthor?
>     & atomContributor*
>     & atomTagline?
>     & atomId?
>     & atomGenerator?
>     & atomCopyright?
>     & atomInfo?
>     & atomModified
>     & atomEntry*



>     & anyElement*)
> }

Why not use anyForeignElement here?

cheers
Bill



From owner-atom-syntax@mail.imc.org  Tue Jul 13 09: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 JAA10198
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 09: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 i6DDKOVi039905;
	Tue, 13 Jul 2004 06:20: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 i6DDKOiC039904;
	Tue, 13 Jul 2004 06:20: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 (mproxy.gmail.com [216.239.56.242])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6DDKOnX039897
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 06:20:24 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so11283337cwc
        for <atom-syntax@imc.org>; Tue, 13 Jul 2004 06:20:24 -0700 (PDT)
Received: by 10.11.99.40 with SMTP id w40mr150256cwb;
        Tue, 13 Jul 2004 06:20:23 -0700 (PDT)
Message-ID: <3f1451f504071306203418e4c1@mail.gmail.com>
Date: Tue, 13 Jul 2004 09:20:23 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Subject: Re: Usage Scenarios for Versioning and Extensibility
Cc: Dare Obasanjo <kpako@yahoo.com>, Atom Syntax <atom-syntax@imc.org>,
        Tim Bray <tim.bray@sun.com>
In-Reply-To: <AA8D7D00-D461-11D8-AFCB-000A95BD86C0@mnot.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <20040712214722.79750.qmail@web41212.mail.yahoo.com> <AA8D7D00-D461-11D8-AFCB-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 Mon, 12 Jul 2004 17:14:54 -0700, Mark Nottingham <mnot@mnot.net> wrote:
> 
> On Jul 12, 2004, at 2:47 PM, Dare Obasanjo wrote:
> 
> > My primary use case for versioning is simple. How can
> > an aggregator which encounters a different version of
> > Atom from one its seen before know whether it is
> > backwards compatible or not? With RSS, the assumption
> > I use in RSS Bandit is that all feeds are RSS 2.0 and
> > the version attribute is ignored.
> 
> I'd like to make this a bit more concrete.

Thanks for setting this conversation on solid ground.
I've tried to fill out the examples using Tim's model.

>
> 0) Let's imagine that Atom 1.0 has been released and finalised in all
> of its glory.

<feed version="1.0" xmlns="atom" ...
   <title>My Stuff</title>

> 
> 1) And it was good... except for that nasty atom:title element; after
> wide deployment experience, it's agreed we need a new version of it.
> So, a new version of Atom is introduced. The new one isn't
> backwards-compatible with the old one.

I would argue against making  a non-backward compatible
change to an element. How about 
introducing a new 'super-title' element in a 2.0 release:

<feed version="2.0" xmlns="atom" ...
   <title>My Stuff</title>
   <super-title>My Extended Stuff</super-title>


> 2) Then, we decide we want to add a new metadata element, let's call it
> "fog." So, a new version of Atom is introduced.

<feed version="3.0" xmlns="atom" ...
   <title>My Stuff</title>
   <super-title>My Extended Stuff</super-title>
   <fog/>


> 3) After a while, someone comes up with a souped-up version of
> atom:title that is backwards-compatible, just *better*. It gets really
> popular, and yet another version of Atom is born.

Note that title and super-title are both
legal but 'super-title' is depracated.

<feed version="4.0" xmlns="atom" ...
   <title>My Stuff</title>
   <super-title>My Extended Stuff</super-title>
   <fog/>


> 4) At the same time, a group of rogue Open Source Software programmers
> descends upon this idyllic scene and introduces its own extensions. Up
> until now, all of our extensions have been approved and incorporated by
> the WG, but these are destined to remain separate.

All of these go in their own namespaces. It is up to 
the authors of those extensions to flag which 
versions of Atom that they interoperate with.

<feed version="4.0" xmlns="atom" ...
   <title>My Stuff</title>
   <super-title>My Extended Stuff</super-title>
   <fog/>
   <foo:bar/>

> 5) Finally, in 2010, we realise that the Atom feed and entry containers
> aren't really doing the job, and we need to change their model. Yet
> Another Version of Atom (YAVA) comes into being.

That is a rather fundamental change for which I would hope
you would select another namespace and mime-type:

<notfeed version="1.0" xmlns="something-besides-atom" ...
   <title>My Stuff</title>
   <super-title>My Extended Stuff</super-title>
   <fog/>
   <foo:bar/>

> Any proposal for versioning should address at least these situations,
> show how the various extensions and changes are identified and
> disambiguated, and should explain how software is to handle them. They
> should also consider how combinations of these scenarios are handled.

Tim's policy seems to work, but with the following caveat/addition:

1. Newer versions of the format are kept backward 
compatible with older versions. Note that in these examples that 
was done by not changing an element in a non-backward compatible 
way but by introducing a new element. Note that in step 1.0 the
'super-title' could have also been introduced as 'title' but in
a different namespace. If you must break 
backward compatibility do it in a new format/namespace/mime-type.

I will also note that the use of mustUnderstand is not 
of use in any of the above scenarios. Are there other 
formats where 'mustUnderstand' semantics have been
successfully deployed? I don't think SOAP's history 
with mustUnderstand is one to point to as representing
'success'. [1]


[1] http://www.pocketsoap.com/weblog/soapInterop/base.html

    Thanks,
    -joe



From owner-atom-syntax@mail.imc.org  Tue Jul 13 09:52: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 JAA10787
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 09:52: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 i6DDYtFB044558;
	Tue, 13 Jul 2004 06:34:55 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6DDYtF3044557;
	Tue, 13 Jul 2004 06:34: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 i6DDYsQZ044501
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 06:34:55 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 55012 messnum 5051503 invoked from network[83.70.39.115/83-70-39-115.bas2.prp.dublin.eircom.net]); 13 Jul 2004 13:34:51 -0000
Received: from 83-70-39-115.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.39.115)
  by mail04.svc.cra.dublin.eircom.net (qp 55012) with SMTP; 13 Jul 2004 13:34:51 -0000
Message-ID: <40F3E4F8.9000608@dehora.net>
Date: Tue, 13 Jul 2004 14:34:48 +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: Usage Scenarios for Versioning and Extensibility
References: <20040712214722.79750.qmail@web41212.mail.yahoo.com> <AA8D7D00-D461-11D8-AFCB-000A95BD86C0@mnot.net> <3f1451f504071306203418e4c1@mail.gmail.com>
In-Reply-To: <3f1451f504071306203418e4c1@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


Joe Gregorio wrote:

> On Mon, 12 Jul 2004 17:14:54 -0700, Mark Nottingham <mnot@mnot.net> wrote:

> 
> Tim's policy seems to work, but with the following caveat/addition:
> 
> 1. Newer versions of the format are kept backward 
> compatible with older versions. 

Yes, I think that is entailed by rules 3 and 4 (they seem to 
conflict/fail without it).

The idea is of adding new element names or QNames rather than 
altering existing ones approaches what Dan Brickley described as 
"monotonic" elsewhere... and on that, I would be happy to see a 
versioning rule/policy that new elements (from any namespace) added 
to new version will not affect the expected behaviour over previous 
elements and versions, ie there's no versioning approach that 
involves/encourages co-occurence constraints between elements; but I 
have no idea how to test for it (except maybe trying to write it 
down in xsd).

cheers
Bill



From owner-atom-syntax@mail.imc.org  Tue Jul 13 10:00: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 KAA11260
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 10:00: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 i6DDhUMe046212;
	Tue, 13 Jul 2004 06:43: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 i6DDhUo0046211;
	Tue, 13 Jul 2004 06:43: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 i6DDhTZE046196;
	Tue, 13 Jul 2004 06:43: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 1BkNZA-0005BY-4I; Tue, 13 Jul 2004 13:43:28 +0000
Message-ID: <40F3E700.5020009@franklinmint.fm>
Date: Tue, 13 Jul 2004 09:43:28 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Hoffman / IMC <phoffman@imc.org>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceSecurityServices
References: <BD18BE9D.1386E%mint@franklinmint.fm> <p06110455bd18ff07e6da@[10.20.30.249]>
In-Reply-To: <p06110455bd18ff07e6da@[10.20.30.249]>
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


Paul Hoffman / IMC wrote:

>
> At 10:18 PM -0400 7/12/04, Robert Sayre wrote:
>
>> -1. You are correct that no one is enthusiastic about WSSE. However, 
>> many
>> have spoken in favor of a Digest workalike with different header 
>> names, so
>> Apache doesn't eat them. I think the spec should reference or define one
>> such mechanism.
>
> Assuming someone else creates such a mechanism, I'm fine with the base 
> spec referencing it as a MAY. Is that what you were thinking, or did 
> you want a SHOULD that is parallel to Digest Auth?


I think the spec isn't done until we have an optional authentication 
scheme that works for CGI scripts on standard Apache configurations. We 
*know* that the existing options are inadequate for this common use 
case. I'm fine with the base spec referencing another draft as a MAY.

Robert Sayre



From owner-atom-syntax@mail.imc.org  Tue Jul 13 10:00: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 KAA11336
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 10:00: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 i6DDh4wH046165;
	Tue, 13 Jul 2004 06: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 i6DDh4mg046164;
	Tue, 13 Jul 2004 06:43:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.84])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DDh3Jp046157
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 06:43:03 -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 i6DDh697010668;
	Tue, 13 Jul 2004 06:43:06 -0700 (PDT)
Received: from [192.168.1.100] (h00080d858303.ne.client2.attbi.com [24.61.1.243])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id i6DDgVLG008787;
	Tue, 13 Jul 2004 06:43:05 -0700 (PDT)
In-Reply-To: <40F3CC36.9080001@intertwingly.net>
References: <BD1995C2.1F3C6%eric.scheid@ironclad.net.au> <opsa2k75lz6dxgxk@mail.online.no> <CFCD3EC6-D4BA-11D8-82B1-000A95DC3D90@mac.com> <40F3CC36.9080001@intertwingly.net>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-18--250199181; protocol="application/pkcs7-signature"
Message-Id: <7C832F0A-D4D2-11D8-82B1-000A95DC3D90@mac.com>
Cc: Atom-syntax Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: a methodical approach to defining what date  elements we need
Date: Tue, 13 Jul 2004 09:42:30 -0400
To: Sam Ruby <rubys@intertwingly.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-18--250199181
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 13 Jul 2004, at 7:49 am, Sam Ruby wrote:

> Please at least *TRY* to be civil.

That is me being civil. Saying the example isn't valid when it's from a 
real blog isn't in the slightest bit constructive.

> You are also simultaneously maintaining that "(Tim's is the only blog 
> in the universe that is)", which tends to argue against this being a 
> representive sample that one should use to base decisions off of.

That's one way to look at it. The other is that by considering this 
stuff properly and thinking about what people currently do you can end 
up with a much more flexible, meaningful model.

> Let's proceed with the assumption for the moment that this is a 
> representative sample.
>
> max(date-on-page) = 2004-06-13
> min(date-on-pate) = 2004-02-17
>
> There also is a significant date which is reflected both in the URL 
> and in a special sidebar "Around February 20, 2004".
>
> These are three dates that appear significant.  What tags should be 
> used for these?

You always ask this and it seems to serve no purpose other than to send 
the debate down a dead end.

Under PaceEntryDates:
  <created>2004-02-17</created>
  <modified>2004-06-12</modified>
  <issued>2004-06-12</issued>

Under the current draft: Not a clue.

The third date might fit neatly in a "subjective" date, or in 
first-issued if we have that, but I've no idea what its meaning was, so 
I'm only guessing.

Graham
--Apple-Mail-18--250199181
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
9w0BCQUxDxcNMDQwNzEzMTM0MjMwWjAjBgkqhkiG9w0BCQQxFgQU05GBxfvrSdnE6Ht8czZz+RzJ
R+kweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAiNetK+hxnzfwKP8W045FwU4V
mZ7fay0AEPidpEnv35HLFp5p5l+A8gZITv9xev+t0LqxBOfnCigv3NJEmFusZqsb5W1h1xHsfNpU
b5OCT63aUM6vyHRv+PwCWGvB27S10Pp8LLu+S1SwZJgfZpnB/5yPSCS4bHj780Qlv5bTh3QMSxyc
Ea201ANO5++kbNouCs8h0g9rD9g4FWxU+H7sXp08uMuJAHC7djjs6zN7SiXmfW28HDPNR08iWQSe
MdjEeMV/9PPO+t9figHVic79KyuhCkkVTeXdyXjD+wlaohyN4tP44ZjKnNhg3A902wJfpBw5ZVuD
5dhB4MfYdSiELwAAAAAAAA==

--Apple-Mail-18--250199181--



From owner-atom-syntax@mail.imc.org  Tue Jul 13 10:06: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 KAA11844
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 10:06: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 i6DDmONr046738;
	Tue, 13 Jul 2004 06:48: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 i6DDmNl6046737;
	Tue, 13 Jul 2004 06:48: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 (mproxy.gmail.com [216.239.56.251])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6DDmNEX046730
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 06:48:23 -0700 (PDT)
	(envelope-from eliast@gmail.com)
Received: by mproxy.gmail.com with SMTP id r62so520929cwc
        for <atom-syntax@imc.org>; Tue, 13 Jul 2004 06:48:25 -0700 (PDT)
Received: by 10.11.120.25 with SMTP id s25mr380562cwc;
        Tue, 13 Jul 2004 06:48:25 -0700 (PDT)
Message-ID: <905f7c91040713064846d39c57@mail.gmail.com>
Date: Tue, 13 Jul 2004 09:48:25 -0400
From: Elias Torres <eliast@gmail.com>
Reply-To: elias@torrez.us
To: randy@kbcafe.com, Atomlist <atom-syntax@imc.org>
Subject: Re: PaceElementOrder: options
Cc: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <20040713075950.79777.qmail@web41506.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <20040713075950.79777.qmail@web41506.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


I like how Randy and Tim are setting up the discussion. I tend to
agree with both: we need to have order (be strict) for "dumb" tools to
understand and we need to be as simple as possible for users to
publish feeds. But, IF in fact this is a cost-benefit discussion, I
would say that the users would benefit the most (especially since
there are more of them) if we don't impose order. The number of
definitive Atom libraries will be much smaller and good programmers
write those, every other developer can just use them. Now, if a
developer chooses to start from scratch, I think by using XML we have
already given them a starting point, plus a XML Schema with choice
groups.  Lastly, all they would have to do is code up cardinality and
their personal tweaks to their library.

My two cents. 

----- Original Message -----
From: Randy Charles Morin <randymorin@yahoo.com>
Date: Tue, 13 Jul 2004 00:59:50 -0700 (PDT)
Subject: Re: PaceElementOrder: options 
To: Mark Nottingham <mnot@mnot.net>, randy@kbcafe.com
Cc: Atomlist <atom-syntax@imc.org>


I think we've put all the cards on the table and we come to a choice.
Not that this choice isn't already made or needs to be made.


Order the elements because it will help some tools do a better job.

Don't order the elements because it's more difficult.


Agreed? Everything else seems to be just argumentative.
Thanks,


Randy
http://www.kbcafe.com


 


Mark Nottingham <mnot@mnot.net> wrote:


On Jul 12, 2004, at 9:25 PM, Randy Charles Morin wrote:

> 1. XSD.exe - 
> http://msdn.microsoft.com/library/en-us/cptools/html/ 
> cpconXMLSchemaDefinitionToolXsdexe.asp
> 2. WSDL.exe - 
> http://msdn.microsoft.com/library/en-us/cptools/html/ 
> cpgrfWebServicesDescriptionLanguageToolWsdlexe.asp
> 3. XMLSpy - http://www.altova.com/products_ide.html
> 4. VS.NET - http://msdn.microsoft.com/vstudio/
> 5. Apache Axis - http://ws.apache.org/axis/
> 6. MSSOAP SDK - 
> http://www.microsoft.com/downloads/details.aspx?FamilyId=C943C0DD- 
> CEEC-4088-9753-86F052EC8450&displaylang=en
> 7. IBM SOAP4J - http://www.alphaworks.ibm.com/tech/soap4j/
>
> And others that I haven't used.
> 1. Code Generation Extensions - 
> http://www.gotdotnet.com/Community/Workspaces/Workspace.aspx?
 
> id=80258a8c-bb4c-48e6-948b-05f6da568f55
> 2. Castor Eclipse plugins - http://xdoclipse.sourceforge.net/
> 3. WSDL2Java Eclipse plugin - 
> http://www.myspotter.com/wsdl2java.shtml
> 4. Novell's jBroker - 
> http://www.novell.com/documentation/workbench41/docs/jbroker-web/docs/ 
> reference/tools/wsdl2java.html
> 5. Webmethods - 
> http://www.webmethods.com/docs/glue/api/electric/wsdl/tools/ 
> WSDL2Java.html

OK, that's a good list.

Tell me if I've got this right -- if we don't have any ordering, these 
tools will not be able to automatically generate code that understands 
the cardinality of atom elements; e.g., "MUST have only one title," 
"MAY have up to three content sections" (I made these up). However, 
they will still be able to generate some code; it's just that any 
consideration of cardinality will have to be hand-coded in.

Are there any other semantically signif!
 icant
 things that such a 
decision would disable Schema from describing?

Looking at that case, how would an implementation use that information, 
except through validation? I.e., would the cardinality information from 
the schema ever actually get used by an aggregator? If so, how?

From the other side, the major problem I've heard is that ordering is 
hard to remember, and may cause more instances to be invalid. From my 
experience, this is true; it's annoying when a metadata-oriented 
application requires you to put elements in an order, even though it 
isn't meaningful. It isn't the end of the world, of course, because 
people will have references, validators, etc.

Are there any other downsides to ordering? I will grant that part of my 
motivation is a) a visceral and growing dislike of XML Schema and b) a 
perhaps-too-pedantic belief that ordering, when required, should be 
semantically significant. Let's leave those to the
 side.

My take is this: it's about programmer efficiency -- not capability -- 
vs. ease *and* correctness of authoring. Considering that programmers 
are a) a smaller and more knowledgeable population, and b) they program 
it once, while authoring is a continual process, my leaning is towards 
unordered elements in Atom.

The fact that a good, solid Atom library that handles this stuff 
automagically will remove the burden from the programmer is what 
cemented it for me. That does require such a library to be built, while 
the libraries above are already existant, but I suspect people are 
going to build some good Atom libraries anyway, because there's a lot 
that Schema can't capture, no matter what we do.

> Thanks and sorry about that last one,

Not at all - there's heat here (on all sides, I think), but light as 
well (ditto), and I for one don't mind a bit of give-and-take if it 
gets us closer to the answer. !
 I assumed
 you were of a like mind -- a 
complement, I hope :)

--
Mark Nottingham http://www.mnot.net/




		________________________________
Do you Yahoo!?

Yahoo! Mail - Helps protect you from nasty viruses.



From owner-atom-syntax@mail.imc.org  Tue Jul 13 10: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 KAA12051
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 10:08: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 i6DDqAnd046991;
	Tue, 13 Jul 2004 06: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 i6DDqA0N046990;
	Tue, 13 Jul 2004 06:52:10 -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 i6DDq9pO046980
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 06:52:10 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 18923 messnum 9279859 invoked from network[83.70.39.115/83-70-39-115.bas2.prp.dublin.eircom.net]); 13 Jul 2004 13:52:06 -0000
Received: from 83-70-39-115.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.39.115)
  by mail10.svc.cra.dublin.eircom.net (qp 18923) with SMTP; 13 Jul 2004 13:52:06 -0000
Message-ID: <40F3E903.30505@dehora.net>
Date: Tue, 13 Jul 2004 14:52:03 +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: Usage Scenarios for Versioning and Extensibility
References: <20040712214722.79750.qmail@web41212.mail.yahoo.com> <AA8D7D00-D461-11D8-AFCB-000A95BD86C0@mnot.net> <87acy45bch.fsf@nwalsh.com>
In-Reply-To: <87acy45bch.fsf@nwalsh.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


Norman Walsh wrote:

> - No element in a namespace other than the Atom namespace is allowed
>   to change the semantics of any element in the Atom namespace.
>   (You can't introduce an extension element that means ignore the
>   atom:title and use the atom:summary for the title instead.)

I would like to see this extended for elements in the atom 
namespace,, or at least make the hurdle to getting this by very high.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Tue Jul 13 10:11: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 KAA12679
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 10:11: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 i6DDsrYI047251;
	Tue, 13 Jul 2004 06:54: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 i6DDsrCZ047250;
	Tue, 13 Jul 2004 06:54:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DDsqTJ047234
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 06:54:52 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from phys-bur-1 ([129.148.9.72])
	by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i6DDsn0R007199
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 06:54:50 -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 <0I0S00C01MJXTG@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com)
 for atom-syntax@imc.org; Tue, 13 Jul 2004 09:54:49 -0400 (EDT)
Received: from mercury (vpn-129-150-32-132.Central.Sun.COM [129.150.32.132])
 by bur-mail1.east.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
 with ESMTP id <0I0S00LU3MN9SZ@bur-mail1.east.sun.com> for atom-syntax@imc.org;
 Tue, 13 Jul 2004 09:54:49 -0400 (EDT)
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BkNjv-0005kb-00	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 09:54:35 -0400
X-URL: http://nwalsh.com/
Date: Tue, 13 Jul 2004 09:54:35 -0400
From: Norman Walsh <ndw@nwalsh.com>
Subject: Re: PaceElementOrder: options
In-reply-to: <40F3E0F5.80105@dehora.net>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <87r7rg2esk.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: <20040712211533.90350.qmail@web41511.mail.yahoo.com>
 <A5343281AE2BD2A2B110E8AF@diva.verity.com> <40F32E81.4050508@dehora.net>
 <871xjg6rhy.fsf@nwalsh.com> <40F3E0F5.80105@dehora.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-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

/ Bill de h=D3ra <bill@dehora.net> was heard to say:
| "Yuck", would be my technical assessment :) however... the pace we're
| talking about (explicitly) doen't deal with order of entry children

Ah. I didn't realize that. My bad. I object to any proposal that
establishes a fixed order in one place but leaves the other unordered.
Given the similarity of content, I think that's just going to be too
confusing.

| just feed children (I punted). Going by your rnc, can I assume you
| expect to write:

My RNC attempts to implement what the -00 draft says. Personally, I
favor putting all the non-entry feed elements in a wrapper, making
that wrapper the required first element of the feed, and letting the
content of that wrapper be unordered:

<feed>
  <feedinfo>
   <tagline>FD85 1117 1888 1681 7689 B5DF </tagline>
   <title>Bill de h=D3ra</title>
   <modified>2004-07-12T18:56:24Z</modified>
   <generator
        url=3D"http://www.movabletype.org/"
        version=3D"2.64">Movable Type</generator>
   <copyright>Copyright (c) 2004, dehora</copyright>
   <id>tag:www.dehora.net,2004:/journal//2</id>
   <link
     rel=3D"alternate"
     type=3D"text/html"
     href=3D"http://www.dehora.net/journal/" />
  </feedinfo>
  <entry>
    ...
  </entry>
  <entry>
    ...
  </entry>
</feed>

                                        Be seeing you,
                                          norm

=2D-=20
Norman Walsh <ndw@nwalsh.com> | A philosophical contempt of life is no
http://nwalsh.com/            | guarantee of courage in the face of
                              | death.--Gustave Vapereau

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA8+mbOyltUcwYWjsRApMkAJ9AwOwWqqjMdxL2czuFXt0IgG3BTACfSARd
SypUHQCveei70AmzpPI4p44=
=Ke0h
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Tue Jul 13 10:11: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 KAA12699
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 10:11: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 i6DDtYJ5047359;
	Tue, 13 Jul 2004 06:55: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 i6DDtYin047358;
	Tue, 13 Jul 2004 06:55:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DDtXKn047297
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 06:55:34 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from phys-bur-1 ([129.148.9.72])
	by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i6DDtV0R007551
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 06:55:31 -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 <0I0S00C01MJXTG@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com)
 for atom-syntax@imc.org; Tue, 13 Jul 2004 09:55:31 -0400 (EDT)
Received: from mercury (vpn-129-150-32-132.Central.Sun.COM [129.150.32.132])
 by bur-mail1.east.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
 with ESMTP id <0I0S00LWMMO4SZ@bur-mail1.east.sun.com> for atom-syntax@imc.org;
 Tue, 13 Jul 2004 09:55:31 -0400 (EDT)
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BkNkM-0005kv-00	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 09:55:02 -0400
X-URL: http://nwalsh.com/
Date: Tue, 13 Jul 2004 09:55:01 -0400
From: Norman Walsh <ndw@nwalsh.com>
Subject: Re: RELAX NG Grammar for draft-...-00.txt
In-reply-to: <40F3E0C0.5060508@dehora.net>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <87n0242eru.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: <87eknkow28.fsf@nwalsh.com> <877jtaldla.fsf@nwalsh.com>
 <40F3E0C0.5060508@dehora.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-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

/ Bill de h=D3ra <bill@dehora.net> was heard to say:
|
|>     & anyElement*)
|> }
|
| Why not use anyForeignElement here?

Because that's not what the -00 draft says. I think it should be anyForeign=
Element.

                                        Be seeing you,
                                          norm

=2D-=20
Norman Walsh <ndw@nwalsh.com> | Great men too make mistakes, and many
http://nwalsh.com/            | among them do it so often that one is
                              | almost tempted to call them little
                              | men.-- Lichtenberg

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA8+m1OyltUcwYWjsRApipAKCXJfSGAxFdHXdF+Ht/3VsxlVeRWwCfR4U+
3EvEcmqFJ6PUPZTlFIWykIU=
=1UZG
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Tue Jul 13 10:13: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 KAA12943
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 10:13:37 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DDwNDI047554;
	Tue, 13 Jul 2004 06:58: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 i6DDwNkc047553;
	Tue, 13 Jul 2004 06:58: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 (mproxy.gmail.com [216.239.56.253])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6DDwMqn047541
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 06:58:22 -0700 (PDT)
	(envelope-from eliast@gmail.com)
Received: by mproxy.gmail.com with SMTP id r65so464456cwc
        for <atom-syntax@imc.org>; Tue, 13 Jul 2004 06:58:20 -0700 (PDT)
Received: by 10.11.119.3 with SMTP id r3mr188138cwc;
        Tue, 13 Jul 2004 06:58:20 -0700 (PDT)
Message-ID: <905f7c910407130658c3a1445@mail.gmail.com>
Date: Tue, 13 Jul 2004 09:58:20 -0400
From: Elias Torres <eliast@gmail.com>
Reply-To: elias@torrez.us
To: Atom WG <atom-syntax@imc.org>
Subject: Re: PaceSecurityServices
In-Reply-To: <p0611044fbd18e903bdd9@10.20.30.249>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <40E16215.6070507@intertwingly.net>
 <40EC9915.4050406@intertwingly.net>
 <3f1451f504070718267c5526b4@mail.gmail.com>
 <40ED6392.2000107@franklinmint.fm>
 <3f1451f504070810104a5122e7@mail.gmail.com>
 <3f1451f504070810296ca252e7@mail.gmail.com> <p0611044fbd18e903bdd9@10.20.30.249>
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 on Digest-only and +1 on removing WSSE.

On Mon, 12 Jul 2004 18:21:45 -0700, Paul Hoffman / IMC <phoffman@imc.org> wrote:
> 
> OK, I'm seeing a trend here and want to check. It sounds like people
> agree that we want Digest Auth as a SHOULD (not a MUST), not to give
> a SHOULD for the WSSE-like mechanism, and not to describe it in the
> core protocol document. Does that sound right?
> 
> If so, I'll update the Pace and add text that implementers should
> also assume that there will be other authentication mechanisms
> needed, some text about why Digest Auth isn't universal, and
> suggestions for folks who will create new auth mechanisms.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
> 
>



From owner-atom-syntax@mail.imc.org  Tue Jul 13 10: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 KAA13868
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 10:19: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 i6DE2aPL047886;
	Tue, 13 Jul 2004 07:02: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 i6DE2aIX047885;
	Tue, 13 Jul 2004 07:02:36 -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 i6DE2ZX8047877
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 07:02: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 (sccrmhc12) with SMTP
          id <2004071314023101200a1ojme>; Tue, 13 Jul 2004 14:02:32 +0000
Date: Tue, 13 Jul 2004 08:02:30 -0600
Subject: Re: a methodical approach to defining what date  elements we need
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: <14B72756-D419-11D8-9D0B-003065EA6144@geckotribe.com>
Message-Id: <480027D1-D4D5-11D8-9B93-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 Monday, July 12, 2004, at 09:35  AM, Antone Roundy wrote:
> 1) objective creation date
> 2) each objective major modification date
> 3) each objective minor modification date
> 4) each objective publication date
> 5) any subjective creation date the author may wish to associate with 
> the entry
> 6) any subjective major modification date the author may wish to 
> associate with the entry
> 7) any subjective minor modification date the author may wish to 
> associate with the entry
> 8) any subjective publication date the author may wish to associate 
> with the entry

Let me see if I can get a sense of what we agree on and what we don't.  
Would I be correct to assume that we can all agree that:

A) to support legacy systems/data which have subjective dates, possibly 
without timezones, we have to support #8?

B) That A (#8) be REQUIRED?

C) that A (#8) be the only REQUIRED date construct (again, to support 
legacy systems & data)?

D) that A (#8) be the only subjective date?

E) that all Date constructs MUST specify a timezone, which MUST be 
-00:00 if it is unknown?

F) that the timezones MUST be numeric, except that either Z or +00:00 
MAY be used for UTC?

G) that all dates except A (#8) MUST be in UTC (Z or +00:00), unless 
unknown?

I've only heard one indirect, and uncommon, argument against my having 
omitted the creation date from my original proposed list. Does anyone 
have a use case for why that needs to be in the feed?

What we don't agree on, or consensus is unclear:

i) Can the issued/published date ever change?

ii) If it can, do we want to preserve a "first issued" date in the 
feed? (first #4)

iii) Do we want different Date Constructs for specifying major and 
minor changes, imperfect though the distinction may be? (last #2 and #3)

iv) If so, what if any guidelines do we want to provide for when to 
change each?

v) What assumptions do we want people to be able to make about omitted 
Date Constructs?  (This will be easier to answer after we've decided on 
which Date Constructs are going to exist).

vi) What do we want to call each of the Date Constructs?


Finally, my answers to the above questions:

i) Yes, as long as we track the first issued date.

ii) Yes.

iii) Yes.

iv) A major update alters or non-trivially expands the scope of the 
message. I minor update does not, and includes such things as spelling 
corrections and rewording for clarification of existing meaning.

v) If a major udpate date exists, but no minor update date exists, they 
are the same.  (Also, if both exist, the minor update must not be 
earlier than the major update).  If no update dates exist, but the 
objective issued date does, the update dates are the same as the issued 
date.  If only the subjective date exists, no other assumptions are 
possible.

vi) My heart is not set on anything in particular, but here's what 
comes to mind: subjective date: issued or published; first issued date, 
first-issued or first-published (can't think of an unambiguous single 
word); last major modification: modified; last minor modification: 
updated.



From owner-atom-syntax@mail.imc.org  Tue Jul 13 10:26:50 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14236
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 10:26:50 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DE75jw048252;
	Tue, 13 Jul 2004 07:07: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 i6DE75i4048251;
	Tue, 13 Jul 2004 07:07:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DE74iT048243
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 07:07:04 -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 <20040713140701012009t617e>; Tue, 13 Jul 2004 14:07:01 +0000
Date: Tue, 13 Jul 2004 08:07:00 -0600
Subject: Re: PaceElementOrder: options
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: <871xjg6rhy.fsf@nwalsh.com>
Message-Id: <E8CF99C1-D4D5-11D8-9B93-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, July 13, 2004, at 06:06  AM, Norman Walsh wrote:
> | I don't see asking people to emit a list of XML elements in a given
> | order to be a burden; in the scheme of things it's trivial compared 
> to
> | asking them to get the encoding straight.
>
> Fair enough. My preference is for a content model that allows
> arbitrary order, but I won't stand in the way of consensus if I'm in
> the minority.
>
I'd prefer what you might call "stream processable" order, ie. feed 
stuff before entries, and if we have any kind of inheritance, 
defaulting or referencing mechanisms, requiring things to be defined 
before use.  Other than that, arbitrary order would be my preference, 
but I won't fall on my sword for it.



From owner-atom-syntax@mail.imc.org  Tue Jul 13 10: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 KAA14915
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 10:34: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 i6DEFmDI048965;
	Tue, 13 Jul 2004 07:15: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 i6DEFmLU048964;
	Tue, 13 Jul 2004 07:15: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 (mproxy.gmail.com [216.239.56.248])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6DEFmIX048953
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 07:15:48 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so11312226cwc
        for <atom-syntax@imc.org>; Tue, 13 Jul 2004 07:15:48 -0700 (PDT)
Received: by 10.11.99.56 with SMTP id w56mr152418cwb;
        Tue, 13 Jul 2004 07:15:47 -0700 (PDT)
Message-ID: <3f1451f5040713071521e6d2e@mail.gmail.com>
Date: Tue, 13 Jul 2004 10:15:47 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Norman Walsh <ndw@nwalsh.com>
Subject: Re: RELAX NG Grammar for draft-...-00.txt
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <87658s6s0h.fsf@nwalsh.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <20040713012505.21328.qmail@web41510.mail.yahoo.com> <87658s6s0h.fsf@nwalsh.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, 13 Jul 2004 07:55:26 -0400, Norman Walsh <ndw@nwalsh.com> wrote:
> / Randy Charles Morin <randymorin@yahoo.com> was heard to say:
> | Norman Walsh wrote:
> | | atomDateConstruct =
> | |    atomCommonAttributes,
> | |    (xsd:date | xsd:dateTime | xsd:gYearMonth | xsd:gYear)
> |>Urk. This is a cut-and-paste bug. I think we mean xsd:dateTime *only* here.
> |
> | I think all four date formats are acceptable. As per section 3.3 Date Construct of the format spec [1].
> |
> | 3.3  Date Constructs
> |
> |    A Date construct is an element whose child content is a W3C Date-Time
> |    string [W3C.NOTE-datetime-19980827].
> |
> | That spec [2] indicates all four date formats are acceptable.
> | Thanks and please clarify if I missed something,
> 
> I think you're right, but saying that date constructs should have a time zone
> (or must in one case), doesn't square very well with allowing "1994" as the
> content.
> 
> I lean towards adopting the RFC for timestamps, myself.

+1 for RFC 3339 

    Thanks,
    -joe



From owner-atom-syntax@mail.imc.org  Tue Jul 13 10: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 KAA15184
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 10: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 i6DEOWqX049584;
	Tue, 13 Jul 2004 07:24: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 i6DEOW3T049583;
	Tue, 13 Jul 2004 07:24: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 i6DEOTQC049574
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 07:24:31 -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 i6DEP9ww007970;
	Tue, 13 Jul 2004 10:25:09 -0400
Message-ID: <40F3F09F.4070602@intertwingly.net>
Date: Tue, 13 Jul 2004 10:24:31 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <dtcd@mac.com>
CC: Atom-syntax Syntax <atom-syntax@imc.org>
Subject: Re: a methodical approach to defining what date  elements we need
References: <BD1995C2.1F3C6%eric.scheid@ironclad.net.au> <opsa2k75lz6dxgxk@mail.online.no> <CFCD3EC6-D4BA-11D8-82B1-000A95DC3D90@mac.com> <40F3CC36.9080001@intertwingly.net> <7C832F0A-D4D2-11D8-82B1-000A95DC3D90@mac.com>
In-Reply-To: <7C832F0A-D4D2-11D8-82B1-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: <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 13 Jul 2004, at 7:49 am, Sam Ruby wrote:
> 
>> Please at least *TRY* to be civil.
> 
> That is me being civil. Saying the example isn't valid when it's from a 
> real blog isn't in the slightest bit constructive.
> 
>> You are also simultaneously maintaining that "(Tim's is the only blog 
>> in the universe that is)", which tends to argue against this being a 
>> representive sample that one should use to base decisions off of.
> 
> That's one way to look at it. The other is that by considering this 
> stuff properly and thinking about what people currently do you can end 
> up with a much more flexible, meaningful model.
> 
>> Let's proceed with the assumption for the moment that this is a 
>> representative sample.
>>
>> max(date-on-page) = 2004-06-13
>> min(date-on-pate) = 2004-02-17
>>
>> There also is a significant date which is reflected both in the URL 
>> and in a special sidebar "Around February 20, 2004".
>>
>> These are three dates that appear significant.  What tags should be 
>> used for these?
> 
> You always ask this and it seems to serve no purpose other than to send 
> the debate down a dead end.
> 
> Under PaceEntryDates:
>  <created>2004-02-17</created>
>  <modified>2004-06-12</modified>
>  <issued>2004-06-12</issued>
> 
> Under the current draft: Not a clue.

Note that there is some information loss there.  In this particular blog 
entry, it probably wasn't all that significant.  In other entries on 
Tim's blog, the nominal issue date can be very significant.

I've already stated what I think the answer would be given the current 
draft:

http://www.imc.org/atom-syntax/mail-archive/msg06805.html

> The third date might fit neatly in a "subjective" date, or in 
> first-issued if we have that, but I've no idea what its meaning was, so 
> I'm only guessing.

If the next rev of the spec were clarified to indicate that "issued" 
means "first-issued", and should only change if the original "issued" 
date was recorded in error (and presumably, such a change would qualify 
as a substantial modification); and furthermore if "modified" were 
clarified to indicate that a change in this value indicates a "notable" 
modification; would these two changes suffice?

Graham, I think we are on the same side here.  We both don't want 
aggregator authors to have to guess anymore.  We want aggregator authors 
to have a clear and unambiguous answer to the question "why did (or did 
not) you sort this entry to the top of the list?" - the answer being 
"because the value of <foo> element did (or did not) change".

Trying to establish what we want to call "foo" is not a dead end. 
Neither my original take on this (last July) nor your take (in February) 
are the definitive last words on this subject.

> Graham

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Tue Jul 13 11: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 LAA16993
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 11:02: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 i6DEffAq051162;
	Tue, 13 Jul 2004 07:41: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 i6DEffXi051161;
	Tue, 13 Jul 2004 07:41:41 -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 i6DEfd2W051137
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 07:41:40 -0700 (PDT)
	(envelope-from ga-atom-syntax@gmane.org)
Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 1BkOTQ-00015n-00
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 16:41:37 +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 <atom-syntax@imc.org>; Tue, 13 Jul 2004 16:41:36 +0200
Received: from stpeter by corp-fw-main.jabber.com with local (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <atom-syntax@imc.org>; Tue, 13 Jul 2004 16:41:36 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: atom-syntax@imc.org
From: Peter Saint-Andre <stpeter@jabber.org>
Subject: Re: [ADMIN] Can we make the default "Reply to list"?
Date: Tue, 13 Jul 2004 08:31:01 -0600
Organization: Jabber Software Foundation
Lines: 21
Message-ID: <pan.2004.07.13.14.31.00.376608@jabber.org>
References: <1e2.2516e92b.2e227f94@aol.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: corp-fw-main.jabber.com
User-Agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity.)
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, 11 Jul 2004 07:33:40 -0400, Svgdeveloper-YDxpq3io04c wrote:

> I wonder whether we can make the default for this list "Reply to list"?
> 
> Shouldn't the norm be to continue discussion of substantive points on
> list?

The default for IETF lists is reply-to-sender. I've been down this road
with the XMPP WG list and believe me, it's not worth a lengthy flame war,
because the result is a foregone conclusion. Within the IETF, the forces
of opposition to reply-to munging have long been ascendant, and resistance
is futile.

Personally I use Gmane and a newsreader for this list and a boatload of
others, which is good for many reasons, not least of which that NTTP
defaults to reply-to-list (after all, that's the point of a newsgroup).
Details here: <http://www.gmane.org/>.

Peter





From owner-atom-syntax@mail.imc.org  Tue Jul 13 11: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 LAA17121
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 11:05: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 i6DElAw6051523;
	Tue, 13 Jul 2004 07:47: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 i6DElA2x051522;
	Tue, 13 Jul 2004 07:47:10 -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 i6DEl60d051509;
	Tue, 13 Jul 2004 07:47:08 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p0611046abd19a5977c08@[10.20.30.249]>
In-Reply-To: <40F3E700.5020009@franklinmint.fm>
References: <BD18BE9D.1386E%mint@franklinmint.fm>
 <p06110455bd18ff07e6da@[10.20.30.249]> <40F3E700.5020009@franklinmint.fm>
Date: Tue, 13 Jul 2004 07:47:17 -0700
To: mint@franklinmint.fm
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: PaceSecurityServices
Cc: Atom Syntax <atom-syntax@imc.org>
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 9:43 AM -0400 7/13/04, Robert Sayre wrote:
>I think the spec isn't done until we have an optional authentication 
>scheme that works for CGI scripts on standard Apache configurations.

OK

>  We *know* that the existing options are inadequate for this common use case.

Fully agree. That's why I said we should have wording in the spec 
talking about it. I was surprised when I found out about the 
limitation, and I suspect many folks in the IETF who will be 
reviewing the document will be as well.

>  I'm fine with the base spec referencing another draft as a MAY.

Good. If someone comes forwards with another auth mechanism that the 
WG agrees is appropriate, it is a good idea for this section of the 
document to say "For example, see the Foo document; this MAY be used 
for authentiation."

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Tue Jul 13 11:06: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 LAA17149
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 11:06:09 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DElA4U051527;
	Tue, 13 Jul 2004 07:47: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 i6DElAJL051525;
	Tue, 13 Jul 2004 07:47:10 -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 i6DEl60b051509;
	Tue, 13 Jul 2004 07:47:07 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p06110469bd19a54668f4@[10.20.30.249]>
In-Reply-To: <14be96d3040713053039dbde91@mail.gmail.com>
References: <40E16215.6070507@intertwingly.net>
 <40EC9915.4050406@intertwingly.net>
 <3f1451f504070718267c5526b4@mail.gmail.com>
 <40ED6392.2000107@franklinmint.fm>
 <3f1451f504070810104a5122e7@mail.gmail.com>
 <3f1451f504070810296ca252e7@mail.gmail.com>
 <p0611044fbd18e903bdd9@[10.20.30.249]> <40F37A14.6040908@aol.net>
 <14be96d3040713053039dbde91@mail.gmail.com>
Date: Tue, 13 Jul 2004 07:43:21 -0700
To: Mark Pilgrim <pilgrim@gmail.com>, John Panzer <jpanzer@aol.net>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: PaceSecurityServices
Cc: Atom WG <atom-syntax@imc.org>
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:30 AM -0400 7/13/04, Mark Pilgrim wrote:
>On Mon, 12 Jul 2004 22:58:44 -0700, John Panzer <jpanzer@aol.net> wrote:
>>  I am uncertain about making Digest Auth a SHOULD rather than a MUST.
>>  What's the reason for leaving the wriggle room?
>
>Some implementations (most wikis, some comment systems) have no need
>for authentication of any kind.

Exactly right. For interoperability, no authentication is needed, 
since some systems will not want it. If you are going to use 
authentication, you SHOULD use Digest Auth. If you can't use Digest 
Auth but you still need authentication, you need to use something 
outside the spec.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Tue Jul 13 11:52:41 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19732
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 11: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 i6DFMb0H054864;
	Tue, 13 Jul 2004 08:22: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 i6DFMbut054863;
	Tue, 13 Jul 2004 08:22:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail03.svc.cra.dublin.eircom.net (mail03.svc.cra.dublin.eircom.net [159.134.118.19])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6DFMape054851
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 08:22:36 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 20629 messnum 2081176 invoked from network[83.70.39.115/83-70-39-115.bas2.prp.dublin.eircom.net]); 13 Jul 2004 15:22:33 -0000
Received: from 83-70-39-115.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.39.115)
  by mail03.svc.cra.dublin.eircom.net (qp 20629) with SMTP; 13 Jul 2004 15:22:33 -0000
Message-ID: <40F3FE36.3030809@dehora.net>
Date: Tue, 13 Jul 2004 16:22:30 +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: Norman Walsh <ndw@nwalsh.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceElementOrder: options
References: <20040712211533.90350.qmail@web41511.mail.yahoo.com> <A5343281AE2BD2A2B110E8AF@diva.verity.com> <40F32E81.4050508@dehora.net> <871xjg6rhy.fsf@nwalsh.com> <40F3E0F5.80105@dehora.net> <87r7rg2esk.fsf@nwalsh.com>
In-Reply-To: <87r7rg2esk.fsf@nwalsh.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


Norman Walsh wrote:

> My RNC attempts to implement what the -00 draft says. Personally, I
> favor putting all the non-entry feed elements in a wrapper, making
> that wrapper the required first element of the feed, and letting the
> content of that wrapper be unordered:
> 
> <feed>
>   <feedinfo>
>   </feedinfo>
>   <entry>
>   </entry>
> </feed>

Ok, I'll go for that; that being:

  1. feed children are ordered: (feedinfo, entry*)
  2. feedinfo children are unordered
  3. entry children are unordered

cheers
Bill



From owner-atom-syntax@mail.imc.org  Tue Jul 13 11: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 LAA19758
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 11: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 i6DFSvlP055184;
	Tue, 13 Jul 2004 08:28: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 i6DFSvg2055183;
	Tue, 13 Jul 2004 08:28: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 i6DFSu6v055170;
	Tue, 13 Jul 2004 08:28:56 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net ([66.57.27.65])
	(authenticated bits=0)
	by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i6DFTZQP011674;
	Tue, 13 Jul 2004 11:29:35 -0400
Message-ID: <40F3FFB9.3000004@intertwingly.net>
Date: Tue, 13 Jul 2004 11:28:57 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: mint@franklinmint.fm
CC: Paul Hoffman / IMC <phoffman@imc.org>, Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceSecurityServices
References: <BD18BE9D.1386E%mint@franklinmint.fm> <p06110455bd18ff07e6da@[10.20.30.249]> <40F3E700.5020009@franklinmint.fm>
In-Reply-To: <40F3E700.5020009@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:
> 
> Paul Hoffman / IMC wrote:
> 
>> At 10:18 PM -0400 7/12/04, Robert Sayre wrote:
>>
>>> -1. You are correct that no one is enthusiastic about WSSE. However, 
>>> many
>>> have spoken in favor of a Digest workalike with different header 
>>> names, so
>>> Apache doesn't eat them. I think the spec should reference or define one
>>> such mechanism.
>>
>> Assuming someone else creates such a mechanism, I'm fine with the base 
>> spec referencing it as a MAY. Is that what you were thinking, or did 
>> you want a SHOULD that is parallel to Digest Auth?
> 
> I think the spec isn't done until we have an optional authentication 
> scheme that works for CGI scripts on standard Apache configurations. We 
> *know* that the existing options are inadequate for this common use 
> case. I'm fine with the base spec referencing another draft as a MAY.

I think you guys are agreeing, but not directly addressing one key 
point: we need a proposal around which there is rough consensus and 
running code.  If we get to 1.0 and such a proposal is not written, then 
we should view this as an indication that it is not a "must have" feature.

- Sam Ruby




From owner-atom-syntax@mail.imc.org  Tue Jul 13 12:06:36 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20750
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 12:06:35 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DFjRiS056084;
	Tue, 13 Jul 2004 08:45:27 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6DFjRMn056083;
	Tue, 13 Jul 2004 08:45:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DFjQFL056069;
	Tue, 13 Jul 2004 08:45:26 -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 1BkPTD-0001OL-5D; Tue, 13 Jul 2004 15:45:27 +0000
Message-ID: <40F40397.3090008@franklinmint.fm>
Date: Tue, 13 Jul 2004 11:45:27 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sam Ruby <rubys@intertwingly.net>
CC: Paul Hoffman / IMC <phoffman@imc.org>, Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceSecurityServices
References: <BD18BE9D.1386E%mint@franklinmint.fm> <p06110455bd18ff07e6da@[10.20.30.249]> <40F3E700.5020009@franklinmint.fm> <40F3FFB9.3000004@intertwingly.net>
In-Reply-To: <40F3FFB9.3000004@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: <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:

>
> I think you guys are agreeing, but not directly addressing one key 
> point: we need a proposal around which there is rough consensus and 
> running code.  If we get to 1.0 and such a proposal is not written, 
> then we should view this as an indication that it is not a "must have" 
> feature.

Absolutely. I just want to make sure the chairs recognize that voices in 
favor of a Digest-like scheme are not necessarily advocating the scheme 
defined in RFC 2617.

Robert Sayre



From owner-atom-syntax@mail.imc.org  Tue Jul 13 12: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 MAA21418
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 12: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 i6DFuMwU056592;
	Tue, 13 Jul 2004 08:56:22 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6DFuMMR056591;
	Tue, 13 Jul 2004 08:56:22 -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 i6DFuLW0056576;
	Tue, 13 Jul 2004 08:56:21 -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 i6DFuI406074;
	Tue, 13 Jul 2004 08:56:18 -0700 (PDT)
Received: from aol.net ([10.169.192.58]) by judge.mcom.com
          (Netscape Messaging Server 4.15) with ESMTP id I0SS9U02.V0W;
          Tue, 13 Jul 2004 08:56:18 -0700 
Message-ID: <40F40623.9090503@aol.net>
Date: Tue, 13 Jul 2004 08:56:19 -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: Paul Hoffman / IMC <phoffman@imc.org>
CC: Mark Pilgrim <pilgrim@gmail.com>, Atom WG <atom-syntax@imc.org>
Subject: Re: PaceSecurityServices
References: <40E16215.6070507@intertwingly.net> <40EC9915.4050406@intertwingly.net> <3f1451f504070718267c5526b4@mail.gmail.com> <40ED6392.2000107@franklinmint.fm> <3f1451f504070810104a5122e7@mail.gmail.com> <3f1451f504070810296ca252e7@mail.gmail.com> <p0611044fbd18e903bdd9@[10.20.30.249]> <40F37A14.6040908@aol.net> <14be96d3040713053039dbde91@mail.gmail.com> <p06110469bd19a54668f4@[10.20.30.249]>
In-Reply-To: <p06110469bd19a54668f4@[10.20.30.249]>
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


Paul Hoffman / IMC wrote:

>
> At 8:30 AM -0400 7/13/04, Mark Pilgrim wrote:
>
>> On Mon, 12 Jul 2004 22:58:44 -0700, John Panzer <jpanzer@aol.net> wrote:
>>
>>>  I am uncertain about making Digest Auth a SHOULD rather than a MUST.
>>>  What's the reason for leaving the wriggle room?
>>
>>
>> Some implementations (most wikis, some comment systems) have no need
>> for authentication of any kind.
>
>
> Exactly right. For interoperability, no authentication is needed, 
> since some systems will not want it. If you are going to use 
> authentication, you SHOULD use Digest Auth. If you can't use Digest 
> Auth but you still need authentication, you need to use something 
> outside the spec.


+1 to SHOULD for both.

I'm still a little nervous about applying this logic to clients (what 
reason does a client have for not implementing at least Digest Auth?) 
but it's a nitpick. 

-John



From owner-atom-syntax@mail.imc.org  Tue Jul 13 13:36: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 NAA27790
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 13:36:57 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DHIjAR062732;
	Tue, 13 Jul 2004 10:18:45 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6DHIjmQ062731;
	Tue, 13 Jul 2004 10:18:45 -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 i6DHIhJ7062725
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 10:18:44 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.19] (unknown [63.96.164.56])
	by mail.mnot.net (Postfix) with ESMTP
	id 26ADA727D; Tue, 13 Jul 2004 10:18:47 -0700 (PDT)
In-Reply-To: <87acy45bch.fsf@nwalsh.com>
References: <20040712214722.79750.qmail@web41212.mail.yahoo.com> <AA8D7D00-D461-11D8-AFCB-000A95BD86C0@mnot.net> <87acy45bch.fsf@nwalsh.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <B2DCC212-D4F0-11D8-9691-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: Atom Syntax <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: Re: Usage Scenarios for Versioning and Extensibility
Date: Tue, 13 Jul 2004 10:18:46 -0700
To: Norman Walsh <ndw@nwalsh.com>
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>
Content-Transfer-Encoding: 7bit


Thanks, Norm - comments / questions inline.

On Jul 13, 2004, at 5:40 AM, Norman Walsh wrote:
> - No element in a namespace other than the Atom namespace is allowed
>   to change the semantics of any element in the Atom namespace.
>   (You can't introduce an extension element that means ignore the
>   atom:title and use the atom:summary for the title instead.)

Agreed.

> - Any element may have an atom:mustUnderstand attribute. If
>   atom:mustUnderstand=true and the element is unrecognized,
>   that's an error. Halt and catch fire.

Rather than "any element", can we say "any child element of atom:feed 
or atom:entry" (adjusted to account for what we do with feedinfo, 
etc.)?

> - If you're reading an Atom document with a version identifier that
>   you recognize:
>
>   - Unrecognized elements in the Atom namespace are an error.
>     Recovery behavior is to ignore them.
>   - Unrecognized elements in any other namespace are ignored.

Is there any difference between these two sub-cases, except in who has 
control of the namespace?

> - If you are reading an Atom document with a version identifier that
>   you don't recognize:
>
>   - Unrecognized elements in the Atom namespace or any other
>     namespace are ignored.
>

Yes, as long as they don't have a mustUnderstand=true flag.

> | 1) And it was good... except for that nasty atom:title element; after
> | wide deployment experience, it's agreed we need a new version of it.
> | So, a new version of Atom is introduced. The new one isn't
> | backwards-compatible with the old one.
>
> A backwards-incompatible change tips over the apple cart. This version
> of Atom goes in a new namespace; it's a different document type.
>
> This is really painful, so let's plan not to do this, ok? :-)

Yes. If it's not backwards-compatible, it gets a new namespace URI 
and/or localname.

> | 2) Then, we decide we want to add a new metadata element, let's call
> | it "fog." So, a new version of Atom is introduced.
>
> One answer is to put this element in a different namespace. Then
> there's no problem.
> Another answer is to put this element in the Atom namespace and bump
> the version identifier. That's no problem either as long as fog doesn't
> change the semantics of any other Atom element.

Agreed, except I don't see the need to bump the version identifier, 
UNLESS we say that "fog" is now required, etc. for the feed itself to 
be valid. See end of message for more discussion.

> | 3) After a while, someone comes up with a souped-up version of
> | atom:title that is backwards-compatible, just *better*. It gets 
> really
> | popular, and yet another version of Atom is born.
>
> Bump the version identifier. No problem.

If it's backwards-compatible, what purpose is served by changing the 
version identifier?

> | 4) At the same time, a group of rogue Open Source Software 
> programmers
> | descends upon this idyllic scene and introduces its own extensions. 
> Up
> | until now, all of our extensions have been approved and incorporated
> | by the WG, but these are destined to remain separate.
>
> They get left in a separate namespace. Applications that recognize 
> them,
> do, and applications that don't, don't.

Yes.

> | 5) Finally, in 2010, we realise that the Atom feed and entry
> | containers aren't really doing the job, and we need to change their
> | model. Yet Another Version of Atom (YAVA) comes into being.
>
> That's just 1 or 2 again, depending on whether or not the change is
> backwards compatible.

Agreed.

One thing that might be helpful to clarify is what the version 
identifier indicates. I've put forth that it identifies a required set 
of metadata that might be extended; i.e., the version identifies the 
requirements, not necessarily the specific set of metadata in the 
message (which can be discovered by inspecting the message). This seems 
to have a nice interaction with the use of namespaces.

This doesn't seem to be what you have in mind. Could you give a 
straw-man rule of thumb as to when the version identifier should be 
changed, and what it identifies?

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Tue Jul 13 14: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 OAA00136
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 14: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 i6DHqAqx065453;
	Tue, 13 Jul 2004 10: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 i6DHqAcX065452;
	Tue, 13 Jul 2004 10:52:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from solution4.MASSLINK.COM (solution4.masslink.com [64.251.112.4])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DHq0q2065427
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 10:52:10 -0700 (PDT)
	(envelope-from dtcd@mac.com)
Received: from [172.30.1.147] (helo=[172.30.1.147])
	by solution4.MASSLINK.COM with esmtp (Exim 3.34 #1)
	id 1BkRRV-0002C8-00; Tue, 13 Jul 2004 13:51:51 -0400
In-Reply-To: <40F3F09F.4070602@intertwingly.net>
References: <BD1995C2.1F3C6%eric.scheid@ironclad.net.au> <opsa2k75lz6dxgxk@mail.online.no> <CFCD3EC6-D4BA-11D8-82B1-000A95DC3D90@mac.com> <40F3CC36.9080001@intertwingly.net> <7C832F0A-D4D2-11D8-82B1-000A95DC3D90@mac.com> <40F3F09F.4070602@intertwingly.net>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-22--235240924; protocol="application/pkcs7-signature"
Message-Id: <50540F00-D4F5-11D8-82B1-000A95DC3D90@mac.com>
Cc: Atom-syntax Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: a methodical approach to defining what date  elements we need
Date: Tue, 13 Jul 2004 13:51:47 -0400
To: Sam Ruby <rubys@intertwingly.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-22--235240924
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 13 Jul 2004, at 10:24 am, Sam Ruby wrote:

> Note that there is some information loss there.  In this particular 
> blog entry, it probably wasn't all that significant.  In other entries 
> on Tim's blog, the nominal issue date can be very significant.

There probably is room in the spec for a nominal date.

> if "modified" were clarified to indicate that a change in this value 
> indicates a "notable" modification; would these two changes suffice?

It's not about modification. My claim is that re-issuing an entry is a 
separate event from all modification. Creation and modification dates 
belong the document underneath the entry. Issuing and reissuing is 
about how the document is published as an entry, which is an 
independent thing.

> Graham, I think we are on the same side here.  We both don't want 
> aggregator authors to have to guess anymore.  We want aggregator 
> authors to have a clear and unambiguous answer to the question "why 
> did (or did not) you sort this entry to the top of the list?" - the 
> answer being "because the value of <foo> element did (or did not) 
> change".

Yes. The interaction between aggregators and publishers needs to be a 
lot clearer than with RSS.

Graham
--Apple-Mail-22--235240924
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
9w0BCQUxDxcNMDQwNzEzMTc1MTQ4WjAjBgkqhkiG9w0BCQQxFgQU158W0v4CKIpjIOwklBQj0rz3
N2QweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAQEP0qGoL7ohvGWSq+asOJTJS
V4G86mx8KmunhGnkyurg9MtWmDR3Z8x0FsE6/Vjd9XZVHrKA+Vou7rDm/CNRK4dWdmWfNZvp+fjo
ziHZxy3fCjArqq8zgMw7GDjidn6pydRCHjJCGItqBEmm8lmQXBrKexSxG/5V/qZ8CiwJQEAOe+sz
dw/XLIVb52VhuYfo/sj5hHiI7B2F8R2g2wt2KSxUEDZgDg4Psd/3v9dZYI77nTYwYT1uFlocsqGY
FWJcPTkIu+wuyn4iOUSOucQQ//yB9DuRgzyXUoSXt8Ywzi2H0fb2+hrZ6a5KguAB0P66XoIesi4D
SvJRNDJnnlpUuwAAAAAAAA==

--Apple-Mail-22--235240924--



From owner-atom-syntax@mail.imc.org  Tue Jul 13 14:18: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 OAA00573
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 14:18: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 i6DHwWZl066142;
	Tue, 13 Jul 2004 10:58:32 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6DHwWaT066141;
	Tue, 13 Jul 2004 10:58:32 -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 i6DHwV7f066135
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 10:58:31 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from phys-bur-1 ([129.148.9.72])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i6DHuS53015021
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 11:56:28 -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 <0I0S00L01XWEXA@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com)
 for atom-syntax@imc.org; Tue, 13 Jul 2004 13:58:34 -0400 (EDT)
Received: from mercury (vpn-129-150-32-132.Central.Sun.COM [129.150.32.132])
 by bur-mail1.east.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
 with ESMTP id <0I0S00EMEXXBNP@bur-mail1.east.sun.com> for atom-syntax@imc.org;
 Tue, 13 Jul 2004 13:58:34 -0400 (EDT)
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BkRXg-0000UI-00	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 13:58:12 -0400
X-URL: http://nwalsh.com/
Date: Tue, 13 Jul 2004 13:58:05 -0400
From: Norman Walsh <ndw@nwalsh.com>
Subject: Re: Usage Scenarios for Versioning and Extensibility
In-reply-to: <B2DCC212-D4F0-11D8-9691-000A95BD86C0@mnot.net>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <87d62zzt5e.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: <20040712214722.79750.qmail@web41212.mail.yahoo.com>
 <AA8D7D00-D461-11D8-AFCB-000A95BD86C0@mnot.net> <87acy45bch.fsf@nwalsh.com>
 <B2DCC212-D4F0-11D8-9691-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-Type: text/plain

/ Mark Nottingham <mnot@mnot.net> was heard to say:
| Thanks, Norm - comments / questions inline.
[...]
|> - Any element may have an atom:mustUnderstand attribute. If
|>   atom:mustUnderstand=true and the element is unrecognized,
|>   that's an error. Halt and catch fire.
|
| Rather than "any element", can we say "any child element of atom:feed
| or atom:entry" (adjusted to account for what we do with feedinfo,
| etc.)?

I think we mean any element, not just the children of feed and entry.
I should be allowed to do this:

  <atom:entry>
    <atom:title>Hello <foo:world atom:mustUnderstand="true"/></atom:title>
    ...
  </atom:entry>

even if it's really stupid :-)

|> - If you're reading an Atom document with a version identifier that
|>   you recognize:
|>
|>   - Unrecognized elements in the Atom namespace are an error.
|>     Recovery behavior is to ignore them.
|>   - Unrecognized elements in any other namespace are ignored.
|
| Is there any difference between these two sub-cases, except in who has
| control of the namespace?

I'm not sure exactly what your asking. My intent is that the former
case is an error. A processor should have the freedom to reject feeds
that are in error. However, if it doesn't reject the feed, it must
proceed by ignoring the error. The latter case isn't an error at all,
it's just an unrecognized extension (and unrecognized extensions must
be ignored).

|> - If you are reading an Atom document with a version identifier that
|>   you don't recognize:
|>
|>   - Unrecognized elements in the Atom namespace or any other
|>     namespace are ignored.
|
| Yes, as long as they don't have a mustUnderstand=true flag.

Right. That was a general rule I made at the beginning.

|> | 1) And it was good... except for that nasty atom:title element; after
|> | wide deployment experience, it's agreed we need a new version of it.
|> | So, a new version of Atom is introduced. The new one isn't
|> | backwards-compatible with the old one.
|>
|> A backwards-incompatible change tips over the apple cart. This version
|> of Atom goes in a new namespace; it's a different document type.
|>
|> This is really painful, so let's plan not to do this, ok? :-)
|
| Yes. If it's not backwards-compatible, it gets a new namespace URI
| and/or localname.

If it gets a new namespace URI, it just becomes an extension element.
If it gets a new local name, then you have to bump the version number.

|> | 2) Then, we decide we want to add a new metadata element, let's call
|> | it "fog." So, a new version of Atom is introduced.
|>
|> One answer is to put this element in a different namespace. Then
|> there's no problem.
|> Another answer is to put this element in the Atom namespace and bump
|> the version identifier. That's no problem either as long as fog doesn't
|> change the semantics of any other Atom element.
|
| Agreed, except I don't see the need to bump the version identifier,
| UNLESS we say that "fog" is now required, etc. for the feed itself to
| be valid. See end of message for more discussion.

If we want to be able to add elements without changing the version
number, then we can't make unrecognized elements in the Atom namespace
be an error. I think it's useful to make them errors because it
catches typos and various other sorts of problems that will otherwise
be silently ignored.

In my view, a feed validator ought to be able to complain about:

  <feed version="Red">
    <entry>
      <lnk rel="start" href="xxx"/>
      ...
    </entry>
  </feed>

if it knows what's valid in "Red" (and "lnk" isn't valid).

If it has never heard of version "Red", then it shouldn't complain
(except perhaps informationally) because it has to assume that "lnk" is
allowed in that version.

|> | 3) After a while, someone comes up with a souped-up version of
|> | atom:title that is backwards-compatible, just *better*. It gets
|> really
|> | popular, and yet another version of Atom is born.
|>
|> Bump the version identifier. No problem.
|
| If it's backwards-compatible, what purpose is served by changing the
| version identifier?

Well, you said it was "backwards-compatible". I assume it has *some*
new semantic or it wouldn't just be backwards-compatible, it would
be "the same as" :-)

If you want processors to be able to take advantage of the new
semantic, you have to give them some clue about it :-)

| One thing that might be helpful to clarify is what the version
| identifier indicates. I've put forth that it identifies a required set
| of metadata that might be extended; i.e., the version identifies the
| requirements, not necessarily the specific set of metadata in the
| message (which can be discovered by inspecting the message). This
| seems to have a nice interaction with the use of namespaces.

The version identifies the RFC to which the feed purports to conform.
It identifies exactly which elements in the Atom namespace are legal
and exactly where they are allowed to occur and what semantics they
have.

| This doesn't seem to be what you have in mind. Could you give a
| straw-man rule of thumb as to when the version identifier should be
| changed, and what it identifies?

If the RFC is revised in a backwards-compatible way, the version number
has to change. If the RFC is revised in a backwards-incompatible way,
it better define a new namespace.

Does that help?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | The happiest people seem to be those
http://nwalsh.com/            | that have no particular reason for
                              | being happy except that they are
                              | so.--W. R. Inge

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA9CKwOyltUcwYWjsRAtVdAKCSd5+2z1IbrE2XffB3I/pSdJIKPACgpRn6
3Ai9xWUxl/ODG4Jpc4ecYCE=
=Z7Da
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Tue Jul 13 14:25: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 OAA01737
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 14:25: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 i6DI6F0w066952;
	Tue, 13 Jul 2004 11:06: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 i6DI6FFU066951;
	Tue, 13 Jul 2004 11:06:15 -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 i6DI6EEX066943
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 11:06:14 -0700 (PDT)
	(envelope-from wunder@verity.com)
Received: from mx-rr.verity.com ([10.3.100.59])
	by beta.verity.com (8.9.3/8.9.3) with ESMTP id LAA07536
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 11:06:12 -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 LAA14316
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 11:06:12 -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, 13 Jul 2004 11:06:12 -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 <0I0S00CKPYA99Q@shazam.verity.com> for atom-syntax@imc.org; Tue,
 13 Jul 2004 11:06:11 -0700 (PDT)
Date: Tue, 13 Jul 2004 11:12:27 -0700
From: Walter Underwood <wunder@verity.com>
Subject: Re: RELAX NG Grammar for draft-...-00.txt
In-reply-to: <20040713012505.21328.qmail@web41510.mail.yahoo.com>
To: Atomlist <atom-syntax@imc.org>
Message-id: <E4D11AD111E0B01D2E9C9026@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: <20040713012505.21328.qmail@web41510.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 Monday, July 12, 2004 06:25:05 PM -0700 Randy Charles Morin 
<randymorin@yahoo.com> wrote:
> Norman Walsh wrote:
>| atomDateConstruct =
>|    atomCommonAttributes,
>|    (xsd:date | xsd:dateTime | xsd:gYearMonth | xsd:gYear)
>> Urk. This is a cut-and-paste bug. I think we mean xsd:dateTime *only*
>> here.
>
> I think all four date formats are acceptable. As per section 3.3 Date
> Construct of the format spec [1].

I strongly favor using RFC 3339 and thus requiring timestamps specified
to the second (or better). Sorting timestamps with different resolutions
is a mess.

Ultraseek does handle the W3C DateTimes, and dealing with the shortened
forms wasn't pretty.

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek



From owner-atom-syntax@mail.imc.org  Tue Jul 13 14: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 OAA02139
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 14:30:28 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DIB1Hj068327;
	Tue, 13 Jul 2004 11:11: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 i6DIB1Sj068326;
	Tue, 13 Jul 2004 11:11: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-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 i6DIB0K7068317
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 11:11:00 -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 i6DIB3il011964
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 12:11:03 -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 <0I0S00EXLYIF6J@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Tue, 13 Jul 2004 12:11:03 -0600 (MDT)
Received: from [192.168.1.100] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0S00KGVYIE3Q@mail.sun.net> for atom-syntax@imc.org; Tue,
 13 Jul 2004 12:11:03 -0600 (MDT)
Date: Tue, 13 Jul 2004 11:11:04 -0700
From: Tim Bray <tbray@textuality.com>
Subject: PaceElementOrder: restart
To: Atomlist Syntax <atom-syntax@imc.org>
Message-id: <0186FD30-D4F8-11D8-8C42-000A95A51C9E@textuality.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.618)
Content-type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1--234084640;
 protocol="application/pkcs7-signature"
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--234084640
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

I am starting a new thread for purely selfish reasons because of the 
way my mail client deals with veeeeeeery long threads, and because I 
think we've made some progress.  BUT, I don't like where we are.  I 
think we have consensus, not on what to do, but on the trade-offs, so 
let me try to write them down:

1. enforcing element order makes it harder for people who hand-author
2. we have to pick an order which is irritating because it's meaningless
3. enforcing order makes life easier for people who use (a significant 
body of) XSD-based tools.
4. enforcing order adds no significant difficulty for people who are 
program-generating Atom

(#4 is new, but seems pretty obvious).

I hate this trade-off, polluting a language design because of the 
broken-ness of a particular schema language is really irritating.

On balance, if the trade-off is really as presented, I'd probably lean 
to requiring order, but only by about 55/45.  Are there any new 
arguments we haven't thought of (please)?  -Tim


--Apple-Mail-1--234084640
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
hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDcxMzE4MTEwNVowIwYJKoZIhvcNAQkEMRYEFCSB
JKY71rGi3KJE0qHfTQdN1xaGMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV
BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLirkwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT
AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3
dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDC4q5MA0GCSqGSIb3DQEBAQUABIIBADtq
6PtlFedKVRWeSYsDM9mT0n3zp8kRKWtqKTMVYuK4HvrnNkEBAijpNuuOUQTIKH0NWKZzOIZS+cZA
JpZmEe0xeqBXe4d8UyFMUoiue9mXOqMvALMmnE1Iq/RvCjGMosjg4+avicOnA0VLJjGKUW9l2p4a
iDIudvUC64YJB2DMazKL96Ff19MMtcqvTs1b/Yi5F5XpERPlG/JXuB3sQIEID+9SSt7CtPWSqNw2
97enl9vEH0owMyVqMle7JdiHoIlG8ByNNO/ptpG3gO0fBS8iy2Okg5CxOsLeztyq99mC0ImbEusQ
J00y+oVAzKpDdEvjIneLmXp9DZudCs8N0XUAAAAAAAA=

--Apple-Mail-1--234084640--



From owner-atom-syntax@mail.imc.org  Tue Jul 13 15:15: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 PAA05794
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 15:15: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 i6DIrhkx071488;
	Tue, 13 Jul 2004 11:53: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 i6DIrhJv071487;
	Tue, 13 Jul 2004 11:53: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 i6DIrfGY071478
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 11:53: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 44C807C1EE; Tue, 13 Jul 2004 21:51:41 +0200 (CEST)
Date: Tue, 13 Jul 2004 20:57:09 +0200
To: "Antone Roundy" <antone@geckotribe.com>
Subject: Re: a methodical approach to defining what date  elements we need
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <175C69EB-D444-11D8-9D0B-003065EA6144@geckotribe.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: <opsa3axjyluvpchu@quark>
In-Reply-To: <175C69EB-D444-11D8-9D0B-003065EA6144@geckotribe.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Mon, 12 Jul 2004 14:43:12 -0600, Antone Roundy <antone@geckotribe.com>  
wrote:

> The purpose of the list is merely to create a (hopefully)
> comprehensive list of POSSIBLE dates, where there's no ambiguity about
> what EXACTLY we mean when we refer to one of them

+1 to that purpose. I hope we can reach consensus on what we (and Dublin  
Core, for that matter) means with the different dates.

> For example, I think we have a pretty good idea of what the term
> "issued" means, but I don't think we have agreement on what the
> <issued> element should contain.

I definately do not think we have a pretty good idea. Or, people have a  
pretty good idea, but the idea is very different from person to person. It  
seems to be a common perception that 'issued' can be a subjective (and  
then, imho, informal) date. I disagree. DC says «Date of formal issuance  
(e.g., publication) of the resource», which I think outrules all  
«subjectiveness» to the 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  Tue Jul 13 15:22: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 PAA06352
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 15: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 i6DJ56QL072385;
	Tue, 13 Jul 2004 12:05: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 i6DJ566o072384;
	Tue, 13 Jul 2004 12:05:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DJ55vK072371;
	Tue, 13 Jul 2004 12:05:05 -0700 (PDT)
	(envelope-from jasnell@us.ibm.com)
Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32])
	by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i6DJ54ko530274;
	Tue, 13 Jul 2004 15:05:04 -0400
Received: from d03nm122.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168])
	by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6DJ52Dv171004;
	Tue, 13 Jul 2004 13:05:03 -0600
In-Reply-To: <0186FD30-D4F8-11D8-8C42-000A95A51C9E@textuality.com>
To: Tim Bray <tbray@textuality.com>
Cc: Atomlist Syntax <atom-syntax@imc.org>, owner-atom-syntax@mail.imc.org
MIME-Version: 1.0
Subject: Re: PaceElementOrder: restart
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
From: James M Snell <jasnell@us.ibm.com>
X-MIMETrack: S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/13/2004 12:04:51 PM,
	Serialize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/13/2004 12:04:51 PM,
	Serialize complete at 07/13/2004 12:04:51 PM,
	Itemize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/13/2004 12:04:51 PM,
	S/MIME Sign complete at 07/13/2004 12:04:51 PM,
	S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/13/2004 12:05:00 PM,
	S/MIME Sign complete at 07/13/2004 12:05:00 PM,
	Serialize by Router on D03NM122/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at
 07/13/2004 13:05:02,
	Serialize complete at 07/13/2004 13:05:02
Message-ID: <OFE4938511.CF6E6D39-ON88256ED0.0068932A-88256ED0.0068D405@us.ibm.com>
Date: Tue, 13 Jul 2004 13:05:00 -0600
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z15984_boundary_sign
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>


This is an S/MIME signed message.

---------z15984_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 0068D0A688256ED0_="

This is a multipart message in MIME format.
--=_alternative 0068D0A688256ED0_=
Content-Type: text/plain; charset="US-ASCII"

owner-atom-syntax@mail.imc.org wrote on 07/13/2004 11:11:04 AM:

> I am starting a new thread for purely selfish reasons because of the 
> way my mail client deals with veeeeeeery long threads, and because I 
> think we've made some progress.  BUT, I don't like where we are.  I 
> think we have consensus, not on what to do, but on the trade-offs, so 
> let me try to write them down:
> 
> 1. enforcing element order makes it harder for people who hand-author
> 2. we have to pick an order which is irritating because it's meaningless
> 3. enforcing order makes life easier for people who use (a significant 
> body of) XSD-based tools.
> 4. enforcing order adds no significant difficulty for people who are 
> program-generating Atom
> 
> (#4 is new, but seems pretty obvious).
> 
> I hate this trade-off, polluting a language design because of the 
> broken-ness of a particular schema language is really irritating.
> 

+1

> On balance, if the trade-off is really as presented, I'd probably lean 
> to requiring order, but only by about 55/45.  Are there any new 
> arguments we haven't thought of (please)?  -Tim
> 

Such constraints should only be imposed in the language if there is a 
solid reason to do so from the languages point of view.  Implementations 
should comform to the constraints of the spec, the spec should not comform 
to the limitations of various implementations.

-1 to requiring order.


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

--=_alternative 0068D0A688256ED0_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>owner-atom-syntax@mail.imc.org wrote on 07/13/2004
11:11:04 AM:<br>
<br>
&gt; I am starting a new thread for purely selfish reasons because of the
<br>
&gt; way my mail client deals with veeeeeeery long threads, and because
I <br>
&gt; think we've made some progress. &nbsp;BUT, I don't like where we are.
&nbsp;I <br>
&gt; think we have consensus, not on what to do, but on the trade-offs,
so <br>
&gt; let me try to write them down:<br>
&gt; <br>
&gt; 1. enforcing element order makes it harder for people who hand-author<br>
&gt; 2. we have to pick an order which is irritating because it's meaningless<br>
&gt; 3. enforcing order makes life easier for people who use (a significant
<br>
&gt; body of) XSD-based tools.<br>
&gt; 4. enforcing order adds no significant difficulty for people who are
<br>
&gt; program-generating Atom<br>
&gt; <br>
&gt; (#4 is new, but seems pretty obvious).<br>
&gt; <br>
&gt; I hate this trade-off, polluting a language design because of the
<br>
&gt; broken-ness of a particular schema language is really irritating.<br>
&gt; </tt></font>
<br>
<br><font size=2><tt>+1</tt></font>
<br><font size=2><tt><br>
&gt; On balance, if the trade-off is really as presented, I'd probably
lean <br>
&gt; to requiring order, but only by about 55/45. &nbsp;Are there any new
<br>
&gt; arguments we haven't thought of (please)? &nbsp;-Tim<br>
&gt; <br>
</tt></font>
<br><font size=2><tt>Such constraints should only be imposed in the language
if there is a solid reason to do so from the languages point of view. &nbsp;Implementations
should comform to the constraints of the spec, the spec should not comform
to the limitations of various implementations.</tt></font>
<br>
<br><font size=2><tt>-1 to requiring order.</tt></font>
<br>
<br>
<br><font size=2 face="sans-serif">- James M Snell<br>
 &nbsp;jasnell@us.ibm.com<br>
 &nbsp;http://www.ibm.com<br>
 &nbsp;(877) 511-5082 / Office<br>
 &nbsp;930-1979 / Tie Line</font>
<br>
--=_alternative 0068D0A688256ED0_=--

---------z15984_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIIUOAIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIISWDCCAtow
ggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1
aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAy
MDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA629xc49NpAPz
cAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7glzJKgPkPzlTZZfznznGbmAWVnNBQ
lyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnwNclOnnP2sKufuPzbTImQTTi5c8JZNZcM
J0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEEBAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1Ud
DgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAPBgNVHRMBAf8EBTADAQH/MDEGA1UdJQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUH
AwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvu
jQupk2oCScMd3FIHLE7hOfu8YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14ke
McF9ViNdewEoBGiAycUq8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIC2jCCAkOgAwIB
AgIDAxS2MA0GCSqGSIb3DQEBBAUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwMTE0MjIw
NzExWhcNMTExMjMxMjIwNzExWjBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25h
bCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrb3Fzj02kA/NwCy5KFMiY
tFgyTJ6kMSQLVSs9uwVHIAVkqy/enDQwZ9b/7uCXMkqA+Q/OVNll/OfOcZuYBZWc0FCXI9qw60KO
J/rTd65FdF4dwp8cw8si0qjOJtYg8cm46fA1yU6ec/awq5+4/NtMiZBNOLlzwlk1lwwnRgXNNwID
AQABo4GqMIGnMBEGCWCGSAGG+EIBAQQEAwIAhzAOBgNVHQ8BAf8EBAMCAcYwHQYDVR0OBBYEFK5U
DpLqqDOpKyQtx8hvMNze80pAMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMA8GA1Ud
EwEB/wQFMAMBAf8wMQYDVR0lBCowKAYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYB
BQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAMnJ7c2YLyrY/PKlFl+7sm8NENfWtFxqdm+6NC6mTagJJ
wx3cUgcsTuE5+7xh9+/G0tTfLzA1qZAQ5GNMPXvmoB9+vJfKnC2JWMFQpIOUEJDXiR4xwX1WI117
ASgEaIDJxSrxHcuuV/hMIO9bgZ6C41MUVmdLTKBgBOImTuIPK8QwggMgMIICiaADAgECAgQ13vTP
MA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQL
EyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0MTUxWhcN
MTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMk
RXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKKlQRkrPFr
U18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkwrFEeO68r
1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOgYaRfMF0x
CzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBD
ZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAxODA4MjIx
NjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAdBgNV
HQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0HQQAEDTAL
GwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwlMQ0AppJu
f7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn00DbOyZY
sih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMgMIICiaADAgEC
AgQ13vTPMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0
MTUxWhcNMTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsG
A1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKK
lQRkrPFrU18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkw
rFEeO68r1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOg
YaRfMF0xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNl
Y3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAx
ODA4MjIxNjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAdBgNVHQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0H
QQAEDTALGwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwl
MQ0AppJuf7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn
00DbOyZYsih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMmMIIC
j6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIxNjM2NTRaMIGFMQsw
CQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEXMBUGA1UEAxMOSmFt
ZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkqhkiG9w0BCQEWEmph
c25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwKpbDG3zMatEuuOT
FYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSyd+7nwqAvbBfPj+0S
vcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7tBJlLrwDRCMoNlPuQ
Kg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQW
BBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOgFAwSamFzbmVs
bEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pAMCcGA1UdJQQgMB4G
CCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAZMKevB7dFfb9
23OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY8BjwVHxiYgG4xkxf
B1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOIzj3lz3xd+uOzqRFg
/Wsg/VMwggMmMIICj6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAy
BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNV
BAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIx
NjM2NTRaMIGFMQswCQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEX
MBUGA1UEAxMOSmFtZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkq
hkiG9w0BCQEWEmphc25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
wKpbDG3zMatEuuOTFYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSy
d+7nwqAvbBfPj+0SvcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7t
BJlLrwDRCMoNlPuQKg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQD
AgXgMB0GA1UdDgQWBBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcU
AgOgFAwSamFzbmVsbEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA
MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQAD
gYEAZMKevB7dFfb923OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY
8BjwVHxiYgG4xkxfB1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOI
zj3lz3xd+uOzqRFg/Wsg/VMxggG7MIIBtwIBATBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJ
bnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0g
Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwF+kzAJBgUrDgMCGgUAoIGiMBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDcxMzE5MDQ1MVowIwYJKoZIhvcNAQkEMRYE
FGSR0KzcQM26FmLAMLLu4PLRSNsdMEMGCSqGSIb3DQEJDzE2MDQwBwYFKw4DAh0wDgYIKoZIhvcN
AwICAgCAMAoGCCqGSIb3DQMHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAvlWXM9zR
hYP853354uW09lUctEiORDjKC/ggqjsoK905T7UTnHuHkgjiRqPjV1brbGmPXlxam7bgHtECdViw
qawimiwqXOXmskAGyMhwJ7i5flNmj63Xce0Pl/s4xt1OSx0tLocGXrTyd6haZUYjV/nDWdfvblHc
Vyc9HPKXb+QAAAAA

---------z15984_boundary_sign--



From owner-atom-syntax@mail.imc.org  Tue Jul 13 15:22: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 PAA06370
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 15:22: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 i6DJ1tsx072249;
	Tue, 13 Jul 2004 12: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 i6DJ1tgM072248;
	Tue, 13 Jul 2004 12:01: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 i6DJ1ta5072242
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 12:01:55 -0700 (PDT)
	(envelope-from mint@franklinmint.fm)
Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94])
	by web02.designerslab.net with asmtp (Exim 4.34)
	id 1BkSXL-0001v1-OG; Tue, 13 Jul 2004 19:01:55 +0000
Message-ID: <40F431A4.1070902@franklinmint.fm>
Date: Tue, 13 Jul 2004 15:01:56 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tim Bray <tbray@textuality.com>
CC: Atomlist Syntax <atom-syntax@imc.org>
Subject: Re: PaceElementOrder: restart
References: <0186FD30-D4F8-11D8-8C42-000A95A51C9E@textuality.com>
In-Reply-To: <0186FD30-D4F8-11D8-8C42-000A95A51C9E@textuality.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


Tim Bray wrote:

> I am starting a new thread for purely selfish reasons because of the 
> way my mail client deals with veeeeeeery long threads, and because I 
> think we've made some progress.  BUT, I don't like where we are.  I 
> think we have consensus, not on what to do, but on the trade-offs, so 
> let me try to write them down:
>
> 1. enforcing element order makes it harder for people who hand-author
> 2. we have to pick an order which is irritating because it's meaningless
> 3. enforcing order makes life easier for people who use (a significant 
> body of) XSD-based tools.


Only for parsing, right? They can generate Atom as if it's strictly 
ordered no matter what.

> 4. enforcing order adds no significant difficulty for people who are 
> program-generating Atom


How useful is strict ordering in the presence of extension elements? 
What about existing vocabularies that are unordered, like XHTML?

Robert Sayre



From owner-atom-syntax@mail.imc.org  Tue Jul 13 15:47: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 PAA08411
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 15:47: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 i6DJLXtB073778;
	Tue, 13 Jul 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 i6DJLXc6073777;
	Tue, 13 Jul 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 smtpgateway.itweb.no ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DJLWXM073765
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 12:21:33 -0700 (PDT)
	(envelope-from asbjorn@tigerstaden.no)
Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19])
	by smtpgateway.itweb.no (Postfix) with ESMTP
	id 9A17D7C119; Tue, 13 Jul 2004 22:19:37 +0200 (CEST)
Date: Tue, 13 Jul 2004 21:25:10 +0200
To: "Eric Scheid" <eric.scheid@ironclad.net.au>
Subject: Re: Q: modfied vs issued vs created
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <BD199E70.1F3EB%eric.scheid@ironclad.net.au>
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: <opsa3b78fhuvpchu@quark>
In-Reply-To: <BD199E70.1F3EB%eric.scheid@ironclad.net.au>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Tue, 13 Jul 2004 14:13:04 +1000, Eric Scheid  
<eric.scheid@ironclad.net.au> wrote:

>> Why would one assume anything else? From where did the idea that
>> atom:issued could be randomly updated, surface?
>
> The spec was silent on the matter. It is observable practice (good or  
> bad) that people do "re-issue" entries with updated content.

Okay.

> It is also observable that most people don¹t ever re-issue the vast
> majority of their entries, so the question is moot for most cases.

True.

> If we need a tighter/narrower definition, then perhaps we need a new  
> element specifically for that purpose. It makes more sense to have a
> [generic] <issued> and a [specific] <first-issued> than to have a
> [specific/narrow] <issued> and a [wider] <latest-issued>.

What I'm having just as much trouble with, is the idea that 'issued', no  
matter what the element is called, is a subjective date of issuance, when  
Dublin Core explicitly says it's the _formal_ date of issuance (or  
publication).

Note that «August issue» of «Sports Illustrated» is nothing but a title.  
'issued' is when it reaches your local store (approximately). Also note  
that 'issue' is a noun, while 'issued' is a verb describing an action. The  
noun and the verb, in metadata context, is not related.

> Alternatively, we could simply have <issued>+ in the spec.

Yes, I've thought about that as well. I think it's a good solution.

> When I look in the frontspiece of a dead-tree book I can usually find
> a list of prior editions.

Yup. That's why Dublin Core has a 'relation'[1] element, which is to be  
used for re-issues of a resource. It seems that none in the Atom community  
wants that though, because that forces one to change the ID of an entry  
when it has undergone «major changes» and is re-issued.

____
[1] <url: http://dublincore.org/documents/relation-element/>

-- 
Asbjørn Ulsberg         -=|=-        asbjornu@hotmail.com
«He's a loathsome offensive brute, yet I can't look away»



From owner-atom-syntax@mail.imc.org  Tue Jul 13 15:58: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 PAA09655
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 15:58:25 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DJZk1T075025;
	Tue, 13 Jul 2004 12: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 i6DJZkCi075024;
	Tue, 13 Jul 2004 12:35:46 -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 i6DJZkLA075005
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 12:35:46 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040713193539.19188.qmail@web41215.mail.yahoo.com>
Received: from [207.46.238.137] by web41215.mail.yahoo.com via HTTP; Tue, 13 Jul 2004 12:35:39 PDT
Date: Tue, 13 Jul 2004 12:35:39 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Version vs. Namespace
To: Mark Nottingham <mnot@mnot.net>, Tim Bray <Tim.Bray@Sun.COM>
Cc: Dare Obasanjo <kpako@yahoo.com>, Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <0E4C6EEF-D475-11D8-AFCB-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: <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> wrote:
> 
>  > 1. Provide a way to signal MustUnderstand so that
> back-rev software 
> > can fail gracefully.
> 
> Can you spell out option #1 (or give a reference
> into this sea of bits 
> we call the mailing list)? On the face of it, I
> don't see how a mU bit 
> is adequate on its own (it makes a lot of sense in
> conjunction with a 
> different namespace).

It depends on the kind of backwards incompatible
change. Adding required elements or new attributes to
an element can be signalled with mustUnderstand.
Changing the semantics of an element on the other hand
can likely not be signalled just with mustUnderstand.
However there seems to be consensus that this is a bad
thing to do. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
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 Jul 13 16:14:23 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11578
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 16:14:22 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DJnK39075859;
	Tue, 13 Jul 2004 12: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 i6DJnKO1075858;
	Tue, 13 Jul 2004 12:49: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 i6DJnJFr075845
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 12:49:20 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net ([66.57.27.65])
	(authenticated bits=0)
	by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i6DJnxVa025491;
	Tue, 13 Jul 2004 15:50:00 -0400
Message-ID: <40F43CC1.20708@intertwingly.net>
Date: Tue, 13 Jul 2004 15:49:21 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <tbray@textuality.com>
CC: Atomlist Syntax <atom-syntax@imc.org>
Subject: Re: PaceElementOrder: restart
References: <0186FD30-D4F8-11D8-8C42-000A95A51C9E@textuality.com>
In-Reply-To: <0186FD30-D4F8-11D8-8C42-000A95A51C9E@textuality.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:

> I am starting a new thread for purely selfish reasons because of the way 
> my mail client deals with veeeeeeery long threads, and because I think 
> we've made some progress.  BUT, I don't like where we are.  I think we 
> have consensus, not on what to do, but on the trade-offs, so let me try 
> to write them down:
> 
> 1. enforcing element order makes it harder for people who hand-author
> 2. we have to pick an order which is irritating because it's meaningless
> 3. enforcing order makes life easier for people who use (a significant 
> body of) XSD-based tools.
> 4. enforcing order adds no significant difficulty for people who are 
> program-generating Atom
> 
> (#4 is new, but seems pretty obvious).
> 
> I hate this trade-off, polluting a language design because of the 
> broken-ness of a particular schema language is really irritating.
> 
> On balance, if the trade-off is really as presented, I'd probably lean 
> to requiring order, but only by about 55/45.  Are there any new 
> arguments we haven't thought of (please)?  -Tim

OK, I have been holding back.  In fact, I'm only sharing this because 
you said (please).  ;-)

I have some experience with testing interop of wire protocols based on 
XML.  XSD even.  The long and short of it is that #3 above is false as 
stated.  What is actually true is that enforcing order makes life easier 
for people who DEFINE XSD based schemas.

More background can be found here [1], but the punch line for the 
impatient: while the XSD tools that I am aware of will be strict in 
producing messages that conform to an ordered schema, they will be 
liberal in consuming messages with respect to the same ordered schemas.

Which raises a number of troubling questions: in particular, should a 
working group consider the observed but unspec'ed behavior of 
predominant implementations when considering such a question?  Even if 
the question at hand involves the polluting a language design simply 
because of the broken-ness of a particular schema language?  Does this 
reopen other questions related to Postel and Draconianianism?

These questions would be fun to ponder on a lazy Friday afternoon.  Pity 
that today is Tuesday.

- Sam Ruby

[1] http://www.intertwingly.net/stories/2002/07/29/expectMore.html



From owner-atom-syntax@mail.imc.org  Tue Jul 13 16:18: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 QAA12154
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 16:18: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 i6DJpMIG076035;
	Tue, 13 Jul 2004 12:51: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 i6DJpMVo076034;
	Tue, 13 Jul 2004 12:51: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 i6DJpMhc076019
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 12:51: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 7DB347C119; Tue, 13 Jul 2004 22:49:26 +0200 (CEST)
Date: Tue, 13 Jul 2004 21:55:05 +0200
To: "Antone Roundy" <antone@geckotribe.com>
Subject: Re: a methodical approach to defining what date  elements we need
References: <63E12F93-D452-11D8-9D0B-003065EA6144@geckotribe.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
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: <opsa3dl3q7uvpchu@quark>
In-Reply-To: <63E12F93-D452-11D8-9D0B-003065EA6144@geckotribe.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Mon, 12 Jul 2004 16:25:33 -0600, Antone Roundy <antone@geckotribe.com>  
wrote:

> 1) By "issued date" and "modified date" do you mean objective  
> timestamps, or author-specifiable (subjective) timestamps?

Objective. Dublin Core uses the word «formal» which I find to be very far  
 from «subjective».

> 2) By "issued" do you mean first issued or most recently issued (if the  
> same entry was "issued" more than once)?

If we would follow DC by the book, there is no past or present. It is only  
«now» which points to «this» item. The issued date is then when the item  
you're looking at was published. If you've made minor changes  
(typographical erratas) to the entry, that may (however uninteresting that  
is for most users and tools) change the 'modified' date. Major changes,  
which makes the entry worth reading again, should be done issuing a _new_  
entry which is related[1] to the previous one.

> 3) By "modified", do you mean the last major change which changed or  
> non-trivially augmented the meaning of the entry

This should trigger a re-issuance of the entry, which would give it a new  
ID and a relation of «is version of» equal to the previous ID.

> Yeah, it may be difficult to draw a perfect line between major and minor  
> changes, but a lot of people, myself included, seem to WANT to be able  
> to differentiate

Then Atom should be able to let you do so. Dublin Core defines this in the  
relation element, and I feel that Atom definately should adopt that term.

____
[1] <url: http://dublincore.org/documents/relation-element/>


-- 
Asbjørn Ulsberg         -=|=-        asbjornu@hotmail.com
«He's a loathsome offensive brute, yet I can't look away»



From owner-atom-syntax@mail.imc.org  Tue Jul 13 16:37: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 QAA14591
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 16:37: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 i6DK7g9H077469;
	Tue, 13 Jul 2004 13: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 i6DK7g8D077468;
	Tue, 13 Jul 2004 13:07: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 (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DK7e4f077462
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 13:07:41 -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 5E3377C119; Tue, 13 Jul 2004 23:05:45 +0200 (CEST)
Date: Tue, 13 Jul 2004 22:11:27 +0200
To: "Walter Underwood" <wunder@verity.com>
Subject: Re: a methodical approach to defining what date  elements we need
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <14B72756-D419-11D8-9D0B-003065EA6144@geckotribe.com> <40F2C2CD.9020307@intertwingly.net> <47071860-D42A-11D8-82B1-000A95DC3D90@mac.com> <opsa1nlh1u6dxgxk@mail.online.no> <6C2098C54ED33AE163D3E2F5@adsl-64-166-133-244.dsl.snfc21.pacbell.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: <opsa3eddg8uvpchu@quark>
In-Reply-To: <6C2098C54ED33AE163D3E2F5@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Mon, 12 Jul 2004 16:17:55 -0700, Walter Underwood <wunder@verity.com>  
wrote:

>> What a view date is, is by it's very nature not in a feed author's
>> control [2].
>
> It is in the author's control if we allow the author to provide
> a display date.

Then that should be <userdate> and not <issued>, as «issued» in Dublin  
Core terms, is the formal date of issuance, not a subjective random string  
formatted as a W3CDTF.

> When an author is posting at 3am local time, or during Ramadan, the
> author's view of the date matters, and should normally be preferred.

Preferred by whom? Not by me, to be sure. And not by NRK. And not by EBU.  
We want dates we can trust, preferably provided by the tools issuing the  
entries. _All_ tools has this action. They just don't apply a date when  
doing it. The date provided by the user should not be <issued>, but  
<userdate>, <visible-date> or something in those lines.

-- 
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 Jul 13 16:44:50 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15470
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 16:44: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 i6DKLtjw078518;
	Tue, 13 Jul 2004 13:21: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 i6DKLtI0078517;
	Tue, 13 Jul 2004 13:21: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 i6DKLsoH078502
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 13:21: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 4F6F27C119; Tue, 13 Jul 2004 23:19:59 +0200 (CEST)
Date: Tue, 13 Jul 2004 22:25:44 +0200
To: "Eric Scheid" <eric.scheid@ironclad.net.au>
Subject: Re: MUST be UTC?
References: <BD19108F.1F1CE%eric.scheid@ironclad.net.au>
Cc: Atom-Syntax <atom-syntax@imc.org>
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: <opsa3e0606uvpchu@quark>
In-Reply-To: <BD19108F.1F1CE%eric.scheid@ironclad.net.au>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Tue, 13 Jul 2004 04:07:43 +1000, Eric Scheid  
<eric.scheid@ironclad.net.au> wrote:

>> Up until the date discussion  surfaced just recently, I actually  
>> thought all Atom dates were objective.  I'm still amazed that's
>> not the case.
>
> you've not been following the career of Samuel Pepys then?

No, but I've just read up about him, and he's hardly a use case for Atom.  
At least nothing within the 80/20 rule. Either way, in his case, <issued>  
should be set to when the diary «entries» were issued to its intended  
audience. For the introduction[1], for example, <issued> should be set to  
'1893-MM-dd', if it's not changed considerably.

If it is, the original should be placed untouched somewhere, and the  
current introduction[1] should be related[2] to it as a «version of» the  
original.

____
[1] <url: http://www.pepysdiary.com/intro/pepys/>
[2] <url: http://dublincore.org/documents/relation-element/>

-- 
Asbjørn Ulsberg         -=|=-        asbjornu@hotmail.com
«He's a loathsome offensive brute, yet I can't look away»



From owner-atom-syntax@mail.imc.org  Tue Jul 13 16:57: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 QAA16866
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 16:57: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 i6DKUxM5078988;
	Tue, 13 Jul 2004 13:30: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 i6DKUxMi078987;
	Tue, 13 Jul 2004 13:30: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 (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DKUwmO078976
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 13:30: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 1418E7C1EE; Tue, 13 Jul 2004 23:29:03 +0200 (CEST)
Date: Tue, 13 Jul 2004 22:34:50 +0200
To: "Eric Scheid" <eric.scheid@ironclad.net.au>
Subject: Re: Q: modfied vs issued vs created
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <BD1990C7.1F3B9%eric.scheid@ironclad.net.au>
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: <opsa3fgcvzuvpchu@quark>
In-Reply-To: <BD1990C7.1F3B9%eric.scheid@ironclad.net.au>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Tue, 13 Jul 2004 13:14:47 +1000, Eric Scheid  
<eric.scheid@ironclad.net.au> wrote:

> Come to that, I'd expect to see more accuracy if the default was minor
> change and the author had to select an option to "re-issue" it. That is,  
> if the option said "this is a major change" instead of "this is a trivial
> change".

Absolutely. +1 on that. A re-issue should, however, not just update  
'issued', but truly re-issue the entry with a new ID and a <relation>  
element that has an attribute 'is-version-of' that points to the old  
version.

-- 
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 Jul 13 17:07: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 RAA17978
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 17:07: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 i6DKkQLP080131;
	Tue, 13 Jul 2004 13:46: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 i6DKkQOB080130;
	Tue, 13 Jul 2004 13:46:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.198])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6DKkPes080123
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 13:46:26 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d19so463195rnf
        for <atom-syntax@imc.org>; Tue, 13 Jul 2004 13:46:11 -0700 (PDT)
Received: by 10.38.72.80 with SMTP id u80mr153485rna;
        Tue, 13 Jul 2004 13:46:11 -0700 (PDT)
Message-ID: <14be96d304071313463a785e12@mail.gmail.com>
Date: Tue, 13 Jul 2004 16:46:11 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Sam Ruby <rubys@intertwingly.net>
Subject: Re: PaceElementOrder: restart
Cc: Tim Bray <tbray@textuality.com>, Atomlist Syntax <atom-syntax@imc.org>
In-Reply-To: <40F43CC1.20708@intertwingly.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <0186FD30-D4F8-11D8-8C42-000A95A51C9E@textuality.com> <40F43CC1.20708@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 Tue, 13 Jul 2004 15:49:21 -0400, Sam Ruby <rubys@intertwingly.net> wrote:
> Does this reopen other questions related to Postel and Draconianianism?

Oh dear God, I hope not.

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Tue Jul 13 17:22: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 RAA20198
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 17:22: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 i6DL1w64081022;
	Tue, 13 Jul 2004 14: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 i6DL1wGL081021;
	Tue, 13 Jul 2004 14:01:58 -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 i6DL1w7t081013
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 14:01:58 -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 <2004071321015501500hchr4e>; Tue, 13 Jul 2004 21:01:55 +0000
Date: Tue, 13 Jul 2004 15:01:54 -0600
Subject: Re: a methodical approach to defining what date  elements we need
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: <opsa3dl3q7uvpchu@quark>
Message-Id: <DE98B349-D50F-11D8-9B93-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 i6DL1w7t081016
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 Tuesday, July 13, 2004, at 01:55  PM, Asbjørn Ulsberg wrote:
> On Mon, 12 Jul 2004 16:25:33 -0600, Antone Roundy 
> <antone@geckotribe.com> wrote:
> ... Dublin Core uses the word ....
> ...
> If we would follow DC by the book
> ...
> ...Dublin Core defines this in the relation[1] element, and I feel 
> that Atom definately should adopt that term.
> ____
> [1] <url: http://dublincore.org/documents/relation-element/>
>
Okay, one more big question (which I think we should revisit a little 
later--see below)--do we want to:
1) adopt Dublin Core elements exclusively (by which I DON'T mean using 
their namespace--just defining the dates in our namespace identically 
to the way they do it)?
2) use a mix of DC and our own elements?
3) make up our own elements which may have the same names as DC dates, 
but possibly different meanings?
4) make up our own elements, being sure that they don't duplicate DC 
element names to avoid confusion?

My answers:
1) If we can find a set of DC dates that meet our needs, and which 
won't cause confusion by having non-intuitive names, fine--I'm not 
familiar enough with DC to comment further on that right now.
2) Once again, if we end up with something that meets our needs, fine.
3) I don't have a problem with this, but I can imagine some others 
would.
4) I hope we can avoid doing this.

...but before we get to the issue of nailing down the names of the Date 
Constructs, why don't we decide what Date Constructs we want (ignoring 
the fact that the names we temporarily refer to them by might be the 
same as DC dates with different meanings).  Once that's done, if 
there's a direct mapping to DC dates which doesn't lose the meaning 
that we decide we want, fine. I do not think it's a good idea to 
squeeze Atom into Dublin Core's set of dates if doing so keeps us from 
being able to express the dates that would serve Atom best.

So, getting back to this:

> 1) objective creation date
> 2) each objective major modification date
> 3) each objective minor modification date
> 4) each objective publication date
> 5) any subjective creation date the author may wish to associate with 
> the entry
> 6) any subjective major modification date the author may wish to 
> associate with the entry
> 7) any subjective minor modification date the author may wish to 
> associate with the entry
> 8) any subjective publication date the author may wish to associate 
> with the entry

can we agree that we need #8, regardless of everything else?

As for the rest, I'm guessing that the following alternative points of 
view capture most everyone's position:

A) We need #4, which can not change, and the last #3.  If #2 occurred, 
a new entry should be created with some means of indicating that it had 
replaced the original entry.

B) We need #4, which can not change, and the last #2/#3--don't 
differentiate between them.

C) We need the last #4 (it can change), the last #2, and the last #3. 
[this is my POV]

D) We need the last #4 (it can change), and the last #2/#3--don't 
differentiate between them.

Comments?  Opinions?



From owner-atom-syntax@mail.imc.org  Tue Jul 13 17:25: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 RAA20438
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 17:25: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 i6DL76Ea081616;
	Tue, 13 Jul 2004 14:07: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 i6DL76kC081615;
	Tue, 13 Jul 2004 14:07:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DL75ZM081602
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 14:07:05 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from phys-bur-1 ([129.148.9.72])
	by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i6DL730R012310
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 14:07:03 -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 <0I0T001016LAEJ@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com)
 for atom-syntax@imc.org; Tue, 13 Jul 2004 17:07:02 -0400 (EDT)
Received: from mercury (vpn-129-150-32-132.Central.Sun.COM [129.150.32.132])
 by bur-mail1.east.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
 with ESMTP id <0I0T006Q16NHK2@bur-mail1.east.sun.com> for atom-syntax@imc.org;
 Tue, 13 Jul 2004 17:07:02 -0400 (EDT)
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BkUU1-000320-00	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 17:06:37 -0400
X-URL: http://nwalsh.com/
Date: Tue, 13 Jul 2004 17:06:36 -0400
From: Norman Walsh <ndw@nwalsh.com>
Subject: Re: a methodical approach to defining what date  elements we need
In-reply-to: <opsa3dl3q7uvpchu@quark>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <87hdsbvcpv.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: <63E12F93-D452-11D8-9D0B-003065EA6144@geckotribe.com>
 <opsa3dl3q7uvpchu@quark>
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-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

/ Asbj=F8rn Ulsberg <asbjorn@tigerstaden.no> was heard to say:
| date. Major changes,  which makes the entry worth reading again,
| should be done issuing a _new_  entry which is related[1] to the
| previous one.

FWIW, I'm convinced. I haven't done it often, but the ability to "reissue"
was really the only thing that made me want the created/issued/modified
triumvirate.

Created =3D when I created the essay.
Issued =3D when I last made "significant" changes to the entry.
Modified =3D when I last changed any of the bits in the entry.

I'm now convinced that it would be better to use just two:

Issued =3D when I published the essay
Modified =3D when I last changed any of the bits in the entry.

If I make a "significant" change, I should

1. Create a new entry with a new ID and new dates
2. Indicate that this new entry dcterms:replaces the original.
2. Update the original to say it's been dcterms:isReplacedBy the new one.

It's more work, but it'll make for a better historical record.

                                        Be seeing you,
                                          norm

=2D-=20
Norman Walsh <ndw@nwalsh.com> | Simplicity is always a virtue.--Edward
http://nwalsh.com/            | Abbey

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA9E7cOyltUcwYWjsRAgy1AKCc3aoG8urOGb7UvDr2oy6tIgvNawCgryWx
zH/S9V8AfwdE7ZG1Y0y75os=
=lW2v
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Tue Jul 13 17: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 RAA25095
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 17: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 i6DLnslG084958;
	Tue, 13 Jul 2004 14:49: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 i6DLnsZw084957;
	Tue, 13 Jul 2004 14:49:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DLnrKK084951
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 14:49:53 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net ([66.57.27.65])
	(authenticated bits=0)
	by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i6DLoaxN031370;
	Tue, 13 Jul 2004 17:50:36 -0400
Message-ID: <40F45906.7060007@intertwingly.net>
Date: Tue, 13 Jul 2004 17:49:58 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Norman Walsh <ndw@nwalsh.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: a methodical approach to defining what date  elements we need
References: <63E12F93-D452-11D8-9D0B-003065EA6144@geckotribe.com> <opsa3dl3q7uvpchu@quark> <87hdsbvcpv.fsf@nwalsh.com>
In-Reply-To: <87hdsbvcpv.fsf@nwalsh.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


Norman Walsh wrote:

> I'm now convinced that it would be better to use just two:
> 
> Issued = when I published the essay
> Modified = when I last changed any of the bits in the entry.
> 
> If I make a "significant" change, I should
> 
> 1. Create a new entry with a new ID and new dates
> 2. Indicate that this new entry dcterms:replaces the original.
> 2. Update the original to say it's been dcterms:isReplacedBy the new one.
> 
> It's more work, but it'll make for a better historical record.

It's not much more work for you, but it is much more work for consumers.

Consider that a typical aggregator polls for data.  If you replace an 
entry twice, and the aggregator missed the first one, then it has an 
incomplete history to reconcile.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Tue Jul 13 18:00: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 SAA25265
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 18:00: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 i6DLlB7a084724;
	Tue, 13 Jul 2004 14:47: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 i6DLlBlb084723;
	Tue, 13 Jul 2004 14:47:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from priv-edtnes85.telusplanet.net (defout.telus.net [199.185.220.240])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DLlAVK084716
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 14:47:10 -0700 (PDT)
	(envelope-from jeremy@jeremygray.ca)
Received: from dora9 ([207.6.254.14]) by priv-edtnes85.telusplanet.net
          (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with ESMTP
          id <20040713214708.CZIP14425.priv-edtnes85.telusplanet.net@dora9>
          for <atom-syntax@imc.org>; Tue, 13 Jul 2004 15:47:08 -0600
Reply-To: <jeremy@jeremygray.ca>
From: "Jeremy Gray" <jeremy@jeremygray.ca>
To: "'Atom Syntax'" <atom-syntax@imc.org>
Subject: RE: a methodical approach to defining what date  elements we need
Date: Tue, 13 Jul 2004 14:47:29 -0700
Message-ID: <002b01c46922$ff079cb0$6400a8c0@dora9>
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.4510
In-Reply-To: <87hdsbvcpv.fsf@nwalsh.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6DLlAVK084718
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


> -----Original Message-----
> From: owner-atom-syntax@mail.imc.org
[mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Norman Walsh
> Sent: Tuesday, July 13, 2004 2:07 PM
> To: Atom Syntax
> Subject: Re: a methodical approach to defining what date elements we need
> 
> 
> / Asbjørn Ulsberg <asbjorn@tigerstaden.no> was heard to say:
> | date. Major changes,  which makes the entry worth reading again, 
> | should be done issuing a _new_  entry which is related[1] to the 
> | previous one.
> 
> FWIW, I'm convinced. I haven't done it often, but the ability to
> "reissue" was really the only thing that made me want the created/
> issued/modified triumvirate.
> 
> Created = when I created the essay.
> Issued = when I last made "significant" changes to the entry.
> Modified = when I last changed any of the bits in the entry.
>
> I'm now convinced that it would be better to use just two:
>
> Issued = when I published the essay
> Modified = when I last changed any of the bits in the entry.
> 
> If I make a "significant" change, I should
> 
> 1. Create a new entry with a new ID and new dates
> 2. Indicate that this new entry dcterms:replaces the original.
> 2. Update the original to say it's been dcterms:isReplacedBy the
> new one.
>
> It's more work, but it'll make for a better historical record.

+1

I've been trying my hardest to just sit back and watch this thread unfold
but I think that Norm hits this one on the head so well that its time to
chime in with my +1.

Issued is objective, gets set once, and never changes.

Modified is objective, gets set initially, and can be updated when minor
changes are made.

Major changes are handled by issuance of a new entry with pointers back from
the new and forth from the old. This has the benefit of recording the full
chain of changes (and retaining the content of each entry version thereof,
allowing for diffs and such) while avoiding the slippery slope that is
first-issued, last-issued, third-issued,
second-to-last-tweak-before-bedtime-issued, etc.) and the data loss of
issued+.

Add in a purely subjective element that authors can use for things like
"After partying late last night" and we're good to go.

Now, who wants to take a stab at a normative definition, if one is even
possible, of a minor change (modification) vs. a major change (requiring new
issuance)? :)

Jeremy Gray




From owner-atom-syntax@mail.imc.org  Tue Jul 13 18:02:57 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25480
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 18:02: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 i6DLq1cw085045;
	Tue, 13 Jul 2004 14:52: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 i6DLq1FU085044;
	Tue, 13 Jul 2004 14:52: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 i6DLq0o3085035
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 14:52:00 -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 i6DLnw53015800
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 15:49:58 -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 <0I0T00JMC8QST4@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Tue, 13 Jul 2004 15:52:05 -0600 (MDT)
Received: from [192.168.1.9] ([154.20.133.9])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0T00CYN8QSE4@mail.sun.net> for atom-syntax@imc.org; Tue,
 13 Jul 2004 15:52:04 -0600 (MDT)
Date: Tue, 13 Jul 2004 14:52:07 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Low-hanging fruit: non-validating parser
To: Atomlist Syntax <atom-syntax@imc.org>
Message-id: <E2DC94E5-D516-11D8-8C42-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: <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'm looking around seeing what we might be able to roll into -01 drafts 
per discussion here.  I think we can update the Format Draft with Rob 
Sayre's language: "Atom documents can be processed by non-validating 
XML processors. An Atom document MUST NOT rely on any behaviors not 
required of such processors."  [But I'd change "document MUST NOT" to 
"software MUST NOT"]. -Tim



From owner-atom-syntax@mail.imc.org  Tue Jul 13 18:06: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 SAA26311
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 18:06: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 i6DLttYq085230;
	Tue, 13 Jul 2004 14:55: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 i6DLttpT085229;
	Tue, 13 Jul 2004 14:55: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 i6DLts4F085223
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 14:55:54 -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 i6DLrq53018414
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 15:53:52 -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 <0I0T00EJB8XAZB@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Tue, 13 Jul 2004 15:55:59 -0600 (MDT)
Received: from [192.168.1.9] ([154.20.133.9])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0T00C0V8X8E4@mail.sun.net> for atom-syntax@imc.org; Tue,
 13 Jul 2004 15:55:58 -0600 (MDT)
Date: Tue, 13 Jul 2004 14:56:00 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Low-hanging fruit: compulsory namespaces
To: Atomlist Syntax <atom-syntax@imc.org>
Message-id: <6D6BAC41-D517-11D8-8C42-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: <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 suggest that we have good enough consensus to remove the paragraph in 
draft-format-00 in section 2. beginning "All elements and attributes in 
an Atom document MUST be namespace-qualified".  Because lots of 
attributes aren't, and when it was pointed out that this would forbid 
encapsulating RSS 2.0 and Docbook, nobody pushed back and said "it's OK 
to forbid that".  -Tim



From owner-atom-syntax@mail.imc.org  Tue Jul 13 18:20: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 SAA28613
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 18: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 i6DM8xTh086060;
	Tue, 13 Jul 2004 15:08: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 i6DM8x6Y086059;
	Tue, 13 Jul 2004 15:08:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DM8vnB086053
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 15:08: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 esmtp (Exim 4.34)
	id 1BkVSI-0003tx-QI; Tue, 13 Jul 2004 22:08:54 +0000
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Tue, 13 Jul 2004 18:09:02 -0400
Subject: Re: a methodical approach to defining what date  elements we need
From: Robert Sayre <mint@franklinmint.fm>
To: Sam Ruby <rubys@intertwingly.net>, Norman Walsh <ndw@nwalsh.com>
CC: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD19D5BE.13933%mint@franklinmint.fm>
In-Reply-To: <40F45906.7060007@intertwingly.net>
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: <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 7/13/04 5:49 PM, "Sam Ruby" <rubys@intertwingly.net> wrote:

> 
> Norman Walsh wrote:
> 
>> I'm now convinced that it would be better to use just two:
>> 
>> Issued = when I published the essay
>> Modified = when I last changed any of the bits in the entry.
>> 
>> If I make a "significant" change, I should
>> 
>> 1. Create a new entry with a new ID and new dates
>> 2. Indicate that this new entry dcterms:replaces the original.
>> 2. Update the original to say it's been dcterms:isReplacedBy the new one.
>> 
>> It's more work, but it'll make for a better historical record.
> 
> It's not much more work for you, but it is much more work for consumers.
> 
> Consider that a typical aggregator polls for data.  If you replace an
> entry twice, and the aggregator missed the first one, then it has an
> incomplete history to reconcile.

But if he just tweaks a date field each update, the consumer won't even know
it missed anything.

Robert Sayre



From owner-atom-syntax@mail.imc.org  Tue Jul 13 18:20: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 SAA28637
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 18:20:59 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DMBmf9086220;
	Tue, 13 Jul 2004 15:11: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 i6DMBmo4086219;
	Tue, 13 Jul 2004 15:11: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 i6DMBlCN086213
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 15:11: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 i6DMBqil017093
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 16:11:52 -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 <0I0T00EAT9NRZB@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Tue, 13 Jul 2004 16:11:52 -0600 (MDT)
Received: from [192.168.1.9] ([154.20.133.9])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0T00C849NRE4@mail.sun.net> for atom-syntax@imc.org; Tue,
 13 Jul 2004 16:11:51 -0600 (MDT)
Date: Tue, 13 Jul 2004 15:11:54 -0700
From: Tim Bray <tbray@textuality.com>
Subject: Low-hanging fruit: multipart/alternative
To: Atomlist Syntax <atom-syntax@imc.org>
Message-id: <A65D9796-D519-11D8-8C42-000A95A51C9E@textuality.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.618)
Content-type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5--219634695;
 protocol="application/pkcs7-signature"
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--219634695
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

I don't think we have consensus on what we're replacing it with, but I 
think that we do have consensus that the description of 
multipart/alternative in 4.13.10 in draft-format-00 should go.  This 
was my take-way from the Atom Community meeting back in June -Tim
--Apple-Mail-5--219634695
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
hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDcxMzIyMTE1NVowIwYJKoZIhvcNAQkEMRYEFEcz
TLnuSSQLtTPrC66oyqTDGJEVMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV
BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLirkwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT
AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3
dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDC4q5MA0GCSqGSIb3DQEBAQUABIIBAGmS
LmGeomcVAbgDIVsZCtea1VAfK+SG2zGVPT4/kQw1tzmeHfp0m4v5tcvBpZhNOc4KmC96U16mGtSV
ixm9wXyRQ9I7NkmlBoJEaD6HbDEWBmFJswLO+eLKvaHD32JYX4zYG95DJ1s00vdpu7+XFkZWQGCJ
D4mY3dVXUajFfCLtRbdo11vK7YaHS8NFugjexPhvykm7WJyXNGHxwQ6V1GWXK8RSirks/rmvW79K
fZAP9e3IFWBLe3n8oy3ixzEarx/mjjzl3qeODNkdMcTqapOl7CFC9VLnvTD9EuLbSg1Tw99o97UE
/lUrfFMzw00bO4Vh2w21YGfhwhynidzyWN4AAAAAAAA=

--Apple-Mail-5--219634695--



From owner-atom-syntax@mail.imc.org  Tue Jul 13 18: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 SAA28704
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 18:23:15 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DMDEPv086253;
	Tue, 13 Jul 2004 15:13: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 i6DMDEwi086252;
	Tue, 13 Jul 2004 15:13: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 i6DMDEiB086246
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 15:13:14 -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 i6DMBC53000213
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 16:11: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 <0I0T00JSO9Q6T4@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Tue, 13 Jul 2004 16:13:19 -0600 (MDT)
Received: from [192.168.1.9] ([154.20.133.9])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0T00C8Q9Q6E4@mail.sun.net> for atom-syntax@imc.org; Tue,
 13 Jul 2004 16:13:18 -0600 (MDT)
Date: Tue, 13 Jul 2004 15:13:22 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Editorial comments on draft-ietf-atompub-format-00
To: Atomlist Syntax <atom-syntax@imc.org>
Message-id: <DABD07E4-D519-11D8-8C42-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: <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


Do we agree that it's OK to batch up editorial comments like this?

[Page 5/sect 2] Did we agree to deprecate Processing Instructions?  I 
believe not, and this is in conflict with RFC3470, and should be 
removed as an editorial correction.  Unless someone can show me how 
this somehow represents consensus based on earlier discussion.

[Page 5/sect 2] I would suggest, per 3470, that the language saying 
Atom should/may/whatever contain DOCTYPES, PIs, and comments is 
superfluous.

[Page 5, sect 2] I think the paragraph about xml:lang should have a 
reference to http://www.w3.org/TR/REC-xml/#sec-lang-tag

[Page 6, sect 3.1.2] the discussion of "escaped" needs a reference to 
what kind of unescaping you're talking about: 
http://www.w3.org/TR/REC-xml/#dt-escape

[Page 7, sect 3.2.2] "atom:url" has to go as an element name.  Either 
"uri" or "web" would be a satisfactory replacement, but since there is 
no in-effect normative text describing what "url" stands for, it's 
really not appropriate.  Same for 4.9 and anywhere else "url" appears.

[page 11, sect 4.12].  Is the text about "xml:lang" here useful, or 
does the discussion above make it superfluous?

[page 12, sect 4.13.1]  I don't think the "title" of a Web Resource is 
a well-defined construct.  It certainly doesn't appear in Web 
architecture.  If you mean "is the same as the contents of the <title> 
element in the case where HTML representations are typically made 
available..." then that's fine.  Or (better) just lose it.

[page 13, sect 4.13.9] Typo in "atom:summary", it says "MAY contain an 
atom:created" you mean "MAY contain an atom:summary"






From owner-atom-syntax@mail.imc.org  Tue Jul 13 18: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 SAA29127
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 18: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 i6DMHOAA086882;
	Tue, 13 Jul 2004 15:17: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 i6DMHO1T086880;
	Tue, 13 Jul 2004 15:17: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 i6DMHOH2086755
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 15:17:24 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040713221724.76821.qmail@web41211.mail.yahoo.com>
Received: from [207.46.238.133] by web41211.mail.yahoo.com via HTTP; Tue, 13 Jul 2004 15:17:24 PDT
Date: Tue, 13 Jul 2004 15:17:24 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: PaceElementOrder: restart
To: Sam Ruby <rubys@intertwingly.net>, Tim Bray <tbray@textuality.com>
Cc: Atomlist Syntax <atom-syntax@imc.org>
In-Reply-To: <40F43CC1.20708@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:
> > > 
> > 1. enforcing element order makes it harder for
> people who hand-author
> > 2. we have to pick an order which is irritating
> because it's meaningless
> > 3. enforcing order makes life easier for people
> who use (a significant 
> > body of) XSD-based tools.
> > 4. enforcing order adds no significant difficulty
> for people who are 
> > program-generating Atom
> > 
> 
> I have some experience with testing interop of wire
> protocols based on 
> XML.  XSD even.  The long and short of it is that #3
> above is false as 
> stated.  What is actually true is that enforcing
> order makes life easier 
> for people who DEFINE XSD based schemas.
> 
> More background can be found here [1], but the punch
> line for the 
> impatient: while the XSD tools that I am aware of
> will be strict in 
> producing messages that conform to an ordered
> schema, they will be 
> liberal in consuming messages with respect to the
> same ordered schemas.

That's not the point. The point is that if the schema
is explicitly unordered (i.e. using xs:choice with
maxOccurs=unbounded instead of an xs:sequence) then
the programming model generated by tools such as
XSD.exe which is what VS.NET uses behind the scenes to
generate stubs from a WSDL will not be strongly typed.


The fact that most XML Web Service stacks don't
actually perform schema validation when consuming XML
messages is interesting to note but I'm not sure it is
particularly pertinent in this discussion. 

My take is that order doesn't matter much for the
syndication case. Aggregator authors already have to
deal with unordered content in RSS so doing the same
in Atom won't be a big deal. As for casual developers,
they'll likely go through standard Atom libraries like
Atom.NET & Atomizer and thus would be insulated from
such issues. 

On the other hand, if there ever is a SOAP API, it
would be much preferable for the format to be ordered
in that context so that the generated classes for
users of tools such as VS.NET have a better developer
experience. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
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 Jul 13 18:28: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 SAA29471
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 18:28: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 i6DMHkAI086997;
	Tue, 13 Jul 2004 15: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 i6DMHkP0086996;
	Tue, 13 Jul 2004 15:17:46 -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 i6DMHi2p086984
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 15:17: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 PAA28067
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 15:17: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 PAA27239
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 15:17:42 -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, 13 Jul 2004 15:17:41 -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 <0I0T00CSS9XF9Q@shazam.verity.com> for atom-syntax@imc.org; Tue,
 13 Jul 2004 15:17:41 -0700 (PDT)
Date: Tue, 13 Jul 2004 15:17:39 -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: Low-hanging fruit: non-validating parser
In-reply-to: <E2DC94E5-D516-11D8-8C42-000A95A51C9E@sun.com>
To: Atomlist Syntax <atom-syntax@imc.org>
Message-id: <ED474CAAF91509F1C62A66A5@[192.168.168.164]>
MIME-version: 1.0
X-Mailer: Mulberry/3.1.5 (Mac OS X)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <E2DC94E5-D516-11D8-8C42-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, July 13, 2004 2:52 PM -0700 Tim Bray <Tim.Bray@Sun.COM> wrote:
>
> [But I'd change "document MUST NOT" to "software MUST NOT"]. -Tim

"implementations MUST NOT". I think Bob Wyman could use a hardware
Atom parser.

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Tue Jul 13 18:30: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 SAA29895
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 18:30: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 i6DMMS0s087400;
	Tue, 13 Jul 2004 15:22: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 i6DMMSPm087399;
	Tue, 13 Jul 2004 15:22:28 -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 i6DMMSAU087392
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 15:22:28 -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 <20040713222222011009o9j7e>; Tue, 13 Jul 2004 22:22:23 +0000
Date: Tue, 13 Jul 2004 16:22:21 -0600
Subject: Re: a methodical approach to defining what date  elements we need
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: <40F45906.7060007@intertwingly.net>
Message-Id: <1C01718E-D51B-11D8-9B93-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, July 13, 2004, at 03:49  PM, Sam Ruby wrote:
>> I'm now convinced that it would be better to use just two:
>> Issued = when I published the essay
>> Modified = when I last changed any of the bits in the entry.
>> If I make a "significant" change, I should
>> 1. Create a new entry with a new ID and new dates
>> 2. Indicate that this new entry dcterms:replaces the original.
>> 2. Update the original to say it's been dcterms:isReplacedBy the new 
>> one.
>> It's more work, but it'll make for a better historical record.
>
> It's not much more work for you, but it is much more work for 
> consumers.
>
> Consider that a typical aggregator polls for data.  If you replace an 
> entry twice, and the aggregator missed the first one, then it has an 
> incomplete history to reconcile.
>
This, and the fact that people ARE going to republish heavily modified 
entries without creating a new one are my big reasons for not favoring 
any kind of "replaces" system.  I'd prefer a modified (big 
change)/updated (small change) combo, which hopefully would be simple 
enough to create a UI for (like someone suggested, default to small 
change and have a checkbox to indicate a big change), and if so, would 
encourage people to differentiate between little fixes and big changes.

On the other hand, that same UI could control whether an entry is 
updated or replaced (though it's greater complexity might result in 
some developers not supporting it).

Anyway, to me, the benefit just doesn't outweigh the much greater 
complexity for the consumer.



From owner-atom-syntax@mail.imc.org  Tue Jul 13 18:36: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 SAA00723
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 18:36: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 i6DMSeZb087703;
	Tue, 13 Jul 2004 15: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 i6DMSeIK087702;
	Tue, 13 Jul 2004 15:28:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from priv-edtnes57.telusplanet.net (outbound01.telus.net [199.185.220.220])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DMS5EX087668
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 15:28:39 -0700 (PDT)
	(envelope-from jeremy@jeremygray.ca)
Received: from dora9 ([207.6.254.14]) by priv-edtnes57.telusplanet.net
          (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with ESMTP
          id <20040713222804.FRWN14951.priv-edtnes57.telusplanet.net@dora9>
          for <atom-syntax@imc.org>; Tue, 13 Jul 2004 16:28:04 -0600
Reply-To: <jeremy@jeremygray.ca>
From: "Jeremy Gray" <jeremy@jeremygray.ca>
To: "'Atom Syntax'" <atom-syntax@imc.org>
Subject: RE: a methodical approach to defining what date  elements we need
Date: Tue, 13 Jul 2004 15:28:26 -0700
Message-ID: <000301c46928$b77f5440$6400a8c0@dora9>
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.4510
In-Reply-To: <40F45906.7060007@intertwingly.net>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


> From: owner-atom-syntax@mail.imc.org
[mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Sam Ruby
> Sent: Tuesday, July 13, 2004 2:50 PM
> To: Norman Walsh
> Cc: Atom Syntax
> Subject: Re: a methodical approach to defining what date elements we need

-snip-

> Consider that a typical aggregator polls for data.  If you replace an 
> entry twice, and the aggregator missed the first one, then it has an 
> incomplete history to reconcile.

Worst case: the aggregator thinks it is an entirely new post.
Middle case: the aggregator notices that there is a pointer to a previous
version and visibly notifies the user that the entry is replacing one it
does not have on hand.
Best case: the aggregator notices the pointer and uses some
yet-to-be-defined mechanism to talk to the server to get the missing entry.

Even the worst case doesn't appear to be particularly problematic. Is there
something I'm missing?

Jeremy Gray



From owner-atom-syntax@mail.imc.org  Tue Jul 13 18:44:38 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01467
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 18:44:37 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DMSqkV087720;
	Tue, 13 Jul 2004 15:28: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 i6DMSqWN087719;
	Tue, 13 Jul 2004 15:28:52 -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 i6DMSBTN087674
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 15:28:51 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6DMSGil027617
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 16:28:16 -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 <0I0T00EEEAF36J@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Tue, 13 Jul 2004 16:28:16 -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 <0I0T00CQLAF3E1@mail.sun.net> for atom-syntax@imc.org; Tue,
 13 Jul 2004 16:28:15 -0600 (MDT)
Date: Tue, 13 Jul 2004 15:26:51 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Editorial comments on draft-atompub-protocol-00
To: Atomlist Syntax <atom-syntax@imc.org>
Message-id: <BC806156-D51B-11D8-8C42-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: <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


[page 3/sect 1.1] busted sentence: 'the and "OPTIONAL"'

[page 5/sect 3.1.3.3] the description of code 400 is borked, see the 
sentence "A short description of the error..."

Same for 3.1.3.4.

[page 5/sect 3.2] the description reads like it's forbidden to do a PUT 
without doing a GET first.  Is this true?  If I know the URI and I know 
what I want to put there, can't I just blast it in?

[page 6/sect.3.2] there's nothing about return codes.  Perhaps you need 
a @to-do note?

[page 6/sect 3.3] Could the FeedURI and PostURI be the same URI?  I 
assume so, but it might be better to be explicit.



From owner-atom-syntax@mail.imc.org  Tue Jul 13 18:45: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 SAA01542
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 18:45:24 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DMZQsT088720;
	Tue, 13 Jul 2004 15:35: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 i6DMZQKr088719;
	Tue, 13 Jul 2004 15:35: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 i6DMZPFI088556
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 15:35: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 434F77C117; Wed, 14 Jul 2004 01:33:23 +0200 (CEST)
Date: Wed, 14 Jul 2004 00:38:28 +0200
To: "Sam Ruby" <rubys@intertwingly.net>, "Norman Walsh" <ndw@nwalsh.com>
Subject: Re: a methodical approach to defining what date  elements we need
Cc: "Atom Syntax" <atom-syntax@imc.org>
References: <63E12F93-D452-11D8-9D0B-003065EA6144@geckotribe.com> <opsa3dl3q7uvpchu@quark> <87hdsbvcpv.fsf@nwalsh.com> <40F45906.7060007@intertwingly.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: <opsa3k6efxuvpchu@quark>
In-Reply-To: <40F45906.7060007@intertwingly.net>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Tue, 13 Jul 2004 17:49:58 -0400, Sam Ruby <rubys@intertwingly.net>  
wrote:

> Consider that a typical aggregator polls for data.  If you replace an  
> entry twice, and the aggregator missed the first one, then it has an  
> incomplete history to reconcile.

It's a good use case, but the aggregator would still have the «hole» if  
the entry was re-issued by just changing 'issue'. The only difference is  
that one now has an option to view all of the changes independantly.

This way of relating re-issues of entries would be best to have work in a  
very similar way to threading. E.g. if the threading-mechanism is based on  
one single element pointing to one single ID, you'd still have the «hole»  
problem, which needs some solution.

One named solution is to define a URN resolution mechanism for atom:id,  
almost like MessageID for USENET on Google. Pubsub or Feedster could, for  
example, be two atom:id resolution hosts. If you're missing an atom:id  
 from your aggregator, ask if Pubsub or Feedster has 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  Tue Jul 13 18: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 SAA01966
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 18:47: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 i6DMWb34087980;
	Tue, 13 Jul 2004 15:32: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 i6DMWbsp087979;
	Tue, 13 Jul 2004 15:32:37 -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 i6DMWbdp087973
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 15:32: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 (sccrmhc12) with SMTP
          id <20040713223236012009sj97e>; Tue, 13 Jul 2004 22:32:37 +0000
Date: Tue, 13 Jul 2004 16:32:35 -0600
Subject: Re: Low-hanging fruit: compulsory namespaces
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: <6D6BAC41-D517-11D8-8C42-000A95A51C9E@sun.com>
Message-Id: <89ED4038-D51C-11D8-9B93-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, July 13, 2004, at 03:56  PM, Tim Bray wrote:
> I suggest that we have good enough consensus to remove the paragraph 
> in draft-format-00 in section 2. beginning "All elements and 
> attributes in an Atom document MUST be namespace-qualified".  Because 
> lots of attributes aren't, and when it was pointed out that this would 
> forbid encapsulating RSS 2.0 and Docbook, nobody pushed back and said 
> "it's OK to forbid that".  -Tim
>
I think I missed something--where would one put RSS 2.0 into an Atom 
feed?  In a content construct?  As inline XML?  How would that be done 
without creating namespace conflicts, assuming the Atom document has 
Atom's namespace as the default namespace?  Is this the correct answer 
to my own question?

<feed xmlns="http://purl.org/atom/ns#draft-ietf-atompub-format-00">
	<entry>
		<atom:content type="application/rss+xml" xmlns="" 
xmlns:atom="http://purl.org/atom/ns#draft-ietf-atompub-format-00">
			<!-- RSS 2.0 goes here -->
		</atom:content>
	</entry>
</feed>



From owner-atom-syntax@mail.imc.org  Tue Jul 13 18:50:02 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02505
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 18:50: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 i6DMghwL089167;
	Tue, 13 Jul 2004 15: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 i6DMghBo089166;
	Tue, 13 Jul 2004 15:42:43 -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 i6DMggFM089160
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 15:42:42 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.19] (unknown [63.96.164.56])
	by mail.mnot.net (Postfix) with ESMTP
	id DE486727D; Tue, 13 Jul 2004 15:42:47 -0700 (PDT)
In-Reply-To: <A65D9796-D519-11D8-8C42-000A95A51C9E@textuality.com>
References: <A65D9796-D519-11D8-8C42-000A95A51C9E@textuality.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <F61FA09A-D51D-11D8-AA19-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: Atomlist Syntax <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: Re: Low-hanging fruit: multipart/alternative
Date: Tue, 13 Jul 2004 15:42:46 -0700
To: Tim Bray <tbray@textuality.com>
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>
Content-Transfer-Encoding: 7bit


+1

On Jul 13, 2004, at 3:11 PM, Tim Bray wrote:

> I don't think we have consensus on what we're replacing it with, but I 
> think that we do have consensus that the description of 
> multipart/alternative in 4.13.10 in draft-format-00 should go.  This 
> was my take-way from the Atom Community meeting back in June -Tim

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Tue Jul 13 18:50: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 SAA02511
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 18:50: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 i6DMYjDV088511;
	Tue, 13 Jul 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 i6DMYjXf088510;
	Tue, 13 Jul 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 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 i6DMYjd0088504
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 15:34:45 -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 esmtp (Exim 4.34)
	id 1BkVrK-0005Op-TT; Tue, 13 Jul 2004 22:34:47 +0000
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Tue, 13 Jul 2004 18:34:55 -0400
Subject: Re: Low-hanging fruit: non-validating parser
From: Robert Sayre <mint@franklinmint.fm>
To: Walter Underwood <wunder@verity.com>, Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD19DBCF.13971%mint@franklinmint.fm>
In-Reply-To: <ED474CAAF91509F1C62A66A5@[192.168.168.164]>
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: <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 7/13/04 6:17 PM, "Walter Underwood" <wunder@verity.com> wrote:

> 
> --On Tuesday, July 13, 2004 2:52 PM -0700 Tim Bray <Tim.Bray@Sun.COM> wrote:
>> 
>> [But I'd change "document MUST NOT" to "software MUST NOT"]. -Tim
> 
> "implementations MUST NOT". I think Bob Wyman could use a hardware
> Atom parser.
> 

Yeah, I like "implementations".

Robert Sayre



From owner-atom-syntax@mail.imc.org  Tue Jul 13 18:52: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 SAA02813
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 18:51: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 i6DMeVMp089044;
	Tue, 13 Jul 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 i6DMeVLP089043;
	Tue, 13 Jul 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 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 i6DMeVgA089037
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 15:40:31 -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 i6DMeail006015
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 16:40:36 -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 <0I0T00EE8AZNZB@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Tue, 13 Jul 2004 16:40:36 -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 <0I0T00CX6AZNE1@mail.sun.net> for atom-syntax@imc.org; Tue,
 13 Jul 2004 16:40:35 -0600 (MDT)
Date: Tue, 13 Jul 2004 15:40:38 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: low-hanging fruit: process
To: Atomlist Syntax <atom-syntax@imc.org>
Message-id: <A9963BE2-D51D-11D8-8C42-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: <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


And, I should say, these low-hanging fruits are my perceptions of where 
the WG got to; I'm quite intently focused on turning up the work 
throughput.  It's perfectly possible I missed some critical piece of 
the email avalanche.  If anyone thinks they're not low-hanging, or 
they're stinky turds instead of tasty fruit, please say so, nobody's 
feelings will be hurt.

  -Tim



From owner-atom-syntax@mail.imc.org  Tue Jul 13 18:52: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 SAA02835
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 18:52:05 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DMiMU5089238;
	Tue, 13 Jul 2004 15:44: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 i6DMiM0C089237;
	Tue, 13 Jul 2004 15:44:22 -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 i6DMiLM2089231
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 15:44:21 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.19] (unknown [63.96.164.56])
	by mail.mnot.net (Postfix) with ESMTP
	id D69C3728C; Tue, 13 Jul 2004 15:44:26 -0700 (PDT)
In-Reply-To: <6D6BAC41-D517-11D8-8C42-000A95A51C9E@sun.com>
References: <6D6BAC41-D517-11D8-8C42-000A95A51C9E@sun.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <3138B98C-D51E-11D8-AA19-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: Atomlist Syntax <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: Re: Low-hanging fruit: compulsory namespaces
Date: Tue, 13 Jul 2004 15:44:25 -0700
To: Tim Bray <Tim.Bray@Sun.COM>
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>
Content-Transfer-Encoding: 7bit


+1.

Do we want to replace this with something along the lines of "children 
of atom:feed and atom:entry must be namespace-qualified?"


On Jul 13, 2004, at 2:56 PM, Tim Bray wrote:

>
> I suggest that we have good enough consensus to remove the paragraph 
> in draft-format-00 in section 2. beginning "All elements and 
> attributes in an Atom document MUST be namespace-qualified".  Because 
> lots of attributes aren't, and when it was pointed out that this would 
> forbid encapsulating RSS 2.0 and Docbook, nobody pushed back and said 
> "it's OK to forbid that".  -Tim
>

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Tue Jul 13 19:07: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 TAA04533
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 19:07: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 i6DMsAt3089710;
	Tue, 13 Jul 2004 15:54: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 i6DMsAfk089709;
	Tue, 13 Jul 2004 15:54:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from priv-edtnes57.telusplanet.net (outbound01.telus.net [199.185.220.220])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DMs5d7089698
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 15:54:09 -0700 (PDT)
	(envelope-from jeremy@jeremygray.ca)
Received: from dora9 ([207.6.254.14]) by priv-edtnes57.telusplanet.net
          (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with ESMTP
          id <20040713225404.HFPD14951.priv-edtnes57.telusplanet.net@dora9>
          for <atom-syntax@imc.org>; Tue, 13 Jul 2004 16:54:04 -0600
Reply-To: <jeremy@jeremygray.ca>
From: "Jeremy Gray" <jeremy@jeremygray.ca>
To: "'Atom Syntax'" <atom-syntax@imc.org>
Subject: RE: a methodical approach to defining what date  elements we need
Date: Tue, 13 Jul 2004 15:54:26 -0700
Message-ID: <000001c4692c$593a3180$6400a8c0@dora9>
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.4510
In-Reply-To: <opsa3k6efxuvpchu@quark>
Importance: Normal
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 i6DMs9d7089704
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


-----Original Message-----
From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org]
On Behalf Of Asbjørn Ulsberg
Sent: Tuesday, July 13, 2004 3:38 PM
To: Sam Ruby; Norman Walsh
Cc: Atom Syntax
Subject: Re: a methodical approach to defining what date elements we need

-snip-

> One named solution is to define a URN resolution mechanism for atom:id,  
> almost like MessageID for USENET on Google. Pubsub or Feedster could, for

> example, be two atom:id resolution hosts. If you're missing an atom:id  
> from your aggregator, ask if Pubsub or Feedster has it.

+1

This would match up nicely with my previous post, turning "Middle case"s
into "Best case"s.

Jeremy Gray




From owner-atom-syntax@mail.imc.org  Tue Jul 13 19:08: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 TAA04944
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 19:08: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 i6DMwjWV089972;
	Tue, 13 Jul 2004 15:58:45 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6DMwjim089971;
	Tue, 13 Jul 2004 15:58: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 i6DMwi60089954
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 15:58: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 7BBD87C112; Wed, 14 Jul 2004 01:56:49 +0200 (CEST)
Date: Wed, 14 Jul 2004 01:02:00 +0200
To: "Antone Roundy" <antone@geckotribe.com>
Subject: Re: a methodical approach to defining what date  elements we need
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <1C01718E-D51B-11D8-9B93-003065EA6144@geckotribe.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: <opsa3l9mmvuvpchu@quark>
In-Reply-To: <1C01718E-D51B-11D8-9B93-003065EA6144@geckotribe.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Tue, 13 Jul 2004 16:22:21 -0600, Antone Roundy <antone@geckotribe.com>  
wrote:

> This, and the fact that people ARE going to republish heavily modified  
> entries without creating a new one are my big reasons for not favoring  
> any kind of "replaces" system.

Sam's problematic use case is just as problematic now as with any  
«supersede» system. An entry might be lost in void no matter what we do.  
The only solution to this is to be able to fetch the entry on a public  
repository, like Google perhaps. USENET's MessageID's already work like  
this. Perhaps atom:id could too.

> I'd prefer a modified (big change)/updated (small change) combo

What about keeping the semantics of 'modified' as is, and add a simple  
solution to the 're-issued' cases, if people are having difficulties with  
accepting <relation>; Allow for several <issued> elements. I would  
definately prefer a <relation>[1]-mechanism over mulitple <issued>  
elements, but it's a good compromise, and <relation> might still be  
supported on top of that <issued> semantic.

What the different <issued> elements would mean, is however not very  
clear. I'm not sure we can do or say anything but «If you re-issue an  
entry, you SHOULD (or MUST) append a new atom:issued element to atom:entry  
that reflects the new issue date. The original atom:issied should be left  
intact». The order of the <issued> element is of no significance; they  
could easilly be ordered chronologically with a string sort (if they are  
in the same timezone).

So, simple solution: multiple <issued> elements. A bit more complicated  
solution: <relation>. The bonus with adding <relation> is, though, that we  
get «for free» all the other attributes of the element, which obsoletes  
current @rel="alternate" with much more explicit attributes; 'IsFormatOf'  
(when an entry is an alternative representation for an HTML article),  
'References' (threading) and 'IsBasedOn' (translations of an entry).

____
[1] <url: http://dublincore.org/documents/relation-element/>

-- 
Asbjørn Ulsberg         -=|=-        asbjornu@hotmail.com
«He's a loathsome offensive brute, yet I can't look away»



From owner-atom-syntax@mail.imc.org  Tue Jul 13 19:15: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 TAA05751
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 19:15: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 i6DN2uwp090186;
	Tue, 13 Jul 2004 16:02: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 i6DN2umo090185;
	Tue, 13 Jul 2004 16:02:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DN2tug090174;
	Tue, 13 Jul 2004 16:02:55 -0700 (PDT)
	(envelope-from jasnell@us.ibm.com)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11])
	by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i6DN2sZW635930;
	Tue, 13 Jul 2004 19:02:54 -0400
Received: from d03nm122.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170])
	by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6DN2rdO404342;
	Tue, 13 Jul 2004 17:02:54 -0600
In-Reply-To: <6D6BAC41-D517-11D8-8C42-000A95A51C9E@sun.com>
To: Tim Bray <Tim.Bray@Sun.COM>
Cc: Atomlist Syntax <atom-syntax@imc.org>, owner-atom-syntax@mail.imc.org
MIME-Version: 1.0
Subject: Re: Low-hanging fruit: compulsory namespaces
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
From: James M Snell <jasnell@us.ibm.com>
X-MIMETrack: S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/13/2004 03:58:27 PM,
	Serialize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/13/2004 03:58:27 PM,
	Serialize complete at 07/13/2004 03:58:27 PM,
	Itemize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/13/2004 03:58:28 PM,
	S/MIME Sign complete at 07/13/2004 03:58:28 PM,
	S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/13/2004 04:02:50 PM,
	S/MIME Sign complete at 07/13/2004 04:02:50 PM,
	Serialize by Router on D03NM122/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at
 07/13/2004 17:02:53,
	Serialize complete at 07/13/2004 17:02:53
Message-ID: <OFA630D0A3.74B22649-ON88256ED0.007E0725-88256ED0.007E9A5A@us.ibm.com>
Date: Tue, 13 Jul 2004 17:02:50 -0600
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z5315_boundary_sign
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>


This is an S/MIME signed message.

---------z5315_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 007E33C388256ED0_="

This is a multipart message in MIME format.
--=_alternative 007E33C388256ED0_=
Content-Type: text/plain; charset="US-ASCII"

I would argue that all elements (at least) need to be namespace qualified, 
even if means using xmlns="" to undeclare a namespace for things like 
embedded RSS.  +1 to not requiring all attributes to be namespace 
qualified except for the obvious global attributes (e.g. mustUnderstand)


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



Tim Bray <Tim.Bray@Sun.COM> 
Sent by: owner-atom-syntax@mail.imc.org
07/13/2004 02:56 PM

To
Atomlist Syntax <atom-syntax@imc.org>
cc

Subject
Low-hanging fruit: compulsory namespaces







I suggest that we have good enough consensus to remove the paragraph in 
draft-format-00 in section 2. beginning "All elements and attributes in 
an Atom document MUST be namespace-qualified".  Because lots of 
attributes aren't, and when it was pointed out that this would forbid 
encapsulating RSS 2.0 and Docbook, nobody pushed back and said "it's OK 
to forbid that".  -Tim



--=_alternative 007E33C388256ED0_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">I would argue that all elements (at
least) need to be namespace qualified, even if means using xmlns=&quot;&quot;
to undeclare a namespace for things like embedded RSS. &nbsp;+1 to not
requiring all attributes to be namespace qualified except for the obvious
global attributes (e.g. mustUnderstand)</font>
<br>
<br>
<br><font size=2 face="sans-serif">- James M Snell<br>
 &nbsp;jasnell@us.ibm.com<br>
 &nbsp;http://www.ibm.com<br>
 &nbsp;(877) 511-5082 / Office<br>
 &nbsp;930-1979 / Tie Line</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Tim Bray &lt;Tim.Bray@Sun.COM&gt;</b>
</font>
<br><font size=1 face="sans-serif">Sent by: owner-atom-syntax@mail.imc.org</font>
<p><font size=1 face="sans-serif">07/13/2004 02:56 PM</font>
<td width=59%>
<table width=100%>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td valign=top><font size=1 face="sans-serif">Atomlist Syntax &lt;atom-syntax@imc.org&gt;</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td valign=top>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td valign=top><font size=1 face="sans-serif">Low-hanging fruit: compulsory
namespaces</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2><tt><br>
I suggest that we have good enough consensus to remove the paragraph in
<br>
draft-format-00 in section 2. beginning &quot;All elements and attributes
in <br>
an Atom document MUST be namespace-qualified&quot;. &nbsp;Because lots
of <br>
attributes aren't, and when it was pointed out that this would forbid <br>
encapsulating RSS 2.0 and Docbook, nobody pushed back and said &quot;it's
OK <br>
to forbid that&quot;. &nbsp;-Tim<br>
<br>
</tt></font>
<br>
--=_alternative 007E33C388256ED0_=--

---------z5315_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIIUOAIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIISWDCCAtow
ggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1
aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAy
MDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA629xc49NpAPz
cAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7glzJKgPkPzlTZZfznznGbmAWVnNBQ
lyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnwNclOnnP2sKufuPzbTImQTTi5c8JZNZcM
J0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEEBAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1Ud
DgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAPBgNVHRMBAf8EBTADAQH/MDEGA1UdJQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUH
AwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvu
jQupk2oCScMd3FIHLE7hOfu8YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14ke
McF9ViNdewEoBGiAycUq8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIC2jCCAkOgAwIB
AgIDAxS2MA0GCSqGSIb3DQEBBAUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwMTE0MjIw
NzExWhcNMTExMjMxMjIwNzExWjBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25h
bCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrb3Fzj02kA/NwCy5KFMiY
tFgyTJ6kMSQLVSs9uwVHIAVkqy/enDQwZ9b/7uCXMkqA+Q/OVNll/OfOcZuYBZWc0FCXI9qw60KO
J/rTd65FdF4dwp8cw8si0qjOJtYg8cm46fA1yU6ec/awq5+4/NtMiZBNOLlzwlk1lwwnRgXNNwID
AQABo4GqMIGnMBEGCWCGSAGG+EIBAQQEAwIAhzAOBgNVHQ8BAf8EBAMCAcYwHQYDVR0OBBYEFK5U
DpLqqDOpKyQtx8hvMNze80pAMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMA8GA1Ud
EwEB/wQFMAMBAf8wMQYDVR0lBCowKAYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYB
BQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAMnJ7c2YLyrY/PKlFl+7sm8NENfWtFxqdm+6NC6mTagJJ
wx3cUgcsTuE5+7xh9+/G0tTfLzA1qZAQ5GNMPXvmoB9+vJfKnC2JWMFQpIOUEJDXiR4xwX1WI117
ASgEaIDJxSrxHcuuV/hMIO9bgZ6C41MUVmdLTKBgBOImTuIPK8QwggMgMIICiaADAgECAgQ13vTP
MA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQL
EyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0MTUxWhcN
MTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMk
RXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKKlQRkrPFr
U18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkwrFEeO68r
1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOgYaRfMF0x
CzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBD
ZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAxODA4MjIx
NjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAdBgNV
HQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0HQQAEDTAL
GwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwlMQ0AppJu
f7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn00DbOyZY
sih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMgMIICiaADAgEC
AgQ13vTPMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0
MTUxWhcNMTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsG
A1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKK
lQRkrPFrU18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkw
rFEeO68r1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOg
YaRfMF0xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNl
Y3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAx
ODA4MjIxNjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAdBgNVHQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0H
QQAEDTALGwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwl
MQ0AppJuf7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn
00DbOyZYsih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMmMIIC
j6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIxNjM2NTRaMIGFMQsw
CQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEXMBUGA1UEAxMOSmFt
ZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkqhkiG9w0BCQEWEmph
c25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwKpbDG3zMatEuuOT
FYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSyd+7nwqAvbBfPj+0S
vcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7tBJlLrwDRCMoNlPuQ
Kg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQW
BBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOgFAwSamFzbmVs
bEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pAMCcGA1UdJQQgMB4G
CCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAZMKevB7dFfb9
23OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY8BjwVHxiYgG4xkxf
B1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOIzj3lz3xd+uOzqRFg
/Wsg/VMwggMmMIICj6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAy
BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNV
BAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIx
NjM2NTRaMIGFMQswCQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEX
MBUGA1UEAxMOSmFtZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkq
hkiG9w0BCQEWEmphc25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
wKpbDG3zMatEuuOTFYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSy
d+7nwqAvbBfPj+0SvcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7t
BJlLrwDRCMoNlPuQKg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQD
AgXgMB0GA1UdDgQWBBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcU
AgOgFAwSamFzbmVsbEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA
MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQAD
gYEAZMKevB7dFfb923OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY
8BjwVHxiYgG4xkxfB1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOI
zj3lz3xd+uOzqRFg/Wsg/VMxggG7MIIBtwIBATBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJ
bnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0g
Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwF+kzAJBgUrDgMCGgUAoIGiMBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDcxMzIyNTgyOFowIwYJKoZIhvcNAQkEMRYE
FFaNPYEvHwdLY2l/bt1s2xoJFofEMEMGCSqGSIb3DQEJDzE2MDQwBwYFKw4DAh0wDgYIKoZIhvcN
AwICAgCAMAoGCCqGSIb3DQMHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAQCu6IL4r
tRVy5ccJ9L9nCZ1b90FLb/V12cGj6000KTyJ87jV1lepOgn7chshQJN/xjrr1s67+Bwwhl9Q6T0U
6THgu7HbdXy+jQfoJP7OhtZFud7HVtML9fI34EJoNPfwL9U7j4Rh5lv8pLEwB4IA1SXopvS+1Abu
Mme5PHEI7v0AAAAA

---------z5315_boundary_sign--



From owner-atom-syntax@mail.imc.org  Tue Jul 13 19:26: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 TAA07285
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 19:26: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 i6DNIYt4091260;
	Tue, 13 Jul 2004 16:18: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 i6DNIY2p091259;
	Tue, 13 Jul 2004 16:18:34 -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 i6DNIX0q091245
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 16:18:33 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 900 messnum 9208798 invoked from network[83.70.39.115/83-70-39-115.bas2.prp.dublin.eircom.net]); 13 Jul 2004 23:18:32 -0000
Received: from 83-70-39-115.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.39.115)
  by mail10.svc.cra.dublin.eircom.net (qp 900) with SMTP; 13 Jul 2004 23:18:32 -0000
Message-ID: <40F46DAC.3030900@dehora.net>
Date: Wed, 14 Jul 2004 00:18:04 +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: Atomlist Syntax <atom-syntax@imc.org>
Subject: Re: Low-hanging fruit: compulsory namespaces
References: <6D6BAC41-D517-11D8-8C42-000A95A51C9E@sun.com>
In-Reply-To: <6D6BAC41-D517-11D8-8C42-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:

> 
> I suggest that we have good enough consensus to remove the paragraph in 
> draft-format-00 in section 2. beginning "All elements and attributes in 
> an Atom document MUST be namespace-qualified".  

Well, hang on there. Take the entire paragraph:

[[[
All elements and attributes in an Atom document MUST be 
namespace-qualified.  Note that this requirement does not preclude 
the use of a default namespace.
]]]

Although I confess I don't know why the last sentence needs to call 
out default namespaces at all, without specifying namespace 
qualification while specifying that default namespace are ok, there 
is room for bleed due to default namespaces. Perhaps if you want to 
strike it, you should add words around xmlns="". Sam mentioned 
xmlns="" recently and it's the only workable means I know of to mix 
plain and namespaced XML. It seems problematic enough that we should 
spec it in:

"All elements in an Atom document MUST be namespace-qualified. Where 
an XML element does not belong to a namespace it MUST be qualified 
by an xmlns="" declaration.  An attribute belonging to an element 
MAY be namespace qualified by that element's namespace. Any 
attribute foreign to an element MUST be namespace-qualified with a 
namespace other than the element's. @@@insert conclusion of QNames 
in content permathread here@@@"


Aside: a side effect of namespaces is that names at different level 
in the document are conflated to one name. We seem to have a number 
of these : title, link, modified, contributor, id, author, 
copyright. Care needs to be taken in the drafts that each of these 
are actually specified once.

cheers
Bill




From owner-atom-syntax@mail.imc.org  Tue Jul 13 19:28: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 TAA07459
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 19: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 i6DNIfbi091269;
	Tue, 13 Jul 2004 16: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 i6DNIeJB091268;
	Tue, 13 Jul 2004 16:18:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf25.cluster1.charter.net (mxsf25.cluster1.charter.net [209.225.28.225])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DNIe2K091262
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 16:18:40 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip20.cluster1.charter.net (mxip20a.cluster1.charter.net [209.225.28.150])
	by mxsf25.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6DNMvK7004894
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 19:22:57 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip20.cluster1.charter.net with ESMTP; 13 Jul 2004 19:18:39 -0400
X-Ironport-AV: i="3.81R,166,1083556800"; 
   d="scan'208"; a="46761016:sNHT14560500"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BkWXg-0006qp-00
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 19:18:32 -0400
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: a methodical approach to defining what date  elements we need
References: <63E12F93-D452-11D8-9D0B-003065EA6144@geckotribe.com>
	<opsa3dl3q7uvpchu@quark> <87hdsbvcpv.fsf@nwalsh.com>
	<40F45906.7060007@intertwingly.net>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Tue, 13 Jul 2004 19:18:26 -0400
In-Reply-To: <40F45906.7060007@intertwingly.net> (Sam Ruby's message of
 "Tue, 13 Jul 2004 17:49:58 -0400")
Message-ID: <87zn63sdh9.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: <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-Type: text/plain

/ Sam Ruby <rubys@intertwingly.net> was heard to say:
| Norman Walsh wrote:
|
|> I'm now convinced that it would be better to use just two:
|> Issued = when I published the essay
|> Modified = when I last changed any of the bits in the entry.
|> If I make a "significant" change, I should
|> 1. Create a new entry with a new ID and new dates
|> 2. Indicate that this new entry dcterms:replaces the original.
|> 2. Update the original to say it's been dcterms:isReplacedBy the new one.
|> It's more work, but it'll make for a better historical record.
|
| It's not much more work for you, but it is much more work for consumers.
|
| Consider that a typical aggregator polls for data.  If you replace an
| entry twice, and the aggregator missed the first one, then it has an
| incomplete history to reconcile.

But my plan is *never* to replace an entry.

I write essay A. It goes out in the feed.

I write essay B, and update essay A. They both go in the feed and B
says it replaces A and the modified A says it's replaced by B.

I write essay C, that replaces B. Now, if you missed B somehow (how,
it's in the feed along with C that you just got?), C still points to B
which points to A.

Or did you mean something else?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Sometimes in life situations develop
http://nwalsh.com/            | that only the half-crazy can get out
                              | of.--La Rochefoucauld

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA9G3HOyltUcwYWjsRAqU3AKCdBtSzopiCJtJLnK4z0BnzNbrfVgCeJJSr
eSn7WGYOsUXH/e0uga/u7R0=
=lkD4
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Tue Jul 13 19:30: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 TAA07666
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 19:30:06 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DNIXuK091252;
	Tue, 13 Jul 2004 16:18:33 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6DNIXmW091251;
	Tue, 13 Jul 2004 16:18:33 -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 i6DNIWwZ091244
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 16:18:33 -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 i6DNIU53003459;
	Tue, 13 Jul 2004 18:18:30 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6DNITrF003455;
	Tue, 13 Jul 2004 18:18:29 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Tim Bray <Tim.Bray@Sun.COM>
Cc: Atomlist Syntax <atom-syntax@imc.org>
Subject: PacePutToCreate (was Re: Editorial comments on draft-atompub-protocol-00)
References: <BC806156-D51B-11D8-8C42-000A95A51C9E@sun.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 13 Jul 2004 18:18:29 -0500
In-Reply-To: <BC806156-D51B-11D8-8C42-000A95A51C9E@sun.com>
Message-ID: <m3y8lnlcmy.fsf@bitsko.slc.ut.us>
Lines: 16
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: <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> writes:

> [page 5/sect 3.2] the description reads like it's forbidden to do a
> PUT without doing a GET first.  Is this true?  If I know the URI and
> I know what I want to put there, can't I just blast it in?

+1 to that!

The publishing system would need to be capable of doing that, of
course, and there's nothing currently specced to indicate that
possibility to a client or provide a set of base-URIs.

PacePutToCreate was created to propose a way to communicate that
information, if the server supported that option.

  -- Ken



From owner-atom-syntax@mail.imc.org  Tue Jul 13 19: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 TAA08161
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 19: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 i6DNO0JS091555;
	Tue, 13 Jul 2004 16:24: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 i6DNO0Oq091554;
	Tue, 13 Jul 2004 16:24:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf13.cluster1.charter.net (mxsf13.cluster1.charter.net [209.225.28.213])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DNNx82091547
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 16:23:59 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip19.cluster1.charter.net (mxip19a.cluster1.charter.net [209.225.28.149])
	by mxsf13.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6DNRl9F030041
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 19:27:47 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip19.cluster1.charter.net with ESMTP; 13 Jul 2004 19:23:57 -0400
X-Ironport-AV: i="3.81R,166,1083556800"; 
   d="scan'208"; a="112846352:sNHT15115158"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BkWcm-0007W1-00
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 19:23:48 -0400
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Low-hanging fruit: compulsory namespaces
References: <6D6BAC41-D517-11D8-8C42-000A95A51C9E@sun.com>
	<3138B98C-D51E-11D8-AA19-000A95BD86C0@mnot.net>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Tue, 13 Jul 2004 19:23:47 -0400
In-Reply-To: <3138B98C-D51E-11D8-AA19-000A95BD86C0@mnot.net> (Mark
 Nottingham's message of "Tue, 13 Jul 2004 15:44:25 -0700")
Message-ID: <87vfgrsd8c.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: <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-Type: text/plain

/ Mark Nottingham <mnot@mnot.net> was heard to say:
| +1.
|
| Do we want to replace this with something along the lines of "children
| of atom:feed and atom:entry must be namespace-qualified?"

That seems reasonable to me.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Many who find the day too long, think
http://nwalsh.com/            | life too short.--Charles Caleb Colton

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA9G8DOyltUcwYWjsRAteDAJ45hc53FgGg1U0NmMEBpviG+uQfqwCgrPlm
2N7Ow8u6+ubJN164ntucKAw=
=BRf/
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Tue Jul 13 19:35: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 TAA08220
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 19:35: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 i6DNOegb091569;
	Tue, 13 Jul 2004 16:24: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 i6DNOejG091568;
	Tue, 13 Jul 2004 16:24:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DNOdEi091562
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 16:24:39 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6DNOiil002516
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 17:24:44 -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 <0I0T00JK3D18T4@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Tue, 13 Jul 2004 17:24:44 -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 <0I0T00CSHD17E4@mail.sun.net> for atom-syntax@imc.org; Tue,
 13 Jul 2004 17:24:44 -0600 (MDT)
Date: Tue, 13 Jul 2004 16:24:46 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Low-hanging fruit: compulsory namespaces
In-reply-to: <3138B98C-D51E-11D8-AA19-000A95BD86C0@mnot.net>
To: Mark Nottingham <mnot@mnot.net>
Cc: Atomlist Syntax <atom-syntax@imc.org>
Message-id: <D44BDCC6-D523-11D8-8C42-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: <6D6BAC41-D517-11D8-8C42-000A95A51C9E@sun.com>
 <3138B98C-D51E-11D8-AA19-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 Jul 13, 2004, at 3:44 PM, Mark Nottingham wrote:

> +1.
>
> Do we want to replace this with something along the lines of "children 
> of atom:feed and atom:entry must be namespace-qualified?"

Sounds good, but of course it hasn't been discussed so we might be 
missing some obvious gotcha.  I'd put it in, on a trial-balloon basis. 
-Tim



From owner-atom-syntax@mail.imc.org  Tue Jul 13 19:43:42 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09408
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 19:43: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 i6DNaduI092740;
	Tue, 13 Jul 2004 16: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 i6DNadrT092739;
	Tue, 13 Jul 2004 16:36: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 i6DNacol092731
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 16:36: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 2FF7D7C112; Wed, 14 Jul 2004 02:34:42 +0200 (CEST)
Date: Wed, 14 Jul 2004 01:40:00 +0200
To: "Tim Bray" <Tim.Bray@sun.com>
Subject: Re: Editorial comments on draft-ietf-atompub-format-00
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <DABD07E4-D519-11D8-8C42-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: <opsa3n0ydbuvpchu@quark>
In-Reply-To: <DABD07E4-D519-11D8-8C42-000A95A51C9E@sun.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Tue, 13 Jul 2004 15:13:22 -0700, Tim Bray <Tim.Bray@Sun.COM> wrote:

> Do we agree that it's OK to batch up editorial comments like this?

I, for one, think it's very nice, if one of the intentions is for the rest  
of the list to comment on them.

> [Page 5/sect 2] Did we agree to deprecate Processing Instructions?

FWIW: I've not agreed to that.

> [Page 5/sect 2] I would suggest, per 3470, that the language saying Atom  
> should/may/whatever contain DOCTYPES, PIs, and comments is superfluous.

+1.

> [Page 5, sect 2] I think the paragraph about xml:lang should have a  
> reference to http://www.w3.org/TR/REC-xml/#sec-lang-tag

+1.

> [Page 6, sect 3.1.2] the discussion of "escaped" needs a reference to  
> what kind of unescaping you're talking about:  
> http://www.w3.org/TR/REC-xml/#dt-escape

+1.

> [Page 7, sect 3.2.2] "atom:url" has to go as an element name.  Either  
> "uri" or "web" would be a satisfactory replacement, but since there is  
> no in-effect normative text describing what "url" stands for, it's  
> really not appropriate.  Same for 4.9 and anywhere else "url" appears.

I had the feel that current consensus was to replace <url> with <link>, at  
least until we agree on what to do with <link>. Maybe when we agree on  
that, it gets reverted back to <url> again. ;-)

> [page 12, sect 4.13.1]  I don't think the "title" of a Web Resource is a  
> well-defined construct.

I agree. I'm not sure what it refers to. I guess it means the <title> of  
an HTML page, and if so, I agree that that's what it should say.

> [page 13, sect 4.13.9] Typo in "atom:summary", it says "MAY contain an  
> atom:created" you mean "MAY contain an atom:summary"

Heh. Some copy+paste error there, I guess. :-)

-- 
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 Jul 13 19:53:31 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10685
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 19:53: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 i6DNkDDY093377;
	Tue, 13 Jul 2004 16: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 i6DNkDCa093376;
	Tue, 13 Jul 2004 16:46: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 i6DNkCBq093369
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 16:46:12 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net ([66.57.27.65])
	(authenticated bits=0)
	by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i6DNkuqa005603;
	Tue, 13 Jul 2004 19:46:56 -0400
Message-ID: <40F4744A.5000709@intertwingly.net>
Date: Tue, 13 Jul 2004 19:46:18 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Norman Walsh <ndw@nwalsh.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: a methodical approach to defining what date  elements we need
References: <63E12F93-D452-11D8-9D0B-003065EA6144@geckotribe.com>	<opsa3dl3q7uvpchu@quark> <87hdsbvcpv.fsf@nwalsh.com>	<40F45906.7060007@intertwingly.net> <87zn63sdh9.fsf@nwalsh.com>
In-Reply-To: <87zn63sdh9.fsf@nwalsh.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


Norman Walsh wrote:
> / Sam Ruby <rubys@intertwingly.net> was heard to say:
> | Norman Walsh wrote:
> |
> |> I'm now convinced that it would be better to use just two:
> |> Issued = when I published the essay
> |> Modified = when I last changed any of the bits in the entry.
> |> If I make a "significant" change, I should
> |> 1. Create a new entry with a new ID and new dates
> |> 2. Indicate that this new entry dcterms:replaces the original.
> |> 2. Update the original to say it's been dcterms:isReplacedBy the new one.
> |> It's more work, but it'll make for a better historical record.
> |
> | It's not much more work for you, but it is much more work for consumers.
> |
> | Consider that a typical aggregator polls for data.  If you replace an
> | entry twice, and the aggregator missed the first one, then it has an
> | incomplete history to reconcile.
> 
> But my plan is *never* to replace an entry.
> 
> I write essay A. It goes out in the feed.
> 
> I write essay B, and update essay A. They both go in the feed and B
> says it replaces A and the modified A says it's replaced by B.
> 
> I write essay C, that replaces B. Now, if you missed B somehow (how,
> it's in the feed along with C that you just got?), C still points to B
> which points to A.
> 
> Or did you mean something else?

Best explained by example.  Consider:

   "B"    = http://norman.walsh.name/2003/02/stthomas
   "feed" = http://norman.walsh.name/atom/whatsnew.xml

Clearly entries are being purged from feeds at some point.

If one fetches a feed intermittently, there can be gaps in history, 
resulting in an inability to reconcile history.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Tue Jul 13 20: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 UAA11533
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 20:03: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 i6DNrJCT093975;
	Tue, 13 Jul 2004 16:53: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 i6DNrJsY093974;
	Tue, 13 Jul 2004 16:53:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6DNrI6G093964
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 16:53:18 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6DNrOil017928
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 17:53:24 -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 <0I0T00EXHECZZB@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Tue, 13 Jul 2004 17:53:24 -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 <0I0T00C0VECYE4@mail.sun.net> for atom-syntax@imc.org; Tue,
 13 Jul 2004 17:53:23 -0600 (MDT)
Date: Tue, 13 Jul 2004 16:53:25 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Low-hanging fruit: compulsory namespaces
In-reply-to: <40F46DAC.3030900@dehora.net>
To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>
Cc: Atomlist Syntax <atom-syntax@imc.org>
Message-id: <D4AC57AE-D527-11D8-A503-000A95A51C9E@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.618)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
References: <6D6BAC41-D517-11D8-8C42-000A95A51C9E@sun.com>
 <40F46DAC.3030900@dehora.net>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6DNrJ6G093967
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 Jul 13, 2004, at 4:18 PM, Bill de hÓra wrote:

>  Perhaps if you want to strike it, you should add words around 
> xmlns="". Sam mentioned xmlns="" recently and it's the only workable 
> means I know of to mix plain and namespaced XML. It seems problematic 
> enough that we should spec it in:
>
> "All elements in an Atom document MUST be namespace-qualified. Where 
> an XML element does not belong to a namespace it MUST be qualified by 
> an xmlns="" declaration.  An attribute belonging to an element MAY be 
> namespace qualified by that element's namespace. Any attribute foreign 
> to an element MUST be namespace-qualified with a namespace other than 
> the element's. @@@insert conclusion of QNames in content permathread 
> here@@@"

No.  XML elements and attributes are either in a namespace or they're 
not.  We should not get into micromanaging the various syntactic tricks 
you could use to accomplish this.  E.g. the following two are both 
perfectly OK and effectively identical:

<!-- assume atom: prefix is declared -->
<!-- assume no default namespace -->
<atom:entry>
  <atom:issued>...
  .. other <atom:xxx> tags
  ..
  <atom:content type="application/rss2+xml">
   <item><title>A chunk of RSS</title></item>
  </atom:content>
</atom:entry>

==============================

<entry xmlns=".. atom's namespace URI.."
  <issued>...
    ... other atom tags
  <content type="application/rss2+xml">
   <item xmlns=""><title></title></item>
  </content>

  -Tim



From owner-atom-syntax@mail.imc.org  Tue Jul 13 20:21:01 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13154
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 20:21: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 i6E0C8sw095770;
	Tue, 13 Jul 2004 17:12: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 i6E0C82U095769;
	Tue, 13 Jul 2004 17:12:08 -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 i6E0C7hH095763
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 17:12:07 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.19] (unknown [63.96.164.56])
	by mail.mnot.net (Postfix) with ESMTP
	id 8DBA7727D; Tue, 13 Jul 2004 17:12:12 -0700 (PDT)
In-Reply-To: <87d62zzt5e.fsf@nwalsh.com>
References: <20040712214722.79750.qmail@web41212.mail.yahoo.com> <AA8D7D00-D461-11D8-AFCB-000A95BD86C0@mnot.net> <87acy45bch.fsf@nwalsh.com> <B2DCC212-D4F0-11D8-9691-000A95BD86C0@mnot.net> <87d62zzt5e.fsf@nwalsh.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <73A44CEC-D52A-11D8-AA19-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: Atom Syntax <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: Re: Usage Scenarios for Versioning and Extensibility
Date: Tue, 13 Jul 2004 17:12:11 -0700
To: Norman Walsh <ndw@nwalsh.com>
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>
Content-Transfer-Encoding: 7bit



On Jul 13, 2004, at 10:58 AM, Norman Walsh wrote:

> I think we mean any element, not just the children of feed and entry.
> I should be allowed to do this:
>
>   <atom:entry>
>     <atom:title>Hello <foo:world 
> atom:mustUnderstand="true"/></atom:title>
>     ...
>   </atom:entry>
>
> even if it's really stupid :-)

OK. Does this mean that extensions (as well as core metadata such as 
atom:title) need to define where mU is allowed in their domains, or is 
is expressly allowed anywhere? If the latter, I'm not so concerned 
about the stupid angle (always hard to rule out), but it seems like it 
might be an implementation burden (e.g., <html:b 
atom:mustUnderstand="true">foo</html:b>).


> |> - If you're reading an Atom document with a version identifier that
> |>   you recognize:
> |>
> |>   - Unrecognized elements in the Atom namespace are an error.
> |>     Recovery behavior is to ignore them.
> |>   - Unrecognized elements in any other namespace are ignored.
> |
> | Is there any difference between these two sub-cases, except in who 
> has
> | control of the namespace?
>
> I'm not sure exactly what your asking. My intent is that the former
> case is an error. A processor should have the freedom to reject feeds
> that are in error. However, if it doesn't reject the feed, it must
> proceed by ignoring the error. The latter case isn't an error at all,
> it's just an unrecognized extension (and unrecognized extensions must
> be ignored).
> |> | 1) And it was good... except for that nasty atom:title element; 
> after
> |> | wide deployment experience, it's agreed we need a new version of 
> it.
> |> | So, a new version of Atom is introduced. The new one isn't
> |> | backwards-compatible with the old one.
> |>
> |> A backwards-incompatible change tips over the apple cart. This 
> version
> |> of Atom goes in a new namespace; it's a different document type.
> |>
> |> This is really painful, so let's plan not to do this, ok? :-)
> |
> | Yes. If it's not backwards-compatible, it gets a new namespace URI
> | and/or localname.
>
> If it gets a new namespace URI, it just becomes an extension element.
> If it gets a new local name, then you have to bump the version number.

I see - this codifies the specialness of the Atom namespace by tying it 
to the version; the version declares definitively what's allowed in the 
Atom namespace.

> |> | 2) Then, we decide we want to add a new metadata element, let's 
> call
> |> | it "fog." So, a new version of Atom is introduced.
> |>
> |> One answer is to put this element in a different namespace. Then
> |> there's no problem.
> |> Another answer is to put this element in the Atom namespace and bump
> |> the version identifier. That's no problem either as long as fog 
> doesn't
> |> change the semantics of any other Atom element.
> |
> | Agreed, except I don't see the need to bump the version identifier,
> | UNLESS we say that "fog" is now required, etc. for the feed itself to
> | be valid. See end of message for more discussion.
>
> If we want to be able to add elements without changing the version
> number, then we can't make unrecognized elements in the Atom namespace
> be an error. I think it's useful to make them errors because it
> catches typos and various other sorts of problems that will otherwise
> be silently ignored.

OK, this is the heart of the matter, and motivates a lot of your design.

> In my view, a feed validator ought to be able to complain about:
>
>   <feed version="Red">
>     <entry>
>       <lnk rel="start" href="xxx"/>
>       ...
>     </entry>
>   </feed>
>
> if it knows what's valid in "Red" (and "lnk" isn't valid).

Clarification: is "link", for the purposes of this example, in the atom 
namespace, or some other one? I.e., does the version also allow you to 
talk about what's allowed (and not) from other namespaces?

> If it has never heard of version "Red", then it shouldn't complain
> (except perhaps informationally) because it has to assume that "lnk" is
> allowed in that version.

Right.

> |> | 3) After a while, someone comes up with a souped-up version of
> |> | atom:title that is backwards-compatible, just *better*. It gets
> |> really
> |> | popular, and yet another version of Atom is born.
> |>
> |> Bump the version identifier. No problem.
> |
> | If it's backwards-compatible, what purpose is served by changing the
> | version identifier?
>
> Well, you said it was "backwards-compatible". I assume it has *some*
> new semantic or it wouldn't just be backwards-compatible, it would
> be "the same as" :-)
>
> If you want processors to be able to take advantage of the new
> semantic, you have to give them some clue about it :-)

This seems like another axis of things that the version identifier can 
talk about. Could you (or anyone else) give a concrete example of an 
element that exhibits this kind of change?

> | One thing that might be helpful to clarify is what the version
> | identifier indicates. I've put forth that it identifies a required 
> set
> | of metadata that might be extended; i.e., the version identifies the
> | requirements, not necessarily the specific set of metadata in the
> | message (which can be discovered by inspecting the message). This
> | seems to have a nice interaction with the use of namespaces.
>
> The version identifies the RFC to which the feed purports to conform.
> It identifies exactly which elements in the Atom namespace are legal
> and exactly where they are allowed to occur and what semantics they
> have.
>
> | This doesn't seem to be what you have in mind. Could you give a
> | straw-man rule of thumb as to when the version identifier should be
> | changed, and what it identifies?
>
> If the RFC is revised in a backwards-compatible way, the version number
> has to change. If the RFC is revised in a backwards-incompatible way,
> it better define a new namespace.
>
> Does that help?

Very much so, thanks.

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Tue Jul 13 20:25: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 UAA13850
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 20:25: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 i6E0ITwu096079;
	Tue, 13 Jul 2004 17:18: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 i6E0IT0Z096078;
	Tue, 13 Jul 2004 17:18:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web41505.mail.yahoo.com (web41505.mail.yahoo.com [66.218.93.88])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6E0ITlk096069
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 17:18:29 -0700 (PDT)
	(envelope-from randymorin@yahoo.com)
Message-ID: <20040714001829.48334.qmail@web41505.mail.yahoo.com>
Received: from [66.46.139.106] by web41505.mail.yahoo.com via HTTP; Tue, 13 Jul 2004 17:18:29 PDT
Date: Tue, 13 Jul 2004 17:18:29 -0700 (PDT)
From: Randy Charles Morin <randymorin@yahoo.com>
Reply-To: randy@kbcafe.com
Subject: Re: PaceElementOrder: restart
To: Sam Ruby <rubys@intertwingly.net>, Tim Bray <tim.bray@sun.com>,
        Atomlist <atom-syntax@imc.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-251034483-1089764309=:47729"
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>


--0-251034483-1089764309=:47729
Content-Type: text/plain; charset=us-ascii

Sam wrote:
>The long and short of it is that #3 above is false as stated. [cut]
 
I disagree that it's false as stated, but I understand your point. What Sam is proposing, please correct me if I'm wrong Sam, that XSD authors write their Atom XSD as if order mattered even though it really doesn't matter. These XSD will be easier to use (by the tools), but slightly inaccurate. That would be acceptable to me, but let me outline a major disadvantage of this approach. The XSD could not be used for validation, because it would impose order. This might be confusing.
Thanks and hope this helps,
 
Randy
http://www.kbcafe.com
 

		
---------------------------------
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
--0-251034483-1089764309=:47729
Content-Type: text/html; charset=us-ascii

<DIV>Sam wrote:</DIV>
<DIV>&gt;<FONT face="Courier New">The long and short of it is that #3 above is false as stated. [cut]</FONT></DIV>
<DIV><FONT face="Courier New"></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New">I disagree that it's false as stated, but I understand your point. </FONT><FONT face="Courier New">What Sam is proposing, please correct me if I'm wrong Sam, that&nbsp;XSD authors&nbsp;write their Atom XSD as if order mattered even though it really doesn't matter. </FONT><FONT face="Courier New">These XSD will be easier to use (by the tools), but slightly inaccurate. That would be acceptable to me, but let me outline a major disadvantage of this approach. The XSD could not be used for validation, because it would impose order. This might be confusing.</FONT></DIV>
<DIV><FONT face="Courier New">Thanks and hope this helps,</FONT></DIV>
<DIV><FONT face="Courier New"></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New">Randy</FONT></DIV>
<DIV><FONT face="Courier New"><A href="http://www.kbcafe.com">http://www.kbcafe.com</A></FONT></DIV>
<DIV><FONT face="Courier New"></FONT>&nbsp;</DIV><p>
		<hr size=1>Do you Yahoo!?<br>
Yahoo! Mail is new and improved - <a href="http://us.rd.yahoo.com/mail_us/taglines/new/*http://promotions.yahoo.com/new_mail">Check it out!</a>
--0-251034483-1089764309=:47729--



From owner-atom-syntax@mail.imc.org  Tue Jul 13 20:29: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 UAA14280
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 20:29: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 i6E0Js9g096195;
	Tue, 13 Jul 2004 17:19: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 i6E0JsWY096194;
	Tue, 13 Jul 2004 17:19:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E0Jn7b096150
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 17:19:52 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Wed, 14 Jul 2004 10:24:35 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Wed, 14 Jul 2004 10:19:20 +1000
Subject: Re: a methodical approach to defining what date  elements we need
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Asbj=?ISO-8859-1?B?+A==?=rn Ulsberg <asbjorn@tigerstaden.no>,
        Antone Roundy <antone@geckotribe.com>
CC: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD1AB928.1F886%eric.scheid@ironclad.net.au>
In-Reply-To: <opsa3l9mmvuvpchu@quark>
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 i6E0Js7b096189
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 14/7/04 9:02 AM, "Asbjørn Ulsberg" <asbjorn@tigerstaden.no> wrote:

> What the different <issued> elements would mean, is however not very
> clear. I'm not sure we can do or say anything but «If you re-issue an
> entry, you SHOULD (or MUST) append a new atom:issued element to atom:entry
> that reflects the new issue date. The original atom:issied should be left
> intact». The order of the <issued> element is of no significance; they
> could easilly be ordered chronologically with a string sort (if they are
> in the same timezone).
> 
> So, simple solution: multiple <issued> elements

+1




From owner-atom-syntax@mail.imc.org  Tue Jul 13 20:36: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 UAA15136
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 20:36: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 i6E0QZYd097049;
	Tue, 13 Jul 2004 17:26:35 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6E0QZDe097048;
	Tue, 13 Jul 2004 17:26:35 -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 i6E0QYxC097039
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 17:26:34 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.19] (unknown [63.96.164.56])
	by mail.mnot.net (Postfix) with ESMTP
	id 75B8C727D; Tue, 13 Jul 2004 17:26:40 -0700 (PDT)
In-Reply-To: <DABD07E4-D519-11D8-8C42-000A95A51C9E@sun.com>
References: <DABD07E4-D519-11D8-8C42-000A95A51C9E@sun.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <7920D913-D52C-11D8-AA19-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: Atomlist Syntax <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: Re: Editorial comments on draft-ietf-atompub-format-00
Date: Tue, 13 Jul 2004 17:26:39 -0700
To: Tim Bray <Tim.Bray@Sun.COM>
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>
Content-Transfer-Encoding: 7bit



On Jul 13, 2004, at 3:13 PM, Tim Bray wrote:

> Do we agree that it's OK to batch up editorial comments like this?

Sure; please CC: the editors, though, to call it out to their attention.

> [Page 5/sect 2] Did we agree to deprecate Processing Instructions?  I 
> believe not, and this is in conflict with RFC3470, and should be 
> removed as an editorial correction.  Unless someone can show me how 
> this somehow represents consensus based on earlier discussion.

It represents the state of the draft as it sat before the WG. There was 
some discussion on it then. I don't think it's editorial just because 
it conflicts with 3470 (although they obviously need to be resolved); 
can we start a separate thread on this one?

> [Page 5/sect 2] I would suggest, per 3470, that the language saying 
> Atom should/may/whatever contain DOCTYPES, PIs, and comments is 
> superfluous.

Agreed.

> [Page 5, sect 2] I think the paragraph about xml:lang should have a 
> reference to http://www.w3.org/TR/REC-xml/#sec-lang-tag

Seems reasonable.

> [Page 6, sect 3.1.2] the discussion of "escaped" needs a reference to 
> what kind of unescaping you're talking about: 
> http://www.w3.org/TR/REC-xml/#dt-escape

Seems reasonable.

> [Page 7, sect 3.2.2] "atom:url" has to go as an element name.  Either 
> "uri" or "web" would be a satisfactory replacement, but since there is 
> no in-effect normative text describing what "url" stands for, it's 
> really not appropriate.  Same for 4.9 and anywhere else "url" appears.

I'm happy to take this as editorial if no one objects.

> [page 11, sect 4.12].  Is the text about "xml:lang" here useful, or 
> does the discussion above make it superfluous?

Do you mean 4.13? If so, yes. This text was incorporated here because 
PaceItemLang was accepted; my intent was to show the language to make 
sure we liked the approach, and then consolidate the approach to 
xml:lang in the next draft.

> [page 12, sect 4.13.1]  I don't think the "title" of a Web Resource is 
> a well-defined construct.  It certainly doesn't appear in Web 
> architecture.  If you mean "is the same as the contents of the <title> 
> element in the case where HTML representations are typically made 
> available..." then that's fine.  Or (better) just lose it.

Are you speaking just about the last sentence? I don't have a strong 
preference here, anyone else?

> [page 13, sect 4.13.9] Typo in "atom:summary", it says "MAY contain an 
> atom:created" you mean "MAY contain an atom:summary"

Ack.


Thanks!

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Tue Jul 13 21:04: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 VAA18948
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 21:04: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 i6E0pZj4099754;
	Tue, 13 Jul 2004 17:51: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 i6E0pZcN099753;
	Tue, 13 Jul 2004 17:51:35 -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 i6E0pTjb099744
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 17:51:34 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Wed, 14 Jul 2004 10:56:36 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Wed, 14 Jul 2004 10:51:18 +1000
Subject: Re: Editorial comments on draft-ietf-atompub-format-00
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Asbj=?ISO-8859-1?B?+A==?=rn Ulsberg <asbjorn@tigerstaden.no>,
        Tim Bray <Tim.Bray@sun.com>
CC: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD1AC0A6.1F89B%eric.scheid@ironclad.net.au>
In-Reply-To: <opsa3n0ydbuvpchu@quark>
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 i6E0pZjb099748
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 14/7/04 9:40 AM, "Asbjørn Ulsberg" <asbjorn@tigerstaden.no> wrote:

>> [Page 7, sect 3.2.2] "atom:url" has to go as an element name.  Either
>> "uri" or "web" would be a satisfactory replacement, but since there is
>> no in-effect normative text describing what "url" stands for, it's
>> really not appropriate.  Same for 4.9 and anywhere else "url" appears.
> 
> I had the feel that current consensus was to replace <url> with <link>, at
> least until we agree on what to do with <link>. Maybe when we agree on
> that, it gets reverted back to <url> again. ;-)


+1




From owner-atom-syntax@mail.imc.org  Tue Jul 13 21: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 VAA19351
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 21:07: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 i6E0s31u099918;
	Tue, 13 Jul 2004 17:54: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 i6E0s3wT099917;
	Tue, 13 Jul 2004 17:54:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.204])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6E0s2fc099911
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 17:54:02 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d15so362766rng
        for <atom-syntax@imc.org>; Tue, 13 Jul 2004 17:54:05 -0700 (PDT)
Received: by 10.38.207.20 with SMTP id e20mr424774rng;
        Tue, 13 Jul 2004 17:54:05 -0700 (PDT)
Message-ID: <14be96d304071317541efca684@mail.gmail.com>
Date: Tue, 13 Jul 2004 20:54:05 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Tim Bray <tbray@textuality.com>
Subject: Re: Low-hanging fruit: multipart/alternative
Cc: Atomlist Syntax <atom-syntax@imc.org>
In-Reply-To: <A65D9796-D519-11D8-8C42-000A95A51C9E@textuality.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <A65D9796-D519-11D8-8C42-000A95A51C9E@textuality.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, 13 Jul 2004 15:11:54 -0700, Tim Bray <tbray@textuality.com> wrote:
> I don't think we have consensus on what we're replacing it with, but I
> think that we do have consensus that the description of
> multipart/alternative in 4.13.10 in draft-format-00 should go.  This
> was my take-way from the Atom Community meeting back in June -Tim

+1.  How about a single element called <choice>?

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Tue Jul 13 21: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 VAA20079
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 21: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 i6E12V7S001240;
	Tue, 13 Jul 2004 18: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 i6E12VWu001239;
	Tue, 13 Jul 2004 18:02: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 i6E12U4K001233
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 18:02:30 -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 i6E12ail022154
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 19:02:36 -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 <0I0T00JHVHKBT4@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Tue, 13 Jul 2004 19:02:36 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0T003DUHKAL2@mail.sun.net> for atom-syntax@imc.org; Tue,
 13 Jul 2004 19:02:35 -0600 (MDT)
Date: Tue, 13 Jul 2004 18:02:37 -0700
From: Tim Bray <tbray@textuality.com>
Subject: Re: Low-hanging fruit: multipart/alternative
In-reply-to: <14be96d304071317541efca684@mail.gmail.com>
To: Mark Pilgrim <pilgrim@gmail.com>
Cc: Atomlist Syntax <atom-syntax@imc.org>
Message-id: <7FBABBD6-D531-11D8-A503-000A95A51C9E@textuality.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.618)
Content-type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3--209391594;
 protocol="application/pkcs7-signature"
References: <A65D9796-D519-11D8-8C42-000A95A51C9E@textuality.com>
 <14be96d304071317541efca684@mail.gmail.com>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>



--Apple-Mail-3--209391594
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On Jul 13, 2004, at 5:54 PM, Mark Pilgrim wrote:

>> I don't think we have consensus on what we're replacing it with, but I
>> think that we do have consensus that the description of
>> multipart/alternative in 4.13.10 in draft-format-00 should go.  This
>> was my take-way from the Atom Community meeting back in June -Tim
>
> +1.  How about a single element called <choice>?

Actually, I thought we'd nuked the whole notion of 
multiple-alternative-representations-of-the-entry, so the idea would be 
to just lose multipart/alternative.  But it's possible I have the wrong 
recollection... -Tim
--Apple-Mail-3--209391594
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
hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDcxNDAxMDIzOFowIwYJKoZIhvcNAQkEMRYEFFIO
sCDiHtMvpvZ2FgGRAEkEiOhmMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV
BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLirkwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT
AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3
dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDC4q5MA0GCSqGSIb3DQEBAQUABIIBADdL
w5NJUQMbeGLMiIRfyZvxQPdJUod9eEhMutN7ld6gYN1sfkfh5aVTDK6GG/6NbLTCCGTe+S7CdqYw
Ao2+rOiW5ec53KwmSweUbgnxF7HzW/xK6H5dOZHf0T02/SQQ75KM67/su5GIWBWagXf0lFkzmhSz
G7a5vjFh2qceCEcWN0kUt6XjqvBTDd77/FVZ3F78D8wtpv/wMS2b3WSqK3mtMxqQfy2YxomeoYv+
2Pr1WgRoOdSWUpu+6SCFCCVBF+TUb51fGxhw4t9knQgswbyXC59t0zZDwJjQbVhP2vQ47SpP4yqr
UP0eWLyEjcZtcGiJ2vrOfBNf0XupO5+VxNQAAAAAAAA=

--Apple-Mail-3--209391594--



From owner-atom-syntax@mail.imc.org  Tue Jul 13 21:32: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 VAA22379
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 21:32: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 i6E1LZj9002824;
	Tue, 13 Jul 2004 18: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 i6E1LZ2b002823;
	Tue, 13 Jul 2004 18:21:35 -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 i6E1LYWi002815
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 18:21:35 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 44740 messnum 4158956 invoked from network[83.70.39.115/83-70-39-115.bas2.prp.dublin.eircom.net]); 14 Jul 2004 01:21:35 -0000
Received: from 83-70-39-115.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.39.115)
  by mail00.svc.cra.dublin.eircom.net (qp 44740) with SMTP; 14 Jul 2004 01:21:35 -0000
Message-ID: <40F48A82.2020408@dehora.net>
Date: Wed, 14 Jul 2004 02:21:06 +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: Atomlist Syntax <atom-syntax@imc.org>
Subject: Re: Low-hanging fruit: compulsory namespaces
References: <6D6BAC41-D517-11D8-8C42-000A95A51C9E@sun.com> <40F46DAC.3030900@dehora.net> <D4AC57AE-D527-11D8-A503-000A95A51C9E@sun.com>
In-Reply-To: <D4AC57AE-D527-11D8-A503-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:


> No.  XML elements and attributes are either in a namespace or they're 
> not.  We should not get into micromanaging the various syntactic tricks 
> you could use to accomplish this.  E.g. the following two are both 
> perfectly OK and effectively identical:
> 
> <snip examples/>

Sorry, the two examples are not identical (don't know what you mean 
by 'effectively'). The second will survive continuous processing, 
the first will not. Pump the first through enough downstream 
processors and there's a chance the prefixes will get dropped 
(there's nothing in the namespaces spec to prevent it). This stuff 
is error and bork prone in much the same way encodings are, For 
plain markup carried in Atom we should really be saying something 
about setting the default namespace to the empty string.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Tue Jul 13 21: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 VAA24679
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 21: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 i6E1hIq3004633;
	Tue, 13 Jul 2004 18:43: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 i6E1hIHu004632;
	Tue, 13 Jul 2004 18:43:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web41506.mail.yahoo.com (web41506.mail.yahoo.com [66.218.93.89])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6E1hI9A004624
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 18:43:18 -0700 (PDT)
	(envelope-from randymorin@yahoo.com)
Message-ID: <20040714014319.29894.qmail@web41506.mail.yahoo.com>
Received: from [24.43.182.164] by web41506.mail.yahoo.com via HTTP; Tue, 13 Jul 2004 18:43:18 PDT
Date: Tue, 13 Jul 2004 18:43:18 -0700 (PDT)
From: Randy Charles Morin <randymorin@yahoo.com>
Reply-To: randy@kbcafe.com
Subject: Re: PaceElementOrder: restart 
To: Atomlist <atom-syntax@imc.org>, Sam Ruby <rubys@intertwingly.net>
Cc: Dare Obasanjo <kpako@yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1461344804-1089769398=:29067"
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>


--0-1461344804-1089769398=:29067
Content-Type: text/plain; charset=us-ascii

Please ignore my response to Sam [1]. I officially revoke it, if that's allowed. Rather, I second Dare's respond [2] verbatim. Dare's most cleverer then me.
Thanks,
 
Randy
http://www.kbcafe.com
 
[1] http://www.imc.org/atom-syntax/mail-archive/msg06924.html
[2] http://www.imc.org/atom-syntax/mail-archive/msg06901.html

		
---------------------------------
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
--0-1461344804-1089769398=:29067
Content-Type: text/html; charset=us-ascii

<DIV>Please ignore my response to Sam [1]. I officially revoke it, if that's allowed. Rather, I second Dare's respond [2] verbatim. Dare's most cleverer then me.</DIV>
<DIV>Thanks,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Randy</DIV>
<DIV><A href="http://www.kbcafe.com">http://www.kbcafe.com</A></DIV>
<DIV>&nbsp;</DIV>
<DIV>[1] <A href="http://www.imc.org/atom-syntax/mail-archive/msg06924.html">http://www.imc.org/atom-syntax/mail-archive/msg06924.html</A></DIV>
<DIV>[2] <A href="http://www.imc.org/atom-syntax/mail-archive/msg06901.html">http://www.imc.org/atom-syntax/mail-archive/msg06901.html</A></DIV><p>
		<hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/mail_us/taglines/50x/*http://promotions.yahoo.com/new_mail/static/efficiency.html">Yahoo! Mail</a> - 50x more storage than other providers!
--0-1461344804-1089769398=:29067--



From owner-atom-syntax@mail.imc.org  Tue Jul 13 22: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 WAA27920
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 22:17: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 i6E28EFR006245;
	Tue, 13 Jul 2004 19:08: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 i6E28EG4006244;
	Tue, 13 Jul 2004 19:08: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 i6E28D4p006236
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 19:08:14 -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 i6E28wlY012043;
	Tue, 13 Jul 2004 22:08:58 -0400
Message-ID: <40F49594.604@intertwingly.net>
Date: Tue, 13 Jul 2004 22:08:20 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <mnot@mnot.net>
CC: Atomlist Syntax <atom-syntax@imc.org>
Subject: Re: Low-hanging fruit: compulsory namespaces
References: <6D6BAC41-D517-11D8-8C42-000A95A51C9E@sun.com> <3138B98C-D51E-11D8-AA19-000A95BD86C0@mnot.net>
In-Reply-To: <3138B98C-D51E-11D8-AA19-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: <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:
> 
> +1.
> 
> Do we want to replace this with something along the lines of "children 
> of atom:feed and atom:entry must be namespace-qualified?"

Add atom:author and atom:contributor.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Tue Jul 13 22: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 WAA29703
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 22: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 i6E2IOF6006797;
	Tue, 13 Jul 2004 19:18: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 i6E2IOLc006796;
	Tue, 13 Jul 2004 19:18: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.197])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6E2INVn006790
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 19:18:23 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d19so481294rnf
        for <atom-syntax@imc.org>; Tue, 13 Jul 2004 19:18:12 -0700 (PDT)
Received: by 10.38.92.10 with SMTP id p10mr162467rnb;
        Tue, 13 Jul 2004 19:18:12 -0700 (PDT)
Message-ID: <14be96d304071319181e2bf741@mail.gmail.com>
Date: Tue, 13 Jul 2004 22:18:12 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Tim Bray <tbray@textuality.com>
Subject: Re: Low-hanging fruit: multipart/alternative
Cc: Atomlist Syntax <atom-syntax@imc.org>
In-Reply-To: <7FBABBD6-D531-11D8-A503-000A95A51C9E@textuality.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <A65D9796-D519-11D8-8C42-000A95A51C9E@textuality.com>
 <14be96d304071317541efca684@mail.gmail.com> <7FBABBD6-D531-11D8-A503-000A95A51C9E@textuality.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, 13 Jul 2004 18:02:37 -0700, Tim Bray <tbray@textuality.com> wrote:
> Actually, I thought we'd nuked the whole notion of
> multiple-alternative-representations-of-the-entry, so the idea would be
> to just lose multipart/alternative.  But it's possible I have the wrong
> recollection... -Tim

Well, I wasn't at that face-to-face meeting, and I don't recall us
discussing it on-list.  I wouldn't call it "low-hanging" to nuke it
permanently.

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Tue Jul 13 22: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 WAA29700
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 22: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 i6E2G11q006593;
	Tue, 13 Jul 2004 19:16: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 i6E2G11V006592;
	Tue, 13 Jul 2004 19:16: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 (mproxy.gmail.com [216.239.56.244])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6E2G04u006585
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 19:16:00 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so11946800cwc
        for <atom-syntax@imc.org>; Tue, 13 Jul 2004 19:16:00 -0700 (PDT)
Received: by 10.11.118.39 with SMTP id q39mr13330cwc;
        Tue, 13 Jul 2004 19:16:00 -0700 (PDT)
Message-ID: <3f1451f5040713191629bc17a6@mail.gmail.com>
Date: Tue, 13 Jul 2004 22:16:00 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Tim Bray <tim.bray@sun.com>
Subject: Re: Editorial comments on draft-atompub-protocol-00
Cc: Atomlist Syntax <atom-syntax@imc.org>
In-Reply-To: <BC806156-D51B-11D8-8C42-000A95A51C9E@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <BC806156-D51B-11D8-8C42-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 Tue, 13 Jul 2004 15:26:51 -0700, Tim Bray <tim.bray@sun.com> wrote:
> 
> [page 3/sect 1.1] busted sentence: 'the and "OPTIONAL"'

Done.

> 
> [page 5/sect 3.1.3.3] the description of code 400 is borked, see the
> sentence "A short description of the error..."

Done.

> 
> Same for 3.1.3.4.

Done.

> 
> [page 5/sect 3.2] the description reads like it's forbidden to do a PUT
> without doing a GET first.  Is this true?  If I know the URI and I know
> what I want to put there, can't I just blast it in?

Good question. I will respond to this in a separate message.

> 
> [page 6/sect.3.2] there's nothing about return codes.  Perhaps you need
> a @to-do note?

Done. Return codes added.

> 
> [page 6/sect 3.3] Could the FeedURI and PostURI be the same URI?  I
> assume so, but it might be better to be explicit.

Done.



From owner-atom-syntax@mail.imc.org  Tue Jul 13 22:36: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 WAA00345
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 22:36: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 i6E2QDA3007299;
	Tue, 13 Jul 2004 19:26: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 i6E2QDg2007298;
	Tue, 13 Jul 2004 19:26:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.251])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6E2QDeE007290
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 19:26:13 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so11953436cwc
        for <atom-syntax@imc.org>; Tue, 13 Jul 2004 19:26:14 -0700 (PDT)
Received: by 10.11.116.34 with SMTP id o34mr520cwc;
        Tue, 13 Jul 2004 19:26:14 -0700 (PDT)
Message-ID: <3f1451f5040713192666d217c4@mail.gmail.com>
Date: Tue, 13 Jul 2004 22:26:14 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Tim Bray <tim.bray@sun.com>
Subject: GET before PUT on an EditURI
Cc: Atomlist Syntax <atom-syntax@imc.org>
In-Reply-To: <BC806156-D51B-11D8-8C42-000A95A51C9E@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <BC806156-D51B-11D8-8C42-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 Tue, 13 Jul 2004 15:26:51 -0700, Tim Bray <tim.bray@sun.com> wrote:
> [page 5/sect 3.2] the description reads like it's forbidden to do a PUT
> without doing a GET first.  Is this true?  If I know the URI and I know
> what I want to put there, can't I just blast it in?

You could, but you might not want to. 

Consider the case of a Wiki. Most Wiki HTML editing forms have 
a nonce, either a hidden time or a hash value. This nonce is used
to protect against edits being lost in a race condition, i.e. user
A starts to edit a page, takes too long and later user B edits the
same page and commits before user A does.

If the client does a GET on the EditURI then the server has a chance
to place a nonce in the entry. The client should preserve
that nonce and submit it with the entry when the edit entry
is PUT back to the EditURI. 

For this scenario to work you need two things. The first 
is that the client does a GET before editing. The second
is that the client preserves all the information elements 
of the entry for submitting back on the PUT,
even for namespaces and elements that the client doesn't know about,
which is something I believe all clients should do.

    -joe



From owner-atom-syntax@mail.imc.org  Tue Jul 13 22:55: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 WAA03060
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 22:55:12 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E2kptK009186;
	Tue, 13 Jul 2004 19: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 i6E2kpi1009185;
	Tue, 13 Jul 2004 19:46: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 i6E2koWn009178
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 19:46:50 -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 i6E2kvil008438
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 20:46:57 -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 <0I0T003RFME8OB@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Tue, 13 Jul 2004 20:46:57 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0T00FA7ME846@mail.sun.net> for atom-syntax@imc.org; Tue,
 13 Jul 2004 20:46:56 -0600 (MDT)
Date: Tue, 13 Jul 2004 19:46:58 -0700
From: Tim Bray <tbray@textuality.com>
Subject: Re: Low-hanging fruit: multipart/alternative
In-reply-to: <14be96d304071319181e2bf741@mail.gmail.com>
To: Atomlist Syntax <atom-syntax@imc.org>
Message-id: <1393DBDA-D540-11D8-A503-000A95A51C9E@textuality.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.618)
Content-type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4--203130592;
 protocol="application/pkcs7-signature"
References: <A65D9796-D519-11D8-8C42-000A95A51C9E@textuality.com>
 <14be96d304071317541efca684@mail.gmail.com>
 <7FBABBD6-D531-11D8-A503-000A95A51C9E@textuality.com>
 <14be96d304071319181e2bf741@mail.gmail.com>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>



--Apple-Mail-4--203130592
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On Jul 13, 2004, at 7:18 PM, Mark Pilgrim wrote:

>> Actually, I thought we'd nuked the whole notion of
>> multiple-alternative-representations-of-the-entry, so the idea would 
>> be
>> to just lose multipart/alternative.  But it's possible I have the 
>> wrong
>> recollection... -Tim
> Well, I wasn't at that face-to-face meeting, and I don't recall us
> discussing it on-list.  I wouldn't call it "low-hanging" to nuke it
> permanently.

Good enough, we were pretty solid in the room but that was the room and 
this is the mailing list, which is official, it isn't low-hanging if 
there's discomfort, so MNot, if you'd already nuked that, you'd better 
de-nuke.   Could someone take ownership of writing a three-line Pace 
saying

"Nuke multipart/alternative for substantial cost and lack of a 
compelling use-case."

Thanks in advance. -Tim

--Apple-Mail-4--203130592
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
hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDcxNDAyNDY1OVowIwYJKoZIhvcNAQkEMRYEFC9o
9lAwCjca+92f5QjGmeDY6xyFMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV
BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLirkwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT
AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3
dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDC4q5MA0GCSqGSIb3DQEBAQUABIIBAKIX
OXaqA3TGi3O+sUGx0KlG31P7psj8oPnUv+ymGO8wUgyrD4+z5/TgLfJEL9IrzkGtLDYPYihlLHL9
e/G2osxANurBfLx4YK5YAbCnmZoqIdOFUqrxly9zBA2H13+LkuQdsmHENWMAjAGBH8XvpIc2+fhG
ohf8Gu4kuKV8mwPgETom3yU7TDbOqvctUBxJ7pwEj5t19+SPU8Jlz8A6bUBq806zMJOir+LXrx7N
Qml1eLbaWgt+76yAEJg7TeLFteIVnujulHRQyBCnXWsvel+HRRcJUfXjFUDTbEhMHlN/Tf/2axwa
Xe/Zpaa/4qHHgrB6pOtsDlifEFji7+loJY4AAAAAAAA=

--Apple-Mail-4--203130592--



From owner-atom-syntax@mail.imc.org  Tue Jul 13 22:57: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 WAA03550
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 22:57: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 i6E2oDII009425;
	Tue, 13 Jul 2004 19:50: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 i6E2oCOl009424;
	Tue, 13 Jul 2004 19:50: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 i6E2oCS5009417
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 19:50:12 -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 i6E2mB53021582
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 20:48:11 -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 <0I0T003ZAMJUOB@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Tue, 13 Jul 2004 20:50:18 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0T00CF9MJTE1@mail.sun.net> for atom-syntax@imc.org; Tue,
 13 Jul 2004 20:50:18 -0600 (MDT)
Date: Tue, 13 Jul 2004 19:50:19 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: GET before PUT on an EditURI
In-reply-to: <3f1451f5040713192666d217c4@mail.gmail.com>
To: Joe Gregorio <joe.gregorio@gmail.com>
Cc: Atomlist Syntax <atom-syntax@imc.org>
Message-id: <8B1D1724-D540-11D8-A503-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: <BC806156-D51B-11D8-8C42-000A95A51C9E@sun.com>
 <3f1451f5040713192666d217c4@mail.gmail.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 Jul 13, 2004, at 7:26 PM, Joe Gregorio wrote:

>> [page 5/sect 3.2] the description reads like it's forbidden to do a 
>> PUT
>> without doing a GET first.  Is this true?  If I know the URI and I 
>> know
>> what I want to put there, can't I just blast it in?
>
> You could, but you might not want to.
>
> Consider the case of a Wiki.

... reasonable use-case elided.

The use-case granted, here's another: I'm a CMS blasting out deltas to 
a feed, where I know something's been updated and I own the data and 
the feed and I just want to damn well update it and not waste cycles 
doing a GET.

So all I'm saying is that the language which explains how you'd 
reasonably use PUT and GET, should also make it clear that PUT does 
what PUT does, and there's no compulsory preceding GET.  -Tim



From owner-atom-syntax@mail.imc.org  Tue Jul 13 23: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 XAA04732
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 23: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 i6E35AsB010397;
	Tue, 13 Jul 2004 20: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 i6E35A1I010396;
	Tue, 13 Jul 2004 20:05: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 (mproxy.gmail.com [216.239.56.250])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6E35AJv010389
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 20:05:10 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so11976206cwc
        for <atom-syntax@imc.org>; Tue, 13 Jul 2004 20:05:14 -0700 (PDT)
Received: by 10.11.99.74 with SMTP id w74mr14039cwb;
        Tue, 13 Jul 2004 20:05:14 -0700 (PDT)
Message-ID: <3f1451f50407132005ec21d76@mail.gmail.com>
Date: Tue, 13 Jul 2004 23:05:14 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Tim Bray <tim.bray@sun.com>
Subject: Re: GET before PUT on an EditURI
Cc: Atomlist Syntax <atom-syntax@imc.org>
In-Reply-To: <8B1D1724-D540-11D8-A503-000A95A51C9E@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <BC806156-D51B-11D8-8C42-000A95A51C9E@sun.com>
 <3f1451f5040713192666d217c4@mail.gmail.com> <8B1D1724-D540-11D8-A503-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 Tue, 13 Jul 2004 19:50:19 -0700, Tim Bray <tim.bray@sun.com> wrote:
> On Jul 13, 2004, at 7:26 PM, Joe Gregorio wrote:
> 
> >> [page 5/sect 3.2] the description reads like it's forbidden to do a
> >> PUT
> >> without doing a GET first.  Is this true?  If I know the URI and I
> >> know
> >> what I want to put there, can't I just blast it in?
> >
> > You could, but you might not want to.
> >
> > Consider the case of a Wiki.
> 
> ... reasonable use-case elided.
> 
> The use-case granted, here's another: I'm a CMS blasting out deltas to
> a feed, where I know something's been updated and I own the data and
> the feed and I just want to damn well update it and not waste cycles
> doing a GET.
> 
> So all I'm saying is that the language which explains how you'd
> reasonably use PUT and GET, should also make it clear that PUT does
> what PUT does, and there's no compulsory preceding GET.  -Tim

How about stating that the client SHOULD do a GET before 
editing?

    -joe



From owner-atom-syntax@mail.imc.org  Tue Jul 13 23:45: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 XAA08566
	for <atompub-archive@lists.ietf.org>; Tue, 13 Jul 2004 23:45: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 i6E3c0ZD013390;
	Tue, 13 Jul 2004 20:38: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 i6E3c0Ke013389;
	Tue, 13 Jul 2004 20:38: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-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 i6E3bx3V013383
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 20:37:59 -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 i6E3Zx53010349
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 21:35:59 -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 <0I0T00I71ORI6D@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Tue, 13 Jul 2004 21:38:06 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0T00KW5ORH3N@mail.sun.net> for atom-syntax@imc.org; Tue,
 13 Jul 2004 21:38:05 -0600 (MDT)
Date: Tue, 13 Jul 2004 20:38:07 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: GET before PUT on an EditURI
In-reply-to: <3f1451f50407132005ec21d76@mail.gmail.com>
To: Joe Gregorio <joe.gregorio@gmail.com>
Cc: Atomlist Syntax <atom-syntax@imc.org>
Message-id: <38AD18BB-D547-11D8-A503-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: <BC806156-D51B-11D8-8C42-000A95A51C9E@sun.com>
 <3f1451f5040713192666d217c4@mail.gmail.com>
 <8B1D1724-D540-11D8-A503-000A95A51C9E@sun.com>
 <3f1451f50407132005ec21d76@mail.gmail.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 Jul 13, 2004, at 8:05 PM, Joe Gregorio wrote:

>> The use-case granted, here's another: I'm a CMS blasting out deltas to
>> a feed, where I know something's been updated and I own the data and
>> the feed and I just want to damn well update it and not waste cycles
>> doing a GET.
>>
>> So all I'm saying is that the language which explains how you'd
>> reasonably use PUT and GET, should also make it clear that PUT does
>> what PUT does, and there's no compulsory preceding GET.  -Tim
>
> How about stating that the client SHOULD do a GET before
> editing?

I don't think so, because I think automatically generated and updated 
feeds with a single point of control will be a common use-case (perhaps 
the majority use-case).  I think we need a clear description of what 
GET does, what PUT does, and a note to describe the common-use case 
where you GET then PUT.  -Tim



From owner-atom-syntax@mail.imc.org  Wed Jul 14 00:01: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 AAA09672
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 00:01:39 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E3pk0N014030;
	Tue, 13 Jul 2004 20: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 i6E3pkS6014029;
	Tue, 13 Jul 2004 20:51:46 -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 i6E3pkDT014022
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 20:51:46 -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 i6E3pq3n023779;
	Tue, 13 Jul 2004 20:51:52 -0700 (PDT)
Received: from [192.168.1.100] (h00080d858303.ne.client2.attbi.com [24.61.1.243])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin01/MantshX 4.0) with ESMTP id i6E3pT6G025565;
	Tue, 13 Jul 2004 20:51:51 -0700 (PDT)
In-Reply-To: <BD19D5BE.13933%mint@franklinmint.fm>
References: <BD19D5BE.13933%mint@franklinmint.fm>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1--199271378; protocol="application/pkcs7-signature"
Message-Id: <0FD92B44-D549-11D8-B24C-000A95DC3D90@mac.com>
Cc: Atom Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: a methodical approach to defining what date  elements we need
Date: Tue, 13 Jul 2004 23:51:17 -0400
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-1--199271378
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 13 Jul 2004, at 6:09 pm, Robert Sayre wrote:

>> Consider that a typical aggregator polls for data.  If you replace an
>> entry twice, and the aggregator missed the first one, then it has an
>> incomplete history to reconcile.
>
> But if he just tweaks a date field each update, the consumer won't 
> even know
> it missed anything.

I think you misunderstand. An aggregator downloads and caches entry A. 
While the user is offline, A is superceded by B and then B is 
superceded by C. The user goes back online and downloads C, which says 
it supercedes B, which the aggregator has never seen. The aggregator 
therefore has no way of knowing and/or conveying to the user that C is 
a later version of A. This is hardly an edge case or a contrived 
scenario.

Compare this with having atom:id be static for all versions of the same 
entry, and the problem never comes up. For the supercedes approach to 
match this robustness, you must either:
a) Include the ids of all previous revisions in every entry (which 
won't scale)
b) Include the id of the original entry in all revisions (which, if you 
swap some element names, is exactly the same as keeping the id static)

If you want to add version ids to atom, I'd be happy for you. Just make 
sure atom:id never changes.

Graham
--Apple-Mail-1--199271378
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
9w0BCQUxDxcNMDQwNzE0MDM1MTE4WjAjBgkqhkiG9w0BCQQxFgQUwaGZIODnC1rEpzkC8gEHGsVM
GucweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEANJCNJck14Nbg8FrwfPlZ3Wva
ked5uOxaGnf06jMOugM9MrH69Hm9khu5cMTY0FRQ42P2/uDZI8dNAaQNz5iVY3iqHkf8c3cqMcZX
8IbtB4ewXByUa/PSQMB5d/1ZSrTNBEqA5lJdSYQAsMq0AZKFCM/KBv3CrH0FSP4rOI8LO17jmh4Z
6bA43kSKIG8SYXWfeZrelFNh/b6AkQbCogHlCXT4ROTqq1gi8KPxFQF4WRStp6UD1Pr8doxSe8Dl
zW9nve5Nkw6gZnhWE/I/pW1FyL2pmBSbhfpf/CpbTAYXm6X9+1xmkUswatAd/uHgFxhHM8Kr2ekS
hEJ48OX9yIDaPQAAAAAAAA==

--Apple-Mail-1--199271378--



From owner-atom-syntax@mail.imc.org  Wed Jul 14 01:00: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 BAA19644
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 01:00:58 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E4mfFl018507;
	Tue, 13 Jul 2004 21:48: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 i6E4mfHp018506;
	Tue, 13 Jul 2004 21:48:41 -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 i6E4meE8018496
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 21:48:40 -0700 (PDT)
	(envelope-from distobj@acm.org)
Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian))
	id 1Bkbhi-0000BT-00; Wed, 14 Jul 2004 00:49:14 -0400
Date: Wed, 14 Jul 2004 00:49:14 -0400
To: Joe Gregorio <joe.gregorio@gmail.com>
Cc: Atomlist Syntax <atom-syntax@imc.org>
Subject: Re: GET before PUT on an EditURI
Message-ID: <20040714044914.GT30868@markbaker.ca>
References: <BC806156-D51B-11D8-8C42-000A95A51C9E@sun.com> <3f1451f5040713192666d217c4@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3f1451f5040713192666d217c4@mail.gmail.com>
User-Agent: Mutt/1.3.28i
From: Mark Baker <distobj@acm.org>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


On Tue, Jul 13, 2004 at 10:26:14PM -0400, Joe Gregorio wrote:
> 
> On Tue, 13 Jul 2004 15:26:51 -0700, Tim Bray <tim.bray@sun.com> wrote:
> > [page 5/sect 3.2] the description reads like it's forbidden to do a PUT
> > without doing a GET first.  Is this true?  If I know the URI and I know
> > what I want to put there, can't I just blast it in?
> 
> You could, but you might not want to. 
> 
> Consider the case of a Wiki. Most Wiki HTML editing forms have 
> a nonce, either a hidden time or a hash value. This nonce is used
> to protect against edits being lost in a race condition, i.e. user
> A starts to edit a page, takes too long and later user B edits the
> same page and commits before user A does.
> 
> If the client does a GET on the EditURI then the server has a chance
> to place a nonce in the entry. The client should preserve
> that nonce and submit it with the entry when the edit entry
> is PUT back to the EditURI. 
> 
> For this scenario to work [...]

By "work", do you mean;

1. user A is notified of a problem when they try to PUT? ... or
2. user B is denied the ability to PUT because A is editing it?

If #1, I suggest that [1] would suffice to detect the conflict.
If #2, perhaps WebDAV LOCK should be considered.

But in both cases, a PUT without a preceding GET is not a problem.

 [1] http://www.w3.org/1999/04/Editing/

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

  Seeking work on large scale application/data integration projects
  and/or the enabling infrastructure for same.



From owner-atom-syntax@mail.imc.org  Wed Jul 14 01:27: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 BAA24947
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 01:27:01 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E5Ibtu023370;
	Tue, 13 Jul 2004 22: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 i6E5IbX8023369;
	Tue, 13 Jul 2004 22:18:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtp105.mail.sc5.yahoo.com (smtp105.mail.sc5.yahoo.com [66.163.169.225])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6E5IapD023363
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 22:18:37 -0700 (PDT)
	(envelope-from meyer_jon@yahoo.com)
Message-Id: <200407140518.i6E5IapD023363@above.proper.com>
Received: from unknown (HELO IBM2950F947866) (meyer?jon@162.84.134.61 with login)
  by smtp105.mail.sc5.yahoo.com with SMTP; 14 Jul 2004 05:18:44 -0000
From: "meyer_jon" <meyer_jon@yahoo.com>
To: "'Sam Ruby'" <rubys@intertwingly.net>,
        "'Antone Roundy'" <antone@geckotribe.com>
Cc: <atom-syntax@imc.org>
Subject: RE: a methodical approach to defining what date  elements we need (UTC, created/modified etc)
Date: Wed, 14 Jul 2004 01:18:42 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <40F2C2CD.9020307@intertwingly.net>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Thread-Index: AcRoNQM78kyWvmtNSpyeHYFj+dueKABI1HaQ
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6E5IbpD023364
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


>> What Bloggers calls Post Date and Time [1], and what LiveJournal  
>> simply calls Date and Local Time of an entry is different.   
>> Qualitatively different.  It is subjective.  It's primary purpose is 
>> for display.  For human consumption.

If people want "qualitative subjective" dates for display, use xsd:string,
remove any specification of how the date is formatted, and be done with it.
Then I can be free to use my favorite human-oriented date approach, e.g.
"environ deux heures après café, Dimanche, mi juin”.

In my opinion, this kind of qualitative subjective information fits very
nicely as part of the content of a blog entry, but if people want an
optional "atom:issued-subjective" element that's ok by me. Lets keep
atom:issued, atom:modified and atom:created as xsd:dateTimes though, with
timezones or UCT. 

Locality is useful data. I would be in favor of an atom:location tag as part
of atom:person tag, so I can say something like:
 
<author>
   <name>John Doe</name>
   <location>US-NY</location>
</author>

Not sure if there is a good standard to use for locations however.

Jon

@issued-subjective="at 1am, sorry if I'm a bit grouchy"




From owner-atom-syntax@mail.imc.org  Wed Jul 14 01:54: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 BAA26701
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 01:54: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 i6E5i4eG028040;
	Tue, 13 Jul 2004 22:44: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 i6E5i4u7028038;
	Tue, 13 Jul 2004 22:44:04 -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 i6E5i4V8027999
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 22:44:04 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040714054406.10203.qmail@web41209.mail.yahoo.com>
Received: from [24.18.129.247] by web41209.mail.yahoo.com via HTTP; Tue, 13 Jul 2004 22:44:06 PDT
Date: Tue, 13 Jul 2004 22:44:06 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: a methodical approach to defining what date  elements we need
To: Norman Walsh <ndw@nwalsh.com>, Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <87hdsbvcpv.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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


--- Norman Walsh <ndw@nwalsh.com> wrote:
> 
> I'm now convinced that it would be better to use
> just two:
> 
> Issued = when I published the essay
> Modified = when I last changed any of the bits in
> the entry.
> 
> If I make a "significant" change, I should
> 
> 1. Create a new entry with a new ID and new dates
> 2. Indicate that this new entry dcterms:replaces the
> original.
> 2. Update the original to say it's been
> dcterms:isReplacedBy the new one.
> 
> It's more work, but it'll make for a better
> historical record.

Why is this better? As an aggregator author I
definitely wouldn't want to support this convoluted
process. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


	
		
__________________________________
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 Jul 14 02:16: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 CAA12101
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 02:16: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 i6E68Ubs032605;
	Tue, 13 Jul 2004 23:08: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 i6E68UDr032604;
	Tue, 13 Jul 2004 23:08: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 i6E68UoN032593
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 23:08: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 i6E68bil004584
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 00:08:37 -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 <0I0T00JC6VQDT4@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Wed, 14 Jul 2004 00:08:37 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0T0034SVQCL2@mail.sun.net> for atom-syntax@imc.org; Wed,
 14 Jul 2004 00:08:37 -0600 (MDT)
Date: Tue, 13 Jul 2004 23:08:39 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Work Queue Rotation #3
To: Atomlist Syntax <atom-syntax@imc.org>
Message-id: <4005DCF4-D55C-11D8-A6EC-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: <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


Here's where I think we are on our current active items from the Public 
Issues List at http://www.intertwingly.net/wiki/pie/AtomPubIssuesList

1. PaceConsistentMimeType - not a peep, roll it in, it's accepted.

2. PaceElementOrder

This is a tough one.  First, we *do* seem to have consensus to add a 
new <feedinfo> (or <head> or some better name) to group all the 
feed-level & default stuff before the first <atom:entry> and that'll be 
in the -01 draft.

Second, the -00 draft says element order is not significant.  This is 
no longer true as we have consensus that <atom:feedinfo> comes before 
<atom:entry>, so -01 needs a change there.

The remaining issue is whether the stuff inside feedinfo has a required 
order.  This Pace actually is written to require no order.  But, it's 
obvious that there is still more work to do here.  So, it seems to me 
like the right thing to do is:

- mark PaceElementOrder as closed
- don't make any changes in the -01 draft aside from <feedinfo>
- Some people, probably including Randy Charles Morin & Dare Obasanjo, 
should pull together a new Pace along the lines of today's discussion, 
pushing for an XSD for use in the context of the Protocol that has 
strict ordering, with associated WSDL, while noting that software that 
receives Atom messages probably won't check the ordering anyhow.  I 
wouldn't be surprised if we could get consensus around that.

If anyone else has a better solution to suggest, let's hear it.

3. PaceSecurityServices

Paul writes: "There was agreement that we want Digest Auth as a SHOULD 
(not a MUST), not to give a SHOULD for the WSSE-like mechanism, and not 
to describe it in the core protocol document. Hopefully, someone 
describes at least one other auth mechanism for Atom, and if the WG 
likes that, we will point to that as a SHOULD as well."

Question to Joe/Rob: is that enough direction for the editors of the 
protocol draft to run with?  If not, you might want to huddle with the 
Security wonks like Paul and MarkP to figure out what should go in the 
-01.

4. PaceFeedSignature

I think we have consensus to reject this one, with the hope that 
someone writes another Pace to say "use XML Digsig", perhaps with some 
Atom-specific guidance.

5. PaceSyntaxGuidelines

Not much discussion, but it looks to me like this one is (sigh) joined 
at the hip to PaceLinkConstruct, thus gets shunted back to the Need To 
Revisit category until that's wrestled to the ground.

==========================

Meta-notes:
1. Ladies and Gentlemen, Boys and Girls, this is progress!  We are 
beginning to approximate what an actual functional working group feels 
like.
2. I think we have enough work done here to produce very solid -01 
drafts of both format and protocol in time for the August IETF 
deadline, which is Monday morning.
3. On the Paces above, it's perfectly possible our perception of 
consensus is wrong, the email volume is terrifying.  If so just say so, 
nobody's going to get mad.  On the other hand, don't panic if you see 
something you don't like go into the draft, it's always OK to suggest a 
change downstream & try to build consensus around it.  There's a reason 
these revs are marked "do not implement."

============================

Next steps: Time for Br'er Sam to turn the crank and rev the issues 
list.  In the meantime, enjoy your continuing permathreads.  I totally 
admire the people who've been grinding away on issued/modified dates 
for like 300 messages now, I assume their understanding of the 
trade-offs is getting razor-sharp.  -Tim



From owner-atom-syntax@mail.imc.org  Wed Jul 14 02:51: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 CAA27138
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 02:51: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 i6E6jSd3041796;
	Tue, 13 Jul 2004 23:45:28 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6E6jSHY041795;
	Tue, 13 Jul 2004 23:45:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6E6jRCO041753
	for <atom-syntax@imc.org>; Tue, 13 Jul 2004 23:45: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 3C8597C112
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 09:43:23 +0200 (CEST)
Date: Wed, 14 Jul 2004 08:48:51 +0200
To: Atom-Syntax <atom-syntax@imc.org>
Subject: "Issued" paces
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: <opsa37vpzguvpchu@quark>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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've created some "issued" paces that are three exclusive (they may be  
inclusive, if altered a bit) proposals to how the atom:issued element is  
to be handled. They are the following, ordered ascending in their  
complexity:

  * PaceObjectiveIssued[1]
  * PaceMultipeIssued[2]
  * PaceIssuedAndRelation[3]

PaceObjectiveIssued simply defines the semantics of issued, but does  
nothing with the data model. In brief; PaceObjectiveIssued defines  
'issued' as a non-subjective, «should be provided by a tool»-element.

PaceMultipeIssued builds on PaceObjectiveIssued and defines the same  
semantics. However, it also extends the data model into allowing multiple  
<issued> elements to indicate that the entry has been issued on several  
occasions.

PaceIssuedAndRelation builds on PaceObjectiveIssued and defines the same  
semantics. However, it also extends the data model with a new <relation>  
element (from Dublin Core[4]) to allow for re-issuance of entries. This is  
the least complete of the proposals, as I haven't got the time to finish  
it up before I run to work. :-)

PaceMultipeIssued and PaceIssuedAndRelation may be combined and thus  
allowing multiple <issued> elements as a simple re-issue mechanism, but  
also allowing the <relation> element as a more advanced,  
history-preserving way of re-issuing an entry.

I hope the different paces are clear in what they try to do, and any  
feedback on them is welcome.

____
[1] <url: http://intertwingly.net/wiki/pie/PaceObjectiveIssued>
[2] <url: http://intertwingly.net/wiki/pie/PaceMultipleIssued>
[3] <url: http://intertwingly.net/wiki/pie/PaceIssuedAndRelation>
[4] <url: http://dublincore.org/documents/relation-element/>

-- 
Asbjørn Ulsberg         -=|=-        asbjornu@hotmail.com
«He's a loathsome offensive brute, yet I can't look away»



From owner-atom-syntax@mail.imc.org  Wed Jul 14 06: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 GAA07814
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 06:37:07 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EAL9ul007140;
	Wed, 14 Jul 2004 03:21: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 i6EAL9Vc007139;
	Wed, 14 Jul 2004 03:21: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 i6EAL8mk007122
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 03:21: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 i6EALj8f006833;
	Wed, 14 Jul 2004 06:21:48 -0400
Message-ID: <40F50909.3060306@intertwingly.net>
Date: Wed, 14 Jul 2004 06:20:57 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <dtcd@mac.com>
CC: Atom-syntax Syntax <atom-syntax@imc.org>
Subject: Re: a methodical approach to defining what date  elements we need
References: <BD1995C2.1F3C6%eric.scheid@ironclad.net.au> <opsa2k75lz6dxgxk@mail.online.no> <CFCD3EC6-D4BA-11D8-82B1-000A95DC3D90@mac.com> <40F3CC36.9080001@intertwingly.net> <7C832F0A-D4D2-11D8-82B1-000A95DC3D90@mac.com> <40F3F09F.4070602@intertwingly.net> <50540F00-D4F5-11D8-82B1-000A95DC3D90@mac.com>
In-Reply-To: <50540F00-D4F5-11D8-82B1-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: <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 13 Jul 2004, at 10:24 am, Sam Ruby wrote:
> 
>> Note that there is some information loss there.  In this particular 
>> blog entry, it probably wasn't all that significant.  In other entries 
>> on Tim's blog, the nominal issue date can be very significant.
> 
> There probably is room in the spec for a nominal date.
> 
>> if "modified" were clarified to indicate that a change in this value 
>> indicates a "notable" modification; would these two changes suffice?
> 
> It's not about modification. My claim is that re-issuing an entry is a 
> separate event from all modification. Creation and modification dates 
> belong the document underneath the entry. Issuing and reissuing is about 
> how the document is published as an entry, which is an independent thing.
> 
>> Graham, I think we are on the same side here.  We both don't want 
>> aggregator authors to have to guess anymore.  We want aggregator 
>> authors to have a clear and unambiguous answer to the question "why 
>> did (or did not) you sort this entry to the top of the list?" - the 
>> answer being "because the value of <foo> element did (or did not) 
>> change".
> 
> Yes. The interaction between aggregators and publishers needs to be a 
> lot clearer than with RSS.

OK, it seems to me that we are making progress, slow progress, but 
progress.  Let me see if I can recap.  What I want to do is describe 
this in terms that can't be confused with terms that are encumbered and 
loaded with previous associations, like issued.

== == == == == == ==

Date 1: Updated

This date is meant to be a machine generated timestamp indicating when 
the most recent substantive change has been made to the entry.

One should be able to depend on this field for sorting purposes, and to 
depend on it to identify if the current version of this content of this 
entry has been (substantially) seen before.

In theory, this field can be updated independent of the content, but in 
practice that is rarely done.  Updating the content without updating 
this field would be with the intent of not drawing attention a change 
that was made.

While time zone information may be present on this field, it is not of 
any primary importance.

  = = =

Date 2: Display

This date is effectively a user entered date.  It means whatever the 
user wants it to mean.  It can be fictitious, it can be in the future. 
It can even be fanciful (Samuel Pepsys comes to mind).

This date is effectively part of the content.  Accordingly, if the 
display timestamp changes, the updated timestamp should also change.

We could define it as a string, but an ability to internationalize and 
search on this field is desirable.  One would rarely sort on this field. 
  Having an ability to express perceived relative local time in this 
field is also desirable.

  = = =

Date 3: Created

Another machine generated timestamp, indicating when the entry was first 
created.

This field is not intended for significantly used by an aggregator.  It 
came into being simply because the first three blog vendors I happened 
to talk to identified this as a common piece of information that they 
all track.  If it truly turns out to be a relatively common concept, 
then assigning it a common name is desirable from a tool migration point 
of view.

If, on the other hand, this field does not survive the standardization 
process, then so be it.

== == == == == == ==

Separate from all this is the ability of multiple entries to be related. 
  One certainly can create new entries which were based on another 
entry.  Capturing this relationship in the format is a desirable thing.

A few things to note, however.  Such new entries are separate and 
distinct from the original.  They would have new ids.  When displaying 
items from a feed, one would expect to see both the original and new 
items separately listed.  The original could continue to be updated 
independently after the new item was created.

  - Sam Ruby



From owner-atom-syntax@mail.imc.org  Wed Jul 14 07:07: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 HAA08893
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 07:07: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 i6EAx26b019806;
	Wed, 14 Jul 2004 03:59: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 i6EAx2J1019805;
	Wed, 14 Jul 2004 03:59:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf17.cluster1.charter.net (mxsf17.cluster1.charter.net [209.225.28.217])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EAx2WJ019754
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 03:59:02 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip16.cluster1.charter.net (mxip16a.cluster1.charter.net [209.225.28.146])
	by mxsf17.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6EB36ep002822
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 07:03:07 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip16.cluster1.charter.net with ESMTP; 14 Jul 2004 06:58:53 -0400
X-Ironport-AV: i="3.81R,167,1083556800"; 
   d="scan'208"; a="116601221:sNHT14939444"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BkhTE-0006UV-00
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 06:58:40 -0400
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Low-hanging fruit: compulsory namespaces
References: <6D6BAC41-D517-11D8-8C42-000A95A51C9E@sun.com>
	<40F46DAC.3030900@dehora.net>
	<D4AC57AE-D527-11D8-A503-000A95A51C9E@sun.com>
	<40F48A82.2020408@dehora.net>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Wed, 14 Jul 2004 06:58:36 -0400
In-Reply-To: <40F48A82.2020408@dehora.net> (Bill de
 =?iso-8859-1?q?h=D3ra's?= message of "Wed, 14 Jul 2004 02:21:06 +0100")
Message-ID: <87iscqsvmr.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: <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-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

/ Bill de h=D3ra <bill@dehora.net> was heard to say:
| Tim Bray wrote:
[...]
|> No.  XML elements and attributes are either in a namespace or
|> they're not.  We should not get into micromanaging the various
|> syntactic tricks you could use to accomplish this.  E.g. the
|> following two are both perfectly OK and effectively identical:
|> <snip examples/>
|
| Sorry, the two examples are not identical (don't know what you mean by
| 'effectively').

No. Sorry. Tim is right. Modulo the prefixes used, those two examples
*are the same*.

| The second will survive continuous processing, the first will not.
| Pump the first through enough downstream processors and there's a
| chance the prefixes will get dropped (there's nothing in the
| namespaces spec to prevent it).

Yes, the prefixes might get dropped, but if they do, then the resulting
document absolutely must come out like this:

<entry xmlns=3D"atom namespace">
  <issued>...
  .. other <xxx> tags
  ..
  <content type=3D"application/rss2+xml">
   <item xmlns=3D""><title>A chunk of RSS</title></item>
  </content>
</entry>

This is just a third way to write *the same* document.

Any other result is a bug in the processor.

| This stuff is error and bork prone
| in much the same way encodings are, For plain markup carried in Atom
| we should really be saying something about setting the default
| namespace to the empty string.

I disagree, but I don't object to saying something as long as what we
say is true.

                                        Be seeing you,
                                          norm

=2D-=20
Norman Walsh <ndw@nwalsh.com> | He who fails to become a giant need not
http://nwalsh.com/            | remain content with being a
                              | dwarf.--Ernest Bramah

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD4DBQBA9RHfOyltUcwYWjsRAvgKAJdSYHSHfXjuLzu9OVtcrTbtabF/AKCwrEyz
fHyvt1i2LwmfgOgzsuWGJw==
=e4EF
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Wed Jul 14 07:24: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 HAA09502
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 07:24: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 i6EBH4HQ025113;
	Wed, 14 Jul 2004 04:17: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 i6EBH4YA025111;
	Wed, 14 Jul 2004 04:17:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf22.cluster1.charter.net (mxsf22.cluster1.charter.net [209.225.28.222])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EBGv6s025015
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 04:17:03 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip15.cluster1.charter.net (mxip15a.cluster1.charter.net [209.225.28.145])
	by mxsf22.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6EBKL8v018225
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 07:20:21 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip15.cluster1.charter.net with ESMTP; 14 Jul 2004 07:16:52 -0400
X-Ironport-AV: i="3.81R,167,1083556800"; 
   d="scan'208"; a="116996953:sNHT14959032"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1Bkhkh-0006gt-00
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 07:16:43 -0400
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: a methodical approach to defining what date  elements we need
References: <63E12F93-D452-11D8-9D0B-003065EA6144@geckotribe.com>
	<opsa3dl3q7uvpchu@quark> <87hdsbvcpv.fsf@nwalsh.com>
	<40F45906.7060007@intertwingly.net> <87zn63sdh9.fsf@nwalsh.com>
	<40F4744A.5000709@intertwingly.net>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Wed, 14 Jul 2004 07:16:42 -0400
In-Reply-To: <40F4744A.5000709@intertwingly.net> (Sam Ruby's message of
 "Tue, 13 Jul 2004 19:46:18 -0400")
Message-ID: <87acy2susl.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: <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-Type: text/plain

/ Sam Ruby <rubys@intertwingly.net> was heard to say:
[...]
| Best explained by example.  Consider:
|
|    "B"    = http://norman.walsh.name/2003/02/stthomas
|    "feed" = http://norman.walsh.name/atom/whatsnew.xml
|
| Clearly entries are being purged from feeds at some point.

Indeed. The most recent 30, IIRC.

| If one fetches a feed intermittently, there can be gaps in history,
| resulting in an inability to reconcile history.

If you watch the feed intermittently, you could have lots of gaps.
It's not impossible to reconcile however, because you have a pointer
to the essay that's been replaced.

Anyway, as I said in response to Dare, I don't expect aggregators to
do anything special with this information (I don't mind if they do,
though). The essays are distinct and just happen to carry metadata
that says they're related.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | When we are tired, we are attacked by
http://nwalsh.com/            | ideas we conquered long ago.-- Nietzsche

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA9RYaOyltUcwYWjsRAjaoAJ0UG/LF/cr09dYR1UB0DDH5rI+ecACeKLCB
ErC+9fDCfk2YjUpAxmG5kMI=
=wp/b
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Wed Jul 14 07:31: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 HAA09791
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 07:31: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 i6EBNHDm026808;
	Wed, 14 Jul 2004 04:23:17 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6EBNHEj026807;
	Wed, 14 Jul 2004 04:23:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf28.cluster1.charter.net (mxsf28.cluster1.charter.net [209.225.28.228])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EBNGnj026783
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 04:23:17 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip16.cluster1.charter.net (mxip16a.cluster1.charter.net [209.225.28.146])
	by mxsf28.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6EBQlc5005568
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 07:26:47 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip16.cluster1.charter.net with ESMTP; 14 Jul 2004 07:23:11 -0400
X-Ironport-AV: i="3.81R,167,1083556800"; 
   d="scan'208"; a="116628920:sNHT14908016"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BkhiO-0006gb-00
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 07:14:20 -0400
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: a methodical approach to defining what date  elements we need
References: <20040714054406.10203.qmail@web41209.mail.yahoo.com>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Wed, 14 Jul 2004 07:14:20 -0400
In-Reply-To: <20040714054406.10203.qmail@web41209.mail.yahoo.com> (Dare
 Obasanjo's message of "Tue, 13 Jul 2004 22:44:06 -0700 (PDT)")
Message-ID: <87eknesuwj.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: <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-Type: text/plain

/ Dare Obasanjo <kpako@yahoo.com> was heard to say:
| --- Norman Walsh <ndw@nwalsh.com> wrote:
|> 
|> I'm now convinced that it would be better to use
|> just two:
|> 
|> Issued = when I published the essay
|> Modified = when I last changed any of the bits in
|> the entry.
|> 
|> If I make a "significant" change, I should
|> 
|> 1. Create a new entry with a new ID and new dates
|> 2. Indicate that this new entry dcterms:replaces the
|> original.
|> 2. Update the original to say it's been
|> dcterms:isReplacedBy the new one.
|> 
|> It's more work, but it'll make for a better
|> historical record.
|
| Why is this better?

I think it's better because the original essay isn't lost.
Readers can find the original as well as the revised version.

| As an aggregator author I
| definitely wouldn't want to support this convoluted
| process. 

I'm not suggesting aggregators should do anything special. There are
two essays, they go in feeds and get aggregated. They happen to carry
with them some metadata that describes that they're related. I don't
care if the aggregator displays that or not. Might be nice if they
did, but it's hardly something you'd have to spend a lot of time
writing code to support.

But apparently my comments on this thread aren't going to help achieve
consensus so I'll stop, mostly. I certainly won't press the issue if
some other consensus arises.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | 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.4 (GNU/Linux)

iD8DBQBA9RWMOyltUcwYWjsRApQ/AJ9kfvz8j6zuZ5ftyNHDrcEzkOXRiwCfRf/9
E6xJFUBKkeZwCI8DFQT22RE=
=CvnI
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Wed Jul 14 08: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 IAA11032
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 08: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 i6EBxvQe036745;
	Wed, 14 Jul 2004 04:59: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 i6EBxvX7036744;
	Wed, 14 Jul 2004 04:59:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from lakermmtao06.cox.net (lakermmtao06.cox.net [68.230.240.33])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EBxupr036715
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 04:59:57 -0700 (PDT)
	(envelope-from millennium@spoonybards.net)
Received: from [10.0.1.2] (really [68.105.186.6]) by lakermmtao06.cox.net
          (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with ESMTP
          id <20040714115951.RSYA19653.lakermmtao06.cox.net@[10.0.1.2]>;
          Wed, 14 Jul 2004 07:59:51 -0400
Message-ID: <40F52038.4050101@spoonybards.net>
Date: Wed, 14 Jul 2004 07:59:52 -0400
From: Beecher Greenman <millennium@spoonybards.net>
User-Agent: Mozilla Thunderbird 0.7 (Macintosh/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ken MacLeod <ken@bitsko.slc.ut.us>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceIntrospection: New Examples for Feed-Based Introspection
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


>>> >    <entry>
>>> >      <title>First Site</title>
>>> >      <link rel="alternate" type="text/html"
>>> > href="http://manyblogs.org/bob/FirstSite"/>
>>> >      <!-- Feed and Post URLs -->
>>> >      <link type="application/atom+xml" rel="service.post"
>>> > href="http://manyblogs.org/bob/FirstSite/post"/>
>>> >      <link type="application/atom+xml" rel="service.feed"
>>> > href="http://manyblogs.org/bob/FirstSite/feed"/>
>>> >      <!-- issued: Time when service was first published. -->
>>> >      <issued>2004-06-24T19:14:06Z</issued>
>>> >      <!-- modified: Time when blog was last updated -->
>>> >      <modified>2004-06-24T19:14:06Z</modified>
>>> >      <id>tag:manyblogs.org,2004-06-24:/bob/FirstSite</id>
>>> >    </entry>
>
>>
>> If this resource description in the list of resource were a <site>
>> resource instead of an <entry> resource, the client would know better
>> what to do with it.


That data is redundant. A client which found this via autodiscovery
knows what types of entries to expect from the @rel attribute of the
autodiscovery link. If it doesn't use this link then it's violating most
common definitions of introspection (which need to be in the context of
the resource being introspected), and so we get an ordinary list of
links, which is really all we can hope to guess about the client's
intentions anyway.


>> Does a client discover that this "entry" is
>> really a "site" by merely the presence of, say, the "service.post" and
>> "service.feed" link?  Main-level entries have the same links (they may
>> have a PostURI and FeedURI for the entry and its comments).


No; it gets this from the fact that it is identified as
"service.introspection" (or some other suitable value of @rel) from the
service it pulled this feed from.

Although a client could theoretically pull this link without using
autodiscovery -perhaps by caching the URL from a previous date- this
violates most definitions of introspection, which normally require the
call to be in context of an object. In a case like this, the feed is
little more than a list of links.


>>> > It's worth noting that Ken MacLeod and Steve Jenson have recently
>>> > proposed that <title> and <id> elements be added to the current
>>> > PaceIntrospection proposal's <site> tag. Both of these seem to have
>>> > been inspired by the similar tags in the feed format, and since what
>>> > I'm proposing uses that format, it already includes both of those
>>> > tags.
>
>>
>> It's worth noting that thousands of resource types can have titles and
>> identifiers, but not all resource types are entries.




>> If we want to make <feed>s into generic lists and <entry>s into
>> generic metadata containers, then fine, lets get consensus on *that*
>> so that we can start specifying a new technique, rather than their
>> element type name, for discovering the resource type that really is
>> being dealt with.


We don't need to "make" <feed>s into generic lists and <entry>s into
generic metadata containers, because they are *already* defined as such.
I am doing nothing other than applying the current definition in a way
not commonly thought about, because people are still thinking of
"entries" as synonymous with blog articles (a definition discarded in
the CommentsAreEntries discussion). If you want to change it in order to
limit its applications, then that's your prerogative, but you'll be
doing just that: changing the definition.



>>     <entry>
>>       <resource-type>site</resource-type>
>>       <title>First Site</title>
>>       <link rel="alternate" type="text/html"
>>          href="http://manyblogs.org/bob/FirstSite"/>
>>       ...
>>     </entry>
>>
>> It's @rel, all over again.


I suppose it is.

- Beecher Greenman





From owner-atom-syntax@mail.imc.org  Wed Jul 14 08:11: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 IAA11203
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 08:11: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 i6EC5RbS038452;
	Wed, 14 Jul 2004 05:05: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 i6EC5Rd4038451;
	Wed, 14 Jul 2004 05:05: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 (mproxy.gmail.com [216.239.56.248])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6EC5RgB038423
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 05:05:27 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so65287cwc
        for <atom-syntax@imc.org>; Wed, 14 Jul 2004 05:05:23 -0700 (PDT)
Received: by 10.11.116.22 with SMTP id o22mr21101cwc;
        Wed, 14 Jul 2004 05:05:23 -0700 (PDT)
Message-ID: <3f1451f504071405056b3a1f02@mail.gmail.com>
Date: Wed, 14 Jul 2004 08:05:23 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Mark Baker <distobj@acm.org>
Subject: Re: GET before PUT on an EditURI
Cc: Atomlist Syntax <atom-syntax@imc.org>
In-Reply-To: <20040714044914.GT30868@markbaker.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <BC806156-D51B-11D8-8C42-000A95A51C9E@sun.com> <3f1451f5040713192666d217c4@mail.gmail.com> <20040714044914.GT30868@markbaker.ca>
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 Wed, 14 Jul 2004 00:49:14 -0400, Mark Baker <distobj@acm.org> wrote:
> 
>  http://www.w3.org/1999/04/Editing/

I am embarrased to say that I'd forgotten that. Handling the Wiki
situation via ETags is much more appropriate.

   Thanks,
   -joe



From owner-atom-syntax@mail.imc.org  Wed Jul 14 09:07: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 JAA14151
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 09:07: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 i6ECwLmJ054442;
	Wed, 14 Jul 2004 05: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 i6ECwLrI054441;
	Wed, 14 Jul 2004 05:58:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf20.cluster1.charter.net (mxsf20.cluster1.charter.net [209.225.28.220])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ECwKJj054408
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 05:58:20 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip02.cluster1.charter.net (mxip02a.cluster1.charter.net [209.225.28.132])
	by mxsf20.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6ED36US026047
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 09:03:06 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip02.cluster1.charter.net with ESMTP; 14 Jul 2004 08:58:16 -0400
X-Ironport-AV: i="3.81R,168,1083556800"; 
   d="scan'217,208"; a="122786874:sNHT17137476"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BkjKn-0001zV-00
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 08:58:05 -0400
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Usage Scenarios for Versioning and Extensibility
References: <20040712214722.79750.qmail@web41212.mail.yahoo.com>
	<AA8D7D00-D461-11D8-AFCB-000A95BD86C0@mnot.net>
	<87acy45bch.fsf@nwalsh.com>
	<B2DCC212-D4F0-11D8-9691-000A95BD86C0@mnot.net>
	<87d62zzt5e.fsf@nwalsh.com>
	<73A44CEC-D52A-11D8-AA19-000A95BD86C0@mnot.net>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Wed, 14 Jul 2004 08:58:05 -0400
In-Reply-To: <73A44CEC-D52A-11D8-AA19-000A95BD86C0@mnot.net> (Mark
 Nottingham's message of "Tue, 13 Jul 2004 17:12:11 -0700")
Message-ID: <87iscqrbj6.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: <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-Type: text/plain
Content-Transfer-Encoding: quoted-printable

/ Mark Nottingham <mnot@mnot.net> was heard to say:
| On Jul 13, 2004, at 10:58 AM, Norman Walsh wrote:
|
|> I think we mean any element, not just the children of feed and entry.
|> I should be allowed to do this:
|>
|>   <atom:entry>
|>     <atom:title>Hello <foo:world
|> atom:mustUnderstand=3D"true"/></atom:title>
|>     ...
|>   </atom:entry>
|>
|> even if it's really stupid :-)
|
| OK. Does this mean that extensions (as well as core metadata such as
| atom:title) need to define where mU is allowed in their domains, or is
| is expressly allowed anywhere? If the latter, I'm not so concerned
| about the stupid angle (always hard to rule out), but it seems like it
| might be an implementation burden (e.g., <html:b
| atom:mustUnderstand=3D"true">foo</html:b>).

Uhm. I think the latter, but all we can say in the spec is that it's
allowed on all the atom: elements and that processors must look for it
on all elements. Whether it's actually allowed on elements in the
norm: namespace is up to the person that defines it.

| I see - this codifies the specialness of the Atom namespace by tying
| it to the version; the version declares definitively what's allowed in
| the Atom namespace.

Right.

|> In my view, a feed validator ought to be able to complain about:
|>
|>   <feed version=3D"Red">
|>     <entry>
|>       <lnk rel=3D"start" href=3D"xxx"/>
|>       ...
|>     </entry>
|>   </feed>
|>
|> if it knows what's valid in "Red" (and "lnk" isn't valid).
|
| Clarification: is "link", for the purposes of this example, in the
| atom namespace, or some other one?

In this example "lnk" is in the Atom namespace and is probably a typo
for "link" (also in the Atom namespace) if version "Red" is known not
to allow "lnk".

| I.e., does the version also allow
| you to talk about what's allowed (and not) from other namespaces?

I don't think the version has any bearing on what's allowed (or not)
From=20other namespaces. We say explicitly that anything's allowed.
I suppose we could say in some future version that elements from
the norm: namespace are forbidden, but I don't imagine we ever will.

The version tells you what RFC to read. The RFC tells you the syntax
and semantics. Anything you can get consensus to write in the RFC you
can control with the version attribute.

|> |> | 3) After a while, someone comes up with a souped-up version of
|> |> | atom:title that is backwards-compatible, just *better*. It gets
|> |> really
|> |> | popular, and yet another version of Atom is born.
|> |>
|> |> Bump the version identifier. No problem.
|> |
|> | If it's backwards-compatible, what purpose is served by changing the
|> | version identifier?
|>
|> Well, you said it was "backwards-compatible". I assume it has *some*
|> new semantic or it wouldn't just be backwards-compatible, it would
|> be "the same as" :-)
|>
|> If you want processors to be able to take advantage of the new
|> semantic, you have to give them some clue about it :-)
|
| This seems like another axis of things that the version identifier can
| talk about. Could you (or anyone else) give a concrete example of an
| element that exhibits this kind of change?

I can contrive one, but I can't think of any natural and useful ones
off the top of my head.

We could add a new atom:initials element to atom:name to allow a feed
to identify the initials of a person. This is a backwards compatible
change to atom:name because an old processor can just ignore the
initials element. But we want new processors to be able to do
something with it. By changing the version, a new processor can know
that the atom:initials element means what the new RFC says it means
and that it should really be there (it isn't a horrible misspelling of
"email").

                                        Be seeing you,
                                          norm

(All of this discussion is still ignoring some nasty details about how
these compatible changes can be expressed in XSD. And I think we
should continue to do so until we figure out what our policy is going
to be, but after we decide what we really want the policy to be, we're
going to have to talk about expressing it (or not) in a schema
language.)

=2D-=20
Norman Walsh <ndw@nwalsh.com> | Some people can stay longer in an hour
http://nwalsh.com/            | than others can in a week

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA9S3dOyltUcwYWjsRArnoAKCh66Fh4wdEOHphD41I0i1hVBdhiACdHIMk
kMJDAVPxWsHMe7CqtYp000U=
=gOer
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Wed Jul 14 09:29: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 JAA16004
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 09:29: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 i6EDLXt2061158;
	Wed, 14 Jul 2004 06: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 i6EDLWYa061157;
	Wed, 14 Jul 2004 06:21: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 i6EDLW2o061134
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 06:21: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 1BkjhS-0003lV-3x; Wed, 14 Jul 2004 13:21:30 +0000
Message-ID: <40F53359.6030206@franklinmint.fm>
Date: Wed, 14 Jul 2004 09:21:29 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tim Bray <Tim.Bray@Sun.COM>
CC: Atomlist Syntax <atom-syntax@imc.org>
Subject: Re: Work Queue Rotation #3
References: <4005DCF4-D55C-11D8-A6EC-000A95A51C9E@sun.com>
In-Reply-To: <4005DCF4-D55C-11D8-A6EC-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



> 4. PaceFeedSignature
>
> I think we have consensus to reject this one, with the hope that 
> someone writes another Pace to say "use XML Digsig", perhaps with some 
> Atom-specific guidance.


PaceSecurityServices contains a section for the format spec that states:

"Atom consumers MUST be able to parse XMLDSig content to extract the 
Atom content, even if they cannot do any signature validation."

I don't think we have consensus on the part of this Pace that concerns 
the format.

Robert Sayre

[1] http://www.intertwingly.net/wiki/pie/PaceSecurityServices




From owner-atom-syntax@mail.imc.org  Wed Jul 14 10:02: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 KAA17580
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 10:02: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 i6EDnxa0069052;
	Wed, 14 Jul 2004 06: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 i6EDnxFZ069051;
	Wed, 14 Jul 2004 06:49: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 i6EDnwUK069029
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 06:49: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 i6EDoeBJ016628
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 09:50:40 -0400
Message-ID: <40F539FE.7010600@intertwingly.net>
Date: Wed, 14 Jul 2004 09:49:50 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: New AtomPubIssuesList for 2004/07/14
References: <40E16215.6070507@intertwingly.net> <40EC9915.4050406@intertwingly.net>
In-Reply-To: <40EC9915.4050406@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


http://www.intertwingly.net/wiki/pie/AtomPubIssuesList

As we are on the cusp of releasing a -01 set of drafs, I thought I would 
keep this iteration light... PaceEntryIdRequired and PaceLang look like 
they should be easy to dispose of.

For the moment, I'm keeping PaceSecurityServices listed as under active 
discission as the last status I saw was Tim asking a question to the 
editors, and Robert replying concerning a portion which he did not 
perceive as quite having reached consensus.

Finally, PacePutDelete was withdrawn by its author.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Wed Jul 14 10: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 KAA17600
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 10:02: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 i6EDrp2N070141;
	Wed, 14 Jul 2004 06: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 i6EDrp4b070140;
	Wed, 14 Jul 2004 06:53: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 i6EDrp0I070134
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 06:53:51 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6EDrril025393
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 07:53:53 -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 <0I0U003HNH9SOB@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Wed, 14 Jul 2004 07:53:53 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0U00F4WH9S46@mail.sun.net> for atom-syntax@imc.org; Wed,
 14 Jul 2004 07:53:52 -0600 (MDT)
Date: Wed, 14 Jul 2004 06:53:55 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Low-hanging fruit: compulsory namespaces
In-reply-to: <40F48A82.2020408@dehora.net>
To: Atomlist Syntax <atom-syntax@imc.org>
Message-id: <3F81CFBF-D59D-11D8-A6EC-000A95A51C9E@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.618)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
References: <6D6BAC41-D517-11D8-8C42-000A95A51C9E@sun.com>
 <40F46DAC.3030900@dehora.net> <D4AC57AE-D527-11D8-A503-000A95A51C9E@sun.com>
 <40F48A82.2020408@dehora.net>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6EDrp0I070135
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 Jul 13, 2004, at 6:21 PM, Bill de hÓra wrote:

> Sorry, the two examples are not identical (don't know what you mean by 
> 'effectively'). The second will survive continuous processing, the 
> first will not. Pump the first through enough downstream processors 
> and there's a chance the prefixes will get dropped (there's nothing in 
> the namespaces spec to prevent it). This stuff is error and bork prone 
> in much the same way encodings are, For plain markup carried in Atom 
> we should really be saying something about setting the default 
> namespace to the empty string.

I went back and reviewed the examples, and I totally disagree.  They 
really are the same, and any chain of processing software that makes 
them come out different is severely buggy, and I don't think bugginess 
at that level is prevalent in widely-used XML-processing tools.

I don't think we should be micromanaging how people do their namespace 
mappings, just like I don't think we should be telling people to prefer 
either of these two over the other

<title>Pat &amp; Mike</title>      <title><![CDATA[Pat & Mike]]></title>

-Tim




From owner-atom-syntax@mail.imc.org  Wed Jul 14 10:04: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 KAA17819
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 10: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 i6EDrMVb070010;
	Wed, 14 Jul 2004 06:53: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 i6EDrMEZ070009;
	Wed, 14 Jul 2004 06:53:22 -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 i6EDrL9W069974
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 06:53:21 -0700 (PDT)
	(envelope-from roger@agincourtmedia.com)
Received: from biggreen ([216.63.148.42]) by journurl.com with MailEnable ESMTP; Wed, 14 Jul 2004 08:52:33 -0500
From: "Roger B." <roger@agincourtmedia.com>
To: "'Sam Ruby'" <rubys@intertwingly.net>
Cc: "'Atom-syntax Syntax'" <atom-syntax@imc.org>
Subject: RE: a methodical approach to defining what date  elements we need
Date: Wed, 14 Jul 2004 08:53:43 -0500
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: <40F50909.3060306@intertwingly.net>
thread-index: AcRpjMG9iqfei/qbQYqdjK2cwzb47QAFYxvQ
Message-ID: <EFA0EF93A05F4657B568EC76AA454.MAI@journurl.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


> Date 1: Updated
> 
> This date is meant to be a machine generated timestamp indicating when
> the most recent substantive change has been made to the entry.

Sam: +1, if we agree that "substantive" is to be defined by the publisher.

> Date 2: Display
> 
> This date is effectively a user entered date.  It means whatever the
> user wants it to mean. ... One would rarely sort on this field.

 +0.5. I don't think "rarely" fits the bill here.

If the chronology of entries matter, the display date is all you can rely
upon. When I'm telling the one-entry-per-day story of my vacation, it
doesn't matter how many times I modify each entry, or how *much* I modify
them, or that I modified them at all... my readers will expect those entries
to show up in their aggregators in the order defined by the Display date.
The story makes no sense otherwise... it becomes a jumbled mess. 

The exception would be newspaper-style aggregators that throw multiple feeds
into a single pile. In that case, both Updated and Display are irrelevant to
the default sort, since such apps generally want to push anything new to the
top, regardless of what the publisher has to say.

None of which is meant to suggest that some people won't sort on Updated,
but Display is the more viable default.

> Date 3: Created
> 
> Another machine generated timestamp, indicating when the entry was first
> created. 

+1 with no caveats.

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/






From owner-atom-syntax@mail.imc.org  Wed Jul 14 10: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 KAA18527
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 10:12: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 i6EE3rZG072685;
	Wed, 14 Jul 2004 07: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 i6EE3rF8072684;
	Wed, 14 Jul 2004 07:03:53 -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 i6EE3qpx072660
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 07:03:52 -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 i6EE3n53013957
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 09:03:49 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6EE3mxs013953;
	Wed, 14 Jul 2004 09:03:48 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceIntrospection: New Examples for Feed-Based Introspection
References: <40F52038.4050101@spoonybards.net>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 14 Jul 2004 09:03:48 -0500
In-Reply-To: <40F52038.4050101@spoonybards.net>
Message-ID: <m3u0walm7v.fsf@bitsko.slc.ut.us>
Lines: 33
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


Beecher Greenman <millennium@spoonybards.net> writes:

> [Ken MacLeod wrote:]
> > If this resource description in the list of resource were a
> > <site> resource instead of an <entry> resource, the client would
> > know better what to do with it.
> 
> That data is redundant. A client which found this via autodiscovery
> knows what types of entries to expect from the @rel attribute of the
> autodiscovery link. If it doesn't use this link then it's violating
> most common definitions of introspection (which need to be in the
> context of the resource being introspected), and so we get an
> ordinary list of links, which is really all we can hope to guess
> about the client's intentions anyway.

OK, this seems to be a very clear statement.  What this is saying is
that one should determine the content type of a resource at a
particular URI location:

 * not by its Internet Media Type (application/atom+xml),
 * not by its XML namespace (http://purl.org/atom/ns#),
 * not by its element type (namespace+localname), and
 * not by any other local means indicated within the content

but rather, solely by the external link property used to reference the
resource (<link rel="service.feed">).

That doesn't work past the first time the link is copied to some other
location, for *any* other purpose (linking, documentation, storage).
Once the link reference "leaves its home", knowledge of what the
resource "is" is lost.

  -- Ken



From owner-atom-syntax@mail.imc.org  Wed Jul 14 10: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 KAA18552
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 10: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 i6EE5CUO073044;
	Wed, 14 Jul 2004 07:05: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 i6EE5CvS073043;
	Wed, 14 Jul 2004 07:05:12 -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 i6EE5BcY073015
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 07:05:12 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040714140508.71897.qmail@web41208.mail.yahoo.com>
Received: from [24.18.129.247] by web41208.mail.yahoo.com via HTTP; Wed, 14 Jul 2004 07:05:08 PDT
Date: Wed, 14 Jul 2004 07:05:08 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: a methodical approach to defining what date  elements we need
To: Sam Ruby <rubys@intertwingly.net>, Graham <dtcd@mac.com>
Cc: Atom-syntax Syntax <atom-syntax@imc.org>
In-Reply-To: <40F50909.3060306@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:
> 
> 
> OK, it seems to me that we are making progress, slow
> progress, but 
> progress.  

Agreed. 
 
> Date 1: Updated
> 
> This date is meant to be a machine generated
> timestamp indicating when 
> the most recent substantive change has been made to
> the entry.

+ 1

>   = = =
> 
> Date 2: Display
> 
> This date is effectively a user entered date.  It
> means whatever the 
> user wants it to mean.  It can be fictitious, it can
> be in the future. 
> It can even be fanciful (Samuel Pepsys comes to
> mind).

-1 

I don't see what purpose this date serves. This is a
potentially bogus date that potentially will confuse
producers and consumers of Atom feeds. 
 
>   = = =
> 
> Date 3: Created
> 
> Another machine generated timestamp, indicating when
> the entry was first 
> created.
> 
> This field is not intended for significantly used by
> an aggregator.  It 
> came into being simply because the first three blog
> vendors I happened 
> to talk to identified this as a common piece of
> information that they 
> all track.  If it truly turns out to be a relatively
> common concept, 
> then assigning it a common name is desirable from a
> tool migration point 
> of view.

I don't see why this date should be in the feed. I can
understand having a concept such as issued but since
it seems tools don't seem to track that very well I
don't see why we should settle for a date field that
is primarily of use only to the content producer not
content consumers. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


	
		
__________________________________
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 Jul 14 10: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 KAA19485
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 10: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 i6EEAonI074864;
	Wed, 14 Jul 2004 07:10: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 i6EEAoGp074863;
	Wed, 14 Jul 2004 07:10: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.206])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6EEAnZp074851
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 07:10:50 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d15so390178rng
        for <atom-syntax@imc.org>; Wed, 14 Jul 2004 07:10:49 -0700 (PDT)
Received: by 10.38.207.20 with SMTP id e20mr537943rng;
        Wed, 14 Jul 2004 07:10:48 -0700 (PDT)
Message-ID: <14be96d30407140710490f561a@mail.gmail.com>
Date: Wed, 14 Jul 2004 10:10:48 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Sam Ruby <rubys@intertwingly.net>
Subject: Re: New AtomPubIssuesList for 2004/07/14
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <40F539FE.7010600@intertwingly.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <40E16215.6070507@intertwingly.net> <40EC9915.4050406@intertwingly.net> <40F539FE.7010600@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 Wed, 14 Jul 2004 09:49:50 -0400, Sam Ruby <rubys@intertwingly.net> wrote:
> 
> http://www.intertwingly.net/wiki/pie/AtomPubIssuesList
> 

PaceShouldBeWellFormed has been withdrawn.  PaceMustBeWellFormed
received no dissent (just one clarification).  I recommend we include
it in -01.

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Wed Jul 14 10:28: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 KAA20206
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 10: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 i6EEM1Ic079084;
	Wed, 14 Jul 2004 07:22: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 i6EEM01p079083;
	Wed, 14 Jul 2004 07:22: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-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 i6EELx9H079070
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 07:22:00 -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 i6EEJt53023596
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 08:19:55 -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 <0I0U0037YIKPOB@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Wed, 14 Jul 2004 08:22:02 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0U00FFWIKP46@mail.sun.net> for atom-syntax@imc.org; Wed,
 14 Jul 2004 08:22:01 -0600 (MDT)
Date: Wed, 14 Jul 2004 07:22:04 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: a methodical approach to defining what date  elements we need
In-reply-to: <40F50909.3060306@intertwingly.net>
To: Atom-syntax Syntax <atom-syntax@imc.org>
Message-id: <2E1EB2AB-D5A1-11D8-A6EC-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: <BD1995C2.1F3C6%eric.scheid@ironclad.net.au>
 <opsa2k75lz6dxgxk@mail.online.no>
 <CFCD3EC6-D4BA-11D8-82B1-000A95DC3D90@mac.com>
 <40F3CC36.9080001@intertwingly.net>
 <7C832F0A-D4D2-11D8-82B1-000A95DC3D90@mac.com>
 <40F3F09F.4070602@intertwingly.net>
 <50540F00-D4F5-11D8-82B1-000A95DC3D90@mac.com>
 <40F50909.3060306@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 Jul 14, 2004, at 3:20 AM, Sam Ruby wrote:

> OK, it seems to me that we are making progress, slow progress, but 
> progress.  Let me see if I can recap.  What I want to do is describe 
> this in terms that can't be confused with terms that are encumbered 
> and loaded with previous associations, like issued.

Near as I can tell, Sam's proposal covers all the use-cases I've seen 
out there in the syndication space, I'm generally +1 on the whole 
thing.

It would be nice if a couple of the heavy implementors were to have a 
close look. -Tim



From owner-atom-syntax@mail.imc.org  Wed Jul 14 10:31: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 KAA20317
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 10:31: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 i6EELR1K078840;
	Wed, 14 Jul 2004 07:21: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 i6EELREK078839;
	Wed, 14 Jul 2004 07:21:27 -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 i6EELQZw078792
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 07:21:27 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 48193 messnum 2038798 invoked from network[83.70.39.115/83-70-39-115.bas2.prp.dublin.eircom.net]); 14 Jul 2004 14:21:23 -0000
Received: from 83-70-39-115.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.39.115)
  by mail03.svc.cra.dublin.eircom.net (qp 48193) with SMTP; 14 Jul 2004 14:21:23 -0000
Message-ID: <40F5415E.5070100@dehora.net>
Date: Wed, 14 Jul 2004 15:21:18 +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: Atomlist Syntax <atom-syntax@imc.org>
Subject: Re: Low-hanging fruit: compulsory namespaces
References: <6D6BAC41-D517-11D8-8C42-000A95A51C9E@sun.com> <40F46DAC.3030900@dehora.net> <D4AC57AE-D527-11D8-A503-000A95A51C9E@sun.com> <40F48A82.2020408@dehora.net> <3F81CFBF-D59D-11D8-A6EC-000A95A51C9E@sun.com>
In-Reply-To: <3F81CFBF-D59D-11D8-A6EC-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:

> I went back and reviewed the examples, and I totally disagree.  They 
> really are the same, and any chain of processing software that makes 
> them come out different is severely buggy, and I don't think bugginess 
> at that level is prevalent in widely-used XML-processing tools.

Ok, I won't dispute that re deployed processor behaviour. But I went 
back and reread the 1.1 Namespaces spec today and I didn't see where 
behaving the way you and Norm say they should not is considered a 
processing error. Seriously, did I miss it?

cheers
Bill



From owner-atom-syntax@mail.imc.org  Wed Jul 14 10:38: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 KAA20954
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 10:38:14 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EEUMun082611;
	Wed, 14 Jul 2004 07:30: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 i6EEUMui082610;
	Wed, 14 Jul 2004 07:30: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 SMTP id i6EEULsF082601
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 07:30:22 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d19so509515rnf
        for <atom-syntax@imc.org>; Wed, 14 Jul 2004 07:30:07 -0700 (PDT)
Received: by 10.38.72.80 with SMTP id u80mr316738rna;
        Wed, 14 Jul 2004 07:30:07 -0700 (PDT)
Message-ID: <14be96d3040714073014f7ba04@mail.gmail.com>
Date: Wed, 14 Jul 2004 10:30:07 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: mint@franklinmint.fm
Subject: Problem of enveloping signatures (was Re: Work Queue Rotation #3)
Cc: Tim Bray <tim.bray@sun.com>, Atomlist Syntax <atom-syntax@imc.org>
In-Reply-To: <40F53359.6030206@franklinmint.fm>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <4005DCF4-D55C-11D8-A6EC-000A95A51C9E@sun.com> <40F53359.6030206@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 Wed, 14 Jul 2004 09:21:29 -0400, Robert Sayre <mint@franklinmint.fm> wrote:
> PaceSecurityServices contains a section for the format spec that states:
> 
> "Atom consumers MUST be able to parse XMLDSig content to extract the
> Atom content, even if they cannot do any signature validation."
> 
> I don't think we have consensus on the part of this Pace that concerns
> the format.

We absolutely do not have consensus on this part.  XML digital
signatures can be stored in 4 places:

1. Separately, with their own URI
2. As a sibling to the element they are signing
3. As a child to the element they are signing (the signature then
contains an XPath query that identifies the part of the element that
constitutes the signature, so that receiving applications can strip it
out before verifying the hash of the remaining nodes)
4. As a parent to the elmeent they are signing

1 - 3 pose no problems.  In the case of 1, we could have a feed-level
link with @rel of "signature" or similar; this is a separate
discussion.  In the case of 2 and 3, XML digital signatures are stored
within their own namespace, so the Must Ignore rules kick in and
non-digsig-aware clients will simply ignore them.

However, in the case of 4, *all* clients (even clients that do not
implement digital signatures, which would be, um, all of them at the
moment) would need to be aware of the digital signature envelope,
because it would take this:

<feed version="0.3" xmlns="http://purl.org/atom/ns#">
<entry>
<title>foo</title>
<link .../>
</entry>
</feed>

and turn it into this:

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo Id="foobar">
<CanonicalizationMethod 
  Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
<SignatureMethod 
  Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1" /> 
<Reference URI="http://www.abccompany.com/news/2000/03_27_00.htm">
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> 
</Reference>
<Reference 
  URI="http://www.w3.org/TR/2000/WD-xmldsig-core-20000228/signature-example.xml">
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>UrXLDLBIta6skoV5/A8Q38GEw44=</DigestValue> 
</Reference>
</SignedInfo>
<SignatureValue>MC0E~LE=</SignatureValue>
<KeyInfo>
<X509Data>
<X509SubjectName>CN=Ed Simon,O=XMLSec Inc.,ST=OTTAWA,C=CA</X509SubjectName>
<X509Certificate>
MIID5jCCA0+gA...lVN
</X509Certificate>
</X509Data>
</KeyInfo>
<feed version="0.3" xmlns="http://purl.org/atom/ns#">
<entry>
<title>foo</title>
<link .../>
</entry>
</feed>
</Signature>

In other words, the XPath of the feed changed from /atom:feed/ to
/dsig:Signature/atom:feed/.  All clients would need to be updated to
look for feeds within a dsig:Signature element.  Indeed, all clients
would need to be updated to look for *any element at all* within a
dsig:Signature element (since theoretically any element within an XML
document can be signed individually).

(Those playing along at home will recognize this as the "multiple
envelope problem," and is worthy of its own permathread.  Look, here's
one: http://www.intertwingly.net/blog/2002/12/20/All-the-way-to-SOAP )

Bottom line: XML digital signatures are OK, but we should explicitly
profile the dsig spec to state that enveloped signatures are *not* OK.
 And we should have a standard "Atom-ish" way of linking to externally
stored signatures.

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Wed Jul 14 10:40: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 KAA21174
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 10:40:06 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EEWanA083642;
	Wed, 14 Jul 2004 07:32: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 i6EEWaII083641;
	Wed, 14 Jul 2004 07:32:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EEWauN083631
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 07:32: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 i6EEWcil019694
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 08:32:38 -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 <0I0U0030VJ2DOB@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Wed, 14 Jul 2004 08:32:38 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0U00C6BJ2DE4@mail.sun.net> for atom-syntax@imc.org; Wed,
 14 Jul 2004 08:32:37 -0600 (MDT)
Date: Wed, 14 Jul 2004 07:32:40 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: New AtomPubIssuesList for 2004/07/14
In-reply-to: <14be96d30407140710490f561a@mail.gmail.com>
To: Atom-Syntax <atom-syntax@imc.org>
Message-id: <A952BCC6-D5A2-11D8-A6EC-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: <40E16215.6070507@intertwingly.net>
 <40EC9915.4050406@intertwingly.net> <40F539FE.7010600@intertwingly.net>
 <14be96d30407140710490f561a@mail.gmail.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 Jul 14, 2004, at 7:10 AM, Mark Pilgrim wrote:

>
> On Wed, 14 Jul 2004 09:49:50 -0400, Sam Ruby <rubys@intertwingly.net> 
> wrote:
>>
>> http://www.intertwingly.net/wiki/pie/AtomPubIssuesList
>>
>
> PaceShouldBeWellFormed has been withdrawn.  PaceMustBeWellFormed
> received no dissent (just one clarification).  I recommend we include
> it in -01.

Sorry.  I strongly dissent on PaceMustBeWellFormed, and also on the 
withdrawing of PaceShouldBeWellFormed.  I think we haven't really faced 
up to these as a community and they TOTALLY need more discussion.  -Tim



From owner-atom-syntax@mail.imc.org  Wed Jul 14 10:47: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 KAA21527
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 10:47: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 i6EEdI6i086563;
	Wed, 14 Jul 2004 07: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 i6EEdIce086562;
	Wed, 14 Jul 2004 07:39: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 i6EEdI9D086551
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 07:39:18 -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 i6EEe0Yu019094;
	Wed, 14 Jul 2004 10:40:00 -0400
Message-ID: <40F5458F.4030202@intertwingly.net>
Date: Wed, 14 Jul 2004 10:39:11 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Dare Obasanjo <kpako@yahoo.com>
CC: Atom-syntax Syntax <atom-syntax@imc.org>
Subject: Re: a methodical approach to defining what date  elements we need
References: <20040714140508.71897.qmail@web41208.mail.yahoo.com>
In-Reply-To: <20040714140508.71897.qmail@web41208.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:

>>Date 2: Display
>>
>>This date is effectively a user entered date.  It
>>means whatever the 
>>user wants it to mean.  It can be fictitious, it can
>>be in the future. 
>>It can even be fanciful (Samuel Pepsys comes to
>>mind).
> 
> -1 
> 
> I don't see what purpose this date serves. This is a
> potentially bogus date that potentially will confuse
> producers and consumers of Atom feeds. 

I'm going to assume for the moment that the problem is my lack of 
ability to express the concept clearly.  But my premise is that you are 
already seeing those types of dates, you simply may not know realize it 
by virtue of the fact that they are improperly or poorly tagged.

Let me be clear: I am not trying to break new ground here.  I am merely 
trying to categorize what I already see out in the field.  So, if you 
will bear with me, let's take a look at the following together:

http://www.livejournal.com/update.bml?mode=full
http://help.blogger.com/bin/answer.py?answer=139&topic=17
http://www.movabletype.org/features.shtml
http://journurl.com/?entry=1007&template=upgrade

In the latter two look for text like and "Movable Type allows you to set 
a post's date stamp to any date or time you wish, for pre-dating or 
post-dating information when it goes live.", and "Pre- and post-date 
entries"

 From this sample, I gather that there is an existing need, it already 
is widely deployed across a number of tools, and presumably has already 
bled into a wide number of feeds that you already have been consuming.

If we deny this information a home, it will simply find one of its own 
accord.

So, how do we capture the concept of a user entered date that means 
whatever the user intends it to mean?

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Wed Jul 14 10:47:45 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21591
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 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 i6EEclLU086315;
	Wed, 14 Jul 2004 07:38:47 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6EEclIU086314;
	Wed, 14 Jul 2004 07:38: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.195])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6EEckE2086302
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 07:38:46 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d15so392019rng
        for <atom-syntax@imc.org>; Wed, 14 Jul 2004 07:38:48 -0700 (PDT)
Received: by 10.38.207.20 with SMTP id e20mr542869rng;
        Wed, 14 Jul 2004 07:38:48 -0700 (PDT)
Message-ID: <14be96d30407140738693529e9@mail.gmail.com>
Date: Wed, 14 Jul 2004 10:38:48 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Ken MacLeod <ken@bitsko.slc.ut.us>
Subject: Re: PaceIntrospection: New Examples for Feed-Based Introspection
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <m3u0walm7v.fsf@bitsko.slc.ut.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <40F52038.4050101@spoonybards.net> <m3u0walm7v.fsf@bitsko.slc.ut.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 14 Jul 2004 09:03:48 -0500, Ken MacLeod <ken@bitsko.slc.ut.us> wrote:
> 
> Beecher Greenman <millennium@spoonybards.net> writes:
> 
> > [Ken MacLeod wrote:]
> > > If this resource description in the list of resource were a
> > > <site> resource instead of an <entry> resource, the client would
> > > know better what to do with it.
> >
> > That data is redundant. A client which found this via autodiscovery
> > knows what types of entries to expect from the @rel attribute of the
> > autodiscovery link. If it doesn't use this link then it's violating
> > most common definitions of introspection (which need to be in the
> > context of the resource being introspected), and so we get an
> > ordinary list of links, which is really all we can hope to guess
> > about the client's intentions anyway.
> 
> OK, this seems to be a very clear statement.  What this is saying is
> that one should determine the content type of a resource at a
> particular URI location:
> 
>  * not by its Internet Media Type (application/atom+xml),
>  * not by its XML namespace (http://purl.org/atom/ns#),
>  * not by its element type (namespace+localname), and
>  * not by any other local means indicated within the content
> 
> but rather, solely by the external link property used to reference the
> resource (<link rel="service.feed">).
> 
> That doesn't work past the first time the link is copied to some other
> location, for *any* other purpose (linking, documentation, storage).
> Once the link reference "leaves its home", knowledge of what the
> resource "is" is lost.

More to the point, it violates every best practice detailed in
<http://www.w3.org/2001/tag/doc/mime-respect.html>.  Participants in
this thread who disagree with Ken would do well to read (or re-read)
that document, in particular section 5
<http://www.w3.org/2001/tag/doc/mime-respect.html#specs>, which
explicitly mentions the priority of the HTML link element as compared
to other (possibly conflicting) server-generated metadata.

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Wed Jul 14 10:50: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 KAA21793
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 10:50: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 i6EEh3Qq088602;
	Wed, 14 Jul 2004 07:43:03 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6EEh320088601;
	Wed, 14 Jul 2004 07:43: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 i6EEh2WC088591
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 07:43:03 -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 i6EEhgxl019244;
	Wed, 14 Jul 2004 10:43:42 -0400
Message-ID: <40F5466D.2050903@intertwingly.net>
Date: Wed, 14 Jul 2004 10:42:53 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 Pilgrim <pilgrim@gmail.com>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: New AtomPubIssuesList for 2004/07/14
References: <40E16215.6070507@intertwingly.net> <40EC9915.4050406@intertwingly.net> <40F539FE.7010600@intertwingly.net> <14be96d30407140710490f561a@mail.gmail.com>
In-Reply-To: <14be96d30407140710490f561a@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


Mark Pilgrim wrote:

> On Wed, 14 Jul 2004 09:49:50 -0400, Sam Ruby <rubys@intertwingly.net> wrote:
> 
>>http://www.intertwingly.net/wiki/pie/AtomPubIssuesList
> 
> PaceShouldBeWellFormed has been withdrawn.  PaceMustBeWellFormed
> received no dissent (just one clarification).  I recommend we include
> it in -01.

Thanks.  I've added PaceShouldBeWellFormed.  I have some comments about 
PaceMustBeWellFormed that I will make in a separate email.

- Sam Ruby




From owner-atom-syntax@mail.imc.org  Wed Jul 14 10:54: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 KAA21943
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 10:54: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 i6EEidPH089259;
	Wed, 14 Jul 2004 07:44: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 i6EEidwC089257;
	Wed, 14 Jul 2004 07:44: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 i6EEibXl089025
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 07:44:38 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 15 Jul 2004 00:49:15 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Thu, 15 Jul 2004 00:43:59 +1000
Subject: Re: PaceEntryIdRequired
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD1B83CF.1FA92%eric.scheid@ironclad.net.au>
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


> The "atom:id" element's content conveys a permanent, globally unique
> identifier for the entry. It 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.
> 
ok so far...

> If the same entry is syndicated in two atom:feeds published by the same
> entity, the entry's atom:id MUST be the same in both feeds. atom:entry MUST
> contain an atom:id element, but MUST NOT contain more than one. The content of
> this element, when present, MUST be a URI.
> 

(1) clarification please: if the same entry is syndicated in other
atom:feeds published by NOT the same entity ... does the atom:id remain the
same? I would hope so ... can we reword to this?

    If the same entry is syndicated in more than one atom:feed
    the entry's atom:id MUST be the same in all those atom:feeds.

(2) editorial: strike "when present" from last sentence, since it will
always be present since it is now required ;-)

(3) detour: would it be better if <id> was instead @id on <entry>?

e.



From owner-atom-syntax@mail.imc.org  Wed Jul 14 10:58: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 KAA22060
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 10:58: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 i6EEnFxq091050;
	Wed, 14 Jul 2004 07:49: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 i6EEnFul091049;
	Wed, 14 Jul 2004 07:49: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 (mproxy.gmail.com [216.239.56.249])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6EEnECl091042
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 07:49:14 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so163807cwc
        for <atom-syntax@imc.org>; Wed, 14 Jul 2004 07:49:17 -0700 (PDT)
Received: by 10.11.99.56 with SMTP id w56mr24438cwb;
        Wed, 14 Jul 2004 07:49:17 -0700 (PDT)
Message-ID: <3f1451f50407140749f045eb@mail.gmail.com>
Date: Wed, 14 Jul 2004 10:49:17 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Ken MacLeod <ken@bitsko.slc.ut.us>
Subject: Re: PaceIntrospection: New Examples for Feed-Based Introspection
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <m3u0walm7v.fsf@bitsko.slc.ut.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <40F52038.4050101@spoonybards.net> <m3u0walm7v.fsf@bitsko.slc.ut.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 14 Jul 2004 09:03:48 -0500, Ken MacLeod <ken@bitsko.slc.ut.us> wrote: 
> OK, this seems to be a very clear statement.  What this is saying is
> that one should determine the content type of a resource at a
> particular URI location:
> 
>  * not by its Internet Media Type (application/atom+xml),
>  * not by its XML namespace (http://purl.org/atom/ns#),
>  * not by its element type (namespace+localname), and
>  * not by any other local means indicated within the content
> 
> but rather, solely by the external link property used to reference the
> resource (<link rel="service.feed">).
> 
> That doesn't work past the first time the link is copied to some other
> location, for *any* other purpose (linking, documentation, storage).
> Once the link reference "leaves its home", knowledge of what the
> resource "is" is lost.

+1 

The indication of the type of content needs to be provided
by either the media type or the  root element name (
localname + namespace), and introspection is a 
different kind of content than a feed.

   -joe



From owner-atom-syntax@mail.imc.org  Wed Jul 14 11: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 LAA22324
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 11: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 i6EElw1K090573;
	Wed, 14 Jul 2004 07:47:58 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6EElwPC090572;
	Wed, 14 Jul 2004 07:47: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 i6EEluF7090555
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 07:47:57 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 15 Jul 2004 00:53:02 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Thu, 15 Jul 2004 00:47:45 +1000
Subject: Re: PaceLang
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD1B84B1.1FA94%eric.scheid@ironclad.net.au>
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


> Add support for the xml:lang special attribute to all the relevant Atom
> elements. From the current draft, it seems enough to specify xml:lang on the
> Content Construct

what about @title in <link> constructs?

e.

(assuming they'll remain)



From owner-atom-syntax@mail.imc.org  Wed Jul 14 11:02: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 LAA22373
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 11:02: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 i6EEqom7092574;
	Wed, 14 Jul 2004 07:52:50 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6EEqohY092573;
	Wed, 14 Jul 2004 07:52: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 (mproxy.gmail.com [216.239.56.244])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6EEqobS092535
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 07:52:50 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so165643cwc
        for <atom-syntax@imc.org>; Wed, 14 Jul 2004 07:52:47 -0700 (PDT)
Received: by 10.11.99.41 with SMTP id w41mr24901cwb;
        Wed, 14 Jul 2004 07:52:47 -0700 (PDT)
Message-ID: <3f1451f50407140752519a0292@mail.gmail.com>
Date: Wed, 14 Jul 2004 10:52:47 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Tim Bray <tim.bray@sun.com>
Subject: Re: Work Queue Rotation #3
Cc: Atomlist Syntax <atom-syntax@imc.org>
In-Reply-To: <4005DCF4-D55C-11D8-A6EC-000A95A51C9E@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <4005DCF4-D55C-11D8-A6EC-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 Tue, 13 Jul 2004 23:08:39 -0700, Tim Bray <tim.bray@sun.com> wrote:
> 3. PaceSecurityServices
> 
> Paul writes: "There was agreement that we want Digest Auth as a SHOULD
> (not a MUST), not to give a SHOULD for the WSSE-like mechanism, and not
> to describe it in the core protocol document. Hopefully, someone
> describes at least one other auth mechanism for Atom, and if the WG
> likes that, we will point to that as a SHOULD as well."
> 
> Question to Joe/Rob: is that enough direction for the editors of the
> protocol draft to run with?  If not, you might want to huddle with the
> Security wonks like Paul and MarkP to figure out what should go in the
> -01.

I think there is enough there to put something in -01. We can
always change it later.

   -joe



From owner-atom-syntax@mail.imc.org  Wed Jul 14 11:06: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 LAA22714
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 11:06: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 i6EEuk4F094252;
	Wed, 14 Jul 2004 07:56:47 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6EEukJX094251;
	Wed, 14 Jul 2004 07:56:46 -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 i6EEukvc094211
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 07:56:46 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040714145637.6292.qmail@web41215.mail.yahoo.com>
Received: from [24.18.129.247] by web41215.mail.yahoo.com via HTTP; Wed, 14 Jul 2004 07:56:37 PDT
Date: Wed, 14 Jul 2004 07:56:37 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: a methodical approach to defining what date  elements we need
To: Sam Ruby <rubys@intertwingly.net>
Cc: Atom-syntax Syntax <atom-syntax@imc.org>
In-Reply-To: <40F5458F.4030202@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:
> 
> So, if you 
> will bear with me, let's take a look at the
> following together:
> 
> http://www.livejournal.com/update.bml?mode=full
>
http://help.blogger.com/bin/answer.py?answer=139&topic=17
> http://www.movabletype.org/features.shtml
> http://journurl.com/?entry=1007&template=upgrade
> 
> In the latter two look for text like and "Movable
> Type allows you to set 
> a post's date stamp to any date or time you wish,
> for pre-dating or 
> post-dating information when it goes live.", and
> "Pre- and post-date 
> entries"
> 
> If we deny this information a home, it will simply
> find one of its own 
> accord.

I would categorize the features described at those
links differently from how you described the date
field. It seems MovableType and other tools allow you
to control something that maps to the 'issued' date of
the entry. 

I sincerely doubt that any of these tool vendors would
want to make the distinction between issued and the
user entered date. I might be wrong so I'd love to get
their opinions. If I go with your descriptions, then
Atom needs 3 dates (last modified, created & bogus
user entered date). As an aggregator author I'd always
ignore the last one. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


	
		
__________________________________
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 Jul 14 11:11: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 LAA23191
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 11:11: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 i6EExONb095361;
	Wed, 14 Jul 2004 07:59:24 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6EExN4C095358;
	Wed, 14 Jul 2004 07:59:23 -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 i6EExNH7095311
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 07:59:23 -0700 (PDT)
	(envelope-from antone@geckotribe.com)
Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134])
          by comcast.net (rwcrmhc11) with SMTP
          id <20040714145920013003g9nte>; Wed, 14 Jul 2004 14:59:21 +0000
Date: Wed, 14 Jul 2004 08:59:20 -0600
Subject: Re: a methodical approach to defining what date  elements we need
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: <40F50909.3060306@intertwingly.net>
Message-Id: <62BB74BC-D5A6-11D8-AE1C-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


Things the following list does not include:

1) A date of first issuance.  Having thought about it a little more, I 
don't see a particular need for it.  If you do, speak up.

2) A date of the most recent minor change (anything not reflected in 
Updated).  I'd like to see this in the format for the following reasons:

	a) The user should have the choice of having their feed reader flag 
minor changes as well as major.
	b) Similarly, software that republishes feeds might want to be aware 
of all minor changes so that it can update the data it is publishing 
when changes are made. Depending on the process, it may be able to 
simply overwrite old data, even if not changed. But if the process of 
replacing old data is laborious (for example, pushing updates out to 
multiple clients), being able to determine when minor updates have been 
made becomes important.
	c) Finally, the point without which a) and b) wouldn't matter 
much--detecting minor changes will be much simpler if it only requires 
checking a date stamp than if the feed reader has to compare all of the 
data in the entry to what it has cached.

One could certainly get by without it, but I'd like to have that date 
stamp in the format.

On Wednesday, July 14, 2004, at 04:20  AM, Sam Ruby wrote:
> Date 1: Updated
>
> This date is meant to be a machine generated timestamp indicating when 
> the most recent substantive change has been made to the entry.
>
> One should be able to depend on this field for sorting purposes, and 
> to depend on it to identify if the current version of this content of 
> this entry has been (substantially) seen before.
>
> In theory, this field can be updated independent of the content, but 
> in practice that is rarely done.  Updating the content without 
> updating this field would be with the intent of not drawing attention 
> a change that was made.

+1.  As was pointed out to me (off list, I think), I had "updated" and 
"modified" backwards.  I agree with this usage of "updated".

> While time zone information may be present on this field, it is not of 
> any primary importance.

-1.  I don't see any reason not to require timezone info in all dates, 
as long as -00:00 (unknown) is allowed.

> Date 2: Display
>
> This date is effectively a user entered date.  It means whatever the 
> user wants it to mean.  It can be fictitious, it can be in the future. 
> It can even be fanciful (Samuel Pepsys comes to mind).
>
> This date is effectively part of the content.  Accordingly, if the 
> display timestamp changes, the updated timestamp should also change.

+1.

> We could define it as a string, but an ability to internationalize and 
> search on this field is desirable.  One would rarely sort on this 
> field.  Having an ability to express perceived relative local time in 
> this field is also desirable.

-1 on defining it as a string.  If someone wants to indicate "Written 
during Ramadan" or something, I'd think that would belong with the rest 
of the content in <content>.  Needing a date field for free-form 
expressions feels like an edge case to me.

> Date 3: Created
>
> Another machine generated timestamp, indicating when the entry was 
> first created.
>
> This field is not intended for significantly used by an aggregator.  
> It came into being simply because the first three blog vendors I 
> happened to talk to identified this as a common piece of information 
> that they all track.  If it truly turns out to be a relatively common 
> concept, then assigning it a common name is desirable from a tool 
> migration point of view.
>
> If, on the other hand, this field does not survive the standardization 
> process, then so be it.

+1  I certainly have no objection to having a creation date in the 
format, but I don't see it being of much use except for things like 
tool migration.  That's enough reason to allow it.  Certainly don't 
require it.

> Separate from all this is the ability of multiple entries to be 
> related.  One certainly can create new entries which were based on 
> another entry.  Capturing this relationship in the format is a 
> desirable thing.
>
> A few things to note, however.  Such new entries are separate and 
> distinct from the original.  They would have new ids.  When displaying 
> items from a feed, one would expect to see both the original and new 
> items separately listed.  The original could continue to be updated 
> independently after the new item was created.

+1 -- as long as people are free to make substantial modifications (and 
signal them through a date change) without being required to call it a 
new entry--as it would be with the above definition of "updated", then 
yes, this is desirable.



From owner-atom-syntax@mail.imc.org  Wed Jul 14 11:17: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 LAA23502
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 11:17: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 i6EF8Buq098935;
	Wed, 14 Jul 2004 08:08: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 i6EF8BHR098934;
	Wed, 14 Jul 2004 08:08:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web41505.mail.yahoo.com (web41505.mail.yahoo.com [66.218.93.88])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6EF8A3K098891
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 08:08:10 -0700 (PDT)
	(envelope-from randymorin@yahoo.com)
Message-ID: <20040714150808.23244.qmail@web41505.mail.yahoo.com>
Received: from [66.46.139.106] by web41505.mail.yahoo.com via HTTP; Wed, 14 Jul 2004 08:08:08 PDT
Date: Wed, 14 Jul 2004 08:08:08 -0700 (PDT)
From: Randy Charles Morin <randymorin@yahoo.com>
Reply-To: randy@kbcafe.com
Subject: PaceAutoDisco
To: Atomlist <atom-syntax@imc.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-2006048722-1089817688=:22600"
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>


--0-2006048722-1089817688=:22600
Content-Type: text/plain; charset=us-ascii

I posted for discussion [1], there was no objection in my pointing to Mark's RFC, so I assume the associated comment [2] holding it back is no longer relevant and that this Pace [3] can be moved forward.
Thanks,
 
Randy
http://www.kbcafe.com
 
[1] http://www.imc.org/atom-syntax/mail-archive/msg06293.html
[2] http://www.intertwingly.net/wiki/pie/AtomPubIssuesList
[3] http://www.intertwingly.net/wiki/pie/PaceAutoDisco

		
---------------------------------
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
--0-2006048722-1089817688=:22600
Content-Type: text/html; charset=us-ascii

<DIV>I posted for discussion [1], there was no objection in my pointing to Mark's RFC, so I assume the associated comment [2] holding it back is no longer relevant and that this Pace [3]&nbsp;can&nbsp;be moved forward.</DIV>
<DIV>Thanks,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Randy</DIV>
<DIV><A href="http://www.kbcafe.com">http://www.kbcafe.com</A></DIV>
<DIV>&nbsp;</DIV>
<DIV>[1] <A href="http://www.imc.org/atom-syntax/mail-archive/msg06293.html">http://www.imc.org/atom-syntax/mail-archive/msg06293.html</A></DIV>
<DIV>[2] <A href="http://www.intertwingly.net/wiki/pie/AtomPubIssuesList">http://www.intertwingly.net/wiki/pie/AtomPubIssuesList</A></DIV>
<DIV>[3] <A href="http://www.intertwingly.net/wiki/pie/PaceAutoDisco">http://www.intertwingly.net/wiki/pie/PaceAutoDisco</A></DIV><p>
		<hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/mail_us/taglines/10/*http://promotions.yahoo.com/new_mail/static/efficiency.html">New and Improved Yahoo! Mail</a> - Send 10MB messages!
--0-2006048722-1089817688=:22600--



From owner-atom-syntax@mail.imc.org  Wed Jul 14 11:18:53 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23576
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 11:18: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 i6EF9a5d099561;
	Wed, 14 Jul 2004 08: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 i6EF9aws099559;
	Wed, 14 Jul 2004 08:09:36 -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 i6EF9aa0099515
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 08:09: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 (rwcrmhc11) with SMTP
          id <20040714150933013003g6ppe>; Wed, 14 Jul 2004 15:09:34 +0000
Date: Wed, 14 Jul 2004 09:09:33 -0600
Subject: Re: PaceLang
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: <BD1B84B1.1FA94%eric.scheid@ironclad.net.au>
Message-Id: <D02C373E-D5A7-11D8-AE1C-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 Wednesday, July 14, 2004, at 08:47  AM, Eric Scheid wrote:
>> Add support for the xml:lang special attribute to all the relevant 
>> Atom
>> elements. From the current draft, it seems enough to specify xml:lang 
>> on the
>> Content Construct
>
> what about @title in <link> constructs?

That brings up an argument in favor of <link ...>put the title 
here</link> (or <linkConstructOfSomeOtherName ...>title 
here</linkConstructOfSomeOtherName>.  With that arrangement, it would 
be perfectly clear that xml:lang applies to the title.



From owner-atom-syntax@mail.imc.org  Wed Jul 14 11: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 LAA24739
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 11: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 i6EFVtmC009953;
	Wed, 14 Jul 2004 08: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 i6EFVtQC009952;
	Wed, 14 Jul 2004 08:31:55 -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 i6EFVt8I009906
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 08:31:55 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040714153153.98934.qmail@web41201.mail.yahoo.com>
Received: from [24.18.129.247] by web41201.mail.yahoo.com via HTTP; Wed, 14 Jul 2004 08:31:53 PDT
Date: Wed, 14 Jul 2004 08:31:53 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: a methodical approach to defining what date  elements we need
To: Antone Roundy <antone@geckotribe.com>, atom-syntax@imc.org
In-Reply-To: <62BB74BC-D5A6-11D8-AE1C-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:
> 
> 
> 2) A date of the most recent minor change (anything
> not reflected in 
> Updated).  I'd like to see this in the format for
> the following reasons:

What is the difference between a minor change and a
major change? Are publishing tools now supposed to
have heuristics that detect when the user fixes a typo
versus adds two new paragraghs to a post? Is the user
supposed to make this distinction themselves? 

What tool vendor has asked for this functionality or
has claimed this functionality makes their job easier? 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
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 Jul 14 11:50: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 LAA24903
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 11: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 i6EFckBi012954;
	Wed, 14 Jul 2004 08:38:46 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6EFckmo012953;
	Wed, 14 Jul 2004 08:38: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-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 i6EFcjhF012943
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 08:38:46 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from phys-bur-1 ([129.148.9.72])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6EFcmil002326
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 09:38:48 -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 <0I0U00201LWP2E@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com)
 for atom-syntax@imc.org; Wed, 14 Jul 2004 11:38:48 -0400 (EDT)
Received: from mercury (vpn-129-150-33-64.Central.Sun.COM [129.150.33.64])
 by bur-mail1.east.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
 with ESMTP id <0I0U003PQM4N54@bur-mail1.east.sun.com> for atom-syntax@imc.org;
 Wed, 14 Jul 2004 11:38:48 -0400 (EDT)
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1Bklq6-0004t2-00	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 11:38:34 -0400
X-URL: http://nwalsh.com/
Date: Wed, 14 Jul 2004 11:38:32 -0400
From: Norman Walsh <ndw@nwalsh.com>
Subject: Re: Low-hanging fruit: compulsory namespaces
In-reply-to: <40F5415E.5070100@dehora.net>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <87k6x6mwef.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: <6D6BAC41-D517-11D8-8C42-000A95A51C9E@sun.com>
 <40F46DAC.3030900@dehora.net> <D4AC57AE-D527-11D8-A503-000A95A51C9E@sun.com>
 <40F48A82.2020408@dehora.net> <3F81CFBF-D59D-11D8-A6EC-000A95A51C9E@sun.com>
 <40F5415E.5070100@dehora.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-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

/ Bill de h=D3ra <bill@dehora.net> was heard to say:
| Tim Bray wrote:
|
|> I went back and reviewed the examples, and I totally disagree.  They
|> really are the same, and any chain of processing software that makes
|> them come out different is severely buggy, and I don't think
|> bugginess at that level is prevalent in widely-used XML-processing
|> tools.
|
| Ok, I won't dispute that re deployed processor behaviour. But I went
| back and reread the 1.1 Namespaces spec today and I didn't see where
| behaving the way you and Norm say they should not is considered a
| processing error. Seriously, did I miss it?

I'm not actually sure what you're asking. Given this document

  <atom:feed xmlns:atom=3D"http://example.org/atom">
    <atom:content mode=3D"xml">
      <no-ns>Non-namespaced element</no-ns>
    </atom:content>
  </atom:feed>

What transformation do you think should be valid that you believe
I think is not valid?

                                        Be seeing you,
                                          norm

=2D-=20
Norman Walsh <ndw@nwalsh.com> | In great affairs men show themselves as
http://nwalsh.com/            | they wish to be seen, in small things
                              | they show themselves as they are.--
                              | Chamfort

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA9VN6OyltUcwYWjsRAiKfAKCOrIUnjrPDAITE7wQFwoYkIZQr6wCgnFBP
rLPOxknzcIJnqUk7SlIFk2w=
=bKAY
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Wed Jul 14 11: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 LAA25244
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 11: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 i6EFmLmA016906;
	Wed, 14 Jul 2004 08:48: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 i6EFmLaC016905;
	Wed, 14 Jul 2004 08:48:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from aaryn.lunarpages.com (aaryn.lunarpages.com [216.193.194.222])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EFmK02016855
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 08:48:20 -0700 (PDT)
	(envelope-from sah@428cobrajet.net)
Received: from h87.s239.netsol.com ([216.168.239.87] helo=dul1shollenbl1)
	by aaryn.lunarpages.com with asmtp (TLSv1:RC4-MD5:128)
	(Exim 4.34)
	id 1BklzX-0002Qx-No
	for atom-syntax@imc.org; Wed, 14 Jul 2004 08:48:19 -0700
From: "Scott Hollenbeck" <sah@428cobrajet.net>
To: "'Atom Syntax'" <atom-syntax@imc.org>
Subject: RE: Low-hanging fruit: compulsory namespaces
Date: Wed, 14 Jul 2004 11:48:50 -0400
Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF02E0F6B0@vsvapostal8.vcorp.ad.vrsn.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
In-Reply-To: <87k6x6mwef.fsf@nwalsh.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - aaryn.lunarpages.com
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - 428cobrajet.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


If I may, another "earlier IETF work" pointer that discusses XML namespaces:

ftp://ftp.rfc-editor.org/in-notes/rfc3688.txt

This "best current practice" RFC talks about URIs used in IETF standards to
identify XML namespaces.

-Scott-



From owner-atom-syntax@mail.imc.org  Wed Jul 14 12:04: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 MAA25549
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 12:04:10 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EFo8Ws017673;
	Wed, 14 Jul 2004 08:50: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 i6EFo8s2017672;
	Wed, 14 Jul 2004 08:50: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.45])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EFo7Tb017664
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 08:50:07 -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 i6EFoAAv022325;
	Wed, 14 Jul 2004 08:50:10 -0700 (PDT)
Received: from [192.168.1.100] (h00080d858303.ne.client2.attbi.com [24.61.1.243])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id i6EFo3LG020097;
	Wed, 14 Jul 2004 08:50:07 -0700 (PDT)
In-Reply-To: <40F50909.3060306@intertwingly.net>
References: <BD1995C2.1F3C6%eric.scheid@ironclad.net.au> <opsa2k75lz6dxgxk@mail.online.no> <CFCD3EC6-D4BA-11D8-82B1-000A95DC3D90@mac.com> <40F3CC36.9080001@intertwingly.net> <7C832F0A-D4D2-11D8-82B1-000A95DC3D90@mac.com> <40F3F09F.4070602@intertwingly.net> <50540F00-D4F5-11D8-82B1-000A95DC3D90@mac.com> <40F50909.3060306@intertwingly.net>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--156148259; protocol="application/pkcs7-signature"
Message-Id: <773AD86F-D5AD-11D8-B24C-000A95DC3D90@mac.com>
Cc: Atom-syntax Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: a methodical approach to defining what date  elements we need
Date: Wed, 14 Jul 2004 11:50:01 -0400
To: Sam Ruby <rubys@intertwingly.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-2--156148259
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 14 Jul 2004, at 6:20 am, Sam Ruby wrote:

> Date 1: Updated

> One should be able to depend on this field for sorting purposes, and 
> to depend on it to identify if the current version of this content of 
> this entry has been (substantially) seen before.

You word this as if you want all publishers to update the field when 
they make substantive changes, and that not updating the field means 
the changes aren't important. Is that correct?

> Date 2: Display
>
> We could define it as a string, but an ability to internationalize and 
> search on this field is desirable.  One would rarely sort on this 
> field.  Having an ability to express perceived relative local time in 
> this field is also desirable.

-1 to string - I want to be able to reformat it.

> A few things to note, however.  Such new entries are separate and 
> distinct from the original.  They would have new ids.  When displaying 
> items from a feed, one would expect to see both the original and new 
> items separately listed.  The original could continue to be updated 
> independently after the new item was created.

So when there's a 1:1 relationship, we use the same id? Fantastic.

Graham
--Apple-Mail-2--156148259
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
9w0BCQUxDxcNMDQwNzE0MTU1MDAxWjAjBgkqhkiG9w0BCQQxFgQUCx9bKqOhhYkIUGQfRO1oOfum
ejwweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAK1UnGyWAopyRLQmVK89Dmweg
qetY3vcSlJ+7a8kMZeTVihdho0WUTmEpLm1414I6Fu/k6/dzBb+ufC9yufdGW1DLp8ZXs7WQQwos
dISkTFx4TR93GEi0nmgqcjVCY2EnL+NFbqaSySzEYNQm5OkoQYjiAVs0QsO5/o6KPl562Q/3vxfl
9shFV9TXXIZWJsB2YN+zDa3sMfbfVYipc8UI07aSbhxbKiEHPeYmA8Dpl1RWc8usMVxHb8qt5L6g
SI4EfN+ee90+tYfJMhoLAXE6DQc3ugIDaoLz+E7IJW0uujhOl2NGiGD5VaCBMF6M3TqXvalmF7VR
Z0ha3Iutsl+ODQAAAAAAAA==

--Apple-Mail-2--156148259--



From owner-atom-syntax@mail.imc.org  Wed Jul 14 12:06: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 MAA25622
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 12:06:47 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EFjBWT015574;
	Wed, 14 Jul 2004 08: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 i6EFjBM6015573;
	Wed, 14 Jul 2004 08:45:11 -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 i6EFjAYl015550
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 08:45:10 -0700 (PDT)
	(envelope-from lists@internetalchemy.org)
Received: (qmail 76278 invoked from network); 14 Jul 2004 15:45:06 -0000
Received: from host81-130-162-88.in-addr.btopenworld.com (HELO ?192.168.254.19?) (81.130.162.88)
  by relay.pair.com with SMTP; 14 Jul 2004 15:45:06 -0000
X-pair-Authenticated: 81.130.162.88
Message-ID: <40F55500.7080809@internetalchemy.org>
Date: Wed, 14 Jul 2004 16:45:04 +0100
From: Ian Davis <lists@internetalchemy.org>
User-Agent: Mozilla Thunderbird 0.7a (Windows/20040614)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Usage Scenarios for Versioning and Extensibility
References: <20040712214722.79750.qmail@web41212.mail.yahoo.com> <AA8D7D00-D461-11D8-AFCB-000A95BD86C0@mnot.net>
In-Reply-To: <AA8D7D00-D461-11D8-AFCB-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: <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:

 > I'd like to make this a bit more concrete.


I think some, maybe all, of these could be handled using OWL constructs.

 >
 > 1) And it was good... except for that nasty atom:title element; after 
wide deployment experience, it's agreed we need a new version of it. So, 
a new version of Atom is introduced. The new one isn't 
backwards-compatible with the old one.


Create a new namespace with copies of all elements. Write an OWL schema 
that declares all elements except atom:title to be owl:equivalentClass 
or owl:equivilentProperty to the relevant element in the in Atom 1.0 
namespace.

Consumers use the schema to define rules in their applications, either 
dynamically or just by hard coding them after readint the schema. When 
the application looks  for particular elements it must also look for 
those that have been declared equivilent to the element they need.

Use owl:DeprecatedClass or owl:DeprecatedProperty to declare that 
previous atom:title has been retired.

Use owl:incompatibleWith on the schema to declare that new version of 
Atom is not backwards compatible. Consumers now should be aware that 
semantics of Atom may have changed.

 >
 > 2) Then, we decide we want to add a new metadata element, let's call 
it "fog." So, a new version of Atom is introduced.


An addition of an optional element is a non-breaking change so add it to 
current namespace. Use owl:backwardCompatibleWith to declare that new 
version of Atom is in every respect backwards compatible.

If element is non-optional, it's a breaking change so use 
owl:incompatibleWith instead.

 > 3) After a while, someone comes up with a souped-up version of 
atom:title that is backwards-compatible, just *better*. It gets really 
popular, and yet another version of Atom is born.


Create a new namespace. Declare all equivilent elements in the same way 
as scenario 1. Declare oldatom:title to be a subClassOf newatom:title, 
i.e. every oldatom:title is a newatom:title but not every newatom:title 
is an oldatom:title since the new one is *better*.

Use owl:backwardCompatibleWith on the schema to declare that new version 
of Atom is in every respect backwards compatible.

 > 4) At the same time, a group of rogue Open Source Software 
programmers descends upon this idyllic scene and introduces its own 
extensions. Up until now, all of our extensions have been approved and 
incorporated by the WG, but these are destined to remain separate.


They create a new namespace and their own OWL schema. They're free to 
subclass or equate any elements they want.

 > 5) Finally, in 2010, we realise that the Atom feed and entry 
containers aren't really doing the job, and we need to change their 
model. Yet Another Version of Atom (YAVA) comes into being.


New namespace, new OWL schema. Use owl:incompatibleWith.

Just one way to do it I'm sure.

Ian




From owner-atom-syntax@mail.imc.org  Wed Jul 14 12:13:47 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26079
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 12:13: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 i6EFsYC0019680;
	Wed, 14 Jul 2004 08:54:34 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6EFsYoI019679;
	Wed, 14 Jul 2004 08:54:34 -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 i6EFsXZq019651
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 08:54: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 (sccrmhc13) with SMTP
          id <2004071415543101600bho5ve>; Wed, 14 Jul 2004 15:54:31 +0000
Date: Wed, 14 Jul 2004 09:54:30 -0600
Subject: Re: a methodical approach to defining what date  elements we need
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: <20040714153153.98934.qmail@web41201.mail.yahoo.com>
Message-Id: <17C1D85C-D5AE-11D8-AE1C-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 Wednesday, July 14, 2004, at 09:31  AM, Dare Obasanjo wrote:
> --- Antone Roundy <antone@geckotribe.com> wrote:
>> 2) A date of the most recent minor change (anything
>> not reflected in
>> Updated).  I'd like to see this in the format for
>> the following reasons:
>
> What is the difference between a minor change and a
> major change? Are publishing tools now supposed to
> have heuristics that detect when the user fixes a typo
> versus adds two new paragraghs to a post? Is the user
> supposed to make this distinction themselves?

On Wednesday, July 14, 2004, at 08:05  AM, Dare Obasanjo wrote:
> On Wednesday, July 14, 2004, at 04:20  AM, Sam Ruby wrote:
>> Date 1: Updated
>>
>> This date is meant to be a machine generated
>> timestamp indicating when
>> the most recent substantive change has been made to
>> the entry.
>
> + 1

If the "updated" date is only updated for substantive changes, then the 
distinction already has to be made somehow.

> What tool vendor has asked for this functionality or
> has claimed this functionality makes their job easier?
I don't know if anyone else has, but in the next version of one of my 
products, which is going to have this functionality, it would make it a 
lot easier for me.



From owner-atom-syntax@mail.imc.org  Wed Jul 14 12: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 MAA26488
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 12:23: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 i6EFxaHg020844;
	Wed, 14 Jul 2004 08:59: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 i6EFxagu020843;
	Wed, 14 Jul 2004 08:59:36 -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 i6EFxZsH020825
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 08:59:36 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 60843 messnum 2585362 invoked from network[83.70.39.115/83-70-39-115.bas2.prp.dublin.eircom.net]); 14 Jul 2004 15:59:32 -0000
Received: from 83-70-39-115.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.39.115)
  by mail08.svc.cra.dublin.eircom.net (qp 60843) with SMTP; 14 Jul 2004 15:59:32 -0000
Message-ID: <40F55860.7000800@dehora.net>
Date: Wed, 14 Jul 2004 16:59:28 +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: Low-hanging fruit: compulsory namespaces
References: <6D6BAC41-D517-11D8-8C42-000A95A51C9E@sun.com> <40F46DAC.3030900@dehora.net> <D4AC57AE-D527-11D8-A503-000A95A51C9E@sun.com> <40F48A82.2020408@dehora.net> <3F81CFBF-D59D-11D8-A6EC-000A95A51C9E@sun.com> <40F5415E.5070100@dehora.net> <87k6x6mwef.fsf@nwalsh.com>
In-Reply-To: <87k6x6mwef.fsf@nwalsh.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


Norman Walsh wrote:

> I'm not actually sure what you're asking. Given this document
> 
>   <atom:feed xmlns:atom="http://example.org/atom">
>     <atom:content mode="xml">
>       <no-ns>Non-namespaced element</no-ns>
>     </atom:content>
>   </atom:feed>
> 
> What transformation do you think should be valid that you believe
> I think is not valid?

I'm not sure what you mean. To me, this is not about what I think 
about valid transformations in and out of default namespaces. It's 
about whether those transformations are specified.

Honestly, in the absence of being to point at normative text and say 
  'clown, your processing is broken', I would expect an utterance 
along the lines of 'inside Atom, you SHOULD qualify your 
non-namespace markup with xmlns=""' to aid robustness and increase 
happiness all round. I'm backing down from MUST since you and Tim 
have pointed out this is buggy behaviour for tools, my mistake. But 
there are plenty of people rolling their own with namespaces out 
there. Saying SHOULD around xmlns="" qualification is not specifying 
bad practice, is not constraining to those who practice well, is not 
subsetting existing 'legal' processing. But it is a useful thing to 
say and I don't believe for a second it's micro-management.

Does that make sense?

cheers
Bill



From owner-atom-syntax@mail.imc.org  Wed Jul 14 12:27: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 MAA26731
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 12:27: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 i6EGHQn1024529;
	Wed, 14 Jul 2004 09: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 i6EGHQ7H024527;
	Wed, 14 Jul 2004 09:17:26 -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 i6EGHNvX024490
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 09:17:25 -0700 (PDT)
	(envelope-from roger@agincourtmedia.com)
Received: from biggreen ([216.63.148.42]) by journurl.com with MailEnable ESMTP; Wed, 14 Jul 2004 11:16:38 -0500
From: "Roger B." <roger@agincourtmedia.com>
To: "'Dare Obasanjo'" <kpako@yahoo.com>
Cc: "'Atom-syntax Syntax'" <atom-syntax@imc.org>
Subject: RE: a methodical approach to defining what date  elements we need
Date: Wed, 14 Jul 2004 11:18:39 -0500
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: <20040714145637.6292.qmail@web41215.mail.yahoo.com>
thread-index: AcRpss5V0z9MEwY6S4WLquKoWA2pHwACLr8Q
Message-ID: <EC7ABF0E1B344BDB930E4E683C882.MAI@journurl.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


> I sincerely doubt that any of these tool vendors would
> want to make the distinction between issued and the
> user entered date.

Dare: Correct... they're one and the same.

> If I go with your descriptions, then
> Atom needs 3 dates (last modified, created & bogus
> user entered date). As an aggregator author I'd always
> ignore the last one.

There's nothing bogus about the user-defined date. It is *the* authoritative
date for an entry... ignoring it means that entries show up in the
aggregator out of order. Which may not be a problem for a particular type of
user or style of aggregator, but it's something to bear in mind.

OTOH, if you're currently respecting pubDate in RSS feeds, then you don't
even need to do anything new. Sam's display date == pubDate.

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/






From owner-atom-syntax@mail.imc.org  Wed Jul 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 MAA27045
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 12:34: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 i6EGL7BT025358;
	Wed, 14 Jul 2004 09: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 i6EGL7ji025357;
	Wed, 14 Jul 2004 09:21: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-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 i6EGL67L025351
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 09:21:06 -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 i6EGJ353011691
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 10:19: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 <0I0U00I87O396D@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Wed, 14 Jul 2004 10:21:09 -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 <0I0U008JEO38OG@mail.sun.net> for atom-syntax@imc.org; Wed,
 14 Jul 2004 10:21:09 -0600 (MDT)
Date: Wed, 14 Jul 2004 09:21:11 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: a methodical approach to defining what date  elements we need
In-reply-to: <20040714153153.98934.qmail@web41201.mail.yahoo.com>
To: Atom-Syntax Syntax <atom-syntax@imc.org>
Message-id: <D1CE520E-D5B1-11D8-A6EC-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: <20040714153153.98934.qmail@web41201.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 Jul 14, 2004, at 8:31 AM, Dare Obasanjo wrote:

>> 2) A date of the most recent minor change (anything
>> not reflected in
>> Updated).  I'd like to see this in the format for
>> the following reasons:
>
> What is the difference between a minor change and a
> major change? Are publishing tools now supposed to
> have heuristics that detect when the user fixes a typo
> versus adds two new paragraghs to a post? Is the user
> supposed to make this distinction themselves?

+1.  This minor/major thing is an invitation to endless hairsplitting 
disputes.   As a consumer of a feed, I want the provider to know when 
they consider it to have been modified, as a binary condition.  As a 
provider of a feed, I don't want to have to invest cycles agonizing 
over how "major" an update is.  It's a binary decision: is it major 
enough for the change to be reflected in the feed, yes or no.  Without 
a shared definition of what major/minor *means*, this will produce zero 
interoperability. -Tim



From owner-atom-syntax@mail.imc.org  Wed Jul 14 12: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 MAA28348
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 12:51: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 i6EGbZKY027829;
	Wed, 14 Jul 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 i6EGbZvS027828;
	Wed, 14 Jul 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 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 i6EGbYAb027805
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 09:37:34 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040714163733.3235.qmail@web41208.mail.yahoo.com>
Received: from [24.18.129.247] by web41208.mail.yahoo.com via HTTP; Wed, 14 Jul 2004 09:37:33 PDT
Date: Wed, 14 Jul 2004 09:37:33 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: a methodical approach to defining what date  elements we need
To: Antone Roundy <antone@geckotribe.com>, atom-syntax@imc.org
In-Reply-To: <17C1D85C-D5AE-11D8-AE1C-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:
> 
> 
> If the "updated" date is only updated for
> substantive changes, then the 
> distinction already has to be made somehow.

Can you back this up with a list of products and how
they differentiate substantive versus non-substantive
claims instead of speculation. If I have to implement
support for this functionality in RSS Bandit I'd like
some well defined and detailed description of what I'm
supposed to do as opposed to speculation based on
hearsay. 
 
> > What tool vendor has asked for this functionality
> or
> > has claimed this functionality makes their job
> easier?
>
> I don't know if anyone else has, but in the next
> version of one of my 
> products, which is going to have this functionality,
> it would make it a 
> lot easier for me.

What product? What functionality is made much easier
by having last-time-a-typo-was-fixed-date &
last-time-a-major-revision-of-text-was-made-date as
opposed to last-modified-date?


=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
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 Jul 14 12:57: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 MAA28734
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 12:57: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 i6EGexUo028313;
	Wed, 14 Jul 2004 09:40: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 i6EGex9b028312;
	Wed, 14 Jul 2004 09:40: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 i6EGewx6028298
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 09:40: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 i6EGfe1C026293;
	Wed, 14 Jul 2004 12:41:40 -0400
Message-ID: <40F56213.1080305@intertwingly.net>
Date: Wed, 14 Jul 2004 12:40:51 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Antone Roundy <antone@geckotribe.com>
CC: atom-syntax@imc.org
Subject: Re: a methodical approach to defining what date  elements we need
References: <62BB74BC-D5A6-11D8-AE1C-003065EA6144@geckotribe.com>
In-Reply-To: <62BB74BC-D5A6-11D8-AE1C-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:
> 
> -1.  I don't see any reason not to require timezone info in all dates, 
> as long as -00:00 (unknown) is allowed.

Just to be clear (and it is confusing, I was initially confused, and 
undoubtably many more became confused by reading what I initially wrote 
on the subject): -00:00 can not be used to express the concept that 
"lunch will be served at noon on Thursday".

A few things to help clarify this: the difference in time between 
2004-07-14T12:05:00-04:00 and 2004-07-14T16:00:00-00:00 is the same as 
the difference between 2004-07-14T12:05:00-04:00 and 
2004-07-14T16:00:00+00:00, namely 5 minutes.

It is not possible to compute the differences between 
2004-07-14T12:05:00 and 2004-07-14T12:00:00.

2004-07-14T12:00:00-04:00 means "noon, EDT"

2004-07-14T12:00:00+00:00 means "noon, UTC"

2004-07-14T12:00:00-00:00 means "the same point in time as noon, UTC, 
but in an undeclared timezone"

"-00:00" notation is apparently meant to convey the information that 
"this timestamp has been canonicalized to UTC".

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Wed Jul 14 12:59: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 MAA28899
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 12: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 i6EGaN3d027656;
	Wed, 14 Jul 2004 09: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 i6EGaNTE027655;
	Wed, 14 Jul 2004 09:36: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 i6EGaMJQ027640
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 09:36:22 -0700 (PDT)
	(envelope-from djpowell@djpowell.net)
Received: (qmail 68959 invoked from network); 14 Jul 2004 16:36:09 -0000
Received: from localhost.34sp.com (HELO localhost) (127.0.0.1)
  by localhost.34sp.com with SMTP; 14 Jul 2004 16:36:09 -0000
Received: from 194.203.191.188 ([194.203.191.188]) 
	by webmail.djpowell.net (IMP) with HTTP 
	for <davep@djpowell.net@localhost>; Wed, 14 Jul 2004 17:36:09 +0100
Message-ID: <1089822969.40f560f9cd72f@webmail.djpowell.net>
Date: Wed, 14 Jul 2004 17:36:09 +0100
From: David Powell <djpowell@djpowell.net>
To: Sam Ruby <rubys@intertwingly.net>
Cc: Graham <dtcd@mac.com>, Atom-syntax Syntax <atom-syntax@imc.org>
Subject: Re: a methodical approach to defining what date  elements we need
References: <BD1995C2.1F3C6%eric.scheid@ironclad.net.au> <opsa2k75lz6dxgxk@mail.online.no> <CFCD3EC6-D4BA-11D8-82B1-000A95DC3D90@mac.com> <40F3CC36.9080001@intertwingly.net> <7C832F0A-D4D2-11D8-82B1-000A95DC3D90@mac.com> <40F3F09F.4070602@intertwingly.net> <50540F00-D4F5-11D8-82B1-000A95DC3D90@mac.com> <40F50909.3060306@intertwingly.net>
In-Reply-To: <40F50909.3060306@intertwingly.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.2
X-Originating-IP: 194.203.191.188
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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 Sam Ruby <rubys@intertwingly.net>:

I'm only going to comment on the choice of dates, not timezones anything else
that could take away from focus.

> Date 1: Updated
> 
> This date is meant to be a machine generated timestamp indicating when 
> the most recent substantive change has been made to the entry.
> 
> One should be able to depend on this field for sorting purposes, and to 
> depend on it to identify if the current version of this content of this 
> entry has been (substantially) seen before.
> 
> In theory, this field can be updated independent of the content, but in 
> practice that is rarely done.  Updating the content without updating 
> this field would be with the intent of not drawing attention a change 
> that was made.
> 

+1

This corresponds to something similar to the last instance of #2 in Antone’s
list.

I imagine it to be updated for anything more significant than correcting a typo
or formatting problem, such as adding an updated extra paragraph, but that is
up to the publisher of course.

I think that this can coexist with "supercedes" techniques (see the below)

This field would be optional.  We can't specify what is and isn’t a major
change, it depends on the publisher's usage.


> Date 2: Display
> 
> This date is effectively a user entered date.  It means whatever the 
> user wants it to mean.  It can be fictitious, it can be in the future. 
> It can even be fanciful (Samuel Pepsys comes to mind).
> 
> This date is effectively part of the content.  Accordingly, if the 
> display timestamp changes, the updated timestamp should also change.

+1

This corresponds to something similar to #8 in Antone's list.

If a blog was analogous to a paper diary, then this field would correspond to
the page that you write on.  Similar to VJOURNAL's DTSTART date [rfc2445
4.6.3].  Just a date that is associated with an entry.

Could be useful for interoperating with vCalendar agents?

This field should be optional.  It is only appropriate for journal type feeds,
but I think that that is a pretty major use case.

> We could define it as a string, but an ability to internationalize and 
> search on this field is desirable.  One would rarely sort on this field. 

Please make this field machine readable.


> Date 3: Created
> 
> Another machine generated timestamp, indicating when the entry was first 
> created.
> 
> This field is not intended for significantly used by an aggregator.  It 
> came into being simply because the first three blog vendors I happened 
> to talk to identified this as a common piece of information that they 
> all track.  If it truly turns out to be a relatively common concept, 
> then assigning it a common name is desirable from a tool migration point 
> of view.
> 
> If, on the other hand, this field does not survive the standardization 
> process, then so be it.

This corresponds to something similar to #1 on Antone's list.  One use of it is
to allow aggregators to sort entries by creation date, and then notify of
updates in a way other than displaying that item at the top of the list. 

I don't have any strong feelings about whether this should be required or not.



So we have dropped

#4 objective publishing date - This is pretty similar to either objective
creation date or objective major modification date isn't it?

#5 subjective creation date, #6 and #7 subjective modification dates - I think
that the only subjective date worth keeping is the display date.  I can do
without these.

#2 except for the last instance -  Keeping archived modification dates around
without anyway of obtaining the old copies seems pretty useless.  I imagine any
supercedes proposal will come up with something more useful, maybe involving
<link>


#3 objective minor modification stamp.

-1 to dropping this.

Pretty much every data object I can think of keeps a last modified stamp, from
HTTP resources, local files, database rows, vCards and vCalendars.  I think
that it is a mistake to remove this.  Last modified dates are necessary for
things like synchronization.  I think we only need keep the last modification
date though, not the whole history. 

This field should be required if the post has been modified in any way.


> Separate from all this is the ability of multiple entries to be related. 
>   One certainly can create new entries which were based on another 
> entry.  Capturing this relationship in the format is a desirable thing.

Some people are suggesting that it is better to have a supercedes mechanism than
to qualify changes as minor or major.  Technically it may be better, but my
opinion is that a supercedes mechanism imposes a more complex workflow on
publishers than simply allowing them to change existing posts, so I would
prefer it if both "major updates" and "supercedes" were both allowed so that
the publisher can decide what is most suitable.

If people want supercedes instead, then they just don't use the "Updated"
field.


-- 
Dave



From owner-atom-syntax@mail.imc.org  Wed Jul 14 13: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 NAA28958
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 13:00: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 i6EGlcwZ029276;
	Wed, 14 Jul 2004 09:47: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 i6EGlc8d029275;
	Wed, 14 Jul 2004 09:47: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 i6EGlba9029239
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 09:47: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 F15467C0F3; Wed, 14 Jul 2004 19:45:31 +0200 (CEST)
To: "Tim Bray" <tbray@textuality.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Low-hanging fruit: multipart/alternative
References: <A65D9796-D519-11D8-8C42-000A95A51C9E@textuality.com> <14be96d304071317541efca684@mail.gmail.com> <7FBABBD6-D531-11D8-A503-000A95A51C9E@textuality.com> <14be96d304071319181e2bf741@mail.gmail.com> <1393DBDA-D540-11D8-A503-000A95A51C9E@textuality.com>
Message-ID: <opsa4zq3fhuvpchu@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: Wed, 14 Jul 2004 18:50:53 +0200
In-Reply-To: <1393DBDA-D540-11D8-A503-000A95A51C9E@textuality.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Tue, 13 Jul 2004 19:46:58 -0700, Tim Bray <tbray@textuality.com> wrote:

> Could someone take ownership of writing a three-line Pace saying
>
> "Nuke multipart/alternative for substantial cost and lack of a
> compelling use-case."

Done: <url: http://intertwingly.net/wiki/pie/PaceNukeMultipart>.

-- 
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 Jul 14 13:01: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 NAA29108
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 13:01: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 i6EGhWYG028648;
	Wed, 14 Jul 2004 09:43:32 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6EGhWLJ028647;
	Wed, 14 Jul 2004 09:43: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 i6EGhUAs028613
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 09:43:31 -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 7CEF17C0F3; Wed, 14 Jul 2004 19:41:18 +0200 (CEST)
To: "Mark Pilgrim" <pilgrim@gmail.com>, "Tim Bray" <tbray@textuality.com>
Cc: "Atomlist Syntax" <atom-syntax@imc.org>
Subject: Re: Low-hanging fruit: multipart/alternative
References: <A65D9796-D519-11D8-8C42-000A95A51C9E@textuality.com> <14be96d304071317541efca684@mail.gmail.com> <7FBABBD6-D531-11D8-A503-000A95A51C9E@textuality.com> <14be96d304071319181e2bf741@mail.gmail.com>
Message-ID: <opsa4zjznquvpchu@quark>
Date: Wed, 14 Jul 2004 18:46:37 +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: <14be96d304071319181e2bf741@mail.gmail.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Tue, 13 Jul 2004 22:18:12 -0400, Mark Pilgrim <pilgrim@gmail.com> wrote:

> Well, I wasn't at that face-to-face meeting, and I don't recall us
> discussing it on-list.  I wouldn't call it "low-hanging" to nuke it
> permanently.

I agree on the «permanently» part, but removing the current description of  
multipart/alternative would imho be a good thing. If we come up with some  
brilliant solution in the future, we can always just squeeze that into the  
specification, right?

-- 
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 Jul 14 13:01: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 NAA29220
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 13:01:38 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EGnZ7N029637;
	Wed, 14 Jul 2004 09: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 i6EGnZjp029636;
	Wed, 14 Jul 2004 09:49:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EGnYcC029630
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 09:49: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 i6EGncil018533
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 10:49:38 -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 <0I0U003CBPEPOB@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Wed, 14 Jul 2004 10:49:38 -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 <0I0U008MJPEOUQ@mail.sun.net> for atom-syntax@imc.org; Wed,
 14 Jul 2004 10:49:37 -0600 (MDT)
Date: Wed, 14 Jul 2004 09:49:39 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Low-hanging fruit: compulsory namespaces
In-reply-to: <40F55860.7000800@dehora.net>
To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>
Cc: Atom Syntax <atom-syntax@imc.org>
Message-id: <CC364146-D5B5-11D8-A6EC-000A95A51C9E@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.618)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
References: <6D6BAC41-D517-11D8-8C42-000A95A51C9E@sun.com>
 <40F46DAC.3030900@dehora.net> <D4AC57AE-D527-11D8-A503-000A95A51C9E@sun.com>
 <40F48A82.2020408@dehora.net> <3F81CFBF-D59D-11D8-A6EC-000A95A51C9E@sun.com>
 <40F5415E.5070100@dehora.net> <87k6x6mwef.fsf@nwalsh.com>
 <40F55860.7000800@dehora.net>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6EGnZcC029631
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 Jul 14, 2004, at 8:59 AM, Bill de hÓra wrote:

> I would expect an utterance along the lines of 'inside Atom, you 
> SHOULD qualify your non-namespace markup with xmlns=""' to aid 
> robustness and increase happiness all round.

Hmm... maybe I'm unusually lucky but I just haven't been bitten by 
things going wrong in this space, and I think I use a reasonably 
vanilla selection of XML tools.  So I'm still uncomfortable with 
putting it in an RFC.  On the other hand, if Bill is one of many who 
get bitten by this kind of thing and would like a good-practice note, 
speak on up. -Tim




From owner-atom-syntax@mail.imc.org  Wed Jul 14 13:08: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 NAA29467
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 13:08:04 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EGrl87030348;
	Wed, 14 Jul 2004 09: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 i6EGrleJ030347;
	Wed, 14 Jul 2004 09:53: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 i6EGrksA030340
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 09:53:46 -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 i6EGsTnH027016;
	Wed, 14 Jul 2004 12:54:29 -0400
Message-ID: <40F56514.2080100@intertwingly.net>
Date: Wed, 14 Jul 2004 12:53:40 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Dare Obasanjo <kpako@yahoo.com>
CC: Atom-syntax Syntax <atom-syntax@imc.org>
Subject: Re: a methodical approach to defining what date  elements we need
References: <20040714145637.6292.qmail@web41215.mail.yahoo.com>
In-Reply-To: <20040714145637.6292.qmail@web41215.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: <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:

> --- Sam Ruby <rubys@intertwingly.net> wrote:
> 
>>So, if you 
>>will bear with me, let's take a look at the
>>following together:
>>
>>http://www.livejournal.com/update.bml?mode=full
>>
> 
> http://help.blogger.com/bin/answer.py?answer=139&topic=17
> 
>>http://www.movabletype.org/features.shtml
>>http://journurl.com/?entry=1007&template=upgrade
>>
>>In the latter two look for text like and "Movable
>>Type allows you to set 
>>a post's date stamp to any date or time you wish,
>>for pre-dating or 
>>post-dating information when it goes live.", and
>>"Pre- and post-date 
>>entries"
>>
>>If we deny this information a home, it will simply
>>find one of its own 
>>accord.
> 
> I would categorize the features described at those
> links differently from how you described the date
> field. It seems MovableType and other tools allow you
> to control something that maps to the 'issued' date of
> the entry. 
> 
> I sincerely doubt that any of these tool vendors would
> want to make the distinction between issued and the
> user entered date. I might be wrong so I'd love to get
> their opinions. If I go with your descriptions, then
> Atom needs 3 dates (last modified, created & bogus
> user entered date). As an aggregator author I'd always
> ignore the last one. 

What I described above is basically what I originally meant by the term 
issued.  People like Asbjørn and Graham have made separate but rather 
compelling cases that the term issued is probably not the most 
appropriate term to be used here.  I'm no longer attached to that term.

As to the label 'bogus', this clearly is something a number of major 
weblogging software vendors have chosen not only to implement, but to 
actively highlight in their features list.  Roger wants to sort on this 
field, Graham wants to reformat it (presumably for localization or 
usability purposes).

I am quite OK with RSSBandit swimming upstream on this issue.  Even if 
the only benefit of keeping this field separate is that there is a 
significantly reduced temptation for tool vendors to 'pollute' the set 
of date fields that RSSBandit actively cares about with information that 
the user carefully and deliberately chose to provide, then clearly this 
should be of significant value.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Wed Jul 14 13:09:36 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29552
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 13:09:36 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EGxHHm031209;
	Wed, 14 Jul 2004 09:59:17 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6EGxH8V031208;
	Wed, 14 Jul 2004 09:59:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.199])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6EGxGvD031201
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 09:59:17 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d5so492224rng
        for <atom-syntax@imc.org>; Wed, 14 Jul 2004 09:59:19 -0700 (PDT)
Received: by 10.38.9.67 with SMTP id 67mr307418rni;
        Wed, 14 Jul 2004 09:59:19 -0700 (PDT)
Message-ID: <14be96d304071409597134a601@mail.gmail.com>
Date: Wed, 14 Jul 2004 12:59:19 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Antone Roundy <antone@geckotribe.com>
Subject: Re: PaceLang
Cc: atom-syntax@imc.org
In-Reply-To: <D02C373E-D5A7-11D8-AE1C-003065EA6144@geckotribe.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <D02C373E-D5A7-11D8-AE1C-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 Wed, 14 Jul 2004 09:09:33 -0600, Antone Roundy <antone@geckotribe.com> wrote:
> 
> On Wednesday, July 14, 2004, at 08:47  AM, Eric Scheid wrote:
> >> Add support for the xml:lang special attribute to all the relevant
> >> Atom
> >> elements. From the current draft, it seems enough to specify xml:lang
> >> on the
> >> Content Construct
> >
> > what about @title in <link> constructs?
> 
> That brings up an argument in favor of <link ...>put the title
> here</link> (or <linkConstructOfSomeOtherName ...>title
> here</linkConstructOfSomeOtherName>.  With that arrangement, it would
> be perfectly clear that xml:lang applies to the title.

No it doesn't.  The XML specification is already crystal clear on this:

http://www.w3.org/TR/REC-xml/#sec-lang-tag

"xml:lang is considered to apply to all attributes and content of the
element where it is specified"

There may be other arguments in favor of changing the link syntax, but
this isn't one of them.

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Wed Jul 14 13:15: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 NAA29795
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 13:15: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 i6EH6xfe032656;
	Wed, 14 Jul 2004 10:06:59 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6EH6xXx032655;
	Wed, 14 Jul 2004 10:06:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EH6xkA032649
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 10:06:59 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from phys-bur-1 ([129.148.9.72])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6EH72il029482
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 11:07:02 -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 <0I0U00301Q6RGE@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com)
 for atom-syntax@imc.org; Wed, 14 Jul 2004 13:07:02 -0400 (EDT)
Received: from mercury (vpn-129-150-33-64.Central.Sun.COM [129.150.33.64])
 by bur-mail1.east.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
 with ESMTP id <0I0U00F2LQ7EG9@bur-mail1.east.sun.com> for atom-syntax@imc.org;
 Wed, 14 Jul 2004 13:07:02 -0400 (EDT)
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BknDF-0005sk-00	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 13:06:33 -0400
X-URL: http://nwalsh.com/
Date: Wed, 14 Jul 2004 13:06:29 -0400
From: Norman Walsh <ndw@nwalsh.com>
Subject: Re: a methodical approach to defining what date  elements we need
In-reply-to: <D1CE520E-D5B1-11D8-A6EC-000A95A51C9E@sun.com>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <87vfgqjz6y.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: <20040714153153.98934.qmail@web41201.mail.yahoo.com>
 <D1CE520E-D5B1-11D8-A6EC-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-Type: text/plain

/ Tim Bray <Tim.Bray@Sun.COM> was heard to say:
| On Jul 14, 2004, at 8:31 AM, Dare Obasanjo wrote:
|
|>> 2) A date of the most recent minor change (anything
|>> not reflected in
|>> Updated).  I'd like to see this in the format for
|>> the following reasons:
|>
|> What is the difference between a minor change and a
|> major change? Are publishing tools now supposed to
|> have heuristics that detect when the user fixes a typo
|> versus adds two new paragraghs to a post? Is the user
|> supposed to make this distinction themselves?
|
| +1.  This minor/major thing is an invitation to endless hairsplitting
| disputes.   As a consumer of a feed, I want the provider to know when
| they consider it to have been modified, as a binary condition.  As a
| provider of a feed, I don't want to have to invest cycles agonizing
| over how "major" an update is.  It's a binary decision: is it major
| enough for the change to be reflected in the feed, yes or no.  Without
| a shared definition of what major/minor *means*, this will produce
| zero interoperability. -Tim

Are you saying that Atom entries need exactly one date: atom:modified?
Or two: atom:modified and atom:{issued|created}? I'm pretty sure
you're not in the three camp.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | For the mental patient's family and
http://nwalsh.com/            | society, mental illness is a 'problem';
                              | for the patient himself it is a
                              | 'solution'.--Thomas Szasz

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA9WgXOyltUcwYWjsRAjIeAKCgWzMO3cuhxX2k950hkD+x5J3pfACgj3aD
6P2viEsvzlQgTGHmlottMf0=
=5XW8
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Wed Jul 14 13:17: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 NAA29861
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 13:17: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 i6EH8OBV032885;
	Wed, 14 Jul 2004 10:08: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 i6EH8O3v032884;
	Wed, 14 Jul 2004 10:08: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.204])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6EH8L8U032864
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 10:08:23 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d5so492879rng
        for <atom-syntax@imc.org>; Wed, 14 Jul 2004 10:08:24 -0700 (PDT)
Received: by 10.38.9.24 with SMTP id 24mr320879rni;
        Wed, 14 Jul 2004 10:08:24 -0700 (PDT)
Message-ID: <14be96d304071410083cc71f90@mail.gmail.com>
Date: Wed, 14 Jul 2004 13:08:24 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: "Asbjørn Ulsberg" <asbjorn@tigerstaden.no>
Subject: Don't bake discrimination into the Atom core (was Re: Low-hanging fruit: multipart/alternative)
Cc: Tim Bray <tbray@textuality.com>, Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <opsa4zq3fhuvpchu@quark>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
References: <A65D9796-D519-11D8-8C42-000A95A51C9E@textuality.com> <14be96d304071317541efca684@mail.gmail.com> <7FBABBD6-D531-11D8-A503-000A95A51C9E@textuality.com> <14be96d304071319181e2bf741@mail.gmail.com> <1393DBDA-D540-11D8-A503-000A95A51C9E@textuality.com> <opsa4zq3fhuvpchu@quark>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6EH8N8U032878
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 Wed, 14 Jul 2004 18:50:53 +0200, Asbjørn Ulsberg
<asbjorn@tigerstaden.no> wrote:
> 
> On Tue, 13 Jul 2004 19:46:58 -0700, Tim Bray <tbray@textuality.com> wrote:
> 
> > Could someone take ownership of writing a three-line Pace saying
> >
> > "Nuke multipart/alternative for substantial cost and lack of a
> > compelling use-case."
> 
> Done: <url: http://intertwingly.net/wiki/pie/PaceNukeMultipart>.

-1 on nuking it without an alternative proposal in place.  Atom's
current content model allows inline content of arbitrary type.  This
includes binary content (such as images) that are intrinsically
inaccessible to people with certain disabilities.  As long as Atom
allows for such inaccessible content to be published within a feed, I
absolutely positively insist -- with my last dying breath -- that we
have some mechanism for allowing publishers to include accessible
alternatives in the same feed, in a way that makes it clear that
*this* is an accessible alternative to *that*.

If you thought I was passionate about certain issues before, you ain't
seen nothin' yet.

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Wed Jul 14 13: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 NAA00455
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 13:28: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 i6EHLB6J035297;
	Wed, 14 Jul 2004 10:21: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 i6EHLBva035296;
	Wed, 14 Jul 2004 10:21:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.240])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6EHLAPa035270
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 10:21:11 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so256625cwc
        for <atom-syntax@imc.org>; Wed, 14 Jul 2004 10:21:11 -0700 (PDT)
Received: by 10.11.99.41 with SMTP id w41mr27865cwb;
        Wed, 14 Jul 2004 10:21:11 -0700 (PDT)
Message-ID: <3f1451f5040714102129846420@mail.gmail.com>
Date: Wed, 14 Jul 2004 13:21:11 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Mark Pilgrim <pilgrim@gmail.com>
Subject: Re: Don't bake discrimination into the Atom core (was Re: Low-hanging fruit: multipart/alternative)
Cc: "Asbjørn Ulsberg" <asbjorn@tigerstaden.no>,
        Tim Bray <tbray@textuality.com>, Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <14be96d304071410083cc71f90@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <A65D9796-D519-11D8-8C42-000A95A51C9E@textuality.com> <14be96d304071317541efca684@mail.gmail.com> <7FBABBD6-D531-11D8-A503-000A95A51C9E@textuality.com> <14be96d304071319181e2bf741@mail.gmail.com> <1393DBDA-D540-11D8-A503-000A95A51C9E@textuality.com> <opsa4zq3fhuvpchu@quark> <14be96d304071410083cc71f90@mail.gmail.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 Wed, 14 Jul 2004 13:08:24 -0400, Mark Pilgrim <pilgrim@gmail.com> wrote:
> 
> -1 on nuking it without an alternative proposal in place.  Atom's
> current content model allows inline content of arbitrary type.  This
> includes binary content (such as images) that are intrinsically
> inaccessible to people with certain disabilities.  As long as Atom
> allows for such inaccessible content to be published within a feed, I
> absolutely positively insist -- with my last dying breath -- that we
> have some mechanism for allowing publishers to include accessible
> alternatives in the same feed, in a way that makes it clear that
> *this* is an accessible alternative to *that*.

I could be wrong, but I thought there was movement towards
a content model that only allowed two types of content, either XML
or escaped HTML. 

Regardless I see no harm in removing something that is 
broken and waiting until later to decide on what to replace it 
with. It could even be replaced in the short term with an empty section
titled "Accessibility" and just filled with "TBD".

   -joe



From owner-atom-syntax@mail.imc.org  Wed Jul 14 13:29: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 NAA00566
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 13:29:47 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EHHOfH034637;
	Wed, 14 Jul 2004 10:17: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 i6EHHOcE034636;
	Wed, 14 Jul 2004 10:17:24 -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 i6EHHLpA034609
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 10:17:23 -0700 (PDT)
	(envelope-from antone@geckotribe.com)
Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134])
          by comcast.net (rwcrmhc12) with SMTP
          id <20040714171714014003aoi0e>; Wed, 14 Jul 2004 17:17:19 +0000
Date: Wed, 14 Jul 2004 11:17:09 -0600
Subject: Re: a methodical approach to defining what date  elements we need
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: <20040714163733.3235.qmail@web41208.mail.yahoo.com>
Message-Id: <A3532B98-D5B9-11D8-AE1C-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 Wednesday, July 14, 2004, at 10:37  AM, Dare Obasanjo wrote:
>> If the "updated" date is only updated for
>> substantive changes, then the
>> distinction already has to be made somehow.
>
> Can you back this up with a list of products and how
> they differentiate substantive versus non-substantive
> claims instead of speculation. If I have to implement
> support for this functionality in RSS Bandit I'd like
> some well defined and detailed description of what I'm
> supposed to do as opposed to speculation based on
> hearsay.

No I don't have a list of products, but you yourself said "+1" to "a 
machine generated timestamp indicating when the most recent substantive 
change has been made to the entry."  Whatever process you would use to 
determine what is a substantive change is fine.  Any other modification 
to the data in the entry whatsoever would be considered non-substantive.

>>> What tool vendor has asked for this functionality or
>>> has claimed this functionality makes their job easier?
>>
>> I don't know if anyone else has, but in the next
>> version of one of my
>> products, which is going to have this functionality,
>> it would make it a
>> lot easier for me.
>
> What product? What functionality is made much easier
> by having last-time-a-typo-was-fixed-date &
> last-time-a-major-revision-of-text-was-made-date as
> opposed to last-modified-date?

CaRP Evolution's mySQL plugin.  
(http://www.geckotribe.com/rss/carp/plugins/mysql.php).  The current 
version does not make such a distinction.  The closest thing it does is 
to compare a subset of the fields in an entry to cached data for 
previous entries to determine whether the new entry is a duplicate or 
not.  Atom will have entry:id to handle that issue, but lacking a 
datestamp for the last minor modification, the same process will have 
to be employed in order to flag minor modifications, which is a feature 
I plan to implement.



From owner-atom-syntax@mail.imc.org  Wed Jul 14 13:32: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 NAA00729
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 13:32: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 i6EHJwmG035086;
	Wed, 14 Jul 2004 10: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 i6EHJwoP035085;
	Wed, 14 Jul 2004 10:19: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 i6EHJvGL035079
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 10:19:57 -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 i6EHKSBF028333;
	Wed, 14 Jul 2004 13:20:28 -0400
Message-ID: <40F56B2A.8050500@intertwingly.net>
Date: Wed, 14 Jul 2004 13:19:38 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 Pilgrim <pilgrim@gmail.com>, Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceMustBeWellFormed
References: <14be96d30407061142441f70ee@mail.gmail.com>
In-Reply-To: <14be96d30407061142441f70ee@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


(6.1 1) I disagree with the recommendation that charset be provided.  In 
fact, one of the primary benefits I see to recommending application/* 
instead of text/* is that one can omit the charset and obtain a sensible 
result.

(6.1 1) I would, howevever, be supportive of a statement that if a 
charset were provided with any application/* MIME type, THEN it MUST 
match what the encoding that would have been determined had the charset 
been omitted.

(6.1 4) it is unclear that the two subbullets of this item only apply IF 
the charset parameter is omitted.  This should be clarified.

(6.2) I am uncomfortable with the lists of prohibitions.  I would be 
much more comfortable with what I see presented in section 4 of the TAG 
findings on Authoritative Metadata[1].

- Sam Ruby

[1] http://www.w3.org/2001/tag/doc/mime-respect.html#inconsistency



From owner-atom-syntax@mail.imc.org  Wed Jul 14 13:34: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 NAA00862
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 13:34:26 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EHL93O035288;
	Wed, 14 Jul 2004 10:21: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 i6EHL9ZS035286;
	Wed, 14 Jul 2004 10:21:09 -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 i6EHL8Yi035279
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 10:21:08 -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 1BknRN-0004uC-KW; Wed, 14 Jul 2004 17:21:09 +0000
Message-ID: <40F56B85.1040905@franklinmint.fm>
Date: Wed, 14 Jul 2004 13:21:09 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sam Ruby <rubys@intertwingly.net>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: PaceSecurityServices (was: New AtomPubIssuesList for 2004/07/14)
References: <40E16215.6070507@intertwingly.net> <40EC9915.4050406@intertwingly.net> <40F539FE.7010600@intertwingly.net>
In-Reply-To: <40F539FE.7010600@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: <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:

> For the moment, I'm keeping PaceSecurityServices listed as under 
> active discission as the last status I saw was Tim asking a question 
> to the editors, and Robert replying concerning a portion which he did 
> not perceive as quite having reached consensus.

The chairs have decided to move forward with PaceSecurityServices for 
the protocol, but not the format. I've removed the XMLDSig content from 
the Pace, and created PaceDigitalSignatures[1] to discuss DSig.

For the protocol, the chairs have decided on the following approach for 
this draft:

* Eliminate references to WSSE, and substitute with TBD references to an 
external authentication mechanism
* include the first paragraph of "K,kk.1 WSSE-style Authentication", 
because that's a good explanation of the situation
* Use all of the text about Digest roughly as-is.

I think this is a fairly accurate representation of the consensus. This 
leaves the protocol spec in need of an externally specified 
authentication scheme that works for CGI scripts on standard Apache 
configurations.

Robert Sayre

[1] http://www.intertwingly.net/wiki/pie/PaceDigitalSignatures



From owner-atom-syntax@mail.imc.org  Wed Jul 14 13: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 NAA01577
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 13: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 i6EHhX1c038588;
	Wed, 14 Jul 2004 10:43: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 i6EHhXQK038587;
	Wed, 14 Jul 2004 10:43:33 -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 i6EHhWFs038581
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 10:43:32 -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 i6EHhZil023284
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 11:43:35 -0600 (MDT)
Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0I0U00KAXRWMZQ@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Wed, 14 Jul 2004 11:43:35 -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 <0I0U00KYGRWI3Q@mail.sun.net> for atom-syntax@imc.org; Wed,
 14 Jul 2004 11:43:31 -0600 (MDT)
Date: Wed, 14 Jul 2004 10:43:27 -0700
From: Tim Bray <tbray@textuality.com>
Subject: Re: Don't bake discrimination into the Atom core (was Re: Low-hanging
 fruit: multipart/alternative)
In-reply-to: <14be96d304071410083cc71f90@mail.gmail.com>
To: Atom Syntax <atom-syntax@imc.org>, Mark Pilgrim <pilgrim@gmail.com>
Message-id: <50434192-D5BD-11D8-A6EC-000A95A51C9E@textuality.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.618)
Content-type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--149341688;
 protocol="application/pkcs7-signature"
References: <A65D9796-D519-11D8-8C42-000A95A51C9E@textuality.com>
 <14be96d304071317541efca684@mail.gmail.com>
 <7FBABBD6-D531-11D8-A503-000A95A51C9E@textuality.com>
 <14be96d304071319181e2bf741@mail.gmail.com>
 <1393DBDA-D540-11D8-A503-000A95A51C9E@textuality.com> <opsa4zq3fhuvpchu@quark>
 <14be96d304071410083cc71f90@mail.gmail.com>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>



--Apple-Mail-2--149341688
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On Jul 14, 2004, at 10:08 AM, Mark Pilgrim wrote:

>>> "Nuke multipart/alternative for substantial cost and lack of a
>>> compelling use-case."
>>
>> Done: <url: http://intertwingly.net/wiki/pie/PaceNukeMultipart>.
>
> -1 on nuking it without an alternative proposal in place.  Atom's
> current content model allows inline content of arbitrary type.  This
> includes binary content (such as images) that are intrinsically
> inaccessible to people with certain disabilities.

Ouch, it had somehow escaped my attention that this was an 
accessibility issue.  Mark is clearly correct that this Cannot Be 
Ignored.  On the other hand, I still think the current two levels of 
<atom:content> distinguished by the type= value feels like bad markup 
design and isn't clear enough what the real goal is.

MarkP is the guy who gets paid to think about accessibility, and thus 
the obvious candidate to write up a Pace for the right thing to do in 
Atom to support this properly and at a cost low enough that we can 
bully the vendors to do the right thing with some hope of success.  If 
he's prepared to argue that the current multipart/alternative is the 
best we can do, that's fine, but that argument has not so far been made 
on the grounds of accessibility.   Also, I think that the spec MUST 
have explicit normative content saying that if you are pushing 
non-textual content through, you SHOULD use said mechanism to provide 
accessible alternatives. -Tim
--Apple-Mail-2--149341688
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
hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDcxNDE3NDMyOFowIwYJKoZIhvcNAQkEMRYEFJQG
m4GnZcGt/3SldGVULbz6g6rNMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV
BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLirkwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT
AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3
dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDC4q5MA0GCSqGSIb3DQEBAQUABIIBAGss
KtmNw2wKaY94ceVXijz7zrOdVrWv/3p5k/EyjkhADgG8AdOOR42bd262FofJgqqo0G9+v13EXwbe
H8ilOyQLTmdogxk8hpLePhHXFIZhmxhPRukEyfyfs6z/IGYpDEVlUThiR7Z11NIAbwvZdbi0STnm
8keZwxCAoJp/udgmk7vvFagCZ/TCsg+xd3acfexh9BnVH/yzp1g3wqk76aZQ0Ei+guAItiBo98PG
+lRSB1Duo+ix659ZDXR1dvZ6TwUnJXV3CR87jnEcony6PrFJDGuWNrrJTv3iD+pJbgoFnqrRQHOR
jEcdcGYVPSLhJXG++eqeIwl2X5l7A8zb3S0AAAAAAAA=

--Apple-Mail-2--149341688--



From owner-atom-syntax@mail.imc.org  Wed Jul 14 13:53: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 NAA01632
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 13:53: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 i6EHf6Z7038233;
	Wed, 14 Jul 2004 10:41: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 i6EHf6r3038232;
	Wed, 14 Jul 2004 10:41:06 -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 i6EHf5kQ038209
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 10:41:05 -0700 (PDT)
	(envelope-from jasnell@us.ibm.com)
Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32])
	by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i6EHf3uc725342;
	Wed, 14 Jul 2004 13:41:03 -0400
Received: from d03nm122.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170])
	by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6EHf2AL194102;
	Wed, 14 Jul 2004 11:41:02 -0600
In-Reply-To: <CC364146-D5B5-11D8-A6EC-000A95A51C9E@sun.com>
To: Tim Bray <Tim.Bray@Sun.COM>
Cc: Atom Syntax <atom-syntax@imc.org>,
        Bill de =?ISO-8859-1?Q?h=D3ra?= <bill@dehora.net>,
        owner-atom-syntax@mail.imc.org
MIME-Version: 1.0
Subject: Re: Low-hanging fruit: compulsory namespaces
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
From: James M Snell <jasnell@us.ibm.com>
X-MIMETrack: S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/14/2004 10:37:09 AM,
	Serialize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/14/2004 10:37:09 AM,
	Serialize complete at 07/14/2004 10:37:09 AM,
	Itemize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/14/2004 10:37:10 AM,
	S/MIME Sign complete at 07/14/2004 10:37:10 AM,
	S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/14/2004 10:40:58 AM,
	S/MIME Sign complete at 07/14/2004 10:40:58 AM,
	Serialize by Router on D03NM122/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at
 07/14/2004 11:41:02,
	Serialize complete at 07/14/2004 11:41:02
Message-ID: <OF1EDB4365.7F21B3FD-ON88256ED1.005F94EC-88256ED1.0061228A@us.ibm.com>
Date: Wed, 14 Jul 2004 11:40:58 -0600
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z17110_boundary_sign
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>


This is an S/MIME signed message.

---------z17110_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 0060C92D88256ED1_="

This is a multipart message in MIME format.
--=_alternative 0060C92D88256ED1_=
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

Owner-atom-syntax@mail.imc.org wrote on 07/14/2004 09:49:39 AM:

>=20
> On Jul 14, 2004, at 8:59 AM, Bill de h=D3ra wrote:
>=20
> > I would expect an utterance along the lines of 'inside Atom, you=20
> > SHOULD qualify your non-namespace markup with xmlns=3D""' to aid=20
> > robustness and increase happiness all round.
>=20
> Hmm... maybe I'm unusually lucky but I just haven't been bitten by=20
> things going wrong in this space, and I think I use a reasonably=20
> vanilla selection of XML tools.  So I'm still uncomfortable with=20
> putting it in an RFC.  On the other hand, if Bill is one of many who=20
> get bitten by this kind of thing and would like a good-practice note,=20
> speak on up. -Tim
>=20
>=20

Where this really becomes an issue is situations where atom:feed MAY be=20
placed into other XML documents, for example, a SOAP envelope.  Imagine,=20
for instance, odd as it may be, an RPC style Web service method that=20
returns an atom:feed.  Apache Axis (and I believe a few other Web service=20
engines) have the tendency to serialize the elements representing the=20
operation using the default namspace, so what you get is something that=20
looks like:

<s:Envelope xmlns:s=3D"...">
  <s:Body>
    <getFeedResponse xmlns=3D"...">
      <atom:feed>...</atom:feed>
    </getFeedResponse>
  </s:Body>
</s:Envelope>

Now, imagine that the atom feed was generated by some other piece of=20
application code that simply handed it off as a DOM document or XML string =

or whatever to the web service engine.  The engine has no way of knowing=20
whether or not the XML contained within it has non-namespace qualified=20
elements, so you could end up with something like:

<s:Envelope xmlns:s=3D"...">
  <s:Body>
    <getFeedResponse xmlns=3D"...">
      <atom:feed>
        <foo />
      </atom:feed>
    </getFeedResponse>
  </s:Body>
</s:Envelope>

Where suddenly the <foo /> element, which should not be in any namespace=20
at all, is now suddenly placed within the same namespace as the=20
<getFeedResponse /> element.

The question becomes: whose problem is this?  Is it the Web services=20
engines problem?  That is, should the engine be aware that it may be=20
handed XML that contains non-qualified elements and do things to ensure=20
that the embedded XML will still be valid (e.g. not serialize any of the=20
top level elements using the default namespace as in option 1 below).  Or=20
is it the atom:feed generators problem?  That is, should the code=20
generating the atom xml be aware that what it is generating may be=20
contained in another bit of XML that may itself define elements in the=20
default namespace and do things to protect it's non-qualified elements as=20
in option 2 below.

Option 1
<s:Envelope xmlns:s=3D"...">
  <s:Body>
    <n:getFeedResponse xmlns:n=3D"...">
      <atom:feed>
        <foo />
      </atom:feed>
    </n:getFeedResponse>
  </s:Body>
</s:Envelope>

Option 2
<s:Envelope xmlns:s=3D"...">
  <s:Body>
    <getFeedResponse xmlns=3D"...">
      <atom:feed>
        <foo xmlns=3D"" />
      </atom:feed>
    </getFeedResponse>
  </s:Body>
</s:Envelope>

I would argue that both approaches are valid.  If you expect your XML to=20
be embedded in other XML and your XML contains non-qualified elements, you =

SHOULD use xmlns=3D"".  If you expect your XML to contain XML that may have=
=20
non-qualified elements, you should not use the default namespace for any=20
of your container elements.  This is reflected in Option 3

Option 3
<s:Envelope xmlns:s=3D"...">
  <s:Body>
    <n:getFeedResponse xmlns:n=3D"...">
      <atom:feed>
        <foo xmlns=3D"" />
      </atom:feed>
    </n:getFeedResponse>
  </s:Body>
</s:Envelope>

=20

- James M Snell
  jasnell@us.ibm.com
  http://www.ibm.com
  (877) 511-5082 / Office
  930-1979 / Tie Line
--=_alternative 0060C92D88256ED1_=
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable


<br><font size=3D2><tt>Owner-atom-syntax@mail.imc.org wrote on 07/14/2004
09:49:39 AM:<br>
<br>
&gt; <br>
&gt; On Jul 14, 2004, at 8:59 AM, Bill de h=D3ra wrote:<br>
&gt; <br>
&gt; &gt; I would expect an utterance along the lines of 'inside Atom,
you <br>
&gt; &gt; SHOULD qualify your non-namespace markup with xmlns=3D&quot;&quot=
;'
to aid <br>
&gt; &gt; robustness and increase happiness all round.<br>
&gt; <br>
&gt; Hmm... maybe I'm unusually lucky but I just haven't been bitten by
<br>
&gt; things going wrong in this space, and I think I use a reasonably <br>
&gt; vanilla selection of XML tools. &nbsp;So I'm still uncomfortable with
<br>
&gt; putting it in an RFC. &nbsp;On the other hand, if Bill is one of many
who <br>
&gt; get bitten by this kind of thing and would like a good-practice note,
<br>
&gt; speak on up. -Tim<br>
&gt; <br>
&gt; <br>
</tt></font>
<br><font size=3D2><tt>Where this really becomes an issue is situations whe=
re
atom:feed MAY be placed into other XML documents, for example, a SOAP envel=
ope.
&nbsp;Imagine, for instance, odd as it may be, an RPC style Web service
method that returns an atom:feed. &nbsp;Apache Axis (and I believe a few
other Web service engines) have the tendency to serialize the elements
representing the operation using the default namspace, so what you get
is something that looks like:</tt></font>
<br>
<br><font size=3D2><tt>&lt;s:Envelope xmlns:s=3D&quot;...&quot;&gt;</tt></f=
ont>
<br><font size=3D2><tt>&nbsp; &lt;s:Body&gt;</tt></font>
<br><font size=3D2><tt>&nbsp; &nbsp; &lt;getFeedResponse xmlns=3D&quot;...&=
quot;&gt;</tt></font>
<br><font size=3D2><tt>&nbsp; &nbsp; &nbsp; &lt;atom:feed&gt;...&lt;/atom:f=
eed&gt;</tt></font>
<br><font size=3D2><tt>&nbsp; &nbsp; &lt;/getFeedResponse&gt;</tt></font>
<br><font size=3D2><tt>&nbsp; &lt;/s:Body&gt;</tt></font>
<br><font size=3D2><tt>&lt;/s:Envelope&gt;</tt></font>
<br>
<br><font size=3D2 face=3D"sans-serif">Now, imagine that the atom feed was
generated by some other piece of application code that simply handed it
off as a DOM document or XML string or whatever to the web service engine.
&nbsp;The engine has no way of knowing whether or not the XML contained
within it has non-namespace qualified elements, so you could end up with
something like:</font>
<br>
<br><font size=3D2><tt>&lt;s:Envelope xmlns:s=3D&quot;...&quot;&gt;</tt></f=
ont>
<br><font size=3D2><tt>&nbsp; &lt;s:Body&gt;</tt></font>
<br><font size=3D2><tt>&nbsp; &nbsp; &lt;getFeedResponse xmlns=3D&quot;...&=
quot;&gt;</tt></font>
<br><font size=3D2><tt>&nbsp; &nbsp; &nbsp; &lt;atom:feed&gt;</tt></font>
<br><font size=3D2><tt>&nbsp; &nbsp; &nbsp; &nbsp; &lt;foo /&gt;</tt></font>
<br><font size=3D2><tt>&nbsp; &nbsp; &nbsp; &lt;/atom:feed&gt;</tt></font>
<br><font size=3D2><tt>&nbsp; &nbsp; &lt;/getFeedResponse&gt;</tt></font>
<br><font size=3D2><tt>&nbsp; &lt;/s:Body&gt;</tt></font>
<br><font size=3D2><tt>&lt;/s:Envelope&gt;</tt></font>
<br>
<br><font size=3D2 face=3D"sans-serif">Where suddenly the &lt;foo /&gt; ele=
ment,
which should not be in any namespace at all, is now suddenly placed within
the same namespace as the &lt;getFeedResponse /&gt; element.</font>
<br>
<br><font size=3D2 face=3D"sans-serif">The question becomes: whose problem
is this? &nbsp;Is it the Web services engines problem? &nbsp;That is, should
the engine be aware that it may be handed XML that contains non-qualified
elements and do things to ensure that the embedded XML will still be valid
(e.g. not serialize any of the top level elements using the default namespa=
ce
as in option 1 below). &nbsp;Or is it the atom:feed generators problem?
&nbsp;That is, should the code generating the atom xml be aware that what
it is generating may be contained in another bit of XML that may itself
define elements in the default namespace and do things to protect it's
non-qualified elements as in option 2 below.</font>
<br>
<br><font size=3D2 face=3D"sans-serif">Option 1</font>
<br><font size=3D2><tt>&lt;s:Envelope xmlns:s=3D&quot;...&quot;&gt;</tt></f=
ont>
<br><font size=3D2><tt>&nbsp; &lt;s:Body&gt;</tt></font>
<br><font size=3D2><tt>&nbsp; &nbsp; &lt;n:getFeedResponse xmlns:n=3D&quot;=
...&quot;&gt;</tt></font>
<br><font size=3D2><tt>&nbsp; &nbsp; &nbsp; &lt;atom:feed&gt;</tt></font>
<br><font size=3D2><tt>&nbsp; &nbsp; &nbsp; &nbsp; &lt;foo /&gt;</tt></font>
<br><font size=3D2><tt>&nbsp; &nbsp; &nbsp; &lt;/atom:feed&gt;</tt></font>
<br><font size=3D2><tt>&nbsp; &nbsp; &lt;/n:getFeedResponse&gt;</tt></font>
<br><font size=3D2><tt>&nbsp; &lt;/s:Body&gt;</tt></font>
<br><font size=3D2><tt>&lt;/s:Envelope&gt;</tt></font>
<br>
<br><font size=3D2 face=3D"sans-serif">Option 2</font>
<br><font size=3D2><tt>&lt;s:Envelope xmlns:s=3D&quot;...&quot;&gt;</tt></f=
ont>
<br><font size=3D2><tt>&nbsp; &lt;s:Body&gt;</tt></font>
<br><font size=3D2><tt>&nbsp; &nbsp; &lt;getFeedResponse xmlns=3D&quot;...&=
quot;&gt;</tt></font>
<br><font size=3D2><tt>&nbsp; &nbsp; &nbsp; &lt;atom:feed&gt;</tt></font>
<br><font size=3D2><tt>&nbsp; &nbsp; &nbsp; &nbsp; &lt;foo xmlns=3D&quot;&q=
uot;
/&gt;</tt></font>
<br><font size=3D2><tt>&nbsp; &nbsp; &nbsp; &lt;/atom:feed&gt;</tt></font>
<br><font size=3D2><tt>&nbsp; &nbsp; &lt;/getFeedResponse&gt;</tt></font>
<br><font size=3D2><tt>&nbsp; &lt;/s:Body&gt;</tt></font>
<br><font size=3D2><tt>&lt;/s:Envelope&gt;</tt></font>
<br>
<br><font size=3D2 face=3D"sans-serif">I would argue that both approaches a=
re
valid. &nbsp;If you expect your XML to be embedded in other XML and your
XML contains non-qualified elements, you SHOULD use xmlns=3D&quot;&quot;.
&nbsp;If you expect your XML to contain XML that may have non-qualified
elements, you should not use the default namespace for any of your container
elements. &nbsp;This is reflected in Option 3</font>
<br>
<br><font size=3D2 face=3D"sans-serif">Option 3</font>
<br><font size=3D2><tt>&lt;s:Envelope xmlns:s=3D&quot;...&quot;&gt;</tt></f=
ont>
<br><font size=3D2><tt>&nbsp; &lt;s:Body&gt;</tt></font>
<br><font size=3D2><tt>&nbsp; &nbsp; &lt;n:getFeedResponse xmlns:n=3D&quot;=
...&quot;&gt;</tt></font>
<br><font size=3D2><tt>&nbsp; &nbsp; &nbsp; &lt;atom:feed&gt;</tt></font>
<br><font size=3D2><tt>&nbsp; &nbsp; &nbsp; &nbsp; &lt;foo xmlns=3D&quot;&q=
uot;
/&gt;</tt></font>
<br><font size=3D2><tt>&nbsp; &nbsp; &nbsp; &lt;/atom:feed&gt;</tt></font>
<br><font size=3D2><tt>&nbsp; &nbsp; &lt;/n:getFeedResponse&gt;</tt></font>
<br><font size=3D2><tt>&nbsp; &lt;/s:Body&gt;</tt></font>
<br><font size=3D2><tt>&lt;/s:Envelope&gt;</tt></font>
<br>
<br><font size=3D2 face=3D"sans-serif">&nbsp;</font>
<br>
<br><font size=3D2 face=3D"sans-serif">- James M Snell<br>
 &nbsp;jasnell@us.ibm.com<br>
 &nbsp;http://www.ibm.com<br>
 &nbsp;(877) 511-5082 / Office<br>
 &nbsp;930-1979 / Tie Line</font>
--=_alternative 0060C92D88256ED1_=--

---------z17110_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIIUOAIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIISWDCCAtow
ggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1
aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAy
MDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA629xc49NpAPz
cAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7glzJKgPkPzlTZZfznznGbmAWVnNBQ
lyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnwNclOnnP2sKufuPzbTImQTTi5c8JZNZcM
J0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEEBAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1Ud
DgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAPBgNVHRMBAf8EBTADAQH/MDEGA1UdJQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUH
AwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvu
jQupk2oCScMd3FIHLE7hOfu8YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14ke
McF9ViNdewEoBGiAycUq8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIC2jCCAkOgAwIB
AgIDAxS2MA0GCSqGSIb3DQEBBAUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwMTE0MjIw
NzExWhcNMTExMjMxMjIwNzExWjBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25h
bCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrb3Fzj02kA/NwCy5KFMiY
tFgyTJ6kMSQLVSs9uwVHIAVkqy/enDQwZ9b/7uCXMkqA+Q/OVNll/OfOcZuYBZWc0FCXI9qw60KO
J/rTd65FdF4dwp8cw8si0qjOJtYg8cm46fA1yU6ec/awq5+4/NtMiZBNOLlzwlk1lwwnRgXNNwID
AQABo4GqMIGnMBEGCWCGSAGG+EIBAQQEAwIAhzAOBgNVHQ8BAf8EBAMCAcYwHQYDVR0OBBYEFK5U
DpLqqDOpKyQtx8hvMNze80pAMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMA8GA1Ud
EwEB/wQFMAMBAf8wMQYDVR0lBCowKAYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYB
BQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAMnJ7c2YLyrY/PKlFl+7sm8NENfWtFxqdm+6NC6mTagJJ
wx3cUgcsTuE5+7xh9+/G0tTfLzA1qZAQ5GNMPXvmoB9+vJfKnC2JWMFQpIOUEJDXiR4xwX1WI117
ASgEaIDJxSrxHcuuV/hMIO9bgZ6C41MUVmdLTKBgBOImTuIPK8QwggMgMIICiaADAgECAgQ13vTP
MA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQL
EyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0MTUxWhcN
MTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMk
RXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKKlQRkrPFr
U18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkwrFEeO68r
1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOgYaRfMF0x
CzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBD
ZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAxODA4MjIx
NjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAdBgNV
HQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0HQQAEDTAL
GwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwlMQ0AppJu
f7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn00DbOyZY
sih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMgMIICiaADAgEC
AgQ13vTPMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0
MTUxWhcNMTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsG
A1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKK
lQRkrPFrU18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkw
rFEeO68r1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOg
YaRfMF0xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNl
Y3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAx
ODA4MjIxNjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAdBgNVHQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0H
QQAEDTALGwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwl
MQ0AppJuf7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn
00DbOyZYsih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMmMIIC
j6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIxNjM2NTRaMIGFMQsw
CQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEXMBUGA1UEAxMOSmFt
ZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkqhkiG9w0BCQEWEmph
c25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwKpbDG3zMatEuuOT
FYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSyd+7nwqAvbBfPj+0S
vcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7tBJlLrwDRCMoNlPuQ
Kg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQW
BBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOgFAwSamFzbmVs
bEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pAMCcGA1UdJQQgMB4G
CCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAZMKevB7dFfb9
23OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY8BjwVHxiYgG4xkxf
B1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOIzj3lz3xd+uOzqRFg
/Wsg/VMwggMmMIICj6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAy
BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNV
BAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIx
NjM2NTRaMIGFMQswCQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEX
MBUGA1UEAxMOSmFtZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkq
hkiG9w0BCQEWEmphc25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
wKpbDG3zMatEuuOTFYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSy
d+7nwqAvbBfPj+0SvcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7t
BJlLrwDRCMoNlPuQKg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQD
AgXgMB0GA1UdDgQWBBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcU
AgOgFAwSamFzbmVsbEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA
MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQAD
gYEAZMKevB7dFfb923OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY
8BjwVHxiYgG4xkxfB1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOI
zj3lz3xd+uOzqRFg/Wsg/VMxggG7MIIBtwIBATBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJ
bnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0g
Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwF+kzAJBgUrDgMCGgUAoIGiMBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDcxNDE3MzcxMFowIwYJKoZIhvcNAQkEMRYE
FFZRO5mWOyjknpp606wUgivixmTyMEMGCSqGSIb3DQEJDzE2MDQwBwYFKw4DAh0wDgYIKoZIhvcN
AwICAgCAMAoGCCqGSIb3DQMHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAd+0MrtY+
okBl7fnN6LW/lK/F6B0eMw/8PSvSts1hqQM2AfdX9ADGpoODJCF4aXkxAkc76qJrajZry/r2Ic1c
fDuE9KV1hvyUQbfvAxs7HaLwcH6D/iZ6gXd1hzmD2kG9HZ2z2ZhrsnCZ7b6OmG6ONwIVttkBd3co
VYC+uGTZMQwAAAAA

---------z17110_boundary_sign--



From owner-atom-syntax@mail.imc.org  Wed Jul 14 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 NAA01680
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 13: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 i6EHksVu039164;
	Wed, 14 Jul 2004 10:46: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 i6EHksLp039163;
	Wed, 14 Jul 2004 10:46:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EHkrS6039156
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 10:46:54 -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 i6EHim53006173
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 11:44:48 -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 <0I0U00E2YS28EU@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Wed, 14 Jul 2004 11:46:57 -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 <0I0U00KJZS283K@mail.sun.net> for atom-syntax@imc.org; Wed,
 14 Jul 2004 11:46:56 -0600 (MDT)
Date: Wed, 14 Jul 2004 10:46:59 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: a methodical approach to defining what date  elements we need
In-reply-to: <87vfgqjz6y.fsf@nwalsh.com>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <CE649170-D5BD-11D8-A6EC-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: <20040714153153.98934.qmail@web41201.mail.yahoo.com>
 <D1CE520E-D5B1-11D8-A6EC-000A95A51C9E@sun.com> <87vfgqjz6y.fsf@nwalsh.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 Jul 14, 2004, at 10:06 AM, Norman Walsh wrote:

> Are you saying that Atom entries need exactly one date: atom:modified?
> Or two: atom:modified and atom:{issued|created}? I'm pretty sure
> you're not in the three camp.

I'm with Sam, we need two.  One last-modified and one "what the user 
wants to appear here" to support this widely-used facility from 
LiveJournal and so on.  The canonical case would be a travel diary, the 
entry for July 1 may have been created on July 3 and modified on July 
8, but from the user's point of view it's still the entry for July 1.  
Frankly I don't see any interesting current or future use for "created" 
but I guess some do. -Tim



From owner-atom-syntax@mail.imc.org  Wed Jul 14 13:55: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 NAA01766
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 13:55: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 i6EHm9Jo039367;
	Wed, 14 Jul 2004 10:48: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 i6EHm9UI039366;
	Wed, 14 Jul 2004 10:48:09 -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 i6EHm9rE039347
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 10:48:09 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040714174807.44676.qmail@web41214.mail.yahoo.com>
Received: from [24.18.129.247] by web41214.mail.yahoo.com via HTTP; Wed, 14 Jul 2004 10:48:07 PDT
Date: Wed, 14 Jul 2004 10:48:07 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: a methodical approach to defining what date  elements we need
To: Sam Ruby <rubys@intertwingly.net>
Cc: Atom-syntax Syntax <atom-syntax@imc.org>
In-Reply-To: <40F56514.2080100@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:
>
> >>http://www.movabletype.org/features.shtml
> >>http://journurl.com/?entry=1007&template=upgrade
> >>
> >>In the latter two look for text like and "Movable
> >>Type allows you to set 
> >>a post's date stamp to any date or time you wish,
> >>for pre-dating or 
> >>post-dating information when it goes live.", and
> >>"Pre- and post-date 
> >>entries"
>
> 
> What I described above is basically what I
> originally meant by the term 
> issued.  
> 
> As to the label 'bogus', this clearly is something a
> number of major 
> weblogging software vendors have chosen not only to
> implement, but to 
> actively highlight in their features list.  

I disagree with your original description. You
described this date as some fanciful user entered date
that could potentially be meaningless. What
MovableType and co provide is a way for the user to
specify the issued date which is not the same as the
user being able to say "43rd day of the 31st month of
the millionth year" as the date. 

This still boils down to two relevant dates to me
issued (which defaults to the created date but the
user can override it) and last-modified. I'd like to
know why you think there should be three and also am
curious whether tools vendors like Roger agree with my
assessment. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
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 Jul 14 13:56: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 NAA01805
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 13: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 i6EHnOZ8039603;
	Wed, 14 Jul 2004 10:49:24 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6EHnN6N039602;
	Wed, 14 Jul 2004 10:49:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mta01-svc.ntlworld.com (mta01-svc.ntlworld.com [62.253.162.41])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EHnNXP039578
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 10:49:23 -0700 (PDT)
	(envelope-from djpowell@djpowell.net)
Received: from cpc2-stke1-5-0-cust245.bagu.cable.ntl.com ([81.111.201.245])
          by mta01-svc.ntlworld.com
          (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP
          id <20040714174843.DCDV9394.mta01-svc.ntlworld.com@cpc2-stke1-5-0-cust245.bagu.cable.ntl.com>;
          Wed, 14 Jul 2004 18:48:43 +0100
Date: Wed, 14 Jul 2004 18:49:16 +0100
From: David Powell <djpowell@djpowell.net>
X-Mailer: The Bat! (v2.12 RC/4) Business
Reply-To: David Powell <djpowell@djpowell.net>
X-Priority: 3 (Normal)
Message-ID: <981954400.20040714184916@djpowell.net>
To: Dare Obasanjo <kpako@yahoo.com>
CC: Antone Roundy <antone@geckotribe.com>, atom-syntax@imc.org
Subject: Re: a methodical approach to defining what date  elements we need
In-Reply-To: <20040714153153.98934.qmail@web41201.mail.yahoo.com>
References: <62BB74BC-D5A6-11D8-AE1C-003065EA6144@geckotribe.com>
 <20040714153153.98934.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: <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


Wednesday, July 14, 2004, 4:31:53 PM, kpako@yahoo.com wrote:

>> 
>> 2) A date of the most recent minor change (anything
>> not reflected in 
>> Updated).  I'd like to see this in the format for
>> the following reasons:

> What is the difference between a minor change and a
> major change?

You could do without "Updated" and just use "Modified" everywhere
instead, but I think that the user experience could be a lot better if
you had "Updated" too.

The difference has more to do with the implied effects I think:

"Modified" would be more like the Atom equivalent to HTTP's
Last-Modified header for entries. It tells software whether to process
an entry rather than ignore it. If Bloglines saw that an entry's
modified date had changed it would probably want to put the entry in
its database, but it wouldn't mark that entry as unread for its users.

You probably wouldn't display "Modified" to a user.


"Updated" would serve two purposes. It could be used for ordering, and
could be displayed at the bottom of the page, but also changing
"Updated" indicates a status change for the entry:

Setting "Updated" implies that the aggregator should indicate that a
change has occurred to the user. Maybe the entry would be marked
unread.

> Are publishing tools now supposed to
> have heuristics that detect when the user fixes a typo
> versus adds two new paragraghs to a post? Is the user
> supposed to make this distinction themselves? 

I think it is a difference in language in the UI.  A checkbox that
says edit this entry, vs republish this entry.


If Atom only had "Modified" to go by, then if a publisher decides to
add an extra field to their old entries, geo-location maybe, then the
readers of the feed would see all of their old posts marked unread,
which might be a bit annoying.


> What tool vendor has asked for this functionality or
> has claimed this functionality makes their job easier?

Sorry can't help there.


-- 
Dave



From owner-atom-syntax@mail.imc.org  Wed Jul 14 13:58: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 NAA01886
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 13:58: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 i6EHmJNH039393;
	Wed, 14 Jul 2004 10:48: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 i6EHmJAA039392;
	Wed, 14 Jul 2004 10:48:19 -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 i6EHmIjb039385
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 10:48:18 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.22] (unknown [63.96.166.30])
	by mail.mnot.net (Postfix) with ESMTP
	id 3913B727D; Wed, 14 Jul 2004 10:48:22 -0700 (PDT)
In-Reply-To: <CC364146-D5B5-11D8-A6EC-000A95A51C9E@sun.com>
References: <6D6BAC41-D517-11D8-8C42-000A95A51C9E@sun.com> <40F46DAC.3030900@dehora.net> <D4AC57AE-D527-11D8-A503-000A95A51C9E@sun.com> <40F48A82.2020408@dehora.net> <3F81CFBF-D59D-11D8-A6EC-000A95A51C9E@sun.com> <40F5415E.5070100@dehora.net> <87k6x6mwef.fsf@nwalsh.com> <40F55860.7000800@dehora.net> <CC364146-D5B5-11D8-A6EC-000A95A51C9E@sun.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <FEA976F2-D5BD-11D8-AA19-000A95BD86C0@mnot.net>
Cc: Atom Syntax <atom-syntax@imc.org>,
        =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>
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: Low-hanging fruit: compulsory namespaces
Date: Wed, 14 Jul 2004 10:48:20 -0700
To: Tim Bray <Tim.Bray@Sun.COM>
X-Mailer: Apple Mail (2.618)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6EHmJjb039386
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


+1 - this is a best practice


On Jul 14, 2004, at 9:49 AM, Tim Bray wrote:

>
> On Jul 14, 2004, at 8:59 AM, Bill de hÓra wrote:
>
>> I would expect an utterance along the lines of 'inside Atom, you 
>> SHOULD qualify your non-namespace markup with xmlns=""' to aid 
>> robustness and increase happiness all round.
>
> Hmm... maybe I'm unusually lucky but I just haven't been bitten by 
> things going wrong in this space, and I think I use a reasonably 
> vanilla selection of XML tools.  So I'm still uncomfortable with 
> putting it in an RFC.  On the other hand, if Bill is one of many who 
> get bitten by this kind of thing and would like a good-practice note, 
> speak on up. -Tim
>
>

--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org  Wed Jul 14 14:06:07 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02378
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 14:06: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 i6EHwUsX041179;
	Wed, 14 Jul 2004 10: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 i6EHwUH6041178;
	Wed, 14 Jul 2004 10:58: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 i6EHwTXS041170
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 10:58:29 -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 i6EHxC9t029991;
	Wed, 14 Jul 2004 13:59:12 -0400
Message-ID: <40F5743E.3000803@intertwingly.net>
Date: Wed, 14 Jul 2004 13:58:22 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Dare Obasanjo <kpako@yahoo.com>
CC: Atom-syntax Syntax <atom-syntax@imc.org>
Subject: Re: a methodical approach to defining what date  elements we need
References: <20040714174807.44676.qmail@web41214.mail.yahoo.com>
In-Reply-To: <20040714174807.44676.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: <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:

> This still boils down to two relevant dates to me
> issued (which defaults to the created date but the
> user can override it) and last-modified. I'd like to
> know why you think there should be three and also am
> curious whether tools vendors like Roger agree with my
> assessment. 

You mentioned a date called "issued" (a name which remains problematic), 
"last-modified", and "created" (as the default for issued).  By my way 
of counting, that makes three.

I see the default for "issued" as being tool specific and therefore not 
normatively specified in the standard, particularly if the third date 
("created") is not present at all in the standard.

What I said about "created" is as follows[1]:

     This field is not intended for significantly[sic] used by an
     aggregator. It came into being simply because the first three blog
     vendors I happened to talk to identified this as a common piece of
     information that they all track. If it truly turns out to be a
     relatively common concept, then assigning it a common name is
     desirable from a tool migration point of view.

     If, on the other hand, this field does not survive the
     standardization process, then so be it.

- Sam Ruby

[1] http://www.imc.org/atom-syntax/mail-archive/msg06946.html



From owner-atom-syntax@mail.imc.org  Wed Jul 14 14:08:21 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02465
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 14:08:21 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EHw62Y041102;
	Wed, 14 Jul 2004 10:58: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 i6EHw60Q041101;
	Wed, 14 Jul 2004 10:58: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 i6EHw50U041093
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 10:58:05 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.22] (unknown [63.96.166.30])
	by mail.mnot.net (Postfix) with ESMTP
	id BABC1727D; Wed, 14 Jul 2004 10:58:08 -0700 (PDT)
In-Reply-To: <50434192-D5BD-11D8-A6EC-000A95A51C9E@textuality.com>
References: <A65D9796-D519-11D8-8C42-000A95A51C9E@textuality.com> <14be96d304071317541efca684@mail.gmail.com> <7FBABBD6-D531-11D8-A503-000A95A51C9E@textuality.com> <14be96d304071319181e2bf741@mail.gmail.com> <1393DBDA-D540-11D8-A503-000A95A51C9E@textuality.com> <opsa4zq3fhuvpchu@quark> <14be96d304071410083cc71f90@mail.gmail.com> <50434192-D5BD-11D8-A6EC-000A95A51C9E@textuality.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <5C39B3EC-D5BF-11D8-AA19-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: Atom Syntax <atom-syntax@imc.org>, Mark Pilgrim <pilgrim@gmail.com>
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: Don't bake discrimination into the Atom core (was Re: Low-hanging fruit: multipart/alternative)
Date: Wed, 14 Jul 2004 10:58:07 -0700
To: Tim Bray <tbray@textuality.com>
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>
Content-Transfer-Encoding: 7bit


I'm confused. Mark says that the current design allows inaccessible 
content, and therefore we shouldn't get rid of the current design?

What am I missing here?

Also, I'm not sure that allowing inaccessible content (i.e., images) in 
Atom is the same as "baking discrimination into the core"; by that 
logic, discrimination is baked into HTML.

I very much agree that we should take positive steps to accommodate 
accessibility.


On Jul 14, 2004, at 10:43 AM, Tim Bray wrote:

> On Jul 14, 2004, at 10:08 AM, Mark Pilgrim wrote:
>
>>>> "Nuke multipart/alternative for substantial cost and lack of a
>>>> compelling use-case."
>>>
>>> Done: <url: http://intertwingly.net/wiki/pie/PaceNukeMultipart>.
>>
>> -1 on nuking it without an alternative proposal in place.  Atom's
>> current content model allows inline content of arbitrary type.  This
>> includes binary content (such as images) that are intrinsically
>> inaccessible to people with certain disabilities.
>
> Ouch, it had somehow escaped my attention that this was an 
> accessibility issue.  Mark is clearly correct that this Cannot Be 
> Ignored.  On the other hand, I still think the current two levels of 
> <atom:content> distinguished by the type= value feels like bad markup 
> design and isn't clear enough what the real goal is.
>
> MarkP is the guy who gets paid to think about accessibility, and thus 
> the obvious candidate to write up a Pace for the right thing to do in 
> Atom to support this properly and at a cost low enough that we can 
> bully the vendors to do the right thing with some hope of success.  If 
> he's prepared to argue that the current multipart/alternative is the 
> best we can do, that's fine, but that argument has not so far been 
> made on the grounds of accessibility.   Also, I think that the spec 
> MUST have explicit normative content saying that if you are pushing 
> non-textual content through, you SHOULD use said mechanism to provide 
> accessible alternatives. -Tim

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Wed Jul 14 14:15: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 OAA02892
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 14: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 i6EI12ud041899;
	Wed, 14 Jul 2004 11:01:02 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6EI12Nd041898;
	Wed, 14 Jul 2004 11:01: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 i6EI11E4041869
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 11:01: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 63E047C0F3; Wed, 14 Jul 2004 20:58:56 +0200 (CEST)
Date: Wed, 14 Jul 2004 20:04:35 +0200
To: "Mark Pilgrim" <pilgrim@gmail.com>
Subject: Re: Don't bake discrimination into the Atom core (was Re: Low-hanging fruit: multipart/alternative)
Cc: "Tim Bray" <tbray@textuality.com>, Atom-Syntax <atom-syntax@imc.org>
References: <A65D9796-D519-11D8-8C42-000A95A51C9E@textuality.com> <14be96d304071317541efca684@mail.gmail.com> <7FBABBD6-D531-11D8-A503-000A95A51C9E@textuality.com> <14be96d304071319181e2bf741@mail.gmail.com> <1393DBDA-D540-11D8-A503-000A95A51C9E@textuality.com> <opsa4zq3fhuvpchu@quark> <14be96d304071410083cc71f90@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: <opsa425xgsuvpchu@quark>
In-Reply-To: <14be96d304071410083cc71f90@mail.gmail.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Wed, 14 Jul 2004 13:08:24 -0400, Mark Pilgrim <pilgrim@gmail.com> wrote:

> -1 on nuking it without an alternative proposal in place.

Okay. I'm not sure if a good alternative proposal will surface anytime  
soon, though. And in the meantime, the current, and very complex mechanism  
remains as the standard. I'm not sure that's a good idea.

> that we have some mechanism for allowing publishers to include
> accessible alternatives in the same feed, in a way that makes it
> clear that *this* is an accessible alternative to *that*.

The element does not have to be introduced to Atom with this pace, but it  
is at least a pace that proposes Atom to adopt Dublin Core's <relation>[1]  
element. The pace's name is PaceIssuedAndRelation[2] and is created as a  
solution for re-issuance of entries.

The good thing about <relation> is that it solves a lot of Atom's  
problems, all in one element, all from one standard. If we adopt it, Atom  
would be able to do:

   - Versioning and re-issuance (IsVersionOf and HasVersion)

   - Fragmentation (IsPartOf and HasPart)

     Could be used for linking individual parts of an entry to the
     entry itself, or individual entries to the «greater whole» the
     entries constitute.

   - Make assertions about alternate formats of a resource (IsFormatOf
     and HasFormat)

     Could be used as a replacement for the ambiguous 'rel="alternate"'
     link construct, to more explicitly state what what you're linking
     to.

     This could imho be a good alternative to the current 'multipart/
     alternative' mechanism.

   - Threading (References and IsReferencedBy)

   - Translations (IsBasedOn and IsBasisFor)

   - Dependancy-checks on resources (Requires and IsRequiredBy)

     I don't know a good use case for this, but one could imagine that
     an entry doesn't «work» without some external part of it not being
     downloaded or viewed with the entry.

I think this element solves so many problems that we should seriously  
consider to adopt it.

> If you thought I was passionate about certain issues before, you ain't
> seen nothin' yet.

I appreciate your passion in regard to accessibility, because you're the  
number one watchdog on inaccessible features and mechanisms. This is a  
quality we need, beccause I don't think there are a lot of people all too  
concerned with this, and if there are, they haven't got the experience  
needed to catch stuff like this alternative mechanism, for instance.

____
[1] <url: http://dublincore.org/documents/relation-element/>
[2] <url: http://intertwingly.net/wiki/pie/PaceIssuedAndRelation>

-- 
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 Jul 14 14: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 OAA02917
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 14: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 i6EI5SGO043073;
	Wed, 14 Jul 2004 11:05: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 i6EI5Sh1043072;
	Wed, 14 Jul 2004 11:05: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.206])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6EI5ROR043066
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 11:05:27 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d15so407657rng
        for <atom-syntax@imc.org>; Wed, 14 Jul 2004 11:05:30 -0700 (PDT)
Received: by 10.38.207.20 with SMTP id e20mr588592rng;
        Wed, 14 Jul 2004 11:05:30 -0700 (PDT)
Message-ID: <14be96d304071411052695dff9@mail.gmail.com>
Date: Wed, 14 Jul 2004 14:05:30 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Subject: Re: Don't bake discrimination into the Atom core (was Re: Low-hanging fruit: multipart/alternative)
Cc: Tim Bray <tbray@textuality.com>, Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <5C39B3EC-D5BF-11D8-AA19-000A95BD86C0@mnot.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <A65D9796-D519-11D8-8C42-000A95A51C9E@textuality.com> <14be96d304071317541efca684@mail.gmail.com> <7FBABBD6-D531-11D8-A503-000A95A51C9E@textuality.com> <14be96d304071319181e2bf741@mail.gmail.com> <1393DBDA-D540-11D8-A503-000A95A51C9E@textuality.com> <opsa4zq3fhuvpchu@quark> <14be96d304071410083cc71f90@mail.gmail.com> <50434192-D5BD-11D8-A6EC-000A95A51C9E@textuality.com> <5C39B3EC-D5BF-11D8-AA19-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 Wed, 14 Jul 2004 10:58:07 -0700, Mark Nottingham <mnot@mnot.net> wrote:
> I'm confused. Mark says that the current design allows inaccessible
> content, and therefore we shouldn't get rid of the current design?
> 
> What am I missing here?

The current design allows inaccessible content *and* accessible
alternatives.  Tim is recommending removing multipart/alternative but
*not* simplifying the content model.  This would leave the spec in a
state that publishers with a way to publish inaccessible content, but
no way to publish accessible alternatives, which is unacceptable.

Note: publishers frequently publish inaccessible content without
accessible alternatives.  That is an advocacy problem, not a
specification problem.  What Tim proposed would create a specification
problem.

Also note that I am not a fan of the type="multipart/alternative"
syntax or design.  But getting rid of it without an
accessibility-enabled alternative is much worse.  We can discuss
replacing the syntax with something better, but we can't simply remove
the functionality.

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Wed Jul 14 14:24: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 OAA04422
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 14:24: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 i6EI9fTs043811;
	Wed, 14 Jul 2004 11:09: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 i6EI9fiE043810;
	Wed, 14 Jul 2004 11:09:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.197])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6EI9eev043802
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 11:09:41 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d19so527136rnf
        for <atom-syntax@imc.org>; Wed, 14 Jul 2004 11:09:32 -0700 (PDT)
Received: by 10.38.72.80 with SMTP id u80mr364907rna;
        Wed, 14 Jul 2004 11:09:32 -0700 (PDT)
Message-ID: <14be96d304071411092c2c44f4@mail.gmail.com>
Date: Wed, 14 Jul 2004 14:09:32 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Sam Ruby <rubys@intertwingly.net>
Subject: Re: PaceMustBeWellFormed
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <40F56B2A.8050500@intertwingly.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <14be96d30407061142441f70ee@mail.gmail.com> <40F56B2A.8050500@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 Wed, 14 Jul 2004 13:19:38 -0400, Sam Ruby <rubys@intertwingly.net> wrote:
> (6.1 1) I disagree with the recommendation that charset be provided.  In
> fact, one of the primary benefits I see to recommending application/*
> instead of text/* is that one can omit the charset and obtain a sensible
> result.

http://www.w3.org/International/questions/qa-encoding-alts.html

> (6.1 1) I would, howevever, be supportive of a statement that if a
> charset were provided with any application/* MIME type, THEN it MUST
> match what the encoding that would have been determined had the charset
> been omitted.

That is not an RFC-2119-compliant use of the word "MUST".  Conflicting
metadata declarations are not an interoperability problem, because
there are clear precedence rules governing which one wins.  (The
charset in the HTTP headers always wins.)

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Wed Jul 14 14:39: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 OAA05364
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 14: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 i6EINeIA046425;
	Wed, 14 Jul 2004 11:23: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 i6EINe3N046424;
	Wed, 14 Jul 2004 11:23:40 -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 i6EINdGV046416
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 11:23:39 -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 i6EIOJfh031126;
	Wed, 14 Jul 2004 14:24:19 -0400
Message-ID: <40F57A22.5060409@intertwingly.net>
Date: Wed, 14 Jul 2004 14:23:30 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 Pilgrim <pilgrim@gmail.com>
CC: Atom-Syntax <atom-syntax@imc.org>, EB2M-MRT@asahi-net.or.jp
Subject: Re: PaceMustBeWellFormed
References: <14be96d30407061142441f70ee@mail.gmail.com> <40F56B2A.8050500@intertwingly.net> <14be96d304071411092c2c44f4@mail.gmail.com>
In-Reply-To: <14be96d304071411092c2c44f4@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


Mark Pilgrim wrote:
> 
>>(6.1 1) I would, howevever, be supportive of a statement that if a
>>charset were provided with any application/* MIME type, THEN it MUST
>>match what the encoding that would have been determined had the charset
>>been omitted.
> 
> That is not an RFC-2119-compliant use of the word "MUST".  Conflicting
> metadata declarations are not an interoperability problem, because
> there are clear precedence rules governing which one wins.  (The
> charset in the HTTP headers always wins.)

It certainly is valid for an RFC produced by the AtomPub working group 
to constrain the permissable values of the charset parameter of the 
Content-Type header MUST be when the application/atom+xml MIME type is 
used in conjunction with either the AtomPub format or protocol.

I would also suggest that we coordinate with RFC 3023 to promote the use 
of similar language in that specification when application/xml is used.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Wed Jul 14 14: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 OAA05639
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 14: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 i6EIPMfG047120;
	Wed, 14 Jul 2004 11: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 i6EIPMjf047119;
	Wed, 14 Jul 2004 11:25: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.192])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6EIPL0N047108
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 11:25:21 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d15so409357rng
        for <atom-syntax@imc.org>; Wed, 14 Jul 2004 11:25:25 -0700 (PDT)
Received: by 10.38.207.60 with SMTP id e60mr102087rng;
        Wed, 14 Jul 2004 11:25:24 -0700 (PDT)
Message-ID: <14be96d304071411257aafcc8e@mail.gmail.com>
Date: Wed, 14 Jul 2004 14:25:24 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Sam Ruby <rubys@intertwingly.net>
Subject: Re: PaceMustBeWellFormed
Cc: Atom-Syntax <atom-syntax@imc.org>, eb2m-mrt@asahi-net.or.jp
In-Reply-To: <40F57A22.5060409@intertwingly.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <14be96d30407061142441f70ee@mail.gmail.com> <40F56B2A.8050500@intertwingly.net> <14be96d304071411092c2c44f4@mail.gmail.com> <40F57A22.5060409@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 Wed, 14 Jul 2004 14:23:30 -0400, Sam Ruby <rubys@intertwingly.net> wrote:
> It certainly is valid for an RFC produced by the AtomPub working group
> to constrain the permissable values of the charset parameter of the
> Content-Type header MUST be when the application/atom+xml MIME type is
> used in conjunction with either the AtomPub format or protocol.

Not if you're normatively referencing RFC 2119, it's not.

> I would also suggest that we coordinate with RFC 3023 to promote the use
> of similar language in that specification when application/xml is used.

That is well beyond our charter.

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Wed Jul 14 14:45: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 OAA05740
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 14:45: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 i6EIUPG4048158;
	Wed, 14 Jul 2004 11: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 i6EIUPpx048157;
	Wed, 14 Jul 2004 11:30:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EIUOnO048150
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 11:30:24 -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 1BkoWP-0008Dm-NA; Wed, 14 Jul 2004 18:30:25 +0000
Message-ID: <40F57BC1.9070401@franklinmint.fm>
Date: Wed, 14 Jul 2004 14:30:25 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mark Pilgrim <pilgrim@gmail.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Don't bake discrimination into the Atom core (was Re: Low-hanging
 fruit: multipart/alternative)
References: <A65D9796-D519-11D8-8C42-000A95A51C9E@textuality.com> <14be96d304071317541efca684@mail.gmail.com> <7FBABBD6-D531-11D8-A503-000A95A51C9E@textuality.com> <14be96d304071319181e2bf741@mail.gmail.com> <1393DBDA-D540-11D8-A503-000A95A51C9E@textuality.com> <opsa4zq3fhuvpchu@quark> <14be96d304071410083cc71f90@mail.gmail.com> <50434192-D5BD-11D8-A6EC-000A95A51C9E@textuality.com> <5C39B3EC-D5BF-11D8-AA19-000A95BD86C0@mnot.net> <14be96d304071411052695dff9@mail.gmail.com>
In-Reply-To: <14be96d304071411052695dff9@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - web02.designerslab.net
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - franklinmint.fm
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


Mark Pilgrim wrote:

>Also note that I am not a fan of the type="multipart/alternative"
>syntax or design.  But getting rid of it without an
>accessibility-enabled alternative is much worse.  We can discuss
>replacing the syntax with something better, but we can't simply remove
>the functionality.
>  
>

What's the use case here? If we remove multipart/alternative, 
inaccessible content will still be surrounded by plain text or HTML 
metadata, and could still have a variety of <link rel="alternate"> 
elements that point to other representations (could be in the same 
feed). Can we improve on this, or do we just need to be more explicit 
about alternate representations?

I don't see mulitpart/alternative helping with photographs, for instance.

Robert Sayre



From owner-atom-syntax@mail.imc.org  Wed Jul 14 14:49: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 OAA05940
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 14: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 i6EIeJtR049652;
	Wed, 14 Jul 2004 11:40:19 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6EIeJT9049648;
	Wed, 14 Jul 2004 11:40:19 -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 i6EIeI69049640
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 11:40:18 -0700 (PDT)
	(envelope-from danbri@w3.org)
Received: by homer.w3.org (Postfix, from userid 13522)
	id 0BA604EFD8; Wed, 14 Jul 2004 14:40:22 -0400 (EDT)
Date: Wed, 14 Jul 2004 14:40:22 -0400
From: Dan Brickley <danbri@w3.org>
To: Mark Nottingham <mnot@mnot.net>
Cc: Tim Bray <tbray@textuality.com>, Atom Syntax <atom-syntax@imc.org>,
        Mark Pilgrim <pilgrim@gmail.com>
Subject: Re: Don't bake discrimination into the Atom core (was Re: Low-hanging fruit: multipart/alternative)
Message-ID: <20040714184022.GU3805@homer.w3.org>
References: <A65D9796-D519-11D8-8C42-000A95A51C9E@textuality.com> <14be96d304071317541efca684@mail.gmail.com> <7FBABBD6-D531-11D8-A503-000A95A51C9E@textuality.com> <14be96d304071319181e2bf741@mail.gmail.com> <1393DBDA-D540-11D8-A503-000A95A51C9E@textuality.com> <opsa4zq3fhuvpchu@quark> <14be96d304071410083cc71f90@mail.gmail.com> <50434192-D5BD-11D8-A6EC-000A95A51C9E@textuality.com> <5C39B3EC-D5BF-11D8-AA19-000A95BD86C0@mnot.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5C39B3EC-D5BF-11D8-AA19-000A95BD86C0@mnot.net>
User-Agent: Mutt/1.5.6+20040523i
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-07-14 10:58-0700]
> 
> I'm confused. Mark says that the current design allows inaccessible 
> content, and therefore we shouldn't get rid of the current design?
> 
> What am I missing here?
> 
> Also, I'm not sure that allowing inaccessible content (i.e., images) in 
> Atom is the same as "baking discrimination into the core"; by that 
> logic, discrimination is baked into HTML.

A lot of folk are very interested in RSS/Atom feeds for sharing of
digital images, typically photo blogs. Often from mobile phones, eg.
here's one I contribute to with some friends:
http://moblog.nicecupoftea.org/

While JPGs may themselves be inaccessible, it is perfectly possible to 
package them with metadata which carries more info about their content
to search engines, directories, non-visual browsers and to visually
impaired users. 

For example, Matt Biddulph has done some nice work using RDF, Wordnet,
FOAF and Dublin Core.
http://www.hackdiary.com/archives/000020.html
http://www.hackdiary.com/archives/000034.html
http://picdiary.com/

This shows that search tools built over namespace-extended feeds can 
make the items described by those feeds more accessible. Eg. searching
over the people in the images, 
http://www.picdiary.com/cgi-bin/findmbox.pl?mbox=mailto:edd@usefulinc.com
or by the things in the images, 
http://www.picdiary.com/cgi-bin/search.pl?word=hotel (not working
currently, ahem). 

Rather than try to stop folk including (by value or reference; principle
is the same) audio and image content in their feeds, I believe our
energies would be better spent encouraging them to associate extra info
with those items. I'm well aware that people don't like to take the time
to add metadata, but also that folk do like their photos to be findable
again and that extension namespaces can play a role in supporting that. 

cheers,

Dan

ps. http://www.kanzaki.com/works/2004/imgdsc/0106.html
http://kanzaki.com/courier/xs/works/2003/imagedesc/photo.rdf.html
http://kanzaki.com/test/exif2rdf?xsl=on&ul=/works/2003/imagedesc/031114_2152.jpg
for more examples, the latter using XSLT and exploiting auto-embedded 
GPS info.



From owner-atom-syntax@mail.imc.org  Wed Jul 14 15:15: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 PAA08453
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 15:15: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 i6EJ6YjD053701;
	Wed, 14 Jul 2004 12:06: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 i6EJ6YMu053700;
	Wed, 14 Jul 2004 12:06:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EJ6Xn6053681
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 12:06: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 <20040714190632015003k2tde>; Wed, 14 Jul 2004 19:06:32 +0000
Date: Wed, 14 Jul 2004 13:06:31 -0600
Subject: Re: a methodical approach to defining what date  elements we need
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: <40F56213.1080305@intertwingly.net>
Message-Id: <EA8E424E-D5C8-11D8-AE1C-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 Wednesday, July 14, 2004, at 10:40  AM, Sam Ruby wrote:
> Antone Roundy wrote:
>> -1.  I don't see any reason not to require timezone info in all 
>> dates, as long as -00:00 (unknown) is allowed.
...
> 2004-07-14T12:00:00-04:00 means "noon, EDT"
>
> 2004-07-14T12:00:00+00:00 means "noon, UTC"
>
> 2004-07-14T12:00:00-00:00 means "the same point in time as noon, UTC, 
> but in an undeclared timezone"
>
> "-00:00" notation is apparently meant to convey the information that 
> "this timestamp has been canonicalized to UTC".
>
Ah, got it.  In that case, would the following be appropriate?

a) Timezone's aren't required for any subjective dates ("display") that 
make it into the spec (for compatibility with existing systems).
b) ...but if the DO specify a timezone (assuming we require them to be 
ISO 8601 (is that right?) dates), the timezone must be numeric or Z 
(meaning that things like "PST" aren't allowed).
c) All objective dates (assuming we require a timezone) must 
canonicalize to UTC and specify -00:00 as their timezone.

I would think that if we require canonicalization to UTC, that -00:00 
would be the appropriate way to express it, rather than Z or +00:00, 
which seems (in the presence of the -00:00 option) to imply that UTC is 
the "native" timezone for the entry.  On the other hand, how important 
is this?  I won't cry if we don't require it.



From owner-atom-syntax@mail.imc.org  Wed Jul 14 15:26: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 PAA09594
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 15:26: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 i6EJHRf8055541;
	Wed, 14 Jul 2004 12:17: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 i6EJHRGi055540;
	Wed, 14 Jul 2004 12:17:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rongo.sixapart.com (dsl081-057-015.sfo1.dsl.speakeasy.net [64.81.57.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EJHRs5055521
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 12:17:27 -0700 (PDT)
	(envelope-from ezra@sixapart.com)
Received: from [192.168.100.250] (Aphrodite.sm.sixapart.com [192.168.100.250])
	by rongo.sixapart.com (Postfix) with ESMTP id 4FCE547BFD
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 11:14:00 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v618)
In-Reply-To: <p06110469bd19a54668f4@[10.20.30.249]>
References: <40E16215.6070507@intertwingly.net> <40EC9915.4050406@intertwingly.net> <3f1451f504070718267c5526b4@mail.gmail.com> <40ED6392.2000107@franklinmint.fm> <3f1451f504070810104a5122e7@mail.gmail.com> <3f1451f504070810296ca252e7@mail.gmail.com> <p0611044fbd18e903bdd9@[10.20.30.249]> <40F37A14.6040908@aol.net> <14be96d3040713053039dbde91@mail.gmail.com> <p06110469bd19a54668f4@[10.20.30.249]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <7020B75C-D5CA-11D8-B222-000A95CFF6CC@sixapart.com>
Content-Transfer-Encoding: 7bit
From: Ezra Cooper <ezra@sixapart.com>
Subject: Re: PaceSecurityServices
Date: Wed, 14 Jul 2004 12:17:24 -0700
To: atom-syntax@imc.org
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>
Content-Transfer-Encoding: 7bit


On Jul 13, 2004, at 7:43 AM, Paul Hoffman / IMC wrote:

> At 8:30 AM -0400 7/13/04, Mark Pilgrim wrote:
>> On Mon, 12 Jul 2004 22:58:44 -0700, John Panzer <jpanzer@aol.net> 
>> wrote:
>>>  I am uncertain about making Digest Auth a SHOULD rather than a MUST.
>>>  What's the reason for leaving the wriggle room?
>>
>> Some implementations (most wikis, some comment systems) have no need
>> for authentication of any kind.
>
> Exactly right. For interoperability, no authentication is needed, 
> since some systems will not want it. If you are going to use 
> authentication, you SHOULD use Digest Auth. If you can't use Digest 
> Auth but you still need authentication, you need to use something 
> outside the spec.

+1

Authentication should be optional; when it is used, I think it's best 
if we have selected one protocol that implementations SHOULD use. If 
implementations have some specific reason to use another protocol, that 
can still be compliant.

I am working on the 'running code' part of the deal--using some 
variations on Digest.

Ezra



From owner-atom-syntax@mail.imc.org  Wed Jul 14 15:38: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 PAA10817
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 15:38: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 i6EJOfoH056753;
	Wed, 14 Jul 2004 12:24: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 i6EJOfVc056751;
	Wed, 14 Jul 2004 12:24:41 -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 i6EJNd90056593
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 12:24:40 -0700 (PDT)
	(envelope-from davep@dpawson.co.uk)
Received: (qmail 6901 invoked from network); 14 Jul 2004 19:43:53 -0000
Received: from dpawson.gotadsl.co.uk (HELO ?192.168.2.6?) (davep@dpawson.co.uk@81.6.251.105)
  by 0 with SMTP; 14 Jul 2004 19:43:53 -0000
Subject: Re: a methodical approach to defining what date  elements we need
From: Dave Pawson <davep@dpawson.co.uk>
Reply-To: davep@dpawson.co.uk
To: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <opsa3eddg8uvpchu@quark>
References: <14B72756-D419-11D8-9D0B-003065EA6144@geckotribe.com>
	 <40F2C2CD.9020307@intertwingly.net>
	 <47071860-D42A-11D8-82B1-000A95DC3D90@mac.com>
	 <opsa1nlh1u6dxgxk@mail.online.no>
	 <6C2098C54ED33AE163D3E2F5@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
	 <opsa3eddg8uvpchu@quark>
Content-Type: text/plain; charset=
Message-Id: <1089832992.2849.16.camel@homer>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) 
Date: Wed, 14 Jul 2004 20:23:12 +0100
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


On Tue, 2004-07-13 at 21:11, AsbjÞrn Ulsberg wrote:
> > When an author is posting at 3am local time, or during Ramadan, the
> > author's view of the date matters, and should normally be preferred.
> 
> Preferred by whom? Not by me, to be sure. And not by NRK. And not by EBU.  
> We want dates we can trust, preferably provided by the tools issuing the  
> entries. _All_ tools has this action.

And what about people generating atom content?
Cut and paste from ....?

regards DaveP



From owner-atom-syntax@mail.imc.org  Wed Jul 14 15:40: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 PAA11072
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 15:40: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 i6EJSX16057356;
	Wed, 14 Jul 2004 12: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 i6EJSXGS057355;
	Wed, 14 Jul 2004 12:28:33 -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 i6EJSWDW057349
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 12:28:33 -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 i6EJTFHR001577;
	Wed, 14 Jul 2004 15:29:15 -0400
Message-ID: <40F58959.20508@intertwingly.net>
Date: Wed, 14 Jul 2004 15:28:25 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Antone Roundy <antone@geckotribe.com>
CC: atom-syntax@imc.org
Subject: Re: a methodical approach to defining what date  elements we need
References: <EA8E424E-D5C8-11D8-AE1C-003065EA6144@geckotribe.com>
In-Reply-To: <EA8E424E-D5C8-11D8-AE1C-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:
> 
> a) Timezone's aren't required for any subjective dates ("display") that 
> make it into the spec (for compatibility with existing systems).

We don't have consensus on that, but yes, that is what I would advocate.

> b) ...but if the DO specify a timezone (assuming we require them to be 
> ISO 8601 (is that right?) dates), the timezone must be numeric or Z 
> (meaning that things like "PST" aren't allowed).

Time zones in ISO 8601 (and therefore in all profiles of ISO 8601, 
include W3CDTF and RFC 3339) are expressed numerically.  PST is not allowed.

> c) All objective dates (assuming we require a timezone) must 
> canonicalize to UTC and specify -00:00 as their timezone.

Some people feel that way.  I don't.  My read of RFC 3339 is that the 
IETF does not, in general, feel that way.  But, yes, if that turns out 
to be the consensus, then specifying -00:00 would be appropriate.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Wed Jul 14 15:44: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 PAA11436
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 15:44:42 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EJUttQ057790;
	Wed, 14 Jul 2004 12:30: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 i6EJUtx9057789;
	Wed, 14 Jul 2004 12:30:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail3.edisontel.com (mail3.edisontel.com [62.94.0.36])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EJUs6Z057767
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 12:30:54 -0700 (PDT)
	(envelope-from danny666@virgilio.it)
Received: from virgilio.it (62.94.1.30) by mail3.edisontel.com (7.0.024)
        id 3FB47F7B00966A2B; Wed, 14 Jul 2004 21:30:51 +0200
Message-ID: <40F58964.1020908@virgilio.it>
Date: Wed, 14 Jul 2004 21:28:36 +0200
From: Danny Ayers <danny666@virgilio.it>
Reply-To: danny@dannyayers.com
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Norman Walsh <ndw@nwalsh.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: a methodical approach to defining what date  elements we need
References: <63E12F93-D452-11D8-9D0B-003065EA6144@geckotribe.com> <opsa3dl3q7uvpchu@quark> <87hdsbvcpv.fsf@nwalsh.com>
In-Reply-To: <87hdsbvcpv.fsf@nwalsh.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


Norman Walsh wrote:

>I'm now convinced that it would be better to use just two:
>
>Issued = when I published the essay
>Modified = when I last changed any of the bits in the entry.
>
>If I make a "significant" change, I should
>
>1. Create a new entry with a new ID and new dates
>2. Indicate that this new entry dcterms:replaces the original.
>2. Update the original to say it's been dcterms:isReplacedBy the new one.
>
>It's more work, but it'll make for a better historical record.
>  
>

+1

Some more justification: *published* is the key word on the web, not 
created. The lazy vendor may fall back on modified == changed 
significantly, but that's not a major problem, the discerning customer 
can work around that.

These dates are primarily for machine-processing (search, sort, display 
order). A date like "issued" as a display date is a different thing - it 
should be part of the content, perhaps as an namespaced extension, or 
alternately:

<atom:entry...>
   <atom:content>
         <xhtml:p>blah blah</xhtml:p>
         <atom:date> 16th July</atom:date>
   </atom:content>
   <atom:issued>2004-07-12...</atom:issued>
   <atom:modified>2004-07-13..<atom:modified>
</atom:entry>

Cheers,
Danny.

-- 

Raw
http://dannyayers.com



From owner-atom-syntax@mail.imc.org  Wed Jul 14 15:45: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 PAA11591
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 15:45: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 i6EJWbCT058078;
	Wed, 14 Jul 2004 12:32: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 i6EJWbPI058077;
	Wed, 14 Jul 2004 12:32:37 -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 i6EJWaBT058045
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 12:32:36 -0700 (PDT)
	(envelope-from roger@agincourtmedia.com)
Received: from biggreen ([216.63.148.42]) by journurl.com with MailEnable ESMTP; Wed, 14 Jul 2004 14:31:52 -0500
From: "Roger B." <roger@agincourtmedia.com>
To: "'Tim Bray'" <Tim.Bray@Sun.COM>, "'Atom Syntax'" <atom-syntax@imc.org>
Subject: RE: a methodical approach to defining what date  elements we need
Date: Wed, 14 Jul 2004 14:33:35 -0500
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: <CE649170-D5BD-11D8-A6EC-000A95A51C9E@sun.com>
thread-index: AcRpyoDkIj7ehD8mSX2Vml+atTIkjQAAsyig
Message-ID: <5362E0FB475943BDA23EBE738EFB5.MAI@journurl.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


> Frankly I don't see any interesting current or future use for "created"
> but I guess some do.

Tim: I keep thinking "import/export", but now that I consider it a bit, it
might be better to save that for an archive:created extension or something.
If you take away atom:created, it should be easier for publishers to intuit
the relation between the remaining date elements and their own app's output.

Here's a list of date-related entry tags from various apps:

Blogger: 
<$BlogItemDateTime$>

MT: 
<$MTEntryDate$>
<$MTEntryModifiedDate$>

WordPress: 
<?php the_date('Y/m/d','before','after',display); ?>

BigBlogTool: 
/.timestamp

ExpressionEngine: 
{entry_date}
{edit_date}

JournURL: 
<weblog:date type="published">
<weblog:date type="updated">
<weblog:date type="created">

Looks to me as if picking the right date for the right element would be
pretty easy for most template systems if "created" is taken off the table.
As long as there is an atom:created in the core, I suspect there will be
people scratching their heads and trying to figure out when to use it and
what goes in it... all for no immediate benefit, at least in terms of pure
syndication.

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/






From owner-atom-syntax@mail.imc.org  Wed Jul 14 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 QAA13580
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 16:08:15 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EJuGVI061970;
	Wed, 14 Jul 2004 12: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 i6EJuGQ9061969;
	Wed, 14 Jul 2004 12:56: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] (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 i6EJuCBb061942;
	Wed, 14 Jul 2004 12:56:13 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p06110426bd1b3deea52a@[10.20.30.249]>
In-Reply-To: <14be96d304071411092c2c44f4@mail.gmail.com>
References: <14be96d30407061142441f70ee@mail.gmail.com>
 <40F56B2A.8050500@intertwingly.net>
 <14be96d304071411092c2c44f4@mail.gmail.com>
Date: Wed, 14 Jul 2004 12:56:40 -0700
To: Mark Pilgrim <pilgrim@gmail.com>, Sam Ruby <rubys@intertwingly.net>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: PaceMustBeWellFormed
Cc: Atom-Syntax <atom-syntax@imc.org>
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:09 PM -0400 7/14/04, Mark Pilgrim wrote:
>On Wed, 14 Jul 2004 13:19:38 -0400, Sam Ruby <rubys@intertwingly.net> wrote:
>>  (6.1 1) I disagree with the recommendation that charset be provided.  In
>>  fact, one of the primary benefits I see to recommending application/*
>>  instead of text/* is that one can omit the charset and obtain a sensible
>>  result.
>
>http://www.w3.org/International/questions/qa-encoding-alts.html

Not sure what this response means. That page has ??? and XXX in a few 
places, and is quite clearly not finshed (or even that clear in 
places).

>  > (6.1 1) I would, howevever, be supportive of a statement that if a
>  > charset were provided with any application/* MIME type, THEN it MUST
>>  match what the encoding that would have been determined had the charset
>>  been omitted.
>
>That is not an RFC-2119-compliant use of the word "MUST".  Conflicting
>metadata declarations are not an interoperability problem, because
>there are clear precedence rules governing which one wins.  (The
>charset in the HTTP headers always wins.)

Correct. If the precedence is given by a MUST, and if what you are 
talking about is not first in the precedence, then a MUST is 
incorrect according to a careful (and possibly legalistic) reading 
RFC 2119.

At 2:25 PM -0400 7/14/04, Mark Pilgrim wrote:
>  > I would also suggest that we coordinate with RFC 3023 to promote the use
>>  of similar language in that specification when application/xml is used.
>
>That is well beyond our charter.

Fully disagree. RFC 3023 is a pre-existing standard in the IETF; we 
should follow it to the best of our ability, and say why we aren't 
when we don't.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Wed Jul 14 16:09: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 QAA13799
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 16:09: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 i6EJxwDC062506;
	Wed, 14 Jul 2004 12:59: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 i6EJxwja062505;
	Wed, 14 Jul 2004 12:59:58 -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 i6EJxqe5062486;
	Wed, 14 Jul 2004 12:59:53 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p06110428bd1b41426c9a@[10.20.30.249]>
In-Reply-To: <14be96d3040714073014f7ba04@mail.gmail.com>
References: <4005DCF4-D55C-11D8-A6EC-000A95A51C9E@sun.com>
 <40F53359.6030206@franklinmint.fm>
 <14be96d3040714073014f7ba04@mail.gmail.com>
Date: Wed, 14 Jul 2004 13:00:23 -0700
To: Mark Pilgrim <pilgrim@gmail.com>, mint@franklinmint.fm
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: Problem of enveloping signatures (was Re: Work Queue Rotation
 #3)
Cc: Tim Bray <tim.bray@sun.com>, Atomlist Syntax <atom-syntax@imc.org>
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 10:30 AM -0400 7/14/04, Mark Pilgrim wrote:
>Bottom line: XML digital signatures are OK, but we should explicitly
>profile the dsig spec to state that enveloped signatures are *not* OK.
>  And we should have a standard "Atom-ish" way of linking to externally
>stored signatures.

+1

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Wed Jul 14 16: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 QAA13843
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 16:10: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 i6EJtVIk061834;
	Wed, 14 Jul 2004 12:55:31 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6EJtVT7061833;
	Wed, 14 Jul 2004 12:55:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EJtTQW061810
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 12:55: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 205587C0F3; Wed, 14 Jul 2004 22:53:24 +0200 (CEST)
Date: Wed, 14 Jul 2004 21:59:29 +0200
To: "Tim Bray" <Tim.Bray@sun.com>
Subject: Re: a methodical approach to defining what date  elements we need
Cc: Atom-Syntax <atom-syntax@imc.org>, "Sam Ruby" <rubys@intertwingly.net>
References: <20040714153153.98934.qmail@web41201.mail.yahoo.com> <D1CE520E-D5B1-11D8-A6EC-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: <opsa48hfo1uvpchu@quark>
In-Reply-To: <D1CE520E-D5B1-11D8-A6EC-000A95A51C9E@sun.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Wed, 14 Jul 2004 09:21:11 -0700, Tim Bray <Tim.Bray@Sun.COM> wrote:

> This minor/major thing is an invitation to endless hairsplitting  
> disputes.

Not when people want it, and are exploiting the vague description of both  
Dublin Core and Atom to use 'issued' to signify «major updates» and  
'modified' to signify «minor updates». If this is something people want,  
Atom should define a rigid mechanism for it, instead of leaving all the  
details up to the implementor.

Dublin Core has the semantics regarding this functionality defined in the  
'relation'[1] element. Atom can be more explicit on the semantics and say  
that 'modified' is only to be updated when typografical erratas are made  
to an entry. Effectively rewriting a whole entry is something people would  
be interested in telling about, and this is something I can understand.  
What they then should do is issue a new entry with a new ID and a  
<relation> elements that has an 'is-part-of' attribute that points to the  
old ID.

Minor changes is reflected in atom:modified, while major changes is  
already supported, because the ID of the story (not the original entry  
itself -- it should be left untouched) changes.

> It's a binary decision: is it major enough for the change to be
> reflected in the feed, yes or no.

I agree to this for the current Atom model. 'issued' should not be  
altered, only 'modified'.

> Without a shared definition of what major/minor *means*, this
> will produce zero interoperability.

It is a mighty simple explanation, but some people might have trouble  
comprehending the difference between «small typographical changes» and  
«major rewrites that potentially changes the meaning of the article» -- I  
don't know. There are of course borderline cases between minor and major  
changes, but those seem so rare that I don't think it's worth ponding much  
on.

What's great about this solution is that it's opt-in. If you want «major  
change» functionality, use the <relation> element and issue a new entry.  
If not, use the <modified> element. The support for <relation> is optional  
both on the consumer and producer side, but everyone still gets what they  
want out of the Atom model since it natively supports both.

What would be very problematic is if someone redefined the meaning of  
'issued' to mean 're-issued' or 'last-issued', because then it would be  
impossible to know what to do when facing the 'issued' element.

About the opt-in of <relation>; it does not impose any problems on either  
the producing or consuming side, as explained below:

---------------

We have a scenario of two users writing in their own and reading each  
other's blogs, and a third user just reading the other's blogs. The  
authors are Anne and Peter, while the reading user is Elisabeth.

Anne uses an authoring tool called «Simple Type» that does not support  
<relation>. She uses an aggregator called «Simple Read» that also doesn't  
support <relation>.

Peter uses a combined authoring and aggregation tool called «Complex Type»  
that does support <relation>.

Elisabeth uses «Complex Read» which supports <relation>.

1. Anne publishes an entry onto her blog, called «My cat is five years  
old!». This entry shows up in an Atom feed with the date 'issued' set to  
the (objective) published date of the entry, and the 'modified' date set  
to the same date.

2. Peter fires up «Complex Type» to read Anne's latest writings. The entry  
«My cat is five years old!» shows up, because it has a new atom:id which  
his aggregator has never seen before.

3. Elisabeth fires up «Complex Read» to read Anne's latest writings. The  
entry «My cat is five years old!» shows up, because it has a new atom:id  
which her aggregator has never seen before. Elisabeth closes «Complex  
Read» and turns off the computer because she has to go to the store.

4. Peter presses the [Write about] button in «Complex Type», which opens a  
new edit window with the subject «My cat is five years old!». Peter edits  
this subject so it says «Anne's cat is five years old!». He then writes  
some words about Anne's cat, how it's so smart it can open doors all by  
itself, and so on. During the writing process of this entry, he saves it  
several times.

5. Peter publishes the entry onto his blog. This entry shows up in an Atom  
feed with 'created' set to the first time he pressed [Save], 'modified'  
set to the last time he pressed [Save] and 'issued' set to the time he  
pressed [Publish]. The entry also contains a 'relation' element with the  
attribute 'is-based-on' set to the ID of Anne's entry.

6. Anne fires up «Simple Read» to read Peter's laterst writings. The entry  
«Anne's cat is five years old» shows up  because it has a new atom:id  
which his aggregator has never seen before. The aggregator does not show  
or do anything special with the 'relation' element, because «Simple Type»  
does not support it.

7. Anne realizes when reading Peter's entry that her cat isn't five, but  
four years old. «Oh my god, how embarrasing», she thinks, and rushes to  
edit her entry and correct the error. She opens up «Simple Type», finds  
the entry «My cat is five years old!» and edits the subject to say «My cat  
is four years old!».

8. Anne presses [Save] again, which instantly publishes the changes to the  
web («Simple Type» doesn't have support for drafts). The entry now shows  
up in her Atom feed with the same 'issued' date, but with an altered  
'modified' date, set to the time she pressed [Save].

8. In the meantime, Peter has written some entries about trivial stuff  
like what he has done that day, his excitement of soon having holidays and  
such.

9. While writing, Peter notices that something has happened in Anne's  
weblog. He is so interested in what goes on at her blog, that he's set his  
aggregator to «Show all changes» on her feed. He has set many other feeds  
to «Only show significant changes», because he's not so interested in the  
small changes authors of them do. When Peter opens the «Anne» folder in  
«Complex Type», he sees that «My cat is four years old!» is in bold. He  
notices that the title has changed and that the cat is not five, but four  
years old.

9. Peter immediately switches to the entry view of «Complex Type» and  
selects his «Anne's cat is five years old!» entry. He then presses the  
[Rewrite] (but not [Edit]) button, because he wants to add some major  
parts to his entry about how absent-minded Anne can be, and not only  
change the title. A new window, containing a copy of the old entry, opens.  
He edits the title, appends two paragraphs at the top explaining in a  
humorous way the error Anne has made, and how lost she can be sometimes.

10. Peter publishes the entry onto his blog. It has now 'created' set to  
the first time he pressed [Save] in this entry (which he pressed two times  
this time), 'modified' set to the last time he pressed [Save] and 'issued'  
set to the time he pressed [Publish]. The entry also has two 'relation'  
elements. The first has 'is-based-on' set to the ID of Anne's entry. The  
other has 'is-version-of' set to the ID of the previous entry he wrote  
about Anne's cat.

Moreover, the original entry Peter wrote is altered and a 'relation'  
element is inserted that has an attribute 'has-version' which points to  
the new entry Peter wrote.

11. Peter publishes a couple of more entries to his blog before he throws  
in the towel and goes to bed.

12. Elisabeth is now home from the store, so she turns on her computer and  
opens up «Complex Read» to see if there are any news. Elisabeth, which  
also subscribes to Peter's feed, notices that he has written an entry  
called «Anne's cat is four years old». She has not seen the entry «Anne's  
cat is five years old» on Peter's blog, because that entry is pushed off  
of Peter's feed.

In «Complex Read», Peter's entry shows up just as in Anne's «Simple Read»,  
but it has an additional «related» button that opens up a small dialog  
window showing Anne's corrected entry «My cat is four years old!».  
Elisabeth remembers that Anne wrote that her cat was five years old, so  
she inspects the «related» window further. It also has a reference to  
Peter's entry «Anne's cat is four years old».

13. Elisabeth clicks Peter's related entry and it opens in a new window in  
«Complex Read». She then reads the old entry, and sees that it shows  
«related» which points to the new and updated entry on Peter's blog. As  
she hasn't read the newest entry yet, she clicks the title which brings  
her to it, and she reads it and gets a good laugh about how silly Anne is  
to forget how old her cat is.

---------------

I'm not sure if this scenario explains anything, but I hope it does. It  
should show that the support for <relation> is highly optional, that it's  
a simple and effective construct, and that the core of Atom could support  
it relatively as-is. It also proves that if Atom isn't going to have  
<relation> in its Core, Atom should not try to solve the «minor» and  
«major» change problem in another proprietary way, because this is the  
common mechanism for re-issuance of stories; not randomly modifying an  
'issued' element.

Sorry about the extreme length of the e-mail, and thanks for reading this  
far!

____
[1] <url: http://dublincore.org/documents/relation-element/>

-- 
Asbjørn Ulsberg         -=|=-        asbjornu@hotmail.com
«He's a loathsome offensive brute, yet I can't look away»



From owner-atom-syntax@mail.imc.org  Wed Jul 14 16:21: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 QAA15131
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 16:21: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 i6EKApFZ064388;
	Wed, 14 Jul 2004 13:10: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 i6EKApCx064387;
	Wed, 14 Jul 2004 13:10: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 (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EKAn5e064368
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 13:10: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 28D687C0F3; Wed, 14 Jul 2004 23:08:44 +0200 (CEST)
Date: Wed, 14 Jul 2004 22:14:51 +0200
To: "David Powell" <djpowell@djpowell.net>
Subject: Re: a methodical approach to defining what date  elements we need
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <BD1995C2.1F3C6%eric.scheid@ironclad.net.au> <opsa2k75lz6dxgxk@mail.online.no> <CFCD3EC6-D4BA-11D8-82B1-000A95DC3D90@mac.com> <40F3CC36.9080001@intertwingly.net> <7C832F0A-D4D2-11D8-82B1-000A95DC3D90@mac.com> <40F3F09F.4070602@intertwingly.net> <50540F00-D4F5-11D8-82B1-000A95DC3D90@mac.com> <40F50909.3060306@intertwingly.net> <1089822969.40f560f9cd72f@webmail.djpowell.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: <opsa4861t8uvpchu@quark>
In-Reply-To: <1089822969.40f560f9cd72f@webmail.djpowell.net>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Wed, 14 Jul 2004 17:36:09 +0100, David Powell <djpowell@djpowell.net>  
wrote:

> So we have dropped

I hope we haven't dropped anything, yet.

> #4 objective publishing date - This is pretty similar to either objective
> creation date

Since 'created' is optional, it does not provide the same, no. If  
'created' were required, 'issued' _could_ be seen as the same, but in a  
strict publishing context, they are just as different as 'created' and  
'modified'.

> or objective major modification date isn't it?

Not at all. Not even close.

> #5 subjective creation date, #6 and #7 subjective modification dates - I  
> think that the only subjective date worth keeping is the display date.

+1. And it should not be called 'issued', because issued asserts that it's  
formal which I think outrules any subjective meaning to what the date is.

> #2 except for the last instance -  Keeping archived modification dates  
> around without anyway of obtaining the old copies seems pretty useless.

The problem of «missing entries» or «holes in the entry chain» is a  
something we have to deal with at some time either way, so excluding and  
banning all functionality that _might_ in an extreme case require a  
solution for the problem, is imho very restrictive.

> I imagine any supercedes proposal will come up with something more  
> useful,
> maybe involving <link>

<url: http://intertwingly.net/wiki/pie/PaceIssuedAndRelation>

> #3 objective minor modification stamp.
>
> -1 to dropping this.

I agree.

> I think we only need keep the last modification date though, not the
> whole history.

I agree with this as well, but if an author would like to provide the  
whole history of an entry, he should be able to. PaceIssuedAndRelation is  
an opt-in solution for this.

> This field should be required if the post has been modified in any way.

As should 'created' and 'issued', imho. 'Display' is the only date I think  
should be optional, although many users and tools will provide it anyway.  
It's imho the date least useful in a publishing and syndication process,  
although maybe useful in the display of an aggregator and for the author,  
somehow.

> Some people are suggesting that it is better to have a supercedes  
> mechanism than to qualify changes as minor or major.

I've also suggested using several <issued> elements to indicate that the  
entry has been issued on several occasions. The concrete proposal for this  
is PaceMultipleIssued[1].

  Technically it may be better, but my opinion is that a supercedes  
mechanism
> imposes a more complex workflow on publishers than simply allowing them
> to change existing posts, so I would prefer it if both "major updates"  
> and
> "supercedes" were both allowed so that the publisher can decide what is
> most suitable.

-1. PaceIssuedAndRelation is 100% opt-in for authors, consumers,  
publishers and aggregators, and it would be a huge mistake to have two  
different ways to express not the same, but _amlost_ same thing. If you  
need to choose, it should be between «change support» (only modification  
of 'modified' to indicate changes) or «minor and major change support»  
(modifications of 'modified' indicates minor changes, a new entry with  
<relation> to the old one, indicates a major change).

> If people want supercedes instead, then they just don't use the "Updated"
> field.

Again, -1 to that.

____
[1] <url: http://intertwingly.net/wiki/pie/PaceMultipleIssued>

-- 
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 Jul 14 16:35: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 QAA17052
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 16:35: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 i6EKRXOH067296;
	Wed, 14 Jul 2004 13:27: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 i6EKRXPi067295;
	Wed, 14 Jul 2004 13:27: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 (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EKRWJ6067274
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 13:27:33 -0700 (PDT)
	(envelope-from asbjorn@tigerstaden.no)
Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19])
	by smtpgateway.itweb.no (Postfix) with ESMTP
	id 370FE7C0F3; Wed, 14 Jul 2004 23:25:27 +0200 (CEST)
To: "Tim Bray" <Tim.Bray@sun.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Work Queue Rotation #3
References: <4005DCF4-D55C-11D8-A6EC-000A95A51C9E@sun.com>
Message-ID: <opsa49y1sxuvpchu@quark>
Date: Wed, 14 Jul 2004 22:31:39 +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: <4005DCF4-D55C-11D8-A6EC-000A95A51C9E@sun.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Tue, 13 Jul 2004 23:08:39 -0700, Tim Bray <Tim.Bray@Sun.COM> wrote:

> 5. PaceSyntaxGuidelines
>
> Not much discussion, but it looks to me like this one is (sigh) joined  
> at the hip to PaceLinkConstruct, thus gets shunted back to the Need To  
> Revisit category until that's wrestled to the ground.

If that's the consensus, I have no problem with this Pace being written up  
as a non-normative appendix of some sort. I also have to note that it does  
not have anything to do with the link construct, but is a general syntax  
guideline for Atom.

-- 
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 Jul 14 16: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 QAA17346
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 16: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 i6EKTNeQ067561;
	Wed, 14 Jul 2004 13: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 i6EKTN0u067560;
	Wed, 14 Jul 2004 13:29:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from vspmail.nscp.aoltw.net (h-64-236-138-233.aoltw.net [64.236.138.233])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EKTMt3067536
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 13:29:22 -0700 (PDT)
	(envelope-from jpanzer@AOL.NET)
Received: from h-10-169-146-121.nscp.aoltw.net (h-10-169-146-121.nscp.aoltw.net [10.169.146.121])
	by vspmail.nscp.aoltw.net (8.11.6/8.11.6) with ESMTP id i6EKYJs17810
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 13:34:30 -0700
Date: Wed, 14 Jul 2004 13:29:11 -0700
From: "John Panzer" <jpanzer@aol.net>
Subject: Feed of site events (was: Thought experiment: Using a synthetic feed to
 find out about other feeds)
To: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <opsavggornuvpchu@quark>
Message-ID: <40F59797.80104@AOL.NET>
References: <200407081614.BHM20108@ms8.netsolmail.com> <m3hdsiqspb.fsf@bitsko.slc.ut.us> <40EE7F98.6040207@intertwingly.net> <opsavggornuvpchu@quark>
X-Mailer: AOL Communicator (20030919.3 Win)
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>


All,

I've been thinking about this a bit more, in between what my company 
considers my 'real' work. Reading the comments from Eric Scheid,  Bob 
Wyman, and Ken MacLeod, I don't see violent opposition to the general 
concept, but some concern about what "modified" means for feeds whose 
subject matter is sites, and why a general "list of things" is different 
from a "feed".

Ken seems to object to the use of a "feed of sites" as a synonym for 
"index of sites".  I agree that the two are different, and I think 
they'd serve different purposes to some extent, but that both will be 
useful.

A "feed of sites" is fuzzy, though -- what does that mean?  Let me 
suggest a more concrete underlying concept:  A "feed of site events". 
That is, a feed which consists of interesting events happening to sites 
separate from the addition/updating/deletion of entries.

The most important event that happens to a site, of course, it its 
creation.  In the "feed of site events" worldview, this would correspond 
to a new entry.  (Today, this new entry appears in places like 
http://bloglines.com/newblogs .)

(The "birth notice" event might also provides a convenient place to put 
some information about the timestamp of the latest entry inside the 
site, but that's really just an optimization for going to the feed URI 
and doing a HEAD request.  So let's say the "birth notice" is a frozen 
historical record.)

A second event that can happen to a site is deletion or quiescence.  In 
the "feed of site events" worldview, this would also correspond to a new 
entry.  (Today, this new entry typically is appended to the end of the 
feed itself, with human readable text.)

A third event is renaming or movement of the site.  This could provide a 
historical record of what happened, in addition to any redirection or 
final notices put on the original site.  (The original site will 
probably go away at some point.)  There are other possible events too.

Looking just at "birth" and "death" notices, a "feed of site events" 
would then give you a chronological journal of what's happening to a 
specific set of sites:

   Site1 born (metadata about site1)
   Site2 born (...)
   Site1 dies (URI relates this event to birth notice above)
   Site3 born

(One could also imagine corrections to the original birth notice and all 
the other edge cases that apply to entries.)

How does this relate to an "index of sites"?  The index gives you a 
snapshot in time (the current state of the world), while the "feed of 
site events" gives you the backstory.  Obviously, given the full 
backstory, you can reconstitute the current state of the world.  The 
index after all the events above would be:

   Site1
   Site3

It would clearly be easier for clients who are interested only in the 
state of the world today to deal with the site index.  However, there 
are use cases for the feed of site events too.  For example, knowing for 
_certain_ that a feed is going away or transmorgifying into something 
else would allow aggregators to help manage feeds more intelligently. 
There's an existing use case (http://bloglines.com/newblogs) for getting 
notified about new feeds, and I think we can all imagine variations of 
that theme.

Please note, I'm not at all arguing against having an "index of feeds" 
capability, whether it's via WebDAV (which seems like a nice, easy, 
standards based approach) or some other way.  I really have two points:

1) There are reasonable use cases for wanting "feeds of site events".
2) An "index of feeds" can be derived from "feeds of site events" but 
not the other way around.
3) Aggregators could use either or both for autodiscovery.

-John Panzer

P.S: I think that a "feed of site events" fits exactly into the 
definition below:

 > >> An aggregator works on the principle of displaying new entries when
 > >> they appear, and sometimes holding "old" entries for perusal, and
 > >> re-showing updated entries if they're changed.
 > >
 > > Some form of that statement should make its way into
 > AtomTerminology[1].
 >
 > Done. I've also sorted the definition terms alphabetically, to make the
 > list more readable.




From owner-atom-syntax@mail.imc.org  Wed Jul 14 16: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 QAA18219
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 16:46: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 i6EKcIHC069046;
	Wed, 14 Jul 2004 13:38: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 i6EKcI41069044;
	Wed, 14 Jul 2004 13:38:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web41511.mail.yahoo.com (web41511.mail.yahoo.com [66.218.93.94])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6EKcHXI069022
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 13:38:17 -0700 (PDT)
	(envelope-from randymorin@yahoo.com)
Message-ID: <20040714203817.8223.qmail@web41511.mail.yahoo.com>
Received: from [66.46.139.106] by web41511.mail.yahoo.com via HTTP; Wed, 14 Jul 2004 13:38:17 PDT
Date: Wed, 14 Jul 2004 13:38:17 -0700 (PDT)
From: Randy Charles Morin <randymorin@yahoo.com>
Reply-To: randy@kbcafe.com
Subject: Re: Work Queue Rotation #3
To: Tim Bray <tim.bray@sun.com>, Atomlist <atom-syntax@imc.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-785332540-1089837497=:7807"
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>


--0-785332540-1089837497=:7807
Content-Type: text/plain; charset=us-ascii

Tim wrote: 
>Some people, probably including Randy Charles Morin 
>& Dare Obasanjo, should pull together a new Pace

 
How about we take Joe's [1] suggestion and break the SOAP implementation off into a separate Internet Draft. I'd rather do this because I've found that Paces are often the place where ideas go to die.
Thanks,
 
Randy
 
[1] http://www.imc.org/atom-syntax/mail-archive/msg06791.html
 

		
---------------------------------
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
--0-785332540-1089837497=:7807
Content-Type: text/html; charset=us-ascii

<DIV>Tim wrote: </DIV>
<DIV>
<DIV>&gt;<FONT face="Courier New">Some people, probably including Randy Charles Morin </FONT></DIV>
<DIV><FONT face="Courier New">&gt;&amp; Dare Obasanjo, should pull together a new Pace</FONT></DIV></DIV>
<DIV>&nbsp;</DIV>
<DIV>How about&nbsp;we take Joe's [1] suggestion and break the SOAP implementation off into a separate Internet Draft. I'd rather do this because I've found that Paces are often the place where ideas go to die.</DIV>
<DIV>Thanks,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Randy</DIV>
<DIV>&nbsp;</DIV>
<DIV>[1] <A href="http://www.imc.org/atom-syntax/mail-archive/msg06791.html">http://www.imc.org/atom-syntax/mail-archive/msg06791.html</A></DIV>
<DIV>&nbsp;</DIV><p>
		<hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/mail_us/taglines/aac/*http://promotions.yahoo.com/new_mail/static/ease.html">Yahoo! Mail Address AutoComplete</a> - You start. We finish.
--0-785332540-1089837497=:7807--



From owner-atom-syntax@mail.imc.org  Wed Jul 14 16:54:18 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19512
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 16:54:17 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EKkAgk070286;
	Wed, 14 Jul 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 i6EKkA5j070285;
	Wed, 14 Jul 2004 13:46: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 (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EKk9Vx070260
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 13:46: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 F00947C0F3; Wed, 14 Jul 2004 23:44:03 +0200 (CEST)
Date: Wed, 14 Jul 2004 22:50:19 +0200
To: "Mark Pilgrim" <pilgrim@gmail.com>,
        "Antone Roundy" <antone@geckotribe.com>
Subject: Re: PaceLang
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <D02C373E-D5A7-11D8-AE1C-003065EA6144@geckotribe.com> <14be96d304071409597134a601@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: <opsa5at5hnuvpchu@quark>
In-Reply-To: <14be96d304071409597134a601@mail.gmail.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Wed, 14 Jul 2004 12:59:19 -0400, Mark Pilgrim <pilgrim@gmail.com> wrote:

> "xml:lang is considered to apply to all attributes and content of the
> element where it is specified"

Does 'xml:lang' also apply to attribute _values_? Either way, wouldn't it  
be wierd to have 'xml:lang="nb-NO"' on a <content> element along with  
@type and @mode which have both english names and values? Take the  
following example:

   <content type="application/xhtml+xml" mode="xml" xml:lang="nb-NO">
     <div xmlns="http://www.w3.org/1999/xhtml">
       <h1>Hei på deg</h1>
     </div>
   </content>

If 'xml:lang' is supposed to apply to both aton:content/@type,  
atom:content/@mode and atom:content/xhtml:div, how is that supposed to  
work, exactly? I find it very wierd that 'xml:lang' not only applies to  
children (and their attributes) of the element it is specified on, but it  
seems that no matter what you do, you'd get into trouble with this  
description of the attribute.

> There may be other arguments in favor of changing the link syntax, but
> this isn't one of them.

I think it is, but that doesn't matter much. I can live with @title, I  
just find 'xml:lang' awkward, 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  Wed Jul 14 17:00:50 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20389
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 17:00: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 i6EKpqZx071280;
	Wed, 14 Jul 2004 13:51: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 i6EKpqI6071279;
	Wed, 14 Jul 2004 13:51:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EKppHQ071245
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 13:51: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 5890F7C0F3; Wed, 14 Jul 2004 23:49:45 +0200 (CEST)
To: "Joe Gregorio" <joe.gregorio@gmail.com>,
        "Mark Pilgrim" <pilgrim@gmail.com>
Cc: "Tim Bray" <tbray@textuality.com>, Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Don't bake discrimination into the Atom core (was Re: Low-hanging fruit: multipart/alternative)
References: <A65D9796-D519-11D8-8C42-000A95A51C9E@textuality.com> <14be96d304071317541efca684@mail.gmail.com> <7FBABBD6-D531-11D8-A503-000A95A51C9E@textuality.com> <14be96d304071319181e2bf741@mail.gmail.com> <1393DBDA-D540-11D8-A503-000A95A51C9E@textuality.com> <opsa4zq3fhuvpchu@quark> <14be96d304071410083cc71f90@mail.gmail.com> <3f1451f5040714102129846420@mail.gmail.com>
Message-ID: <opsa5a3ok4uvpchu@quark>
Date: Wed, 14 Jul 2004 22:56:02 +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: <3f1451f5040714102129846420@mail.gmail.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Wed, 14 Jul 2004 13:21:11 -0400, Joe Gregorio <joe.gregorio@gmail.com>  
wrote:

> Regardless I see no harm in removing something that is broken and waiting
> until later to decide on what to replace it with. It could even be
> replaced in the short term with an empty section titled "Accessibility"
> and just filled with "TBD".

+1. I think the current model is broken, and that it shouldn't be in the  
specification. The longer it stays there, the longer it will take to get  
rid of the potential implementations of 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 Jul 14 17:05: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 RAA20875
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 17:05: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 i6EKwQTR072570;
	Wed, 14 Jul 2004 13:58: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 i6EKwQ2x072569;
	Wed, 14 Jul 2004 13:58: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 i6EKwPpd072553;
	Wed, 14 Jul 2004 13:58: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 i6EKxANH006223;
	Wed, 14 Jul 2004 16:59:10 -0400
Message-ID: <40F59E6C.2060405@intertwingly.net>
Date: Wed, 14 Jul 2004 16:58:20 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <phoffman@imc.org>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceMustBeWellFormed
References: <14be96d30407061142441f70ee@mail.gmail.com> <40F56B2A.8050500@intertwingly.net> <14be96d304071411092c2c44f4@mail.gmail.com> <p06110426bd1b3deea52a@[10.20.30.249]>
In-Reply-To: <p06110426bd1b3deea52a@[10.20.30.249]>
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


Paul Hoffman / IMC wrote:

> At 2:09 PM -0400 7/14/04, Mark Pilgrim wrote:
> 
>> On Wed, 14 Jul 2004 13:19:38 -0400, Sam Ruby <rubys@intertwingly.net> 
>> wrote:
>>
>>> (6.1 1) I would, howevever, be supportive of a statement that if a
>>> charset were provided with any application/* MIME type, THEN it MUST
>>>  match what the encoding that would have been determined had the charset
>>>  been omitted.
>>
>> That is not an RFC-2119-compliant use of the word "MUST".  Conflicting
>> metadata declarations are not an interoperability problem, because
>> there are clear precedence rules governing which one wins.  (The
>> charset in the HTTP headers always wins.)
> 
> Correct. If the precedence is given by a MUST, and if what you are 
> talking about is not first in the precedence, then a MUST is incorrect 
> according to a careful (and possibly legalistic) reading RFC 2119.

What spec defines the precedence rules for a MIME type that we have yet 
to register (i.e., application/atom+xml)?

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Wed Jul 14 17:05: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 RAA20917
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 17:05: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 i6EKuBZa072223;
	Wed, 14 Jul 2004 13: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 i6EKuBTn072222;
	Wed, 14 Jul 2004 13:56:11 -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 i6EKuAEK072215
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 13:56: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 i6EKuqW1005878;
	Wed, 14 Jul 2004 16:56:52 -0400
Message-ID: <40F59DE2.2080503@intertwingly.net>
Date: Wed, 14 Jul 2004 16:56:02 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: "Roger B." <roger@agincourtmedia.com>
CC: "'Atom Syntax'" <atom-syntax@imc.org>
Subject: Re: a methodical approach to defining what date  elements we need
References: <5362E0FB475943BDA23EBE738EFB5.MAI@journurl.com>
In-Reply-To: <5362E0FB475943BDA23EBE738EFB5.MAI@journurl.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


Roger B. wrote:
>>Frankly I don't see any interesting current or future use for "created"
>>but I guess some do.
> 
> 
> Tim: I keep thinking "import/export", but now that I consider it a bit, it
> might be better to save that for an archive:created extension or something.
> If you take away atom:created, it should be easier for publishers to intuit
> the relation between the remaining date elements and their own app's output.
> 
> Here's a list of date-related entry tags from various apps:
> 
> Blogger: 
> <$BlogItemDateTime$>
> 
> MT: 
> <$MTEntryDate$>
> <$MTEntryModifiedDate$>
> 
> WordPress: 
> <?php the_date('Y/m/d','before','after',display); ?>
> 
> BigBlogTool: 
> /.timestamp
> 
> ExpressionEngine: 
> {entry_date}
> {edit_date}
> 
> JournURL: 
> <weblog:date type="published">
> <weblog:date type="updated">
> <weblog:date type="created">
> 
> Looks to me as if picking the right date for the right element would be
> pretty easy for most template systems if "created" is taken off the table.
> As long as there is an atom:created in the core, I suspect there will be
> people scratching their heads and trying to figure out when to use it and
> what goes in it... all for no immediate benefit, at least in terms of pure
> syndication.

Roger, you see a pattern that I don't yet see.  I see a list of 
applications, some with one, two, or three different dates.  But the 
idea of doing this bottom up REALLY appeals to me.  So: to aid my 
comprehension, I have made an attempt to collate these dates:

   http://www.intertwingly.net/wiki/pie/BlogToolDateSurvey

I'll readily admit that I took some guesses here... feel free to correct 
me where I went astray.

Once we have the shape of the table correct, lets see if we can get a 
few more rows filled in.  I can investigate the answers for Blosxom and 
perhaps even Radio.  Perhaps others can pitch in.

Then we can try to label the columns.  That surely will be 
controversial.  And take a first pass at which ones belong in the core, 
and which ones are good candicates for extensions.

Once that is done, we can try to provide a prose description for each 
column, and go back and verify how well such a description matches with 
each tool.

Finally, we can settle on the cardinalities (min and max) for each 
column.  And revisit the core/extension decision for each.

And then perhaps we can retire the eight current PACEs which are related 
to dates, and replace them with one around which we have consensus.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Wed Jul 14 17:15:04 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22391
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 17:15: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 i6EL0FHL072937;
	Wed, 14 Jul 2004 14:00: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 i6EL0FQB072936;
	Wed, 14 Jul 2004 14:00: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 i6EL0Ege072899
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 14:00: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 C7DE27C112; Wed, 14 Jul 2004 23:58:04 +0200 (CEST)
Date: Wed, 14 Jul 2004 23:03:20 +0200
To: "Tim Bray" <Tim.Bray@sun.com>
Subject: Re: a methodical approach to defining what date  elements we need
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <20040714153153.98934.qmail@web41201.mail.yahoo.com> <D1CE520E-D5B1-11D8-A6EC-000A95A51C9E@sun.com> <87vfgqjz6y.fsf@nwalsh.com> <CE649170-D5BD-11D8-A6EC-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: <opsa5bfuoluvpchu@quark>
In-Reply-To: <CE649170-D5BD-11D8-A6EC-000A95A51C9E@sun.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Wed, 14 Jul 2004 10:46:59 -0700, Tim Bray <Tim.Bray@Sun.COM> wrote:

> I'm with Sam, we need two.  One last-modified and one "what the user  
> wants to appear here" to support this widely-used facility from  
> LiveJournal and so on.

I would like an 'issued' too, thank you. You can't put anything on the web  
without 'issuing' it, hence all tools in existanse has and performs this  
action, thus should it also be incredibly simple to provide such a date.  
Why I, for one, would need such a date is explained in length at several  
occasions, and is summarized with: It is important to know when a story  
was originally written and/or issued to know be able to set the original  
context of the story before reading.

> The canonical case would be a travel diary, the entry for July 1 may
> have been created on July 3 and modified on July 8, but from the
> user's point of view it's still the entry for July 1.

Then it's 'created' and probably 'issued' July 1st, and 'modified' July  
8th. What the user-provided date is set to is of no interest to any of the  
uses I see that NRK and ePerSpace will ever have with Atom (as an input,  
not output format).

> Frankly I don't see any interesting current or future use for "created"  
> but I guess some do.

I do, I do! :-)

-- 
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 Jul 14 17:17: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 RAA22727
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 17:17: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 i6ELBDYo074754;
	Wed, 14 Jul 2004 14:11: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 i6ELBDdn074753;
	Wed, 14 Jul 2004 14:11: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 i6ELBCj4074729
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 14:11: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 11F617C0F3; Thu, 15 Jul 2004 00:09:07 +0200 (CEST)
To: davep@dpawson.co.uk
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: a methodical approach to defining what date  elements we need
References: <14B72756-D419-11D8-9D0B-003065EA6144@geckotribe.com>  <40F2C2CD.9020307@intertwingly.net>  <47071860-D42A-11D8-82B1-000A95DC3D90@mac.com>  <opsa1nlh1u6dxgxk@mail.online.no>  <6C2098C54ED33AE163D3E2F5@adsl-64-166-133-244.dsl.snfc21.pacbell.net>  <opsa3eddg8uvpchu@quark> <1089832992.2849.16.camel@homer>
Message-ID: <opsa5bya0ruvpchu@quark>
Date: Wed, 14 Jul 2004 23:14:24 +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: <1089832992.2849.16.camel@homer>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Wed, 14 Jul 2004 20:23:12 +0100, Dave Pawson <davep@dpawson.co.uk>  
wrote:

> And what about people generating atom content?

Could you elaborate on «generating atom content»? Do you mean by hand? In  
how many cases do you think that will happen, and nonetheless, don't you  
think people that does this is able to read the specification to find out  
what the different dates are to be used for?

> Cut and paste from ....?

I don't understand this question, 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 Jul 14 17:18:16 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22800
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 17:18: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 i6EL74xc074116;
	Wed, 14 Jul 2004 14:07: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 i6EL7405074115;
	Wed, 14 Jul 2004 14:07:04 -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 i6EL73kg074098
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 14:07: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 CDE397C0F3; Thu, 15 Jul 2004 00:04:57 +0200 (CEST)
Date: Wed, 14 Jul 2004 23:10:14 +0200
To: "Sam Ruby" <rubys@intertwingly.net>
Subject: Re: a methodical approach to defining what date  elements we need
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <20040714174807.44676.qmail@web41214.mail.yahoo.com> <40F5743E.3000803@intertwingly.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: <opsa5brcapuvpchu@quark>
In-Reply-To: <40F5743E.3000803@intertwingly.net>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Wed, 14 Jul 2004 13:58:22 -0400, Sam Ruby <rubys@intertwingly.net>  
wrote:

> I see the default for "issued" as being tool specific and therefore not  
> normatively specified in the standard

How can 'issued' be tool-specific? How is it possible to put a resource  
anywhere on the web without performing an action at a time that equals  
'issued'? As far as my brain can stretch, absolutely all tools need to  
'issue' entries onto the web site and into the feed no matter what dates  
they provide, and timestamping this action onto the issued entry would not  
require more than two lines of code in most languages and implementations.

> particularly if the third date ("created") is not present at all in the
> standard.

I could live without a 'created', but we need to have some date that  
indicates when the entry was first made available -- when it is from.

> What I said about "created" is as follows[1]:
>
>      This field is not intended for significantly[sic] used by an
>      aggregator.

Maybe not by an aggregator, but I see its uses in what I and my company  
will do with Atom feeds. 'created' is, however, not as important as  
'issued'. No matter what, both of these dates should be provided by tools  
and should not be subjective. And they should never ever change.

> If, on the other hand, this field does not survive the
> standardization process, then so be it.

Yes, I could live 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  Wed Jul 14 17:33: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 RAA24401
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 17:33: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 i6ELJUDg076056;
	Wed, 14 Jul 2004 14:19: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 i6ELJUUT076055;
	Wed, 14 Jul 2004 14:19: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.202])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6ELJTIp076041
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 14:19:29 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d15so422591rng
        for <atom-syntax@imc.org>; Wed, 14 Jul 2004 14:19:34 -0700 (PDT)
Received: by 10.38.207.20 with SMTP id e20mr632727rng;
        Wed, 14 Jul 2004 14:19:34 -0700 (PDT)
Message-ID: <14be96d30407141419614b8117@mail.gmail.com>
Date: Wed, 14 Jul 2004 17:19:34 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Sam Ruby <rubys@intertwingly.net>
Subject: Re: PaceMustBeWellFormed
Cc: Paul Hoffman / IMC <phoffman@imc.org>, Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <40F59E6C.2060405@intertwingly.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <14be96d30407061142441f70ee@mail.gmail.com> <40F56B2A.8050500@intertwingly.net> <14be96d304071411092c2c44f4@mail.gmail.com> <p06110426bd1b3deea52a@[10.20.30.249]> <40F59E6C.2060405@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 Wed, 14 Jul 2004 16:58:20 -0400, Sam Ruby <rubys@intertwingly.net> wrote:
> What spec defines the precedence rules for a MIME type that we have yet
> to register (i.e., application/atom+xml)?

Section 8 of http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-00.txt
states:

"""Optional parameters:
      "charset": This parameter has identical semantics to the charset
         parameter of the "application/xml" media type as specified in
         RFC 3023."""

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Wed Jul 14 17: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 RAA24440
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 17:34: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 i6ELR4RP077185;
	Wed, 14 Jul 2004 14: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 i6ELR4M1077184;
	Wed, 14 Jul 2004 14:27: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.198])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6ELR3XG077147
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 14:27:03 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d19so542894rnf
        for <atom-syntax@imc.org>; Wed, 14 Jul 2004 14:27:02 -0700 (PDT)
Received: by 10.38.72.80 with SMTP id u80mr409673rna;
        Wed, 14 Jul 2004 14:27:02 -0700 (PDT)
Message-ID: <14be96d30407141427187f294d@mail.gmail.com>
Date: Wed, 14 Jul 2004 17:27:02 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: PaceMustBeWellFormed
Cc: Sam Ruby <rubys@intertwingly.net>, Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <p06110426bd1b3deea52a@10.20.30.249>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <14be96d30407061142441f70ee@mail.gmail.com>
 <40F56B2A.8050500@intertwingly.net>
 <14be96d304071411092c2c44f4@mail.gmail.com> <p06110426bd1b3deea52a@10.20.30.249>
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 Wed, 14 Jul 2004 12:56:40 -0700, Paul Hoffman / IMC <phoffman@imc.org> wrote:
> At 2:09 PM -0400 7/14/04, Mark Pilgrim wrote:
> >On Wed, 14 Jul 2004 13:19:38 -0400, Sam Ruby <rubys@intertwingly.net> wrote:
> >>  (6.1 1) I disagree with the recommendation that charset be provided.  In
> >>  fact, one of the primary benefits I see to recommending application/*
> >>  instead of text/* is that one can omit the charset and obtain a sensible
> >>  result.
> >
> >http://www.w3.org/International/questions/qa-encoding-alts.html
> 
> Not sure what this response means. That page has ??? and XXX in a few
> places, and is quite clearly not finshed (or even that clear in
> places).

True.  Just about the only part they've decided on is the part that
backs up my argument:

"""Since the HTTP Content-Type header has precedence, and is also the
easiest information to retrieve (user-agents do not have to parse the
resource to get it), it is almost always the preferred way to provide
the character encoding for an (X)HTML document"""

I submit that the same is true of an Atom document.  It has multiple
ways to specify the encoding (in-band and out-of-band), and the HTTP
Content-Type header takes precedence, therefore it should be the
preferred way to provide the character encoding for an Atom document.

The same unfinished document has a remarkably complete discussion of
when this is not possible:

"""However, in at least two cases, this is simply not possible:

    * The document author does not have any way to configure the
server to send the proper HTTP Content-Type header
    * The document is not served via HTTP.
"""

These cases also apply equally well to Atom documents.

I admit the link was dropped in without explanation, but I'm not sure
what other conclusion you could draw from that document.  Are you
suggesting that Atom documents are so different from XHTML documents
that a different precendence order should apply, or that a different
practice should be considered "best practice"?

If my wrestling with RFC 3023 has taught me anything, it is that HTTP
has primacy.  If you want to serve Atom feeds over BEEP, then
obviously different rules will apply.  Everyone I know serves them
exclusively over HTTP.

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Wed Jul 14 17:36: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 RAA24475
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 17:36: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 i6ELJDYh075999;
	Wed, 14 Jul 2004 14:19:13 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6ELJDsE075998;
	Wed, 14 Jul 2004 14:19: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-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 i6ELJCR5075992
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 14:19:12 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6ELJHil006597
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 15:19: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 <0I0V000WG1W53E@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Wed, 14 Jul 2004 15:19:17 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0V00F891W446@mail.sun.net> for atom-syntax@imc.org; Wed,
 14 Jul 2004 15:19:17 -0600 (MDT)
Date: Wed, 14 Jul 2004 14:19:15 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceLang
In-reply-to: <opsa5at5hnuvpchu@quark>
To: Atom-Syntax <atom-syntax@imc.org>
Message-id: <75B3F5DF-D5DB-11D8-A6EC-000A95A51C9E@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.618)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
References: <D02C373E-D5A7-11D8-AE1C-003065EA6144@geckotribe.com>
 <14be96d304071409597134a601@mail.gmail.com> <opsa5at5hnuvpchu@quark>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6ELJCR5075993
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 Jul 14, 2004, at 1:50 PM, Asbjørn Ulsberg wrote:

> Does 'xml:lang' also apply to attribute _values_? Either way, wouldn't 
> it be wierd to have 'xml:lang="nb-NO"' on a <content> element along 
> with @type and @mode which have both english names and values? Take 
> the following example:
>
>   <content type="application/xhtml+xml" mode="xml" xml:lang="nb-NO">
>     <div xmlns="http://www.w3.org/1999/xhtml">
>       <h1>Hei på deg</h1>
>     </div>
>   </content>

xml:lang applies on those contacts where the content is interpreted as 
being in human language, not protocol keywords.  In this case, only to 
the content of <h1> -Tim




From owner-atom-syntax@mail.imc.org  Wed Jul 14 17:44:52 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25439
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 17:44: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 i6ELYiAj079292;
	Wed, 14 Jul 2004 14:34:44 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6ELYiRV079291;
	Wed, 14 Jul 2004 14:34:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.193])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6ELYhgO079285
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 14:34:43 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d5so512095rng
        for <atom-syntax@imc.org>; Wed, 14 Jul 2004 14:34:42 -0700 (PDT)
Received: by 10.38.9.67 with SMTP id 67mr369329rni;
        Wed, 14 Jul 2004 14:34:42 -0700 (PDT)
Message-ID: <14be96d3040714143410404efb@mail.gmail.com>
Date: Wed, 14 Jul 2004 17:34:42 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: "Asbjørn Ulsberg" <asbjorn@tigerstaden.no>
Subject: Re: PaceLang
Cc: Antone Roundy <antone@geckotribe.com>, Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <opsa5at5hnuvpchu@quark>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
References: <D02C373E-D5A7-11D8-AE1C-003065EA6144@geckotribe.com> <14be96d304071409597134a601@mail.gmail.com> <opsa5at5hnuvpchu@quark>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6ELYigO079286
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 Wed, 14 Jul 2004 22:50:19 +0200, Asbjørn Ulsberg
<asbjorn@tigerstaden.no> wrote:
> On Wed, 14 Jul 2004 12:59:19 -0400, Mark Pilgrim <pilgrim@gmail.com> wrote:
> 
> > "xml:lang is considered to apply to all attributes and content of the
> > element where it is specified"
> 
> Does 'xml:lang' also apply to attribute _values_? Either way, wouldn't it
> be wierd to have 'xml:lang="nb-NO"' on a <content> element along with
> @type and @mode which have both english names and values? Take the
> following example:
> 
>    <content type="application/xhtml+xml" mode="xml" xml:lang="nb-NO">

@type and @rel are enumerations.  They have a predefined set of
values; they are not free-form text in any human language.

> I think it is, but that doesn't matter much. I can live with @title, I
> just find 'xml:lang' awkward, that's all.

We are using it exactly as it is specified in the XML specification,
and I see no compelling reason to do otherwise.

However, this does bring up the point that xml:lang is not just
specific to Content constructs, and therefore this Pace is invalid.

* <atom:link> can also have xml:lang, which applies to the @title attribute.
* <atom:author> (or <atom:name> within author) can have xml:lang,
which applies to the author's name.
* Ditto <atom:contributor> (unless we've dropped that by now)
* <atom:generator> can have xml:lang which applies to the toolkit name.

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Wed Jul 14 17:47: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 RAA25787
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 17:47: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 i6ELZgmo079454;
	Wed, 14 Jul 2004 14: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 i6ELZg5d079453;
	Wed, 14 Jul 2004 14:35:42 -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 i6ELZfkM079435
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 14:35:42 -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 i6ELZe53019569
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 16:35:41 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6ELZebn019565;
	Wed, 14 Jul 2004 16:35:40 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Don't bake discrimination into the Atom core (was Re: Low-hanging fruit: multipart/alternative)
References: <A65D9796-D519-11D8-8C42-000A95A51C9E@textuality.com>
	<14be96d304071317541efca684@mail.gmail.com>
	<7FBABBD6-D531-11D8-A503-000A95A51C9E@textuality.com>
	<14be96d304071319181e2bf741@mail.gmail.com>
	<1393DBDA-D540-11D8-A503-000A95A51C9E@textuality.com>
	<opsa4zq3fhuvpchu@quark> <14be96d304071410083cc71f90@mail.gmail.com>
	<50434192-D5BD-11D8-A6EC-000A95A51C9E@textuality.com>
	<5C39B3EC-D5BF-11D8-AA19-000A95BD86C0@mnot.net>
	<20040714184022.GU3805@homer.w3.org>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 14 Jul 2004 16:35:40 -0500
In-Reply-To: <20040714184022.GU3805@homer.w3.org>
Message-ID: <m3k6x6l1ar.fsf@bitsko.slc.ut.us>
Lines: 56
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


Dan Brickley <danbri@w3.org> writes:

> Rather than try to stop folk including (by value or reference;
> principle is the same) audio and image content in their feeds, I
> believe our energies would be better spent encouraging them to
> associate extra info with those items. I'm well aware that people
> don't like to take the time to add metadata, but also that folk do
> like their photos to be findable again and that extension namespaces
> can play a role in supporting that.

PaceSimpleContentType was driven in part by the multipart/alternative
issue, as well as the "binary upload" and "what is an Internet Media
Type entity represented as XML Characters" issues.

That Pace lightly addresses the accessibility issue: put the "best
representation" in content/@src, put alternate representations of the
content in (proposing here) content-alternate/@src.

  (End of main reply, clarifications follow.)

Note, the current spec still contains text that says "multiple
<content> elements are allowed", but provides *no* processing rules
for determining "best" representations among them, and document order
(by other processing rules in Atom) is not considered significant(+1).
PaceSimpleContentType dissallows multiple <content> elements rather
than re-specify MIME precedence rules.

Note that MIME multipart/alternative processing rules ranks the
alternatives, whereas PaceSimpleContentType only indicates "best" and
"alternates", leaving the client to select among the alternates based
on media type.

It is possible in theory that a URI referenced content/@src resource
may be content-type negotiable, but I doubt anyone would seriously
consider that an option for both standard content negotiation issues
as well as publisher implementation reasons.

It is possible in theory that a URI referenced content/@src resource
may itself be a multipart/alternative MIME media type, but "Put
simply, the Web doesn't know about compound objects."
(PaceNonEntryResources, et al)

PaceSimpleContentType chooses to explicitly label (type) each content
use rather than overload semantics from MIME:

  * content is the "best representation"
  * content/@src is content-by-reference
  * 0+ content-alternate elements are alternates
  * 0 or 1 content-source is the "source representation" (for editing
    purposes)

Note, 'content-alternate' has the same relation type as the
'alternate', but denotes an alternate of the content or content
reference, not the entry itself.

  -- Ken



From owner-atom-syntax@mail.imc.org  Wed Jul 14 17:54: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 RAA26920
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 17:54: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 i6ELfRgG080416;
	Wed, 14 Jul 2004 14:41: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 i6ELfRFe080415;
	Wed, 14 Jul 2004 14:41:27 -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 i6ELfQHt080388
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 14:41:27 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 70705 messnum 15253695 invoked from network[83.70.39.115/83-70-39-115.bas2.prp.dublin.eircom.net]); 14 Jul 2004 21:41:25 -0000
Received: from 83-70-39-115.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.39.115)
  by mail11.svc.cra.dublin.eircom.net (qp 70705) with SMTP; 14 Jul 2004 21:41:25 -0000
Message-ID: <40F5A880.6020406@dehora.net>
Date: Wed, 14 Jul 2004 22:41: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
To: Tim Bray <Tim.Bray@Sun.COM>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Low-hanging fruit: compulsory namespaces
References: <6D6BAC41-D517-11D8-8C42-000A95A51C9E@sun.com> <40F46DAC.3030900@dehora.net> <D4AC57AE-D527-11D8-A503-000A95A51C9E@sun.com> <40F48A82.2020408@dehora.net> <3F81CFBF-D59D-11D8-A6EC-000A95A51C9E@sun.com> <40F5415E.5070100@dehora.net> <87k6x6mwef.fsf@nwalsh.com> <40F55860.7000800@dehora.net> <CC364146-D5B5-11D8-A6EC-000A95A51C9E@sun.com>
In-Reply-To: <CC364146-D5B5-11D8-A6EC-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:


> Hmm... maybe I'm unusually lucky but I just haven't been bitten by 
> things going wrong in this space, and I think I use a reasonably vanilla 
> selection of XML tools.  So I'm still uncomfortable with putting it in 
> an RFC.  On the other hand, if Bill is one of many who get bitten by 
> this kind of thing and would like a good-practice note, speak on up. -Tim

Thanks, but I wasn't looking for a BP. I do accept what you've said 
about buggy tools, but what the tools are doing vis-a-vis the right 
thing is not spec'd as far as I can tell (I checked as best I 
could). This goes beyond a tooling or best practice issue, and 
points to architecture - in an internet where everyone and their dog 
has an XML envelope and is careful to keep processing of said 
envelope and body orthogonal, default namespaced XML and plain XML 
don't mesh well. Then again, we can't even get wf XML to be the 
general case for feeds so maybe I'm on crack asking for something 
like this.

Thanks to the XML enveloping bonaza, assuming what's in front of 
your eyes right now is the whole XML document and not a child node 
is a fallacy in the spirit of Deutsch - you absolutely have to 
expect your markup to get embedded. Thusly, Jame's Options 1 *and* 2 
cease to be valid - Option 3 is what remains as the only robust 
approach (as in being strict in what you emit). My answer to Jame's 
question, "whose problem is this?" is twofold;  1) it's no-one's 
problem because it's too easy for anyone to say it's not my problem. 
2) it becomes a non-problem when people take care to qualify any 
plain XML they expect will get onto to the web inside xmlns="".

My position is still that I would like to see words in the format 
around xmlns="" - respectfully, it a no-brainer to SHOULD it. Other 
than that, I think I'm done talking it up :)

cheers
Bill



From owner-atom-syntax@mail.imc.org  Wed Jul 14 18:26: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 SAA01988
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 18:26: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 i6EMIIKC086509;
	Wed, 14 Jul 2004 15:18: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 i6EMIIgg086508;
	Wed, 14 Jul 2004 15:18:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web41504.mail.yahoo.com (web41504.mail.yahoo.com [66.218.93.87])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6EMIHDq086493
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 15:18:17 -0700 (PDT)
	(envelope-from randymorin@yahoo.com)
Message-ID: <20040714221817.60539.qmail@web41504.mail.yahoo.com>
Received: from [66.46.139.106] by web41504.mail.yahoo.com via HTTP; Wed, 14 Jul 2004 15:18:17 PDT
Date: Wed, 14 Jul 2004 15:18:17 -0700 (PDT)
From: Randy Charles Morin <randymorin@yahoo.com>
Reply-To: randy@kbcafe.com
Subject: Re: Work Queue Rotation #3 
To: Tim Bray <tim.bray@sun.com>, Atomlist <atom-syntax@imc.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1468659457-1089843497=:50452"
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>


--0-1468659457-1089843497=:50452
Content-Type: text/plain; charset=us-ascii

Tim wrote:
>This is a tough one. First, we *do* seem to have consensus to 
>add a new <feedinfo> (or <head> or some better name) to group 
>all the feed-level & default stuff before the first 
><atom:entry> and that'll be in the -01 draft.

Do we have a Pace for feedinfo?
Thanks,
 
Randy
http://www.kbcafe.com
 

		
---------------------------------
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
--0-1468659457-1089843497=:50452
Content-Type: text/html; charset=us-ascii

<DIV><FONT face="Courier New">Tim wrote:</FONT></DIV>
<DIV><FONT face="Courier New">&gt;This is a tough one. First, we *do* seem to have consensus to </FONT></DIV>
<DIV><FONT face="Courier New">&gt;add a new &lt;feedinfo&gt; (or &lt;head&gt; or some better name) to group </FONT></DIV>
<DIV><FONT face="Courier New">&gt;all the feed-level &amp; default stuff before the first </FONT></DIV>
<DIV><FONT face="Courier New">&gt;&lt;atom:entry&gt; and that'll be in the -01 draft.</FONT><BR></DIV>
<DIV>Do we have a Pace for feedinfo?</DIV>
<DIV>Thanks,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Randy</DIV>
<DIV><A href="http://www.kbcafe.com">http://www.kbcafe.com</A></DIV>
<DIV>&nbsp;</DIV><p>
		<hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/mail_us/taglines/virus/*http://promotions.yahoo.com/new_mail/static/protection.html">Yahoo! Mail</a> - Helps protect you from nasty viruses.
--0-1468659457-1089843497=:50452--



From owner-atom-syntax@mail.imc.org  Wed Jul 14 18:34: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 SAA02244
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 18:34: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 i6EMHOe9086389;
	Wed, 14 Jul 2004 15:17: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 i6EMHOCa086388;
	Wed, 14 Jul 2004 15:17:24 -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 i6EMHNRu086374;
	Wed, 14 Jul 2004 15:17:23 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net ([66.57.27.65])
	(authenticated bits=0)
	by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i6EMI8HD010201;
	Wed, 14 Jul 2004 18:18:08 -0400
Message-ID: <40F5B0EE.3030608@intertwingly.net>
Date: Wed, 14 Jul 2004 18:17:18 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 Pilgrim <pilgrim@gmail.com>
CC: Paul Hoffman / IMC <phoffman@imc.org>, Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceMustBeWellFormed
References: <14be96d30407061142441f70ee@mail.gmail.com> <40F56B2A.8050500@intertwingly.net> <14be96d304071411092c2c44f4@mail.gmail.com> <p06110426bd1b3deea52a@[10.20.30.249]> <40F59E6C.2060405@intertwingly.net> <14be96d30407141419614b8117@mail.gmail.com>
In-Reply-To: <14be96d30407141419614b8117@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


Mark Pilgrim wrote:

> On Wed, 14 Jul 2004 16:58:20 -0400, Sam Ruby <rubys@intertwingly.net>
> wrote:
> 
>> What spec defines the precedence rules for a MIME type that we have
>> yet to register (i.e., application/atom+xml)?
> 
> Section 8 of
> http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-00.txt 
> states:
> 
> """Optional parameters: "charset": This parameter has identical
> semantics to the charset parameter of the "application/xml" media
> type as specified in RFC 3023."""

It seems to me that THIS is the IETF work group has authority to issue 
new revisions of that draft specification.  Since this is under our 
control, surely we can construct language using the keyword MUST in a 
RFC 2119 compliant manner which covers this situation.

What am I missing?

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Wed Jul 14 18: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 SAA02901
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 18:39: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 i6EMMmg5087326;
	Wed, 14 Jul 2004 15: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 i6EMMmLe087325;
	Wed, 14 Jul 2004 15:22:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EMMlSW087309
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 15:22:47 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net ([66.57.27.65])
	(authenticated bits=0)
	by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i6EMNWQf010404;
	Wed, 14 Jul 2004 18:23:32 -0400
Message-ID: <40F5B232.7000407@intertwingly.net>
Date: Wed, 14 Jul 2004 18:22:42 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 Pilgrim <pilgrim@gmail.com>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceLang
References: <D02C373E-D5A7-11D8-AE1C-003065EA6144@geckotribe.com> <14be96d304071409597134a601@mail.gmail.com> <opsa5at5hnuvpchu@quark> <14be96d3040714143410404efb@mail.gmail.com>
In-Reply-To: <14be96d3040714143410404efb@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


Mark Pilgrim wrote:
> 
> However, this does bring up the point that xml:lang is not just
> specific to Content constructs, and therefore this Pace is invalid.

I don't follow.  Why can't we define validity constraints which 
constrain which elements an xml:lang attribute may, or may not, be placed?

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Wed Jul 14 18:40:07 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02972
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 18:40: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 i6EMLlBQ087177;
	Wed, 14 Jul 2004 15:21:47 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6EMLltG087176;
	Wed, 14 Jul 2004 15:21: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 i6EMLkQJ087169
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 15:21:46 -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 i6EMJg53020498
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 16:19:42 -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 <0I0V00EDM4SFEU@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Wed, 14 Jul 2004 16:21:51 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0V00KBW4SE3Q@mail.sun.net> for atom-syntax@imc.org; Wed,
 14 Jul 2004 16:21:51 -0600 (MDT)
Date: Wed, 14 Jul 2004 15:21:54 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Work Queue Rotation #3
In-reply-to: <20040714203817.8223.qmail@web41511.mail.yahoo.com>
To: Atomlist <atom-syntax@imc.org>
Message-id: <35E800B0-D5E4-11D8-A6EC-000A95A51C9E@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.618)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
References: <20040714203817.8223.qmail@web41511.mail.yahoo.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6EMLkQJ087170
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 Jul 14, 2004, at 1:38 PM, Randy Charles Morin wrote:

> How about we take Joe's [1] suggestion and break the SOAP 
> implementation off into a separate Internet Draft. I'd rather do this 
> because I've found that Paces are often the place where ideas go to 
> die.

I'm inclined to disagree twice.  In our brief history, we've adopted 
about 50% of the Paces we've considered, so the "go to die" remark is 
not supported by the evidence.  Second, if the Atom Protocol is going 
to include a SOAP mode, I think that should be in there as a 
first-class citizen so that we can write clean rules, for example 
requiring server implementations to provide both.  -Tim




From owner-atom-syntax@mail.imc.org  Wed Jul 14 18:40: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 SAA03094
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 18:40: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 i6EMOCBr087540;
	Wed, 14 Jul 2004 15:24: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 i6EMOChI087539;
	Wed, 14 Jul 2004 15:24:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6EMNgwe087437
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 15:24:11 -0700 (PDT)
	(envelope-from jasnell@us.ibm.com)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11])
	by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i6EMNgtf484668;
	Wed, 14 Jul 2004 18:23:42 -0400
Received: from d03nm122.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170])
	by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6EMNfjZ358024;
	Wed, 14 Jul 2004 16:23:42 -0600
In-Reply-To: <40F5A880.6020406@dehora.net>
To: Bill de =?ISO-8859-1?Q?h=D3ra?= <bill@dehora.net>
Cc: Atom Syntax <atom-syntax@imc.org>, owner-atom-syntax@mail.imc.org,
        Tim Bray <Tim.Bray@Sun.COM>
MIME-Version: 1.0
Subject: Re: Low-hanging fruit: compulsory namespaces
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
From: James M Snell <jasnell@us.ibm.com>
X-MIMETrack: S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/14/2004 03:16:36 PM,
	Serialize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/14/2004 03:16:36 PM,
	Serialize complete at 07/14/2004 03:16:36 PM,
	Itemize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/14/2004 03:16:37 PM,
	S/MIME Sign complete at 07/14/2004 03:16:37 PM,
	S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/14/2004 03:23:38 PM,
	S/MIME Sign complete at 07/14/2004 03:23:38 PM,
	Serialize by Router on D03NM122/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at
 07/14/2004 16:23:41,
	Serialize complete at 07/14/2004 16:23:41
Message-ID: <OFDC1AC829.19123828-ON88256ED1.007A1339-88256ED1.007B0384@us.ibm.com>
Date: Wed, 14 Jul 2004 16:23:39 -0600
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z21578_boundary_sign
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>


This is an S/MIME signed message.

---------z21578_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 007A5EB788256ED1_="

This is a multipart message in MIME format.
--=_alternative 007A5EB788256ED1_=
Content-Type: text/plain; charset="US-ASCII"

owner-atom-syntax@mail.imc.org wrote on 07/14/2004 02:41:20 PM:

> 
> Tim Bray wrote:
> 
> 
> > Hmm... maybe I'm unusually lucky but I just haven't been bitten by 
> > things going wrong in this space, and I think I use a reasonably 
vanilla 
> > selection of XML tools.  So I'm still uncomfortable with putting it in 

> > an RFC.  On the other hand, if Bill is one of many who get bitten by 
> > this kind of thing and would like a good-practice note, speak on up. 
-Tim
> 
> Thanks, but I wasn't looking for a BP. I do accept what you've said 
> about buggy tools, but what the tools are doing vis-a-vis the right 
> thing is not spec'd as far as I can tell (I checked as best I 
> could). This goes beyond a tooling or best practice issue, and 
> points to architecture - in an internet where everyone and their dog 
> has an XML envelope and is careful to keep processing of said 
> envelope and body orthogonal, default namespaced XML and plain XML 
> don't mesh well. Then again, we can't even get wf XML to be the 
> general case for feeds so maybe I'm on crack asking for something 
> like this.
> 
> Thanks to the XML enveloping bonaza, assuming what's in front of 
> your eyes right now is the whole XML document and not a child node 
> is a fallacy in the spirit of Deutsch - you absolutely have to 
> expect your markup to get embedded. Thusly, Jame's Options 1 *and* 2 
> cease to be valid - Option 3 is what remains as the only robust 
> approach (as in being strict in what you emit). My answer to Jame's 
> question, "whose problem is this?" is twofold;  1) it's no-one's 
> problem because it's too easy for anyone to say it's not my problem. 
> 2) it becomes a non-problem when people take care to qualify any 
> plain XML they expect will get onto to the web inside xmlns="".
> 
> My position is still that I would like to see words in the format 
> around xmlns="" - respectfully, it a no-brainer to SHOULD it. Other 
> than that, I think I'm done talking it up :)
> 

+1 on this.  While my options 1 & 2 are, strictly speaking, valid 
approaches, they are not robust.  Assuming that Atom feeds MAY be embedded 
in other XML documents, child elements that do not belong to a namespace 
SHOULD include the xmlns="" null namespace declaration.


> cheers
> Bill
> 


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

--=_alternative 007A5EB788256ED1_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>owner-atom-syntax@mail.imc.org wrote on 07/14/2004
02:41:20 PM:<br>
<br>
&gt; <br>
&gt; Tim Bray wrote:<br>
&gt; <br>
&gt; <br>
&gt; &gt; Hmm... maybe I'm unusually lucky but I just haven't been bitten
by <br>
&gt; &gt; things going wrong in this space, and I think I use a reasonably
vanilla <br>
&gt; &gt; selection of XML tools. &nbsp;So I'm still uncomfortable with
putting it in <br>
&gt; &gt; an RFC. &nbsp;On the other hand, if Bill is one of many who get
bitten by <br>
&gt; &gt; this kind of thing and would like a good-practice note, speak
on up. -Tim<br>
&gt; <br>
&gt; Thanks, but I wasn't looking for a BP. I do accept what you've said
<br>
&gt; about buggy tools, but what the tools are doing vis-a-vis the right
<br>
&gt; thing is not spec'd as far as I can tell (I checked as best I <br>
&gt; could). This goes beyond a tooling or best practice issue, and <br>
&gt; points to architecture - in an internet where everyone and their dog
<br>
&gt; has an XML envelope and is careful to keep processing of said <br>
&gt; envelope and body orthogonal, default namespaced XML and plain XML
<br>
&gt; don't mesh well. Then again, we can't even get wf XML to be the <br>
&gt; general case for feeds so maybe I'm on crack asking for something
<br>
&gt; like this.<br>
&gt; <br>
&gt; Thanks to the XML enveloping bonaza, assuming what's in front of <br>
&gt; your eyes right now is the whole XML document and not a child node
<br>
&gt; is a fallacy in the spirit of Deutsch - you absolutely have to <br>
&gt; expect your markup to get embedded. Thusly, Jame's Options 1 *and*
2 <br>
&gt; cease to be valid - Option 3 is what remains as the only robust <br>
&gt; approach (as in being strict in what you emit). My answer to Jame's
<br>
&gt; question, &quot;whose problem is this?&quot; is twofold; &nbsp;1)
it's no-one's <br>
&gt; problem because it's too easy for anyone to say it's not my problem.
<br>
&gt; 2) it becomes a non-problem when people take care to qualify any <br>
&gt; plain XML they expect will get onto to the web inside xmlns=&quot;&quot;.<br>
&gt; <br>
&gt; My position is still that I would like to see words in the format
<br>
&gt; around xmlns=&quot;&quot; - respectfully, it a no-brainer to SHOULD
it. Other <br>
&gt; than that, I think I'm done talking it up :)<br>
&gt; </tt></font>
<br>
<br><font size=2><tt>+1 on this. &nbsp;While my options 1 &amp; 2 are,
strictly speaking, valid approaches, they are not robust. &nbsp;Assuming
that Atom feeds MAY be embedded in other XML documents, child elements
that do not belong to a namespace SHOULD include the xmlns=&quot;&quot;
null namespace declaration.</tt></font>
<br>
<br><font size=2><tt><br>
&gt; cheers<br>
&gt; Bill<br>
&gt; <br>
</tt></font>
<br>
<br><font size=2 face="sans-serif">- James M Snell<br>
 &nbsp;jasnell@us.ibm.com<br>
 &nbsp;http://www.ibm.com<br>
 &nbsp;(877) 511-5082 / Office<br>
 &nbsp;930-1979 / Tie Line</font>
<br>
--=_alternative 007A5EB788256ED1_=--

---------z21578_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIIUOAIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIISWDCCAtow
ggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1
aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAy
MDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA629xc49NpAPz
cAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7glzJKgPkPzlTZZfznznGbmAWVnNBQ
lyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnwNclOnnP2sKufuPzbTImQTTi5c8JZNZcM
J0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEEBAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1Ud
DgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAPBgNVHRMBAf8EBTADAQH/MDEGA1UdJQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUH
AwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvu
jQupk2oCScMd3FIHLE7hOfu8YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14ke
McF9ViNdewEoBGiAycUq8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIC2jCCAkOgAwIB
AgIDAxS2MA0GCSqGSIb3DQEBBAUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwMTE0MjIw
NzExWhcNMTExMjMxMjIwNzExWjBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25h
bCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrb3Fzj02kA/NwCy5KFMiY
tFgyTJ6kMSQLVSs9uwVHIAVkqy/enDQwZ9b/7uCXMkqA+Q/OVNll/OfOcZuYBZWc0FCXI9qw60KO
J/rTd65FdF4dwp8cw8si0qjOJtYg8cm46fA1yU6ec/awq5+4/NtMiZBNOLlzwlk1lwwnRgXNNwID
AQABo4GqMIGnMBEGCWCGSAGG+EIBAQQEAwIAhzAOBgNVHQ8BAf8EBAMCAcYwHQYDVR0OBBYEFK5U
DpLqqDOpKyQtx8hvMNze80pAMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMA8GA1Ud
EwEB/wQFMAMBAf8wMQYDVR0lBCowKAYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYB
BQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAMnJ7c2YLyrY/PKlFl+7sm8NENfWtFxqdm+6NC6mTagJJ
wx3cUgcsTuE5+7xh9+/G0tTfLzA1qZAQ5GNMPXvmoB9+vJfKnC2JWMFQpIOUEJDXiR4xwX1WI117
ASgEaIDJxSrxHcuuV/hMIO9bgZ6C41MUVmdLTKBgBOImTuIPK8QwggMgMIICiaADAgECAgQ13vTP
MA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQL
EyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0MTUxWhcN
MTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMk
RXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKKlQRkrPFr
U18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkwrFEeO68r
1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOgYaRfMF0x
CzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBD
ZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAxODA4MjIx
NjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAdBgNV
HQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0HQQAEDTAL
GwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwlMQ0AppJu
f7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn00DbOyZY
sih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMgMIICiaADAgEC
AgQ13vTPMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0
MTUxWhcNMTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsG
A1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKK
lQRkrPFrU18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkw
rFEeO68r1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOg
YaRfMF0xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNl
Y3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAx
ODA4MjIxNjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAdBgNVHQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0H
QQAEDTALGwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwl
MQ0AppJuf7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn
00DbOyZYsih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMmMIIC
j6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIxNjM2NTRaMIGFMQsw
CQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEXMBUGA1UEAxMOSmFt
ZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkqhkiG9w0BCQEWEmph
c25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwKpbDG3zMatEuuOT
FYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSyd+7nwqAvbBfPj+0S
vcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7tBJlLrwDRCMoNlPuQ
Kg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQW
BBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOgFAwSamFzbmVs
bEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pAMCcGA1UdJQQgMB4G
CCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAZMKevB7dFfb9
23OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY8BjwVHxiYgG4xkxf
B1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOIzj3lz3xd+uOzqRFg
/Wsg/VMwggMmMIICj6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAy
BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNV
BAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIx
NjM2NTRaMIGFMQswCQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEX
MBUGA1UEAxMOSmFtZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkq
hkiG9w0BCQEWEmphc25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
wKpbDG3zMatEuuOTFYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSy
d+7nwqAvbBfPj+0SvcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7t
BJlLrwDRCMoNlPuQKg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQD
AgXgMB0GA1UdDgQWBBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcU
AgOgFAwSamFzbmVsbEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA
MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQAD
gYEAZMKevB7dFfb923OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY
8BjwVHxiYgG4xkxfB1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOI
zj3lz3xd+uOzqRFg/Wsg/VMxggG7MIIBtwIBATBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJ
bnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0g
Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwF+kzAJBgUrDgMCGgUAoIGiMBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDcxNDIyMTYzNlowIwYJKoZIhvcNAQkEMRYE
FOQcNKguVY7wdjgGORToDWNRWC5KMEMGCSqGSIb3DQEJDzE2MDQwBwYFKw4DAh0wDgYIKoZIhvcN
AwICAgCAMAoGCCqGSIb3DQMHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAgvooo6E0
ueEHRd1Iihd/fkwz1TTVr6dU+qjiyDQGfRzAaKNRT/Jxjb1kEWb0W5FK00XKpch8IUjZtKf2DOQC
4dg4/otuSnqUaD/TBqhBqd2mlwNvQupFr8ZSxetPZa8YaFUu72U2a0CgxRPfkhnmpIexRl9KjGiB
PW0lvHMba0gAAAAA

---------z21578_boundary_sign--



From owner-atom-syntax@mail.imc.org  Wed Jul 14 18:50: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 SAA04359
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 18:50: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 i6EMgw3r090598;
	Wed, 14 Jul 2004 15: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 i6EMgw2W090597;
	Wed, 14 Jul 2004 15:42:58 -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 i6EMggkC090552;
	Wed, 14 Jul 2004 15:42:43 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p0611042bbd1b66fa15ef@[10.20.30.249]>
In-Reply-To: <14be96d30407141427187f294d@mail.gmail.com>
References: <14be96d30407061142441f70ee@mail.gmail.com>
 <40F56B2A.8050500@intertwingly.net>
 <14be96d304071411092c2c44f4@mail.gmail.com>
 <p06110426bd1b3deea52a@10.20.30.249>
 <14be96d30407141427187f294d@mail.gmail.com>
Date: Wed, 14 Jul 2004 15:43:14 -0700
To: Mark Pilgrim <pilgrim@gmail.com>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: PaceMustBeWellFormed
Cc: Sam Ruby <rubys@intertwingly.net>, Atom-Syntax <atom-syntax@imc.org>
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 5:27 PM -0400 7/14/04, Mark Pilgrim wrote:
>I submit that the same is true of an Atom document.  It has multiple
>ways to specify the encoding (in-band and out-of-band), and the HTTP
>Content-Type header takes precedence, therefore it should be the
>preferred way to provide the character encoding for an Atom document.

Agree. But we *have* to say the explicitly in the document if we 
expect anyone to interoperate.

>I admit the link was dropped in without explanation, but I'm not sure
>what other conclusion you could draw from that document.

That it is something that the W3C is thinking about but haven't come 
to a firm conclusion on.

>   Are you
>suggesting that Atom documents are so different from XHTML documents
>that a different precendence order should apply, or that a different
>practice should be considered "best practice"?

Nope. I am (now) saying explicitly that we have to lay out our rules 
in the spec.

>If my wrestling with RFC 3023 has taught me anything, it is that HTTP
>has primacy.

Sounds good to me. How do others feel?

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Wed Jul 14 19:02: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 TAA06301
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 19:02: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 i6EMpeS0092084;
	Wed, 14 Jul 2004 15:51:40 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6EMpeYC092083;
	Wed, 14 Jul 2004 15:51:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from 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 i6EMpb8h092060
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 15:51:39 -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 i6EMpb53020396
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 17:51:38 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6EMpbIp020392;
	Wed, 14 Jul 2004 17:51:37 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Feed of site events (was: Thought experiment: Using a synthetic feed to find out about other feeds)
References: <200407081614.BHM20108@ms8.netsolmail.com>
	<m3hdsiqspb.fsf@bitsko.slc.ut.us> <40EE7F98.6040207@intertwingly.net>
	<opsavggornuvpchu@quark> <40F59797.80104@AOL.NET>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 14 Jul 2004 17:51:37 -0500
In-Reply-To: <40F59797.80104@AOL.NET>
Message-ID: <m37jt6kxs6.fsf@bitsko.slc.ut.us>
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


"John Panzer" <jpanzer@aol.net> writes:

> A "feed of sites" is fuzzy, though -- what does that mean?  Let me
> suggest a more concrete underlying concept: A "feed of site events".
> That is, a feed which consists of interesting events happening to
> sites separate from the addition/updating/deletion of entries.

This has been discussed before, on the wiki look around
RevisedConceptualModel, ConceptualModelRevisited.  Some head messages
in the list archive:

    http://imc.org/atom-syntax/mail-archive/msg01029.html
    http://imc.org/atom-syntax/mail-archive/msg01046.html
    http://imc.org/atom-syntax/mail-archive/msg01068.html
    http://imc.org/atom-syntax/mail-archive/msg01075.html

These refer specifically to the model of "event streams", or feed
elements that represent changes of state of resources.  (Note: not
talking about events in the sense of "football game" or "conference".)

The distinction is subtle but obvious in hindsight:

  * The current model of "feed of entries" is copies of or references
    to entry resources that have changed state, rather than any
    indication of "why" they have changed or why they are in the feed.

  * A "feed of site events" models a set of "change notices" telling
    you what or why something changed, and then pointing to the entry
    or other site resource.

I wasn't too particular the first time about which model we choose,
but it should be clear that these models *are* distinct, and current
Atom and syndication practice follow the "feed of entries" model.

> P.S: I think that a "feed of site events" fits exactly into the
> definition below:

 > >> An aggregator works on the principle of displaying new entries
 > >> when they appear, and sometimes holding "old" entries for
 > >> perusal, and re-showing updated entries if they're changed.

A "feed of site events" would fulfill that requirement, but one thing
I want to be clear in the "Atom is only generic containers" thread is
that each of the resource types really does model different things and
Atom is speccing how those models are represented and how they are
used.  One can propose a change to the model, but one can't say the
models are generic, all-purpose containers.  WebDAV has a much more
generic model of resource containers, resource metadata, and
notification that would fulfill the requirements as well, yet it too
has a model of representation and usage that is different.

  -- Ken



From owner-atom-syntax@mail.imc.org  Wed Jul 14 19:08: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 TAA06953
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 19:08: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 i6EMxLIO093309;
	Wed, 14 Jul 2004 15:59: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 i6EMxLTu093308;
	Wed, 14 Jul 2004 15:59:21 -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 i6EMxLHZ093290
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 15:59:21 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040714225921.1933.qmail@web41214.mail.yahoo.com>
Received: from [207.46.238.138] by web41214.mail.yahoo.com via HTTP; Wed, 14 Jul 2004 15:59:21 PDT
Date: Wed, 14 Jul 2004 15:59:21 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Low-hanging fruit: compulsory namespaces
To: "Bill_de_hÓra" <bill@dehora.net>
Cc: atom-syntax@imc.org
In-Reply-To: <40F5A880.6020406@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:
> 
> Tim Bray wrote:
> 
> 
> > Hmm... maybe I'm unusually lucky but I just
> haven't been bitten by 
> > things going wrong in this space, and I think I
> use a reasonably vanilla 
> > selection of XML tools.  So I'm still
> uncomfortable with putting it in 
> > an RFC.  On the other hand, if Bill is one of many
> who get bitten by 
> > this kind of thing and would like a good-practice
> note, speak on up. -Tim
> 
> Thanks, but I wasn't looking for a BP. I do accept
> what you've said 
> about buggy tools, but what the tools are doing
> vis-a-vis the right 
> thing is not spec'd as far as I can tell (I checked
> as best I 
> could). This goes beyond a tooling or best practice
> issue, and 
> points to architecture - in an internet where
> everyone and their dog 
> has an XML envelope and is careful to keep
> processing of said 
> envelope and body orthogonal, default namespaced XML
> and plain XML 
> don't mesh well. Then again, we can't even get wf
> XML to be the 
> general case for feeds so maybe I'm on crack asking
> for something 
> like this.
> 
> Thanks to the XML enveloping bonaza, assuming what's
> in front of 
> your eyes right now is the whole XML document and
> not a child node 
> is a fallacy in the spirit of Deutsch - you
> absolutely have to 
> expect your markup to get embedded. Thusly, Jame's
> Options 1 *and* 2 
> cease to be valid - Option 3 is what remains as the
> only robust 
> approach (as in being strict in what you emit). My
> answer to Jame's 
> question, "whose problem is this?" is twofold;  1)
> it's no-one's 
> problem because it's too easy for anyone to say it's
> not my problem. 
> 2) it becomes a non-problem when people take care to
> qualify any 
> plain XML they expect will get onto to the web
> inside xmlns="".
> 
> My position is still that I would like to see words
> in the format 
> around xmlns="" - respectfully, it a no-brainer to
> SHOULD it. Other 
> than that, I think I'm done talking it up :)

-1. 

I agree with Tim. I haven't seen this behavior in any
of the various XML tools I've used in the wild. It
seems this would basically be putting potentially
confusing text about namespaces in the text due to one
or two buggy implementations of XML tools or some bad
code that someone once saw on the Web. 



=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
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 Jul 14 19:22: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 TAA08006
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 19:22: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 i6ENCc2Q095488;
	Wed, 14 Jul 2004 16:12: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 i6ENCc8E095486;
	Wed, 14 Jul 2004 16:12:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ENCaCd095473
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 16:12: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 i6ENCgil008029
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 17:12:42 -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 <0I0V00K71755ZQ@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Wed, 14 Jul 2004 17:12:42 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0V00KA07553N@mail.sun.net> for atom-syntax@imc.org; Wed,
 14 Jul 2004 17:12:41 -0600 (MDT)
Date: Wed, 14 Jul 2004 16:12:38 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceMustBeWellFormed
In-reply-to: <p0611042bbd1b66fa15ef@[10.20.30.249]>
To: Atom-Syntax <atom-syntax@imc.org>
Message-id: <4CB0764A-D5EB-11D8-A6EC-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: <14be96d30407061142441f70ee@mail.gmail.com>
 <40F56B2A.8050500@intertwingly.net>
 <14be96d304071411092c2c44f4@mail.gmail.com>
 <p06110426bd1b3deea52a@10.20.30.249>
 <14be96d30407141427187f294d@mail.gmail.com>
 <p0611042bbd1b66fa15ef@[10.20.30.249]>
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 Jul 14, 2004, at 3:43 PM, Paul Hoffman / IMC wrote:

> At 5:27 PM -0400 7/14/04, Mark Pilgrim wrote:
>> If my wrestling with RFC 3023 has taught me anything, it is that HTTP
>> has primacy.
>
> Sounds good to me. How do others feel?

I feel very unhappy.  Mark produced excellent statistics demonstrating 
powerfully that (in the case of RSS) a very high proportion of websites 
cheerfully ignore 3023, and that, as a consequence of this, a high 
proportion of RSS clients cheerfully ignore 3023 since if they followed 
it, they would have to throw otherwise-OK data away.   Specifically, 
the problem is that 3023 blesses the use of text/xml with no charset 
(which was the Apache default for *.xml for a long time) which in 
nearly every case is wrong, and thus, if you follow the rest of 3023, 
will force software to throw the data on the ground.

Mark has made two intelligent, coherent suggestions for how we might 
deal with this:

1. In the case where the data is delivered as text/html with no 
charset, ignore what RFC3023 says and ascertain if this is a 
well-formed Atom instance using the (very robust) self-describing 
nature of XML as regards character encodings.
2. Because of the broken-ness in 3023 and Apache, always serve 
everything as US-ASCII by using  numeric character references for all 
non-ASCII characters.

Mark subsequently stated he wants to withdraw suggestion #1 but I'm 
dissenting on that, it's a reasonable proposal that we should look at.  
There may be other proposals worthy of our consideration.

In any case, saying "HTTP has primacy" sounds good but should cause 
extreme nervousness in the case that (1) the relevant media-type RFC is 
broken and (2) the media-type is demonstrably being used incorrectly in 
a high proportion of cases.

And I *guarantee* that a high proportion of implementors will, if we 
foolishly say, "follow the 3023 rules" cheerfully ignore us if it will 
result in them having to discard apparently valid Atom feeds.

I do not think that this is anyone else's problem.  It's our problem.  
-Tim



From owner-atom-syntax@mail.imc.org  Wed Jul 14 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 TAA09761
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 19:39: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 i6ENUCle098367;
	Wed, 14 Jul 2004 16:30:12 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6ENUCdl098366;
	Wed, 14 Jul 2004 16:30: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 i6ENUBCf098353;
	Wed, 14 Jul 2004 16:30: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 i6ENUkt3013674;
	Wed, 14 Jul 2004 19:30:47 -0400
Message-ID: <40F5C1F4.5080709@intertwingly.net>
Date: Wed, 14 Jul 2004 19:29:56 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <phoffman@imc.org>
CC: Mark Pilgrim <pilgrim@gmail.com>, Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceMustBeWellFormed
References: <14be96d30407061142441f70ee@mail.gmail.com> <40F56B2A.8050500@intertwingly.net> <14be96d304071411092c2c44f4@mail.gmail.com> <p06110426bd1b3deea52a@10.20.30.249> <14be96d30407141427187f294d@mail.gmail.com> <p0611042bbd1b66fa15ef@[10.20.30.249]>
In-Reply-To: <p0611042bbd1b66fa15ef@[10.20.30.249]>
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


Paul Hoffman / IMC wrote:
> 
>> If my wrestling with RFC 3023 has taught me anything, it is that HTTP
>> has primacy.
> 
> Sounds good to me. How do others feel?

I don't think that is framing the question correctly.  As an example, I 
presume that we are free to say that in order to produce an Atom 
compliant application, the following header MUST be present:

   Content-Type: application/atom+xml; charset=utf-8

In other words, we are free to specify what content-types are valid, and 
we are free to specify what charsets are valid.

Now, I am not going to propose that we limit charset to utf-8.  Instead, 
I am simply saying that we should treat as an error the case where the 
charset in the HTTP header and the encoding that RFC 3023 would have 
determined to be in effect in the absence of a charset parameter are 
different.

If it isn't valid for them to be different, the question of precedence 
never comes up.

I presume that we can control the definition for mime types that we have 
yet to define.  And while we can work with the authors of RFC 3023, I 
don't have any hope that they will change the definition for text/xml, 
but there just *might* be wiggle room to consider a change in 
application/xml.

Mark, does that seem OK, or do you still want to specify the precedence?

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Wed Jul 14 19:42: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 TAA10202
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 19:42: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 i6ENXWwI098947;
	Wed, 14 Jul 2004 16:33: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 i6ENXWvC098946;
	Wed, 14 Jul 2004 16:33:32 -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 i6ENXVNq098930
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 16:33:31 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 90673 messnum 15325486 invoked from network[83.70.39.115/83-70-39-115.bas2.prp.dublin.eircom.net]); 14 Jul 2004 23:33:31 -0000
Received: from 83-70-39-115.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.39.115)
  by mail11.svc.cra.dublin.eircom.net (qp 90673) with SMTP; 14 Jul 2004 23:33:31 -0000
Message-ID: <40F5C2C6.1080704@dehora.net>
Date: Thu, 15 Jul 2004 00:33:26 +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: Low-hanging fruit: compulsory namespaces
References: <20040714225921.1933.qmail@web41214.mail.yahoo.com>
In-Reply-To: <20040714225921.1933.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: <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:

> I agree with Tim. I haven't seen this behavior in any
> of the various XML tools I've used in the wild. 

It's already been pointed out that this is not a tools matter.


> It
> seems this would basically be putting potentially
> confusing text about namespaces in the text 

Please explain what you find confusing.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Wed Jul 14 19:55: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 TAA11849
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 19:55: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 i6ENjYEc000702;
	Wed, 14 Jul 2004 16:45:34 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6ENjYfO000701;
	Wed, 14 Jul 2004 16:45:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.200])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6ENjX1X000695
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 16:45:33 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d15so432466rng
        for <atom-syntax@imc.org>; Wed, 14 Jul 2004 16:45:38 -0700 (PDT)
Received: by 10.38.207.60 with SMTP id e60mr2898rng;
        Wed, 14 Jul 2004 16:45:38 -0700 (PDT)
Message-ID: <14be96d3040714164534e0561c@mail.gmail.com>
Date: Wed, 14 Jul 2004 19:45:38 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Sam Ruby <rubys@intertwingly.net>
Subject: Re: PaceLang
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <40F5B232.7000407@intertwingly.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <D02C373E-D5A7-11D8-AE1C-003065EA6144@geckotribe.com> <14be96d304071409597134a601@mail.gmail.com> <opsa5at5hnuvpchu@quark> <14be96d3040714143410404efb@mail.gmail.com> <40F5B232.7000407@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 Wed, 14 Jul 2004 18:22:42 -0400, Sam Ruby <rubys@intertwingly.net> wrote:
> Mark Pilgrim wrote:
> >
> > However, this does bring up the point that xml:lang is not just
> > specific to Content constructs, and therefore this Pace is invalid.
> 
> I don't follow.  Why can't we define validity constraints which
> constrain which elements an xml:lang attribute may, or may not, be placed?

I was under the impression that the current draft allowed xml:lang
anywhere, and this Pace was restricting it to Content constructs.  My
point is that there are several other places in feeds where xml:lang
would be useful.

I think we should withdraw PaceLang and keep the language currently in the spec.

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Wed Jul 14 20:06:38 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13798
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 20:06:38 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ENvAMa002307;
	Wed, 14 Jul 2004 16:57: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 i6ENvAJA002306;
	Wed, 14 Jul 2004 16:57:10 -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 i6ENvAhG002300
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 16:57:10 -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 9889F4EF06;
	Wed, 14 Jul 2004 19:57:13 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040715075513.046ea260@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Thu, 15 Jul 2004 08:00:16 +0900
To: Sam Ruby <rubys@intertwingly.net>, Mark Pilgrim <pilgrim@gmail.com>
From: Martin Duerst <duerst@w3.org>
Subject: Re: PaceMustBeWellFormed
Cc: Atom-Syntax <atom-syntax@imc.org>, EB2M-MRT@asahi-net.or.jp
In-Reply-To: <40F57A22.5060409@intertwingly.net>
References: <14be96d304071411092c2c44f4@mail.gmail.com>
 <14be96d30407061142441f70ee@mail.gmail.com>
 <40F56B2A.8050500@intertwingly.net>
 <14be96d304071411092c2c44f4@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 14:23 04/07/14 -0400, Sam Ruby wrote:

>Mark Pilgrim wrote:
>>
>>>(6.1 1) I would, howevever, be supportive of a statement that if a
>>>charset were provided with any application/* MIME type, THEN it MUST
>>>match what the encoding that would have been determined had the charset
>>>been omitted.

This does not make sense. Assume you blog is generated by some
script, or comes out of a database. The scripting language or
database treats everything as characters, it doesn't have a clue
what encoding will be used when the stuff is served as HTTP.
Then there is a last step that does the encoding, and puts
on a HTTP header.


>>That is not an RFC-2119-compliant use of the word "MUST".  Conflicting
>>metadata declarations are not an interoperability problem, because
>>there are clear precedence rules governing which one wins.  (The
>>charset in the HTTP headers always wins.)
>
>It certainly is valid for an RFC produced by the AtomPub working group to 
>constrain the permissable values of the charset parameter of the 
>Content-Type header MUST be when the application/atom+xml MIME type is 
>used in conjunction with either the AtomPub format or protocol.

It is possible to do that, but it may be highly preferable not to
create exceptions to the general rule for application/...+xml.


>I would also suggest that we coordinate with RFC 3023 to promote the use 
>of similar language in that specification when application/xml is used.

There may be a new draft out by now. There is a mailing list
specifically for discussing RFC 3023 and its successor. It's
ietf-xml-mime.imc.org. (List-Archive:
http://www.imc.org/ietf-xml-mime/mail-archive/,
List-Subscribe: mailto:ietf-xml-mime-request@imc.org?body=subscribe).

I suggest that people interested in that discussion join that list.


Regards,    Martin.
Content-Type: text/plain; charset="us-ascii"
X-UIDL: 526780e3b94f30cec999b6d288ca074b




From owner-atom-syntax@mail.imc.org  Wed Jul 14 20:15:04 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14556
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 20:15:04 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6F05h0p003816;
	Wed, 14 Jul 2004 17:05: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 i6F05h3Z003814;
	Wed, 14 Jul 2004 17:05:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6F05hSe003790
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 17:05:43 -0700 (PDT)
	(envelope-from stevej@google.com)
Received: from [172.24.72.132] (dhcp-172-24-72-132.corp.google.com [172.24.72.132])
	(authenticated bits=0)
	by 216-239-45-4.google.com (8.12.11/8.12.9) with ESMTP id i6F05LHr018152
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Wed, 14 Jul 2004 17:05:32 -0700
In-Reply-To: <CC364146-D5B5-11D8-A6EC-000A95A51C9E@sun.com>
References: <6D6BAC41-D517-11D8-8C42-000A95A51C9E@sun.com> <40F46DAC.3030900@dehora.net> <D4AC57AE-D527-11D8-A503-000A95A51C9E@sun.com> <40F48A82.2020408@dehora.net> <3F81CFBF-D59D-11D8-A6EC-000A95A51C9E@sun.com> <40F5415E.5070100@dehora.net> <87k6x6mwef.fsf@nwalsh.com> <40F55860.7000800@dehora.net> <CC364146-D5B5-11D8-A6EC-000A95A51C9E@sun.com>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <A90FCC42-D5F2-11D8-9B45-000A95B09B46@google.com>
Cc: Atom Syntax <atom-syntax@imc.org>
From: steve jenson <stevej@google.com>
Subject: Re: Low-hanging fruit: compulsory namespaces
Date: Wed, 14 Jul 2004 17:05:20 -0700
To: Tim Bray <Tim.Bray@Sun.COM>
X-Mailer: Apple Mail (2.613)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6F05hSe003809
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 Jul 14, 2004, at 9:49 AM, Tim Bray wrote:

> On Jul 14, 2004, at 8:59 AM, Bill de hÓra wrote:
>
>> I would expect an utterance along the lines of 'inside Atom, you 
>> SHOULD qualify your non-namespace markup with xmlns=""' to aid 
>> robustness and increase happiness all round.
>
> Hmm... maybe I'm unusually lucky but I just haven't been bitten by 
> things going wrong in this space, and I think I use a reasonably 
> vanilla selection of XML tools.  So I'm still uncomfortable with 
> putting it in an RFC.  On the other hand, if Bill is one of many who 
> get bitten by this kind of thing and would like a good-practice note, 
> speak on up. -Tim

Blogger feeds won't wrap your content in a <div 
xmlns="http://www.w3.org/1999/xhtml"> if your fragment is well formed. 
Sometimes this means that you'll end up with html tags in the atom 
namespace. I didn't notice this was a problem until users of 
Mozilla-based newsreaders pointed it out. A note like this would have 
persuaded me to unset the default namespace before the problem arose.


Steve




From owner-atom-syntax@mail.imc.org  Wed Jul 14 20:15: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 UAA14558
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 20:15:04 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6F047q7003613;
	Wed, 14 Jul 2004 17: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 i6F0470v003612;
	Wed, 14 Jul 2004 17:04: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 i6F0473v003606
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 17:04:07 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.23] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id C5EA7727D; Wed, 14 Jul 2004 17:04:12 -0700 (PDT)
In-Reply-To: <40F5A880.6020406@dehora.net>
References: <6D6BAC41-D517-11D8-8C42-000A95A51C9E@sun.com> <40F46DAC.3030900@dehora.net> <D4AC57AE-D527-11D8-A503-000A95A51C9E@sun.com> <40F48A82.2020408@dehora.net> <3F81CFBF-D59D-11D8-A6EC-000A95A51C9E@sun.com> <40F5415E.5070100@dehora.net> <87k6x6mwef.fsf@nwalsh.com> <40F55860.7000800@dehora.net> <CC364146-D5B5-11D8-A6EC-000A95A51C9E@sun.com> <40F5A880.6020406@dehora.net>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <8015AD64-D5F2-11D8-AA19-000A95BD86C0@mnot.net>
Cc: Atom Syntax <atom-syntax@imc.org>, Tim Bray <Tim.Bray@Sun.COM>
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: Low-hanging fruit: compulsory namespaces
Date: Wed, 14 Jul 2004 17:04:11 -0700
To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>
X-Mailer: Apple Mail (2.618)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6F0473v003607
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 Jul 14, 2004, at 2:41 PM, Bill de hÓra wrote:

> Thanks, but I wasn't looking for a BP. I do accept what you've said 
> about buggy tools, but what the tools are doing vis-a-vis the right 
> thing is not spec'd as far as I can tell (I checked as best I could). 
> This goes beyond a tooling or best practice issue, and points to 
> architecture - in an internet where everyone and their dog has an XML 
> envelope and is careful to keep processing of said envelope and body 
> orthogonal, default namespaced XML and plain XML don't mesh well. Then 
> again, we can't even get wf XML to be the general case for feeds so 
> maybe I'm on crack asking for something like this.
>
> Thanks to the XML enveloping bonaza, assuming what's in front of your 
> eyes right now is the whole XML document and not a child node is a 
> fallacy in the spirit of Deutsch - you absolutely have to expect your 
> markup to get embedded. Thusly, Jame's Options 1 *and* 2 cease to be 
> valid - Option 3 is what remains as the only robust approach (as in 
> being strict in what you emit). My answer to Jame's question, "whose 
> problem is this?" is twofold;  1) it's no-one's problem because it's 
> too easy for anyone to say it's not my problem. 2) it becomes a 
> non-problem when people take care to qualify any plain XML they expect 
> will get onto to the web inside xmlns="".
>
> My position is still that I would like to see words in the format 
> around xmlns="" - respectfully, it a no-brainer to SHOULD it. Other 
> than that, I think I'm done talking it up :)


Hi Bill,

I would very much like to see this kind of language in a "Best 
Practices" appendix or a Primer, but would object to making it 
normative with a SHOULD. It's advice about the use of an underlying 
specification -- Namespace in XML -- not specific to Atom. There may 
not be RFC2119 language specifically addressing this situation in the 
underlying specifications, but the implications of namespace defaulting 
are clear upon a careful reading of the appropriate specs; we just need 
to emphasise that for implementers and users, not place a normative 
requirement on them.

Cheers,



--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org  Wed Jul 14 20:19:24 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15166
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 20:19:24 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6F09jS7004330;
	Wed, 14 Jul 2004 17: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 i6F09j7o004329;
	Wed, 14 Jul 2004 17:09:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6F09iGt004323
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 17:09:44 -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 i6F07f53016218
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 18:07:41 -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 <0I0V00KS29SDZQ@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Wed, 14 Jul 2004 18:09:50 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0V00CLV9SDE1@mail.sun.net> for atom-syntax@imc.org; Wed,
 14 Jul 2004 18:09:49 -0600 (MDT)
Date: Wed, 14 Jul 2004 17:09:52 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceLang
In-reply-to: <14be96d3040714164534e0561c@mail.gmail.com>
To: Atom-Syntax Syntax <atom-syntax@imc.org>
Message-id: <4B1F9CA8-D5F3-11D8-A6EC-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: <D02C373E-D5A7-11D8-AE1C-003065EA6144@geckotribe.com>
 <14be96d304071409597134a601@mail.gmail.com> <opsa5at5hnuvpchu@quark>
 <14be96d3040714143410404efb@mail.gmail.com>
 <40F5B232.7000407@intertwingly.net> <14be96d3040714164534e0561c@mail.gmail.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 Jul 14, 2004, at 4:45 PM, Mark Pilgrim wrote:

> I was under the impression that the current draft allowed xml:lang
> anywhere, and this Pace was restricting it to Content constructs.  My
> point is that there are several other places in feeds where xml:lang
> would be useful.
>
> I think we should withdraw PaceLang and keep the language currently in 
> the spec.

+1  -Tim



From owner-atom-syntax@mail.imc.org  Wed Jul 14 20:25: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 UAA16521
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 20:25: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 i6F0H8V4005351;
	Wed, 14 Jul 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 i6F0H8Lk005350;
	Wed, 14 Jul 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 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 i6F0H8iH005334
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 17:17:08 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040715001709.38343.qmail@web41211.mail.yahoo.com>
Received: from [131.107.3.70] by web41211.mail.yahoo.com via HTTP; Wed, 14 Jul 2004 17:17:09 PDT
Date: Wed, 14 Jul 2004 17:17:09 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Low-hanging fruit: compulsory namespaces
To: "Bill_de_hÓra" <bill@dehora.net>, atom-syntax@imc.org
In-Reply-To: <40F5C2C6.1080704@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:
>
> > It
> > seems this would basically be putting potentially
> > confusing text about namespaces in the text 
> 
> Please explain what you find confusing.

I don't find anything confusing. Many of my users in
my dayjob (users of XML on Microsoft platforms) are
confused by XML namespaces and it is all black magic
to them why changing an attribute {default namespace
decl) can make their previously working XPath
expressions fail. 

I don't think putting some 'best practice' for broken
tools [which is what I saw in the examples James
showed] won't lead to confusion to XML novices who are
working with Atom on how XML namespaces are used. 


=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
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 Jul 14 20:26: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 UAA16549
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 20:26: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 i6F0HMwA005394;
	Wed, 14 Jul 2004 17: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 i6F0HMGK005393;
	Wed, 14 Jul 2004 17:17: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 i6F0HMgt005387
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 17:17:22 -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 i6F0HRJd012639;
	Wed, 14 Jul 2004 17:17:28 -0700 (PDT)
Received: from [192.168.1.100] (h00080d858303.ne.client2.attbi.com [24.61.1.243])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id i6F0HFZt008033;
	Wed, 14 Jul 2004 17:17:19 -0700 (PDT)
In-Reply-To: <D1CE520E-D5B1-11D8-A6EC-000A95A51C9E@sun.com>
References: <20040714153153.98934.qmail@web41201.mail.yahoo.com> <D1CE520E-D5B1-11D8-A6EC-000A95A51C9E@sun.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <517C18FB-D5F4-11D8-B24C-000A95DC3D90@mac.com>
Content-Transfer-Encoding: 7bit
Cc: Atom-Syntax Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: a methodical approach to defining what date  elements we need
Date: Wed, 14 Jul 2004 20:17:12 -0400
To: Tim Bray <Tim.Bray@Sun.COM>
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>
Content-Transfer-Encoding: 7bit


On 14 Jul 2004, at 12:21 pm, Tim Bray wrote:

> +1.  This minor/major thing is an invitation to endless hairsplitting 
> disputes.   As a consumer of a feed, I want the provider to know when 
> they consider it to have been modified, as a binary condition.  As a 
> provider of a feed, I don't want to have to invest cycles agonizing 
> over how "major" an update is.  It's a binary decision: is it major 
> enough for the change to be reflected in the feed, yes or no.  Without 
> a shared definition of what major/minor *means*, this will produce 
> zero interoperability. -Tim

You can sidestep this by saying that publishers *have the option* of 
using <updated> when they have made major changes, and to actually say 
that it is intended to have the effect of bringing the entry back to 
the users attention (how to word that effectively, I have no idea). 
That way, publishing systems that don't make any distinction just don't 
update/use the element, which will simply have the effect of not 
bringing any updates to the end user's attention. Publishers who do use 
the element simply need to ask themselves "Do I wish yo bring these 
changes to the user's attention?". I think it has a good chance of 
working.

(Obviously this is very specific to aggregators)

Graham



From owner-atom-syntax@mail.imc.org  Wed Jul 14 20:34: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 UAA16946
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 20:34:58 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6F0OBq9006805;
	Wed, 14 Jul 2004 17:24: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 i6F0OBRX006804;
	Wed, 14 Jul 2004 17:24:11 -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 i6F0O9J0006685
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 17:24:10 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 15 Jul 2004 10:28:55 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Thu, 15 Jul 2004 10:23:36 +1000
Subject: Re: PaceLang
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD1C0BA8.1FBBC%eric.scheid@ironclad.net.au>
In-Reply-To: <14be96d3040714164534e0561c@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: <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 15/7/04 9:45 AM, "Mark Pilgrim" <pilgrim@gmail.com> wrote:

> I was under the impression that the current draft allowed xml:lang
> anywhere, and this Pace was restricting it to Content constructs.  My
> point is that there are several other places in feeds where xml:lang
> would be useful.

the problem was someone pointed out that you can only *put* xml:lang in
those places which are specified as allowing xml:lang (with the other places
still being affected, but only by an ancestor xml:lang)

I don't remember if this was an xml:lang spec issue or if it was a
tools/schema issue.

if indeed the xml:lang spec says "you can only *put* this where explicitly
allowed", then we need to do more than what is in the spec now... ie.
enumerate the elements which are allowed to specify @xml:lang

e.



From owner-atom-syntax@mail.imc.org  Wed Jul 14 20:35: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 UAA16965
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 20:35: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 i6F0QFNC007159;
	Wed, 14 Jul 2004 17:26: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 i6F0QFJB007158;
	Wed, 14 Jul 2004 17:26: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 i6F0QEeG007152
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 17:26:14 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net ([66.57.27.65])
	(authenticated bits=0)
	by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i6F0QusF016293;
	Wed, 14 Jul 2004 20:26:56 -0400
Message-ID: <40F5CF1E.1000503@intertwingly.net>
Date: Wed, 14 Jul 2004 20:26:06 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: steve jenson <stevej@google.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Low-hanging fruit: compulsory namespaces
References: <6D6BAC41-D517-11D8-8C42-000A95A51C9E@sun.com> <40F46DAC.3030900@dehora.net> <D4AC57AE-D527-11D8-A503-000A95A51C9E@sun.com> <40F48A82.2020408@dehora.net> <3F81CFBF-D59D-11D8-A6EC-000A95A51C9E@sun.com> <40F5415E.5070100@dehora.net> <87k6x6mwef.fsf@nwalsh.com> <40F55860.7000800@dehora.net> <CC364146-D5B5-11D8-A6EC-000A95A51C9E@sun.com> <A90FCC42-D5F2-11D8-9B45-000A95B09B46@google.com>
In-Reply-To: <A90FCC42-D5F2-11D8-9B45-000A95B09B46@google.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


steve jenson wrote:
> 
> Blogger feeds won't wrap your content in a <div 
> xmlns="http://www.w3.org/1999/xhtml"> if your fragment is well formed. 
> Sometimes this means that you'll end up with html tags in the atom 
> namespace. I didn't notice this was a problem until users of 
> Mozilla-based newsreaders pointed it out. A note like this would have 
> persuaded me to unset the default namespace before the problem arose.

Ouch.  I'll go fix the feedvalidator to check fot this.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Wed Jul 14 20: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 UAA17138
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 20:36: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 i6F0TuxZ007671;
	Wed, 14 Jul 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 i6F0TuIE007670;
	Wed, 14 Jul 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 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6F0TuuA007655
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 17:29:56 -0700 (PDT)
	(envelope-from stevej@google.com)
Received: from [172.24.72.132] (dhcp-172-24-72-132.corp.google.com [172.24.72.132])
	(authenticated bits=0)
	by 216-239-45-4.google.com (8.12.11/8.12.9) with ESMTP id i6F0Tit2026273
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Wed, 14 Jul 2004 17:29:44 -0700
In-Reply-To: <40F5CF1E.1000503@intertwingly.net>
References: <6D6BAC41-D517-11D8-8C42-000A95A51C9E@sun.com> <40F46DAC.3030900@dehora.net> <D4AC57AE-D527-11D8-A503-000A95A51C9E@sun.com> <40F48A82.2020408@dehora.net> <3F81CFBF-D59D-11D8-A6EC-000A95A51C9E@sun.com> <40F5415E.5070100@dehora.net> <87k6x6mwef.fsf@nwalsh.com> <40F55860.7000800@dehora.net> <CC364146-D5B5-11D8-A6EC-000A95A51C9E@sun.com> <A90FCC42-D5F2-11D8-9B45-000A95B09B46@google.com> <40F5CF1E.1000503@intertwingly.net>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <10ED1F59-D5F6-11D8-9B45-000A95B09B46@google.com>
Content-Transfer-Encoding: 7bit
Cc: Atom Syntax <atom-syntax@imc.org>
From: steve jenson <stevej@google.com>
Subject: Re: Low-hanging fruit: compulsory namespaces
Date: Wed, 14 Jul 2004 17:29:43 -0700
To: Sam Ruby <rubys@intertwingly.net>
X-Mailer: Apple Mail (2.613)
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 Jul 14, 2004, at 5:26 PM, Sam Ruby wrote:

> steve jenson wrote:
>> Blogger feeds won't wrap your content in a <div 
>> xmlns="http://www.w3.org/1999/xhtml"> if your fragment is well 
>> formed. Sometimes this means that you'll end up with html tags in the 
>> atom namespace. I didn't notice this was a problem until users of 
>> Mozilla-based newsreaders pointed it out. A note like this would have 
>> persuaded me to unset the default namespace before the problem arose.
>
> Ouch.  I'll go fix the feedvalidator to check fot this.

That would have persuaded me, too!

Thanks,
Steve



From owner-atom-syntax@mail.imc.org  Wed Jul 14 20:42: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 TAA11854
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 19:55: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 i6ENlZ4I000984;
	Wed, 14 Jul 2004 16:47: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 i6ENlZxE000983;
	Wed, 14 Jul 2004 16:47:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web41504.mail.yahoo.com (web41504.mail.yahoo.com [66.218.93.87])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6ENlYk8000969
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 16:47:34 -0700 (PDT)
	(envelope-from randymorin@yahoo.com)
Message-ID: <20040714234735.79614.qmail@web41504.mail.yahoo.com>
Received: from [66.46.139.106] by web41504.mail.yahoo.com via HTTP; Wed, 14 Jul 2004 16:47:35 PDT
Date: Wed, 14 Jul 2004 16:47:35 -0700 (PDT)
From: Randy Charles Morin <randymorin@yahoo.com>
Reply-To: randy@kbcafe.com
Subject: An alternative workable schema that's unordered? Yes!
To: Atomlist <atom-syntax@imc.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1381390582-1089848855=:79105"
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>


--0-1381390582-1089848855=:79105
Content-Type: text/plain; charset=us-ascii

I'm just developing this idea, but there's a way to allow unordered elements in Atom and have it expressed in XSD. With of course minor changes to the syntax. I'll start by presenting the XSD.

<xs:complexType name="feedinfoType">
<xs:all>
<xs:element name="title" type="atom:contentType" /> 
<xs:element name="author" type="atom:authorType" minOccurs="0" /> 
<xs:element name="tagline" type="atom:contentType" minOccurs="0" /> 
<xs:element name="id" type="xs:anyURI" minOccurs="0" /> 
<xs:element name="generator" type="atom:generatorType" minOccurs="0" /> 
<xs:element name="copyright" type="xs:string" minOccurs="0" /> 
<xs:element name="info" type="atom:contentType" minOccurs="0" /> 
<xs:element name="modified" type="xs:dateTime" /> 
</xs:all>
</xs:complexType>

<xs:complexType name="feedType">
<xs:sequence>
<xs:element name="entryinfo" type="atom:entryinfoType"/>
<xs:element name="link" type="atom:linkType" minOccurs="0" maxOccurs="unbounded" /> 
<xs:element name="contributor" type="atom:authorType" minOccurs="0" maxOccurs="unbounded" /> 
<xs:element name="entry" type="atom:entryType" minOccurs="0" maxOccurs="unbounded" /> 
</xs:sequence>
<xs:attribute name="version" type="atom:versionType" use="required" /> 
<xs:attribute ref="xml:lang" use="optional" />
</xs:complexType>


In this case, the elements w/ cardinality greater than 1 are removed from the feedinfo and placed at the same level as entry and ordered. This would also mean creating an entryinfo element in entry that would contain all the unordered elements w/ cardinality of less than 2. Thoughts?
 
Randy
http://www.kbcafe.com
 
Example feed
 
<feed>
   <feedinfo>
      <title>asdf</title>
      ...
   </feedinfo>
   <link .../>
   <link .../>
   <entry>
      <entryinfo>
         <title>asdf</title>
      </entryinfo>
      <link .../>
      <content .../>
   </entry>
</feed>

		
---------------------------------
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
--0-1381390582-1089848855=:79105
Content-Type: text/html; charset=us-ascii

<DIV>I'm just developing this idea, but there's a way to allow unordered elements in Atom and have it expressed in XSD. With of course minor changes to the syntax. I'll start by presenting the XSD.</DIV>
<DIV>
<DIV><FONT size=2>
<P></FONT><FONT color=#0000ff size=2>&lt;</FONT><FONT color=#800000 size=2>xs:complexType</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>name</FONT><FONT color=#0000ff size=2>="feedinfoType"&gt;<BR></FONT><FONT color=#0000ff size=2>&lt;</FONT><FONT color=#800000 size=2>xs:all</FONT><FONT color=#0000ff size=2>&gt;<BR></FONT><FONT color=#0000ff size=2>&lt;</FONT><FONT color=#800000 size=2>xs:element</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>name</FONT><FONT color=#0000ff size=2>="title"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>type</FONT><FONT color=#0000ff size=2>="atom:contentType"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#0000ff size=2>/&gt;</FONT><FONT size=2> <BR></FONT><FONT color=#0000ff size=2>&lt;</FONT><FONT color=#800000 size=2>xs:element</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>name</FONT><FONT color=#0000ff size=2>="author"</FONT><FONT color=#ff00ff siz!
 e=2>
 </FONT><FONT color=#ff0000 size=2>type</FONT><FONT color=#0000ff size=2>="atom:authorType"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>minOccurs</FONT><FONT color=#0000ff size=2>="0"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#0000ff size=2>/&gt;</FONT><FONT size=2> <BR></FONT><FONT color=#0000ff size=2>&lt;</FONT><FONT color=#800000 size=2>xs:element</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>name</FONT><FONT color=#0000ff size=2>="tagline"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>type</FONT><FONT color=#0000ff size=2>="atom:contentType"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>minOccurs</FONT><FONT color=#0000ff size=2>="0"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#0000ff size=2>/&gt;</FONT><FONT size=2> <BR></FONT><FONT color=#0000ff size=2>&lt;</FONT><FONT color=#800000 size=2>xs:element</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000
 size=2>name</FONT><FONT color=#0000ff size=2>="id"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>type</FONT><FONT color=#0000ff size=2>="xs:anyURI"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>minOccurs</FONT><FONT color=#0000ff size=2>="0"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#0000ff size=2>/&gt;</FONT><FONT size=2> <BR></FONT><FONT color=#0000ff size=2>&lt;</FONT><FONT color=#800000 size=2>xs:element</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>name</FONT><FONT color=#0000ff size=2>="generator"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>type</FONT><FONT color=#0000ff size=2>="atom:generatorType"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>minOccurs</FONT><FONT color=#0000ff size=2>="0"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#0000ff size=2>/&gt;</FONT><FONT size=2> <BR></FONT><FONT color=#0000ff size=2>&lt;</FONT><FONT color=#80!
 0000
 size=2>xs:element</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>name</FONT><FONT color=#0000ff size=2>="copyright"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>type</FONT><FONT color=#0000ff size=2>="xs:string"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>minOccurs</FONT><FONT color=#0000ff size=2>="0"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#0000ff size=2>/&gt;</FONT><FONT size=2> <BR></FONT><FONT color=#0000ff size=2>&lt;</FONT><FONT color=#800000 size=2>xs:element</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>name</FONT><FONT color=#0000ff size=2>="info"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>type</FONT><FONT color=#0000ff size=2>="atom:contentType"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>minOccurs</FONT><FONT color=#0000ff size=2>="0"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#0000ff size=2>/&gt;</FONT!
 ><FONT
 size=2> <BR></FONT><FONT color=#0000ff size=2>&lt;</FONT><FONT color=#800000 size=2>xs:element</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>name</FONT><FONT color=#0000ff size=2>="modified"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>type</FONT><FONT color=#0000ff size=2>="xs:dateTime"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#0000ff size=2>/&gt;</FONT><FONT size=2> <BR></FONT><FONT color=#0000ff size=2>&lt;/</FONT><FONT color=#800000 size=2>xs:all</FONT><FONT color=#0000ff size=2>&gt;<BR></FONT><FONT color=#0000ff size=2>&lt;/</FONT><FONT color=#800000 size=2>xs:complexType</FONT><FONT color=#0000ff size=2>&gt;</P></FONT><FONT size=2>
<P></FONT><FONT color=#0000ff size=2>&lt;</FONT><FONT color=#800000 size=2>xs:complexType</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>name</FONT><FONT color=#0000ff size=2>="feedType"&gt;<BR></FONT><FONT color=#0000ff size=2>&lt;</FONT><FONT color=#800000 size=2>xs:sequence</FONT><FONT color=#0000ff size=2>&gt;<BR></FONT><FONT color=#0000ff size=2>&lt;</FONT><FONT color=#800000 size=2>xs:element</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>name</FONT><FONT color=#0000ff size=2>="entryinfo"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>type</FONT><FONT color=#0000ff size=2>="atom:entryinfoType"/&gt;<BR></FONT><FONT color=#0000ff size=2>&lt;</FONT><FONT color=#800000 size=2>xs:element</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>name</FONT><FONT color=#0000ff size=2>="link"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>type</FONT><FONT color=#0000ff
 size=2>="atom:linkType"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>minOccurs</FONT><FONT color=#0000ff size=2>="0"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>maxOccurs</FONT><FONT color=#0000ff size=2>="unbounded"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#0000ff size=2>/&gt;</FONT><FONT size=2> <BR></FONT><FONT color=#0000ff size=2>&lt;</FONT><FONT color=#800000 size=2>xs:element</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>name</FONT><FONT color=#0000ff size=2>="contributor"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>type</FONT><FONT color=#0000ff size=2>="atom:authorType"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>minOccurs</FONT><FONT color=#0000ff size=2>="0"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>maxOccurs</FONT><FONT color=#0000ff size=2>="unbounded"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#000!
 0ff
 size=2>/&gt;</FONT><FONT size=2> <BR></FONT><FONT color=#0000ff size=2>&lt;</FONT><FONT color=#800000 size=2>xs:element</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>name</FONT><FONT color=#0000ff size=2>="entry"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>type</FONT><FONT color=#0000ff size=2>="atom:entryType"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>minOccurs</FONT><FONT color=#0000ff size=2>="0"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>maxOccurs</FONT><FONT color=#0000ff size=2>="unbounded"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#0000ff size=2>/&gt;</FONT><FONT size=2> <BR></FONT><FONT color=#0000ff size=2>&lt;/</FONT><FONT color=#800000 size=2>xs:sequence</FONT><FONT color=#0000ff size=2>&gt;<BR></FONT><FONT color=#0000ff size=2>&lt;</FONT><FONT color=#800000 size=2>xs:attribute</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>name</FONT><!
 FONT
 color=#0000ff size=2>="version"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>type</FONT><FONT color=#0000ff size=2>="atom:versionType"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>use</FONT><FONT color=#0000ff size=2>="required"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#0000ff size=2>/&gt;</FONT><FONT size=2> <BR></FONT><FONT color=#0000ff size=2>&lt;</FONT><FONT color=#800000 size=2>xs:attribute</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>ref</FONT><FONT color=#0000ff size=2>="xml:lang"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#ff0000 size=2>use</FONT><FONT color=#0000ff size=2>="optional"</FONT><FONT color=#ff00ff size=2> </FONT><FONT color=#0000ff size=2>/&gt;<BR></FONT><FONT color=#0000ff size=2>&lt;/</FONT><FONT color=#800000 size=2>xs:complexType</FONT><FONT color=#0000ff size=2>&gt;</FONT><FONT color=#0000ff size=2></P></FONT></DIV></DIV>
<DIV>In this case, the elements w/ cardinality greater than 1 are removed from the feedinfo and placed at the same level as entry and ordered. This would also mean creating an entryinfo element in entry that would contain all the unordered elements w/ cardinality of less than 2. Thoughts?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Randy</DIV>
<DIV><A href="http://www.kbcafe.com">http://www.kbcafe.com</A></DIV>
<DIV>&nbsp;</DIV>
<DIV>Example feed</DIV>
<DIV>&nbsp;</DIV>
<DIV>&lt;feed&gt;</DIV>
<DIV>&nbsp;&nbsp; &lt;feedinfo&gt;</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;title&gt;asdf&lt;/title&gt;</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...</DIV>
<DIV>&nbsp;&nbsp; &lt;/feedinfo&gt;</DIV>
<DIV>&nbsp;&nbsp; &lt;link .../&gt;</DIV>
<DIV>&nbsp;&nbsp; &lt;link .../&gt;</DIV>
<DIV>&nbsp;&nbsp; &lt;entry&gt;</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;entryinfo&gt;</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;title&gt;asdf&lt;/title&gt;</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/entryinfo&gt;</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;link .../&gt;</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;content .../&gt;</DIV>
<DIV>&nbsp;&nbsp; &lt;/entry&gt;</DIV>
<DIV>&lt;/feed&gt;</DIV><p>
		<hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/mail_us/taglines/50x/*http://promotions.yahoo.com/new_mail/static/efficiency.html">Yahoo! Mail</a> - 50x more storage than other providers!
--0-1381390582-1089848855=:79105--



From owner-atom-syntax@mail.imc.org  Wed Jul 14 20:53: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 UAA18994
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 20:53: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 i6F0gD79009677;
	Wed, 14 Jul 2004 17:42: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 i6F0gD7D009675;
	Wed, 14 Jul 2004 17:42:13 -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 i6F0gCDZ009642
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 17:42:12 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040715004213.95239.qmail@web41204.mail.yahoo.com>
Received: from [131.107.3.70] by web41204.mail.yahoo.com via HTTP; Wed, 14 Jul 2004 17:42:13 PDT
Date: Wed, 14 Jul 2004 17:42:13 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Low-hanging fruit: compulsory namespaces
To: steve jenson <stevej@google.com>, Tim Bray <Tim.Bray@Sun.COM>
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <A90FCC42-D5F2-11D8-9B45-000A95B09B46@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


--- steve jenson <stevej@google.com> wrote:
> 
> Blogger feeds won't wrap your content in a <div 
> xmlns="http://www.w3.org/1999/xhtml"> if your
> fragment is well formed. 
> Sometimes this means that you'll end up with html
> tags in the atom 
> namespace. I didn't notice this was a problem until
> users of 
> Mozilla-based newsreaders pointed it out. A note
> like this would have 
> persuaded me to unset the default namespace before
> the problem arose.

This implies that Blogger is not using XML tools to
generate their feeds. No XML tools I've come across
would make such mistakes unless they are extremely
buggy. I think adding this text to the normative spec
is akin to adding stuff like 'best practices for
parsing XML with regexes' in the spec. 

Putting it in a primer or an Atom tutorial is OK but I
don't think it should be in the spec. Workarounds for
buggy products and tutorials for basic XML
fundamentals shouldn't clutter the spec especially
when it may give the readers the implication that
there is more significance to this text than there
actually is. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
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 Jul 14 20:53: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 UAA18999
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 20:53:45 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6F0icAS010321;
	Wed, 14 Jul 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 i6F0ic91010320;
	Wed, 14 Jul 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 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6F0icHG010300
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 17:44:38 -0700 (PDT)
	(envelope-from stevej@google.com)
Received: from [172.24.72.132] (dhcp-172-24-72-132.corp.google.com [172.24.72.132])
	(authenticated bits=0)
	by 216-239-45-4.google.com (8.12.11/8.12.9) with ESMTP id i6F0iYCe020705
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Wed, 14 Jul 2004 17:44:34 -0700
In-Reply-To: <20040715004213.95239.qmail@web41204.mail.yahoo.com>
References: <20040715004213.95239.qmail@web41204.mail.yahoo.com>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <2359AA70-D5F8-11D8-9B45-000A95B09B46@google.com>
Content-Transfer-Encoding: 7bit
Cc: Atom Syntax <atom-syntax@imc.org>
From: steve jenson <stevej@google.com>
Subject: Re: Low-hanging fruit: compulsory namespaces
Date: Wed, 14 Jul 2004 17:44:32 -0700
To: Dare Obasanjo <kpako@yahoo.com>
X-Mailer: Apple Mail (2.613)
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 Jul 14, 2004, at 5:42 PM, Dare Obasanjo wrote:

> --- steve jenson <stevej@google.com> wrote:
>>
>> Blogger feeds won't wrap your content in a <div
>> xmlns="http://www.w3.org/1999/xhtml"> if your
>> fragment is well formed.
>> Sometimes this means that you'll end up with html
>> tags in the atom
>> namespace. I didn't notice this was a problem until
>> users of
>> Mozilla-based newsreaders pointed it out. A note
>> like this would have
>> persuaded me to unset the default namespace before
>> the problem arose.
>
> This implies that Blogger is not using XML tools to
> generate their feeds. No XML tools I've come across
> would make such mistakes unless they are extremely
> buggy. I think adding this text to the normative spec
> is akin to adding stuff like 'best practices for
> parsing XML with regexes' in the spec.

I'm using the DOM provided with Java 1.4.2. It does have
plenty of bugs. I guess this is another one.

-steve



From owner-atom-syntax@mail.imc.org  Wed Jul 14 20:57:49 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20063
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 20: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 i6F0nKxl011100;
	Wed, 14 Jul 2004 17: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 i6F0nKUu011099;
	Wed, 14 Jul 2004 17:49:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from dd1516.kasserver.com (dd1516.kasserver.com [81.209.148.207])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6F0nJ6F011081
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 17:49:19 -0700 (PDT)
	(envelope-from sc@itst.org)
Received: from [192.168.1.10] (p50816F07.dip0.t-ipconnect.de [80.129.111.7])
	by dd1516.kasserver.com (Postfix) with ESMTP id 2429616C692
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 02:49:19 +0200 (CEST)
Message-ID: <40F5D4F9.5070108@itst.org>
Date: Thu, 15 Jul 2004 02:51:05 +0200
From: Sascha Carlin <sc@itst.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707
X-Accept-Language: en, de
MIME-Version: 1.0
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Regarding UseCases
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


http://www.intertwingly.net/wiki/pie/UseCases

Discussions can be local and can spread over serveral places. How are 
discussions represented in Atom? What use cases exist for this special 
application?

Regards, Sascha

-- 
Sascha Carlin * Heinrich-Heine-Str. 1 * 64319 Pfungstadt
http://www.itst.org/         **         +49 6157 157 205



From owner-atom-syntax@mail.imc.org  Wed Jul 14 21:56:35 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29661
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 21:56:35 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6F1bcbj019492;
	Wed, 14 Jul 2004 18:37: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 i6F1bcul019491;
	Wed, 14 Jul 2004 18:37:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from vspmail.nscp.aoltw.net (h-64-236-138-233.aoltw.net [64.236.138.233])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6F1bc4l019472
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 18:37:38 -0700 (PDT)
	(envelope-from jpanzer@AOL.NET)
Received: from h-10-169-146-121.nscp.aoltw.net (h-10-169-146-121.nscp.aoltw.net [10.169.146.121])
	by vspmail.nscp.aoltw.net (8.11.6/8.11.6) with ESMTP id i6F1ghs18118;
	Wed, 14 Jul 2004 18:42:43 -0700
Date: Wed, 14 Jul 2004 18:37:35 -0700
From: "John Panzer" <jpanzer@AOL.NET>
Subject: Re: Feed of site events (was: Thought experiment: Using a synthetic feed
 to find out about other feeds)
To: "Ken MacLeod" <ken@bitsko.slc.ut.us>
cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <m37jt6kxs6.fsf@bitsko.slc.ut.us>
Message-ID: <40F5DFDF.3050700@AOL.NET>
References: <200407081614.BHM20108@ms8.netsolmail.com> <m3hdsiqspb.fsf@bitsko.slc.ut.us> <40EE7F98.6040207@intertwingly.net> <opsavggornuvpchu@quark> <40F59797.80104@AOL.NET> <m37jt6kxs6.fsf@bitsko.slc.ut.us>
X-Mailer: AOL Communicator (20030919.3 Win)
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>




Ken MacLeod wrote on 7/14/2004, 3:51 PM:

 >
 > "John Panzer" <jpanzer@aol.net> writes:
 >
 > > A "feed of sites" is fuzzy, though -- what does that mean?  Let me
 > > suggest a more concrete underlying concept: A "feed of site events".
 > > That is, a feed which consists of interesting events happening to
 > > sites separate from the addition/updating/deletion of entries.
 >
 > This has been discussed before, on the wiki look around
 > RevisedConceptualModel, ConceptualModelRevisited.  Some head messages
 > in the list archive:
 >
 >     http://imc.org/atom-syntax/mail-archive/msg01029.html
 >     http://imc.org/atom-syntax/mail-archive/msg01046.html
 >     http://imc.org/atom-syntax/mail-archive/msg01068.html
 >     http://imc.org/atom-syntax/mail-archive/msg01075.html
 >
 > These refer specifically to the model of "event streams", or feed
 > elements that represent changes of state of resources.  (Note: not
 > talking about events in the sense of "football game" or "conference".)
 >
 > The distinction is subtle but obvious in hindsight:
 >
 >   * The current model of "feed of entries" is copies of or references
 >     to entry resources that have changed state, rather than any
 >     indication of "why" they have changed or why they are in the feed.
 >
 >   * A "feed of site events" models a set of "change notices" telling
 >     you what or why something changed, and then pointing to the entry
 >     or other site resource.
 >
 > I wasn't too particular the first time about which model we choose,
 > but it should be clear that these models *are* distinct, and current
 > Atom and syndication practice follow the "feed of entries" model.

Hmm.  I think one of us isn't understanding the other here.

The "feed of site events" I'm talking about has absolutely nothing to do 
with the entries _inside_ the site.

In other words, if I post an entry, my "feed of site events" does not 
change in any way.

If I create a new site, however, my "feed of site events" for (say) my 
username, or for the host provider, produces a new entry, which 
represents the creation event.

I'm not trying to say that _every_ Atom feed is a "feed of events".

Am I confused?

-John




From owner-atom-syntax@mail.imc.org  Wed Jul 14 22: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 WAA00374
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 22: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 i6F1jvkD020710;
	Wed, 14 Jul 2004 18:45: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 i6F1jvcV020709;
	Wed, 14 Jul 2004 18:45: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 i6F1ju7m020702
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 18:45:57 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net (slip-12-65-25-172.mis.prserv.net [12.65.25.172])
	(authenticated bits=0)
	by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i6F1kfua020038;
	Wed, 14 Jul 2004 21:46:42 -0400
Message-ID: <40F5E1CF.2010102@intertwingly.net>
Date: Wed, 14 Jul 2004 21:45:51 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <dtcd@mac.com>
CC: Atom-Syntax Syntax <atom-syntax@imc.org>
Subject: Re: a methodical approach to defining what date  elements we need
References: <20040714153153.98934.qmail@web41201.mail.yahoo.com> <D1CE520E-D5B1-11D8-A6EC-000A95A51C9E@sun.com> <517C18FB-D5F4-11D8-B24C-000A95DC3D90@mac.com>
In-Reply-To: <517C18FB-D5F4-11D8-B24C-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: <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 14 Jul 2004, at 12:21 pm, Tim Bray wrote:
> 
>> +1.  This minor/major thing is an invitation to endless hairsplitting 
>> disputes.   As a consumer of a feed, I want the provider to know when 
>> they consider it to have been modified, as a binary condition.  As a 
>> provider of a feed, I don't want to have to invest cycles agonizing 
>> over how "major" an update is.  It's a binary decision: is it major 
>> enough for the change to be reflected in the feed, yes or no.  Without 
>> a shared definition of what major/minor *means*, this will produce 
>> zero interoperability. -Tim
> 
> You can sidestep this by saying that publishers *have the option* of 
> using <updated> when they have made major changes, and to actually say 
> that it is intended to have the effect of bringing the entry back to the 
> users attention (how to word that effectively, I have no idea). That 
> way, publishing systems that don't make any distinction just don't 
> update/use the element, which will simply have the effect of not 
> bringing any updates to the end user's attention. Publishers who do use 
> the element simply need to ask themselves "Do I wish yo bring these 
> changes to the user's attention?". I think it has a good chance of working.
> 
> (Obviously this is very specific to aggregators)

+1

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Wed Jul 14 23:50: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 XAA05915
	for <atompub-archive@lists.ietf.org>; Wed, 14 Jul 2004 23:50: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 i6F3XUPv037293;
	Wed, 14 Jul 2004 20:33: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 i6F3XU1w037292;
	Wed, 14 Jul 2004 20:33:30 -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 i6F3XT9U037270
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 20:33:29 -0700 (PDT)
	(envelope-from roger@agincourtmedia.com)
Received: from biggreen ([216.63.148.42]) by journurl.com with MailEnable ESMTP; Wed, 14 Jul 2004 22:32:44 -0500
From: "Roger B." <roger@agincourtmedia.com>
To: "'Dare Obasanjo'" <kpako@yahoo.com>
Cc: "'Atom-syntax Syntax'" <atom-syntax@imc.org>
Subject: RE: a methodical approach to defining what date  elements we need
Date: Wed, 14 Jul 2004 22:34:30 -0500
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: <20040714174807.44676.qmail@web41214.mail.yahoo.com>
thread-index: AcRpyq9iXBaXx/LRQTu9oHWJrTjciQATKBUA
Message-ID: <D6AD94D06307435B9CB78A9EBEF81D.MAI@journurl.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


To Sam:
> You
> described this date as some fanciful user entered date
> that could potentially be meaningless. What
> MovableType and co provide is a way for the user to
> specify the issued date which is not the same as the
> user being able to say "43rd day of the 31st month of
> the millionth year" as the date.

Yikes! If that's what people have been talking about when they discuss
"subjective" or "user-defined" dates, then I have been very, very confused.

When I use those terms, I am referring to an actual date. The user enters
"2004-07-14", "07/14/2004", or "Wed, 14 Jul 2004", and the app parses the
submitted data into a raw date that is tucked away in the database. During
output, the date is transformed into whatever format (822, 8601, etc.) is
required by the user's template. 

So I am most definitely *not* arguing in favor of forcing aggregator authors
to figure out how to sort arbitrary strings masquerading as dates. What I
*am* arguing for are:

(1) The Atom-equivalent of RSS pubDate. Meaning, a date that indicates where
an entry falls within the chronological flow of a blog/feed.

(2) An understanding that (1) may be user-defined (see above), and that the
user may change the value of (1) at whim.

(3) A "this entry was last updated at this time" element, usually referred
to in Atom terms as "modified" and usually machine-defined.

If necessary, I can also provide a distinct "created" date, but outside of
migration between tools, there's not much value in it. 

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/ 







From owner-atom-syntax@mail.imc.org  Thu Jul 15 00:08: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 AAA06403
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 00: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 i6F41Z0S041795;
	Wed, 14 Jul 2004 21:01: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 i6F41Za0041794;
	Wed, 14 Jul 2004 21:01:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-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 i6F41YkV041788
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 21:01:34 -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 i6F3xW53020854
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 21:59:32 -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 <0I0V00KR5KITZQ@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Wed, 14 Jul 2004 22:01:41 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0V003FSKISL2@mail.sun.net> for atom-syntax@imc.org; Wed,
 14 Jul 2004 22:01:41 -0600 (MDT)
Date: Wed, 14 Jul 2004 21:01:43 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: a methodical approach to defining what date  elements we need
In-reply-to: <D6AD94D06307435B9CB78A9EBEF81D.MAI@journurl.com>
To: "'Atom-syntax Syntax'" <atom-syntax@imc.org>
Message-id: <AF14E8F6-D613-11D8-A6EC-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: <D6AD94D06307435B9CB78A9EBEF81D.MAI@journurl.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 Jul 14, 2004, at 8:34 PM, Roger B. wrote:

> So I am most definitely *not* arguing in favor of forcing aggregator 
> authors
> to figure out how to sort arbitrary strings masquerading as dates. 
> What I
> *am* arguing for are:

My best take at this time from following these threads, although this 
isn't at the front of our work queue, is that I do not see much chance 
of getting consensus on any dates other than these two, which (if I 
understand correctly) are the same two that Sam and Dare have been 
arguing for. -Tim

> (1) The Atom-equivalent of RSS pubDate. Meaning, a date that indicates 
> where
> an entry falls within the chronological flow of a blog/feed.
>
> (2) An understanding that (1) may be user-defined (see above), and 
> that the
> user may change the value of (1) at whim.
>
> (3) A "this entry was last updated at this time" element, usually 
> referred
> to in Atom terms as "modified" and usually machine-defined.
>
> If necessary, I can also provide a distinct "created" date, but 
> outside of
> migration between tools, there's not much value in it.
>
> --
> Roger Benningfield
> JournURL: http://journurl.com/
> blog: http://admin.support.journurl.com/
>



From owner-atom-syntax@mail.imc.org  Thu Jul 15 00: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 AAA06976
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 00:23: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 i6F4F2wm044119;
	Wed, 14 Jul 2004 21:15: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 i6F4F2Zr044118;
	Wed, 14 Jul 2004 21:15: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 i6F4F2F1044112
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 21:15:02 -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 i6F4F83n018630
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 21:15:08 -0700 (PDT)
Received: from [192.168.1.100] (h00080d858303.ne.client2.attbi.com [24.61.1.243])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id i6F4F10t002028
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 21:15:08 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v618)
Content-Transfer-Encoding: 7bit
Message-Id: <2E0F8DF6-D610-11D8-B24C-000A95DC3D90@mac.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: Atom-Syntax Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: Don't bake discrimination into the Atom core (was Re: Low-hanging fruit: multipart/alternative)
Date: Wed, 14 Jul 2004 23:36:38 -0400
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>
Content-Transfer-Encoding: 7bit


Mark Pilgrim wrote:

> The current design allows inaccessible content *and* accessible
> alternatives.  Tim is recommending removing multipart/alternative but
> *not* simplifying the content model.  This would leave the spec in a
> state that publishers with a way to publish inaccessible content, but
> no way to publish accessible alternatives, which is unacceptable.

<title>? <summary>? Can't the accessible content go in there? Summary 
especially seems like a good place for, say, a textual description of a 
picture or movie - it might even be the right place as well. Granted, 
inaccessible content can be placed in all three, but saying there's no 
place for alternate content is an outright lie.

+1 to PaceNukeMultipart. I'm shocked it ever got in.

Graham



From owner-atom-syntax@mail.imc.org  Thu Jul 15 00: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 AAA07492
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 00:34: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 i6F4PGk2046299;
	Wed, 14 Jul 2004 21:25: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 i6F4PGMB046298;
	Wed, 14 Jul 2004 21:25:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6F4PFH4046282
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 21:25:15 -0700 (PDT)
	(envelope-from jasnell@us.ibm.com)
Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32])
	by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i6F4PHZW490898;
	Thu, 15 Jul 2004 00:25:17 -0400
Received: from d03nm122.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170])
	by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6F4PGAL121870;
	Wed, 14 Jul 2004 22:25:16 -0600
In-Reply-To: <20040715004213.95239.qmail@web41204.mail.yahoo.com>
To: Dare Obasanjo <kpako@yahoo.com>
Cc: Atom Syntax <atom-syntax@imc.org>, owner-atom-syntax@mail.imc.org,
        steve jenson <stevej@google.com>, Tim Bray <Tim.Bray@Sun.COM>
MIME-Version: 1.0
Subject: Re: Low-hanging fruit: compulsory namespaces
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
From: James M Snell <jasnell@us.ibm.com>
X-MIMETrack: S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/14/2004 09:23:28 PM,
	Serialize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/14/2004 09:23:28 PM,
	Serialize complete at 07/14/2004 09:23:28 PM,
	Itemize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/14/2004 09:23:28 PM,
	S/MIME Sign complete at 07/14/2004 09:23:28 PM,
	S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/14/2004 09:25:12 PM,
	S/MIME Sign complete at 07/14/2004 09:25:12 PM,
	Serialize by Router on D03NM122/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at
 07/14/2004 22:25:16,
	Serialize complete at 07/14/2004 22:25:16
Message-ID: <OF04D94F9E.031492AC-ON88256ED2.0017A763-88256ED2.001847E3@us.ibm.com>
Date: Wed, 14 Jul 2004 22:25:14 -0600
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z5196_boundary_sign
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>


This is an S/MIME signed message.

---------z5196_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 00181EFF88256ED2_="

This is a multipart message in MIME format.
--=_alternative 00181EFF88256ED2_=
Content-Type: text/plain; charset="US-ASCII"

owner-atom-syntax@mail.imc.org wrote on 07/14/2004 05:42:13 PM:

> 
> --- steve jenson <stevej@google.com> wrote:
> > 
> > Blogger feeds won't wrap your content in a <div 
> > xmlns="http://www.w3.org/1999/xhtml"> if your
> > fragment is well formed. 
> > Sometimes this means that you'll end up with html
> > tags in the atom 
> > namespace. I didn't notice this was a problem until
> > users of 
> > Mozilla-based newsreaders pointed it out. A note
> > like this would have 
> > persuaded me to unset the default namespace before
> > the problem arose.
> 
> This implies that Blogger is not using XML tools to
> generate their feeds. No XML tools I've come across
> would make such mistakes unless they are extremely
> buggy. I think adding this text to the normative spec
> is akin to adding stuff like 'best practices for
> parsing XML with regexes' in the spec. 
> 
> Putting it in a primer or an Atom tutorial is OK but I
> don't think it should be in the spec. Workarounds for
> buggy products and tutorials for basic XML
> fundamentals shouldn't clutter the spec especially
> when it may give the readers the implication that
> there is more significance to this text than there
> actually is. 
> 

I'm good with this as long as it's at least mentioned *somewhere*... A 
primer for atom implementors, for instance.  Something that could go 
through and delineate various issues that represent best practice concerns 
vs. stuff that should codified in the spec. 

Perhaps we should create a "BestPractices" page in the wiki where we can 
start to collect these types of issues to keep track of them until a 
primer can be written?

> =====
> THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
> My dungeon will have its own qualified medical staff complete with 
> bodyguards. That way if a prisoner becomes sick and his cellmate 
> tells the guard it's an emergency, the guard will fetch a trauma 
> team instead of opening up the cell for a look.
> 
> 
> 
> __________________________________
> Do you Yahoo!?
> New and Improved Yahoo! Mail - Send 10MB messages!
> http://promotions.yahoo.com/new_mail 
> 


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

--=_alternative 00181EFF88256ED2_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>owner-atom-syntax@mail.imc.org wrote on 07/14/2004
05:42:13 PM:<br>
<br>
&gt; <br>
&gt; --- steve jenson &lt;stevej@google.com&gt; wrote:<br>
&gt; &gt; <br>
&gt; &gt; Blogger feeds won't wrap your content in a &lt;div <br>
&gt; &gt; xmlns=&quot;http://www.w3.org/1999/xhtml&quot;&gt; if your<br>
&gt; &gt; fragment is well formed. <br>
&gt; &gt; Sometimes this means that you'll end up with html<br>
&gt; &gt; tags in the atom <br>
&gt; &gt; namespace. I didn't notice this was a problem until<br>
&gt; &gt; users of <br>
&gt; &gt; Mozilla-based newsreaders pointed it out. A note<br>
&gt; &gt; like this would have <br>
&gt; &gt; persuaded me to unset the default namespace before<br>
&gt; &gt; the problem arose.<br>
&gt; <br>
&gt; This implies that Blogger is not using XML tools to<br>
&gt; generate their feeds. No XML tools I've come across<br>
&gt; would make such mistakes unless they are extremely<br>
&gt; buggy. I think adding this text to the normative spec<br>
&gt; is akin to adding stuff like 'best practices for<br>
&gt; parsing XML with regexes' in the spec. <br>
&gt; <br>
&gt; Putting it in a primer or an Atom tutorial is OK but I<br>
&gt; don't think it should be in the spec. Workarounds for<br>
&gt; buggy products and tutorials for basic XML<br>
&gt; fundamentals shouldn't clutter the spec especially<br>
&gt; when it may give the readers the implication that<br>
&gt; there is more significance to this text than there<br>
&gt; actually is. <br>
&gt; </tt></font>
<br>
<br><font size=2><tt>I'm good with this as long as it's at least mentioned
*somewhere*... A primer for atom implementors, for instance. &nbsp;Something
that could go through and delineate various issues that represent best
practice concerns vs. stuff that should codified in the spec. &nbsp;</tt></font>
<br>
<br><font size=2><tt>Perhaps we should create a &quot;BestPractices&quot;
page in the wiki where we can start to collect these types of issues to
keep track of them until a primer can be written?</tt></font>
<br><font size=2><tt><br>
&gt; =====<br>
&gt; THINGS TO DO IF I BECOME AN EVIL OVERLORD #95<br>
&gt; My dungeon will have its own qualified medical staff complete with
<br>
&gt; bodyguards. That way if a prisoner becomes sick and his cellmate <br>
&gt; tells the guard it's an emergency, the guard will fetch a trauma <br>
&gt; team instead of opening up the cell for a look.<br>
&gt; <br>
&gt; <br>
&gt; &nbsp; &nbsp; &nbsp; <br>
&gt; __________________________________<br>
&gt; Do you Yahoo!?<br>
&gt; New and Improved Yahoo! Mail - Send 10MB messages!<br>
&gt; http://promotions.yahoo.com/new_mail <br>
&gt; <br>
</tt></font>
<br>
<br><font size=2 face="sans-serif">- James M Snell<br>
 &nbsp;jasnell@us.ibm.com<br>
 &nbsp;http://www.ibm.com<br>
 &nbsp;(877) 511-5082 / Office<br>
 &nbsp;930-1979 / Tie Line</font>
<br>
--=_alternative 00181EFF88256ED2_=--

---------z5196_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIIUOAIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIISWDCCAtow
ggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1
aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAy
MDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA629xc49NpAPz
cAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7glzJKgPkPzlTZZfznznGbmAWVnNBQ
lyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnwNclOnnP2sKufuPzbTImQTTi5c8JZNZcM
J0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEEBAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1Ud
DgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAPBgNVHRMBAf8EBTADAQH/MDEGA1UdJQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUH
AwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvu
jQupk2oCScMd3FIHLE7hOfu8YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14ke
McF9ViNdewEoBGiAycUq8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIC2jCCAkOgAwIB
AgIDAxS2MA0GCSqGSIb3DQEBBAUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwMTE0MjIw
NzExWhcNMTExMjMxMjIwNzExWjBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25h
bCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrb3Fzj02kA/NwCy5KFMiY
tFgyTJ6kMSQLVSs9uwVHIAVkqy/enDQwZ9b/7uCXMkqA+Q/OVNll/OfOcZuYBZWc0FCXI9qw60KO
J/rTd65FdF4dwp8cw8si0qjOJtYg8cm46fA1yU6ec/awq5+4/NtMiZBNOLlzwlk1lwwnRgXNNwID
AQABo4GqMIGnMBEGCWCGSAGG+EIBAQQEAwIAhzAOBgNVHQ8BAf8EBAMCAcYwHQYDVR0OBBYEFK5U
DpLqqDOpKyQtx8hvMNze80pAMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMA8GA1Ud
EwEB/wQFMAMBAf8wMQYDVR0lBCowKAYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYB
BQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAMnJ7c2YLyrY/PKlFl+7sm8NENfWtFxqdm+6NC6mTagJJ
wx3cUgcsTuE5+7xh9+/G0tTfLzA1qZAQ5GNMPXvmoB9+vJfKnC2JWMFQpIOUEJDXiR4xwX1WI117
ASgEaIDJxSrxHcuuV/hMIO9bgZ6C41MUVmdLTKBgBOImTuIPK8QwggMgMIICiaADAgECAgQ13vTP
MA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQL
EyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0MTUxWhcN
MTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMk
RXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKKlQRkrPFr
U18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkwrFEeO68r
1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOgYaRfMF0x
CzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBD
ZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAxODA4MjIx
NjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAdBgNV
HQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0HQQAEDTAL
GwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwlMQ0AppJu
f7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn00DbOyZY
sih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMgMIICiaADAgEC
AgQ13vTPMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0
MTUxWhcNMTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsG
A1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKK
lQRkrPFrU18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkw
rFEeO68r1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOg
YaRfMF0xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNl
Y3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAx
ODA4MjIxNjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAdBgNVHQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0H
QQAEDTALGwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwl
MQ0AppJuf7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn
00DbOyZYsih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMmMIIC
j6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIxNjM2NTRaMIGFMQsw
CQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEXMBUGA1UEAxMOSmFt
ZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkqhkiG9w0BCQEWEmph
c25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwKpbDG3zMatEuuOT
FYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSyd+7nwqAvbBfPj+0S
vcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7tBJlLrwDRCMoNlPuQ
Kg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQW
BBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOgFAwSamFzbmVs
bEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pAMCcGA1UdJQQgMB4G
CCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAZMKevB7dFfb9
23OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY8BjwVHxiYgG4xkxf
B1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOIzj3lz3xd+uOzqRFg
/Wsg/VMwggMmMIICj6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAy
BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNV
BAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIx
NjM2NTRaMIGFMQswCQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEX
MBUGA1UEAxMOSmFtZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkq
hkiG9w0BCQEWEmphc25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
wKpbDG3zMatEuuOTFYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSy
d+7nwqAvbBfPj+0SvcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7t
BJlLrwDRCMoNlPuQKg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQD
AgXgMB0GA1UdDgQWBBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcU
AgOgFAwSamFzbmVsbEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA
MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQAD
gYEAZMKevB7dFfb923OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY
8BjwVHxiYgG4xkxfB1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOI
zj3lz3xd+uOzqRFg/Wsg/VMxggG7MIIBtwIBATBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJ
bnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0g
Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwF+kzAJBgUrDgMCGgUAoIGiMBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDcxNTA0MjMyOFowIwYJKoZIhvcNAQkEMRYE
FFpkOxB/7HVflFiFQovrel2VFcE/MEMGCSqGSIb3DQEJDzE2MDQwBwYFKw4DAh0wDgYIKoZIhvcN
AwICAgCAMAoGCCqGSIb3DQMHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAYI9UWivW
YiuiZnye8uUnJm/la3vOeGoYfhg13VmYiQwDuVPS1JAZhA0r12Pzy0W3Ix3Aru3XDXq2mSYvqRbI
6gSsMonphTWw6gf8VmlsZ7m9OXiL0B4T3FNaF0tJgFv2VbKxREQDB0v7MKbOPBb8YJyQuZTKia+b
2wvzLNB2kmEAAAAA

---------z5196_boundary_sign--



From owner-atom-syntax@mail.imc.org  Thu Jul 15 00:46:14 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08588
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 00:46: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 i6F4c2Zi048651;
	Wed, 14 Jul 2004 21:38: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 i6F4c2sq048650;
	Wed, 14 Jul 2004 21:38:02 -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 i6F4c27x048625
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 21:38: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 VAA16019
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 21:38: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 VAA09149
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 21:38:02 -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); Wed, 14 Jul 2004 21:38:01 -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 <0I0V00L6JM7BGR@shazam.verity.com> for atom-syntax@imc.org; Wed,
 14 Jul 2004 21:38:01 -0700 (PDT)
Date: Wed, 14 Jul 2004 21:38:01 -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: PaceMustBeWellFormed
In-reply-to: <14be96d30407141427187f294d@mail.gmail.com>
To: Atom-Syntax <atom-syntax@imc.org>
Message-id: 
 <B1CF7C5F3C9875E645F9C55A@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: <14be96d30407061142441f70ee@mail.gmail.com>
 <40F56B2A.8050500@intertwingly.net>
 <14be96d304071411092c2c44f4@mail.gmail.com>
 <p06110426bd1b3deea52a@10.20.30.249>
 <14be96d30407141427187f294d@mail.gmail.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 Wednesday, July 14, 2004 5:27 PM -0400 Mark Pilgrim <pilgrim@gmail.com> wrote:
>
> If my wrestling with RFC 3023 has taught me anything, it is that HTTP
> has primacy.

That is true. The spec also has no way to handle the following
common case:

>     * The document author does not have any way to configure the
>       server to send the proper HTTP Content-Type header

This is a part of the HTTP spec which is simply not practiced.
Clearly, document authors need to specify encodings, and most
servers do not provide an easy way to do that.

Atom can specify that they must control it, but the spec won't
change how the web really works.

This is like the ROBOTS meta tag compared to the robots.txt file,
if that analogy makes sense to anyone. Authors are guaranteed to
have control over their own documents. They are not guaranteed
to have control over anything else.

Has anyone ever deployed a transcoding server? I've never seen
on in real use.

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Thu Jul 15 01:12: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 BAA09826
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 01:12: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 i6F53kra054340;
	Wed, 14 Jul 2004 22: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 i6F53kc9054339;
	Wed, 14 Jul 2004 22:03: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 i6F53jRa054323
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 22:03:45 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i6F51h53015034
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 23:01:43 -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 <0I0V0000FNEG3E@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Wed, 14 Jul 2004 23:03:52 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0V00KWYNEF3N@mail.sun.net> for atom-syntax@imc.org; Wed,
 14 Jul 2004 23:03:52 -0600 (MDT)
Date: Wed, 14 Jul 2004 22:03:54 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Thought experiment
To: "'Atom-syntax Syntax'" <atom-syntax@imc.org>
Cc: Greg Stein <gstein@google.com>
Message-id: <5E91DE20-D61C-11D8-A6EC-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: <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


Flash forward a few months; Atom 1.0 is done, lots of implementations 
are out there, everybody's happy, and big-time deployment starts.  So, 
how are Atom feeds going to get deployed?  I see the following common 
cases:

1. They'll be deployed by competent people who know how things work, 
and served as application/atom+xml
2. They'll be served by people who don't know that stuff or don't 
control their web server, and:
2.a. they'll be named whatever.atom, and based on Apache's defaults, 
end up being served as text/plain, or
2.b they'll be named whatever.xml and based on Apache's defaults, end 
up being served as text/xml, unless
2.c they have a really recent Apache, in which case they'll be served 
as application/xml

<sidenote>People of Earth to Greg Stein: could we change the Apache 
default media type for ".atom" to "application/atom+xml" ASAP, like 
right now, as a gesture in the right direction?</sidenote>

So, the question we face, in the context of PaceMustBeWellFormed and 
PaceShouldBeWellFormed, is "how big a problem do we have?"  I.e. how 
many feeds end up in 2.a or 2.b above?  In the case of RSS, it's pretty 
ugly, see Mark's numbers: 
http://imc.org/atom-syntax/mail-archive/msg05588.html.

I wonder if we could convince ourselves that if we mounted a really 
vigorous publicity campaign, i.e. we all agree, for the next few 
months, whenever we're talking to a co-worker or a journo or from a 
conference stage, to say never say "Atom" without, within the next 45 
seconds, also saying "which as we all know must be served as 
application/atom+xml or it won't work"; I wonder, as I say, if we all 
did that, whether the proportion in categories 2.a and 2.b above might 
be small enough that we could not worry about it?  -Tim



From owner-atom-syntax@mail.imc.org  Thu Jul 15 01:40: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 BAA11708
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 01: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 i6F5UUA4066407;
	Wed, 14 Jul 2004 22:30: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 i6F5UTpo066406;
	Wed, 14 Jul 2004 22:30:29 -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 i6F5UTHg066374
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 22:30: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 WAA18026
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 22:30: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 WAA12714
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 22:30:31 -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); Wed, 14 Jul 2004 22:30: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 <0I0V00LUEOMNGR@shazam.verity.com> for atom-syntax@imc.org; Wed,
 14 Jul 2004 22:30:27 -0700 (PDT)
Date: Wed, 14 Jul 2004 22:30:25 -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: a methodical approach to defining what date  elements we need
In-reply-to: <1089822969.40f560f9cd72f@webmail.djpowell.net>
To: Atom-syntax Syntax <atom-syntax@imc.org>
Message-id: 
 <FD38CB896F14214C2B2F128A@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: <BD1995C2.1F3C6%eric.scheid@ironclad.net.au>
 <opsa2k75lz6dxgxk@mail.online.no>
 <CFCD3EC6-D4BA-11D8-82B1-000A95DC3D90@mac.com>
 <40F3CC36.9080001@intertwingly.net>
 <7C832F0A-D4D2-11D8-82B1-000A95DC3D90@mac.com>
 <40F3F09F.4070602@intertwingly.net>
 <50540F00-D4F5-11D8-82B1-000A95DC3D90@mac.com>
 <40F50909.3060306@intertwingly.net>
 <1089822969.40f560f9cd72f@webmail.djpowell.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 Wednesday, July 14, 2004 5:36 PM +0100 David Powell <djpowell@djpowell.net> wrote:
>
># 3 objective minor modification stamp.
>
> -1 to dropping this.
>
> Pretty much every data object I can think of keeps a last modified stamp, from
> HTTP resources, local files, database rows, vCards and vCalendars.  I think
> that it is a mistake to remove this.  Last modified dates are necessary for
> things like synchronization.  I think we only need keep the last modification
> date though, not the whole history.
>
> This field should be required if the post has been modified in any way.

For search engines, I agree. A search engine will read the feed
and decide whether something should be revisited. The last-modified
date is required for the most up-to-date index.

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Thu Jul 15 02:00: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 CAA12537
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 02:00: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 i6F5rwNI080957;
	Wed, 14 Jul 2004 22:53:58 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6F5rwEL080956;
	Wed, 14 Jul 2004 22:53:58 -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 i6F5rviv080947
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 22:53:58 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i6F5pu53004402
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 23:51:56 -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 <0I0V007ZZPQ438@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Wed, 14 Jul 2004 23:54:05 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0V00KXPPQ43N@mail.sun.net> for atom-syntax@imc.org; Wed,
 14 Jul 2004 23:54:04 -0600 (MDT)
Date: Wed, 14 Jul 2004 22:54:08 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PacePutDelete Withdrawn
In-reply-to: <3f1451f504071218365f8ebf05@mail.gmail.com>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <6315ADDE-D623-11D8-A6EC-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: <3f1451f504071218365f8ebf05@mail.gmail.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 Jul 12, 2004, at 6:36 PM, Joe Gregorio wrote:

> I initially proposed PacePutDelete[1]
> and now I would like to withdraw it.

[Speaking as an individual, not co-chair] I dissent strongly on the 
withdrawing of this Pace at this time, and would like to see it go back 
into the "needs revisiting" queue.  We have not yet taken up the 
cluster of issues around SOAP and REST, and until we do, it is 
inappropriate to remove options from consideration. -Tim



From owner-atom-syntax@mail.imc.org  Thu Jul 15 02:00: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 CAA12682
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 02:00: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 i6F5rI4R080671;
	Wed, 14 Jul 2004 22:53:18 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6F5rI96080668;
	Wed, 14 Jul 2004 22:53: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 i6F5rHO0080594
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 22:53:17 -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 WAA18813
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 22:53: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 WAA14165
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 22:53:19 -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); Wed, 14 Jul 2004 22:53:19 -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 <0I0V00L36POOGR@shazam.verity.com> for atom-syntax@imc.org; Wed,
 14 Jul 2004 22:53:14 -0700 (PDT)
Date: Wed, 14 Jul 2004 22:53:14 -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: Editorial comments on draft-ietf-atompub-format-00
In-reply-to: <DABD07E4-D519-11D8-8C42-000A95A51C9E@sun.com>
To: Atomlist Syntax <atom-syntax@imc.org>
Message-id: 
 <CE1BBEB80F51B99ADD2D5DFC@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: <DABD07E4-D519-11D8-8C42-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, July 13, 2004 3:13 PM -0700 Tim Bray <Tim.Bray@Sun.COM> wrote:
>
> [page 12, sect 4.13.1]  I don't think the "title" of a Web Resource
> is a well-defined construct.  It certainly doesn't appear in Web
> architecture.  If you mean "is the same as the contents of the <title>
> element in the case where HTML representations are typically made
> available..." then that's fine.  Or (better) just lose it.

It isn't in the published web architecture, but it is there in
the real web. The title is what shows up in search engine results.

In practice, nearly all formats have a provision for some sort
of title. text/plain doesn't have an explicit title in the format,
but the resource draft-ietf-atompub-format-00.txt does have a title,
regardless. An entry for it should use that title.

Titles are critical for navigation, and encouraging them in the
format is very important. Resources without titles are very hard
to present in any abbreviated form.

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Thu Jul 15 02:21: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 CAA26600
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 02:21: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 i6F6A4Fw090232;
	Wed, 14 Jul 2004 23:10: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 i6F6A4qI090231;
	Wed, 14 Jul 2004 23:10:04 -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 i6F6A3H8090148
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 23:10: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 88E367C0F3; Thu, 15 Jul 2004 09:07:52 +0200 (CEST)
Date: Thu, 15 Jul 2004 08:13:23 +0200
To: "Eric Scheid" <eric.scheid@ironclad.net.au>
Subject: Re: PaceLang
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <BD1C0BA8.1FBBC%eric.scheid@ironclad.net.au>
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: <opsa50wlrnuvpchu@quark>
In-Reply-To: <BD1C0BA8.1FBBC%eric.scheid@ironclad.net.au>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Thu, 15 Jul 2004 10:23:36 +1000, Eric Scheid  
<eric.scheid@ironclad.net.au> wrote:

> I don't remember if this was an xml:lang spec issue or if it was a
> tools/schema issue.

IIRC, it was a schema-issue. However, the current specification text does  
not state clearly enough (or at all) that 'xml:lang' also affects the  
attributes of the element it is placed on, and I find it strange that the  
text in the Atom spec is not just a copy + paste from the XML spec. This  
is the current language of the specification:

    Any element in an Atom document MAY have an xml:lang attribute, whose
    content indicates the default natural language of the element's
    content.  The content of this attribute MUST be a language tag
    [RFC3066].  When determining element content's natural language, the
    first xml:lang attribute encountered in that element's ancestors MUST
    be used.

We should somehow append the text «xml:lang is considered to apply to all  
attributes and content of the element where it is specified» to that  
paragraph, so attributes are explicitly named as well. I think it also  
should be mentioned throughout the specification which attributes are  
affected by 'xml:lang' and which aren't.

Is there a way in XSD to handle this elegantly? Can one e.g. say which  
attributes are and aren't a part of the human readable content and not,  
and thus which attributes (and elements) that are affected and not by  
'xml:lang'?

-- 
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 Jul 15 02:22: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 CAA26696
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 02:22:17 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6F6EZi4092358;
	Wed, 14 Jul 2004 23:14: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 i6F6EZ4j092357;
	Wed, 14 Jul 2004 23:14: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 (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6F6EYO1092301
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 23:14:35 -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 2C1B97C0F3; Thu, 15 Jul 2004 09:12:28 +0200 (CEST)
To: randy@kbcafe.com
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: An alternative workable schema that's unordered? Yes!
References: <20040714234735.79614.qmail@web41504.mail.yahoo.com>
Message-ID: <opsa5039wuuvpchu@quark>
Date: Thu, 15 Jul 2004 08:17:59 +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: <20040714234735.79614.qmail@web41504.mail.yahoo.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Wed, 14 Jul 2004 16:47:35 -0700 (PDT), Randy Charles Morin  
<randymorin@yahoo.com> wrote:

> <feed>
>    <feedinfo>
>       <title>asdf</title>
>       ...
>    </feedinfo>
>    <link .../>
>    <link .../>
>    <entry>
>       <entryinfo>
>          <title>asdf</title>
>       </entryinfo>
>       <link .../>
>       <content .../>
>    </entry>
> </feed>

I've always thought it is kind of messy to not group the feed-level  
information together, so if this is all it takes to make Atom XSD  
friendly, I'm all for it. I'm not sure the elements should be called  
<feedinfo> and <entryinfo>, though. What about <head>?

-- 
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 Jul 15 02:23: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 CAA26829
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 02:23: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 i6F6Fe32092845;
	Wed, 14 Jul 2004 23: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 i6F6Fe3E092844;
	Wed, 14 Jul 2004 23:15:40 -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 i6F6FdZR092748
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 23:15:40 -0700 (PDT)
	(envelope-from julian.reschke@gmx.de)
Received: (qmail 31877 invoked by uid 65534); 15 Jul 2004 06:15:37 -0000
Received: from p50825AAE.dip.t-dialin.net (EHLO [192.168.0.2]) (80.130.90.174)
  by mail.gmx.net (mp015) with SMTP; 15 Jul 2004 08:15:37 +0200
X-Authenticated: #1915285
Message-ID: <40F62105.6080600@gmx.de>
Date: Thu, 15 Jul 2004 08:15:33 +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: Sam Ruby <rubys@intertwingly.net>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceMustBeWellFormed
References: <14be96d30407061142441f70ee@mail.gmail.com> <40F56B2A.8050500@intertwingly.net> <14be96d304071411092c2c44f4@mail.gmail.com> <p06110426bd1b3deea52a@10.20.30.249> <14be96d30407141427187f294d@mail.gmail.com> <p0611042bbd1b66fa15ef@[10.20.30.249]> <40F5C1F4.5080709@intertwingly.net>
In-Reply-To: <40F5C1F4.5080709@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:
> ...
> I presume that we can control the definition for mime types that we have 
> yet to define.  And while we can work with the authors of RFC 3023, I 
> don't have any hope that they will change the definition for text/xml, 
> but there just *might* be wiggle room to consider a change in 
> application/xml.
> ...

What kind of change are you looking for for application/xml?

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From owner-atom-syntax@mail.imc.org  Thu Jul 15 02:35: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 CAA27914
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 02:35: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 i6F6RKUF098590;
	Wed, 14 Jul 2004 23: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 i6F6RK1N098589;
	Wed, 14 Jul 2004 23:27:20 -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 i6F6RI6X098540
	for <atom-syntax@imc.org>; Wed, 14 Jul 2004 23:27: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 A0E157C0F3; Thu, 15 Jul 2004 09:25:04 +0200 (CEST)
To: "Sascha Carlin" <sc@itst.org>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Regarding UseCases
References: <40F5D4F9.5070108@itst.org>
Message-ID: <opsa51pdt8uvpchu@quark>
Date: Thu, 15 Jul 2004 08:30:39 +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: <40F5D4F9.5070108@itst.org>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Thu, 15 Jul 2004 02:51:05 +0200, Sascha Carlin <sc@itst.org> wrote:

> Discussions can be local and can spread over serveral places. How are  
> discussions represented in Atom? What use cases exist for this special  
> application?

I propose that we use Dublin Core's <relation>[1] element, which then  
would not distinguish between «local» and «distributed» discussions. All  
discussions are discussions, no matter how and where they are held. The  
appropriate attributes to use for a discussion, are 'References' and  
'IsReferencedBy'.

That way, you could have bidirectional pointers; both from the referenced  
(the entry that is being commented on) and the referencing (the comment)  
entry.

____
[1] <url: http://dublincore.org/documents/relation-element/>

-- 
Asbjørn Ulsberg         -=|=-        asbjornu@hotmail.com
«He's a loathsome offensive brute, yet I can't look away»



From owner-atom-syntax@mail.imc.org  Thu Jul 15 05: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 FAA07384
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 05:52: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 i6F9cgYm084258;
	Thu, 15 Jul 2004 02:38: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 i6F9cgiP084256;
	Thu, 15 Jul 2004 02:38: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 i6F9cf70084201
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 02:38:41 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 29922 messnum 4183906 invoked from network[83.70.39.115/83-70-39-115.bas2.prp.dublin.eircom.net]); 15 Jul 2004 09:38:36 -0000
Received: from 83-70-39-115.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.39.115)
  by mail00.svc.cra.dublin.eircom.net (qp 29922) with SMTP; 15 Jul 2004 09:38:36 -0000
Message-ID: <40F65098.1070708@dehora.net>
Date: Thu, 15 Jul 2004 10:38: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
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Low-hanging fruit: compulsory namespaces
References: <20040715004213.95239.qmail@web41204.mail.yahoo.com>
In-Reply-To: <20040715004213.95239.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: <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:

> This implies that Blogger is not using XML tools to
> generate their feeds. No XML tools I've come across
> would make such mistakes unless they are extremely
> buggy. I think adding this text to the normative spec
> is akin to adding stuff like 'best practices for
> parsing XML with regexes' in the spec. 

Can you show me the spec text that indicates this is a bug? I 
couldn't find it.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Thu Jul 15 06: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 GAA08313
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 06:11:30 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FA1x1i094085;
	Thu, 15 Jul 2004 03:01:59 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6FA1xqf094084;
	Thu, 15 Jul 2004 03:01: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 (pop.gmx.net [213.165.64.20])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6FA1vGK094029
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 03:01:57 -0700 (PDT)
	(envelope-from julian.reschke@gmx.de)
Received: (qmail 8326 invoked by uid 65534); 15 Jul 2004 10:01:52 -0000
Received: from p50824C84.dip0.t-ipconnect.de (EHLO [192.168.1.17]) (80.130.76.132)
  by mail.gmx.net (mp017) with SMTP; 15 Jul 2004 12:01:52 +0200
X-Authenticated: #1915285
Message-ID: <40F6560F.7070106@gmx.de>
Date: Thu, 15 Jul 2004 12:01:51 +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: Low-hanging fruit: compulsory namespaces
References: <20040715004213.95239.qmail@web41204.mail.yahoo.com> <40F65098.1070708@dehora.net>
In-Reply-To: <40F65098.1070708@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:
> 
> Dare Obasanjo wrote:
> 
>> This implies that Blogger is not using XML tools to
>> generate their feeds. No XML tools I've come across
>> would make such mistakes unless they are extremely
>> buggy. I think adding this text to the normative spec
>> is akin to adding stuff like 'best practices for
>> parsing XML with regexes' in the spec. 
> 
> 
> Can you show me the spec text that indicates this is a bug? I couldn't 
> find it.

Bill,

if the DOM you're using supports DOM level 2, and is working in 
namespace-aware mode, no legal DOM method call (such as 
importNode/addChild) may mess with namespace names of existing nodes. If 
this occurs, this is a severe bug.

On the other hand, maybe it's not the DOM implementation itself, but 
broken DOM serialization code that's causing the problem you're seeing? 
Back a few years ago, when I tried to use Xerces' (version 1) XML 
serializer (which is the predecessor of what's in jdk 1.4 AFAIK), I 
eventually had to give up and write my own, because it didn't work well 
with namespaces. I'm not sure how much the situation has improved since 
(if it doesn't, we've got Tim here to make people aware of it :-).

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From owner-atom-syntax@mail.imc.org  Thu Jul 15 07: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 HAA10991
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 07: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 i6FAuevx012264;
	Thu, 15 Jul 2004 03:56: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 i6FAueFN012263;
	Thu, 15 Jul 2004 03:56:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FAuepd012254
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 03:56:40 -0700 (PDT)
	(envelope-from gstein@google.com)
Received: from buu.corp.google.com (buu.corp.google.com [172.24.67.34])
	by 216-239-45-4.google.com (8.12.11/8.12.9) with ESMTP id i6FAuY0M006745
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 15 Jul 2004 03:56:34 -0700
Received: from gstein by buu.corp.google.com with local (Exim 4.14 #4)
	id 1Bl3uj-0004hC-Ax by authid <gstein>; Thu, 15 Jul 2004 03:56:33 -0700
Date: Thu, 15 Jul 2004 03:56:33 -0700
From: Greg Stein <gstein@google.com>
To: Tim Bray <Tim.Bray@Sun.COM>
Cc: atom-syntax@imc.org
Subject: Re: Thought experiment
Message-ID: <20040715105633.GB17690@google.com>
References: <5E91DE20-D61C-11D8-A6EC-000A95A51C9E@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5E91DE20-D61C-11D8-A6EC-000A95A51C9E@sun.com>
User-Agent: Mutt/1.4.1i
X-URL: http://www.lyra.org/greg/
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


On Wed, Jul 14, 2004 at 10:03:54PM -0700, Tim Bray wrote:
>...
> <sidenote>People of Earth to Greg Stein: could we change the Apache 
> default media type for ".atom" to "application/atom+xml" ASAP, like 
> right now, as a gesture in the right direction?</sidenote>

The mime.types that is shipped with Apache derives its information from
two places: the IANA, and (apparently) some standardized W3C types. I
don't know where Roy got the W3C list to incorporate, but will follow up
(and report back here).

In short, it has to appear in one of those two places for it to be in the
mime.types file.

Note that the rules for IANA registration are covered under RFC 2048. A
brief glance over that appears that we'd need to be an RFC *first* instead
of just an I-D.

Of course, that is rather painful if the Apache file waits for the RFC --
there would be a huge lag between when the type is settled in the spec
process, when you really want to have it pushed out to users, and when it
is finally published by the IANA. IOW, the pragmatic choice is for Apache
to be optimistic/pragmatic: assume success and jam that in there today.
Let me chat with Roy; I'm going to assume we can simply refer to section 8
of our I-D as "sufficient", then remove the special quotation once the
IANA publishes.

Cheers,
-g



From owner-atom-syntax@mail.imc.org  Thu Jul 15 07: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 HAA11109
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 07: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 i6FB04lL012819;
	Thu, 15 Jul 2004 04: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 i6FB04cP012818;
	Thu, 15 Jul 2004 04:00:04 -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 i6FB03DH012787
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 04:00:04 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 51165 messnum 9211790 invoked from network[83.70.39.115/83-70-39-115.bas2.prp.dublin.eircom.net]); 15 Jul 2004 10:59:57 -0000
Received: from 83-70-39-115.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.39.115)
  by mail10.svc.cra.dublin.eircom.net (qp 51165) with SMTP; 15 Jul 2004 10:59:57 -0000
Message-ID: <40F663A9.80309@dehora.net>
Date: Thu, 15 Jul 2004 11:59:53 +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: Julian Reschke <julian.reschke@gmx.de>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Low-hanging fruit: compulsory namespaces
References: <20040715004213.95239.qmail@web41204.mail.yahoo.com> <40F65098.1070708@dehora.net> <40F6560F.7070106@gmx.de>
In-Reply-To: <40F6560F.7070106@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:

> Bill,
> 
> if the DOM you're using supports DOM level 2, and is working in 
> namespace-aware mode, no legal DOM method call (such as 
> importNode/addChild) may mess with namespace names of existing nodes. If 
> this occurs, this is a severe bug.

Julian,

Thanks, that's good to hear; I'll dig out the relevant text. My 
suspicion is that the reason these things don't work to well with 
namespaces is because namespaces doesn't say anything (?) about 
constrining "pollution" via default scoping rules, it just says what 
default scoping rules are the case. This is the issue - the right 
thing by regular and namespaced markup is consistently someone's 
else's problem; one is left to infer it instead of having an 
explicitly stated constraint. [this is not a "pity the children" 
argument it's a "specification by interpretation is an oxymoron" 
argument.]

As for a BP/Primer. I wouldn't bet on a primer or rely on such a 
thing to get the right thing done - if Atom needs a Primer, we've 
failed as a WG in my opinion. I guess we'd better all use DOM L2/3 
in the meantime!

cheers
Bill



From owner-atom-syntax@mail.imc.org  Thu Jul 15 07:21: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 HAA11696
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 07:21: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 i6FBB5X6015186;
	Thu, 15 Jul 2004 04:11:05 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6FBB5vg015185;
	Thu, 15 Jul 2004 04:11: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 i6FBB4mU015179
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 04:11:05 -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 i6FBBSj0014192;
	Thu, 15 Jul 2004 07:11:28 -0400
Message-ID: <40F66628.4010004@intertwingly.net>
Date: Thu, 15 Jul 2004 07:10:32 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Julian Reschke <julian.reschke@gmx.de>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceMustBeWellFormed
References: <14be96d30407061142441f70ee@mail.gmail.com> <40F56B2A.8050500@intertwingly.net> <14be96d304071411092c2c44f4@mail.gmail.com> <p06110426bd1b3deea52a@10.20.30.249> <14be96d30407141427187f294d@mail.gmail.com> <p0611042bbd1b66fa15ef@[10.20.30.249]> <40F5C1F4.5080709@intertwingly.net> <40F62105.6080600@gmx.de>
In-Reply-To: <40F62105.6080600@gmx.de>
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


Julian Reschke wrote:
> 
> Sam Ruby wrote:
> 
>> ...
>> I presume that we can control the definition for mime types that we 
>> have yet to define.  And while we can work with the authors of RFC 
>> 3023, I don't have any hope that they will change the definition for 
>> text/xml, but there just *might* be wiggle room to consider a change 
>> in application/xml.
>> ...
> 
> What kind of change are you looking for for application/xml?

Consider the following:

   Content-type: application/xml; charset=iso-8859-7

   <?xml version="1.0" encoding="iso-8859-1"?>
   <foo>Iñtërnâtiônàlizætiøn</foo>

Until now, the discussion appears to have been framed in terms of 
precedence rules: which charset/encoding "wins"?  The tradition is to 
say that the above document is well-formed (and possibly even valid) and 
that no error or even warning is proscribed.

First tangent: the tradition is also to defer to HTTP as being the most 
authoritative meta-data in this situation.  The reason appears to be 
based on the promise given to folks that enabled them to write 
transcoders dealing with content-types of "text/*".  As people appear to 
have deployed solutions based on this promise, it is a promise that is 
rather difficult to retract.  I fully understand and appreciate that.

Back to application/xml.  As near as I can tell, no such promise has 
been made for application/xml.  In fact, RFC 3023 [1] is rather clear: 
when the charset parameter is not present, "An XML-unaware MIME 
processor SHOULD make no assumptions about the charset of the XML MIME 
entity."; and RFC 3023 only proscribes the use of 
content-transfer-encoding (a completely transparent pair of 
transformations) when dealing with situations such as 16 bit encodings 
transported over 7-bit transports.

Back to the example above.  While the current specs may say it is 
well-formed, and even proscribe how it should be interpreted, I see a 
document that is seriously confused.  And I see the relevant draconian 
provisions of the XML specification tossing other documents which have 
committed significantly lesser infractions involving so-called smart 
quotes out on their ear.

So, given that documents such as the above do not tend to appear in 
practice (can you give an example?), and have no reason to appear in 
practice (any transcoders that understand application/xml had better 
understand xml prologs), and that the likelihood that the current 
precedence rules will produce the intended result is low (given the way 
that modern web servers are configured, if the above data were served 
statically, I would tend to trust the document prolog more than the HTTP 
headers in this particular circumstance)... given all this, what is my 
recommendation?

My recommendation is that the presence of conflicting charset/encoding 
information in documents served as application/xml be treated as a 
well-formedness error.

Second tangent: such a recommendation does not affect documents served 
simply as "Content-type: application/xml", i.e., without a charset 
explicitly specified on the HTTP header.  RFC 3023[1] sections 8.9 
through 8.12 defer to the rules defined in the XML specification for 
determining the encoding in such circumstances, so inconsistency is not 
possible in this situation.

What does the above recommendation mean to users of formats such as 
application/atom+xml?  Simply that applications such as the 
feedvalidator should flag such situations (it currently does, albeit 
with a warning), and that libraries such as the feedparser should set 
bozo bits or equivalent in such situations (it doesn't currently as the 
above is currently completely legal), and that applications built on 
such libraries should not attempt to resolve such inconsistencies 
without the consent of the user[2].

- Sam Ruby

[1] http://www.ietf.org/rfc/rfc3023.txt
[2] http://www.w3.org/2001/tag/doc/mime-respect.html#inconsistency



From owner-atom-syntax@mail.imc.org  Thu Jul 15 07:43: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 HAA12701
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 07:43: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 i6FBXiao018966;
	Thu, 15 Jul 2004 04:33: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 i6FBXiJY018965;
	Thu, 15 Jul 2004 04:33: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 (pop.gmx.net [213.165.64.20])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6FBXgO7018940
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 04:33:43 -0700 (PDT)
	(envelope-from julian.reschke@gmx.de)
Received: (qmail 26230 invoked by uid 65534); 15 Jul 2004 11:33:38 -0000
Received: from p50824C84.dip0.t-ipconnect.de (EHLO [192.168.1.17]) (80.130.76.132)
  by mail.gmx.net (mp013) with SMTP; 15 Jul 2004 13:33:38 +0200
X-Authenticated: #1915285
Message-ID: <40F66B90.6050200@gmx.de>
Date: Thu, 15 Jul 2004 13:33: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: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Low-hanging fruit: compulsory namespaces
References: <20040715004213.95239.qmail@web41204.mail.yahoo.com> <40F65098.1070708@dehora.net> <40F6560F.7070106@gmx.de> <40F663A9.80309@dehora.net>
In-Reply-To: <40F663A9.80309@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:
> 
>> Bill,
>>
>> if the DOM you're using supports DOM level 2, and is working in 
>> namespace-aware mode, no legal DOM method call (such as 
>> importNode/addChild) may mess with namespace names of existing nodes. 
>> If this occurs, this is a severe bug.
> 
> 
> Julian,
> 
> Thanks, that's good to hear; I'll dig out the relevant text. My 
> suspicion is that the reason these things don't work to well with 
> namespaces is because namespaces doesn't say anything (?) about 
> constrining "pollution" via default scoping rules, it just says what 
> default scoping rules are the case. This is the issue - the right thing 
> by regular and namespaced markup is consistently someone's else's 
> problem; one is left to infer it instead of having an explicitly stated 
> constraint. [this is not a "pity the children" argument it's a 
> "specification by interpretation is an oxymoron" argument.]

I think it's up to DOM to specify what adding namespaced childs (without 
explicit prefix) means. And I'd be *very* surprised if it would allow an 
implementation to change the namespace name because of that.

As far as I can tell, the issue is with serialization, not DOM 
construction, and thus it's (unfortunately) out of the scope of DOM level 2.

> As for a BP/Primer. I wouldn't bet on a primer or rely on such a thing 
> to get the right thing done - if Atom needs a Primer, we've failed as a 
> WG in my opinion. I guess we'd better all use DOM L2/3 in the meantime!

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From owner-atom-syntax@mail.imc.org  Thu Jul 15 07:55: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 HAA13415
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 07:55: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 i6FBiIts020546;
	Thu, 15 Jul 2004 04: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 i6FBiI08020545;
	Thu, 15 Jul 2004 04:44:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (mail.gmx.de [213.165.64.20])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6FBiG29020521
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 04:44:17 -0700 (PDT)
	(envelope-from julian.reschke@gmx.de)
Received: (qmail 18183 invoked by uid 65534); 15 Jul 2004 11:44:12 -0000
Received: from p50824C84.dip0.t-ipconnect.de (EHLO [192.168.1.17]) (80.130.76.132)
  by mail.gmx.net (mp009) with SMTP; 15 Jul 2004 13:44:12 +0200
X-Authenticated: #1915285
Message-ID: <40F66E0B.2000206@gmx.de>
Date: Thu, 15 Jul 2004 13:44:11 +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: Sam Ruby <rubys@intertwingly.net>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceMustBeWellFormed
References: <14be96d30407061142441f70ee@mail.gmail.com> <40F56B2A.8050500@intertwingly.net> <14be96d304071411092c2c44f4@mail.gmail.com> <p06110426bd1b3deea52a@10.20.30.249> <14be96d30407141427187f294d@mail.gmail.com> <p0611042bbd1b66fa15ef@[10.20.30.249]> <40F5C1F4.5080709@intertwingly.net> <40F62105.6080600@gmx.de> <40F66628.4010004@intertwingly.net>
In-Reply-To: <40F66628.4010004@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:
 > ...
> My recommendation is that the presence of conflicting charset/encoding 
> information in documents served as application/xml be treated as a 
> well-formedness error.
> ...

Thanks for the clarification, Sam. I absolutely agree here; a conflict 
indicates that something (transcoding?) has gone wrong; and it makes a 
lot of sense to throw the result away...

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From owner-atom-syntax@mail.imc.org  Thu Jul 15 07:59: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 HAA13933
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 07:59: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 i6FBnWwV021363;
	Thu, 15 Jul 2004 04:49:32 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6FBnWh7021362;
	Thu, 15 Jul 2004 04:49: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 i6FBnVIG021356
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 04:49:32 -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 i6FBoE4V016121;
	Thu, 15 Jul 2004 07:50:14 -0400
Message-ID: <40F66F3E.6020604@intertwingly.net>
Date: Thu, 15 Jul 2004 07:49:18 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: "Roger B." <roger@agincourtmedia.com>
CC: "'Dare Obasanjo'" <kpako@yahoo.com>,
        "'Atom-syntax Syntax'" <atom-syntax@imc.org>
Subject: Re: a methodical approach to defining what date  elements we need
References: <D6AD94D06307435B9CB78A9EBEF81D.MAI@journurl.com>
In-Reply-To: <D6AD94D06307435B9CB78A9EBEF81D.MAI@journurl.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


Roger B. wrote:

> To Sam:
> 
>> You described this date as some fanciful user entered date that
>> could potentially be meaningless. What MovableType and co provide
>> is a way for the user to specify the issued date which is not the
>> same as the user being able to say "43rd day of the 31st month of 
>> the millionth year" as the date.
> 
> Yikes! If that's what people have been talking about when they
> discuss "subjective" or "user-defined" dates, then I have been very,
> very confused.

Roger, you weren't confused.

> So I am most definitely *not* arguing in favor of forcing aggregator
> authors to figure out how to sort arbitrary strings masquerading as
> dates. What I *am* arguing for are:
> 
> (1) The Atom-equivalent of RSS pubDate. Meaning, a date that
> indicates where an entry falls within the chronological flow of a
> blog/feed.

The RSS 2.0 definition of pubDate is as follows: "Its value is a date,
indicating when the item was published. If it's a date in the future,
aggregators may choose to not display the item until that date."

I prefer something that more closely captures Tim's description [1]:

> The canonical case would be a travel diary, the entry for July 1 may
> have been created on July 3 and modified on July 8, but from the
> user's point of view it's still the entry for July 1.

- Sam Ruby

[1] http://www.imc.org/atom-syntax/mail-archive/msg07000.html



From owner-atom-syntax@mail.imc.org  Thu Jul 15 08:18: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 IAA14939
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 08:18: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 i6FC3XKI023770;
	Thu, 15 Jul 2004 05:03: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 i6FC3XSd023769;
	Thu, 15 Jul 2004 05:03:33 -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 i6FC3W6d023763
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 05:03:33 -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 i6FC47in016825;
	Thu, 15 Jul 2004 08:04:07 -0400
Message-ID: <40F6727F.70908@intertwingly.net>
Date: Thu, 15 Jul 2004 08:03:11 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Julian Reschke <julian.reschke@gmx.de>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceMustBeWellFormed
References: <14be96d30407061142441f70ee@mail.gmail.com> <40F56B2A.8050500@intertwingly.net> <14be96d304071411092c2c44f4@mail.gmail.com> <p06110426bd1b3deea52a@10.20.30.249> <14be96d30407141427187f294d@mail.gmail.com> <p0611042bbd1b66fa15ef@[10.20.30.249]> <40F5C1F4.5080709@intertwingly.net> <40F62105.6080600@gmx.de> <40F66628.4010004@intertwingly.net> <40F66E0B.2000206@gmx.de>
In-Reply-To: <40F66E0B.2000206@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:

> Sam Ruby wrote:
>  > ...
> 
>> My recommendation is that the presence of conflicting charset/encoding 
>> information in documents served as application/xml be treated as a 
>> well-formedness error.
>> ...
> 
> Thanks for the clarification, Sam. I absolutely agree here; a conflict 
> indicates that something (transcoding?) has gone wrong; and it makes a 
> lot of sense to throw the result away...

A second, and unrelated, suggestion that emerged from this discussion is 
that an informative note be added to section 8.5 "Text/xml with Omitted 
Charset" suggesting the use of XML numeric character references as a 
means of expressing non-ASCII characters.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Thu Jul 15 08:28: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 IAA15699
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 08: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 i6FCIYgd026114;
	Thu, 15 Jul 2004 05:18: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 i6FCIYPt026113;
	Thu, 15 Jul 2004 05:18:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FCIWb9026106
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 05:18:33 -0700 (PDT)
	(envelope-from Janne.Jalkanen@nokia.com)
Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159])
	by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6FCIO816169;
	Thu, 15 Jul 2004 15:18:25 +0300 (EET DST)
X-Scanned: Thu, 15 Jul 2004 15:18:15 +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 i6FCIF0f007272;
	Thu, 15 Jul 2004 15:18:15 +0300
Received: from mgw-int1.ntc.nokia.com (172.21.143.96)
	by esdks004.ntc.nokia.com 00IJjaCG; Thu, 15 Jul 2004 15:18:13 EEST
Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77])
	by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6FCICn00325;
	Thu, 15 Jul 2004 15:18:12 +0300 (EET DST)
Received: from nokia.com ([172.21.60.114]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Thu, 15 Jul 2004 15:18:13 +0300
Message-ID: <40F67602.2000002@nokia.com>
Date: Thu, 15 Jul 2004 15:18:10 +0300
From: Janne Jalkanen <Janne.Jalkanen@nokia.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040122
X-Accept-Language: fi, en-us, en
MIME-Version: 1.0
To: ext Joe Gregorio <joe.gregorio@gmail.com>
CC: Tim Bray <tim.bray@sun.com>, Atomlist Syntax <atom-syntax@imc.org>
Subject: Re: GET before PUT on an EditURI
References: <BC806156-D51B-11D8-8C42-000A95A51C9E@sun.com> <3f1451f5040713192666d217c4@mail.gmail.com> <8B1D1724-D540-11D8-A503-000A95A51C9E@sun.com> <3f1451f50407132005ec21d76@mail.gmail.com>
In-Reply-To: <3f1451f50407132005ec21d76@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 15 Jul 2004 12:18:13.0251 (UTC) FILETIME=[CCBEBD30:01C46A65]
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



>How about stating that the client SHOULD do a GET before 
>editing?
>  
>
A wiki would naturally dismiss a PUT without the corresponding nonce as 
invalid, and thus no problem.  (There's still the question of how the 
nonce should be sent back to the client; there's no facility for it 
right now.)

Some other CMSs would not.

I think a SHOULD is in order, since nothing really breaks if it's not 
required; however a MUST would mean that it would be an inconvinience to 
many.

/Janne



From owner-atom-syntax@mail.imc.org  Thu Jul 15 08: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 IAA15800
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 08: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 i6FCKREo026401;
	Thu, 15 Jul 2004 05:20: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 i6FCKR97026400;
	Thu, 15 Jul 2004 05:20:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from imo-d04.mx.aol.com (imo-d04.mx.aol.com [205.188.157.36])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FCKQpw026378
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 05:20:26 -0700 (PDT)
	(envelope-from Svgdeveloper@aol.com)
Received: from Svgdeveloper@aol.com
	by imo-d04.mx.aol.com (mail_out_v37_r2.6.) id n.1dc.26455919 (16781);
	Thu, 15 Jul 2004 08:20:07 -0400 (EDT)
From: Svgdeveloper@aol.com
Message-ID: <1dc.26455919.2e27d077@aol.com>
Date: Thu, 15 Jul 2004 08:20:07 EDT
Subject: Re: PaceMustBeWellFormed
To: rubys@intertwingly.net, atom-syntax@imc.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_1dc.26455919.2e27d077_boundary"
X-Mailer: 8.0 for Windows sub 670
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>



--part1_1dc.26455919.2e27d077_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 7/15/2004 12:11:53 PM GMT Daylight Time, 
rubys@intertwingly.net writes:

> Back to the example above.  While the current specs may say it is 
> well-formed, and even proscribe how it should be interpreted, I see a 
> document that is seriously confused.  And I see the relevant draconian 
> provisions of the XML specification tossing other documents which have 
> committed significantly lesser infractions involving so-called smart 
> quotes out on their ear.
> 
> So, given that documents such as the above do not tend to appear in 
> practice (can you give an example?), and have no reason to appear in 
> practice (any transcoders that understand application/xml had better 
> understand xml prologs), and that the likelihood that the current 
> precedence rules will produce the intended result is low (given the way 
> that modern web servers are configured, if the above data were served 
> statically, I would tend to trust the document prolog more than the HTTP 
> headers in this particular circumstance)... given all this, what is my 
> recommendation?
> 
> My recommendation is that the presence of conflicting charset/encoding 
> information in documents served as application/xml be treated as a 
> well-formedness error.

It seems to me to risk introducing an unnecessary source of confusion re 
terminology.

I would suggest that Atom apply, as relevant, the term well-formedness as 
specified in XML 1.0 (nth Edition) and use another term for situations not 
covered by the XML 1.0 definition of well-formedness.

Andrew Watt

--part1_1dc.26455919.2e27d077_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML><FONT FACE=3Darial,helvetica><HTML><FONT  SIZE=3D2 PTSIZE=3D10 FAMILY=
=3D"SANSSERIF" FACE=3D"Arial" LANG=3D"0">In a message dated 7/15/2004 12:11:=
53 PM GMT Daylight Time, rubys@intertwingly.net writes:<BR>
<BR>
<BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT=
: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">Back to the example above.&nbsp=
; While the current specs may say it is <BR>
well-formed, and even proscribe how it should be interpreted, I see a <BR>
document that is seriously confused.&nbsp; And I see the relevant draconian=20=
<BR>
provisions of the XML specification tossing other documents which have <BR>
committed significantly lesser infractions involving so-called smart <BR>
quotes out on their ear.<BR>
<BR>
So, given that documents such as the above do not tend to appear in <BR>
practice (can you give an example?), and have no reason to appear in <BR>
practice (any transcoders that understand application/xml had better <BR>
understand xml prologs), and that the likelihood that the current <BR>
precedence rules will produce the intended result is low (given the way <BR>
that modern web servers are configured, if the above data were served <BR>
statically, I would tend to trust the document prolog more than the HTTP <BR=
>
headers in this particular circumstance)... given all this, what is my <BR>
recommendation?<BR>
<BR>
My recommendation is that the presence of conflicting charset/encoding <BR>
information in documents served as application/xml be treated as a <BR>
well-formedness error.</BLOCKQUOTE><BR>
<BR>
It seems to me to risk introducing an unnecessary source of confusion re ter=
minology.<BR>
<BR>
I would suggest that Atom apply, as relevant, the term well-formedness as sp=
ecified in XML 1.0 (nth Edition) and use another term for situations not cov=
ered by the XML 1.0 definition of well-formedness.<BR>
<BR>
Andrew Watt</FONT></HTML>

--part1_1dc.26455919.2e27d077_boundary--



From owner-atom-syntax@mail.imc.org  Thu Jul 15 08: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 IAA16777
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 08:53: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 i6FCgTRv030539;
	Thu, 15 Jul 2004 05:42: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 i6FCgTTi030538;
	Thu, 15 Jul 2004 05:42: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 i6FCgSSd030523
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 05:42:28 -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 1Bl5ZA-0006hn-EQ; Thu, 15 Jul 2004 12:42:24 +0000
Message-ID: <40F67BAD.6070708@franklinmint.fm>
Date: Thu, 15 Jul 2004 08:42:21 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Janne Jalkanen <Janne.Jalkanen@nokia.com>
CC: ext Joe Gregorio <joe.gregorio@gmail.com>, Tim Bray <tim.bray@sun.com>,
        Atomlist Syntax <atom-syntax@imc.org>
Subject: Re: GET before PUT on an EditURI
References: <BC806156-D51B-11D8-8C42-000A95A51C9E@sun.com> <3f1451f5040713192666d217c4@mail.gmail.com> <8B1D1724-D540-11D8-A503-000A95A51C9E@sun.com> <3f1451f50407132005ec21d76@mail.gmail.com> <40F67602.2000002@nokia.com>
In-Reply-To: <40F67602.2000002@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: <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


Janne Jalkanen wrote:

>
>
>> How about stating that the client SHOULD do a GET before editing?
>>  
>>
>
> I think a SHOULD is in order, since nothing really breaks if it's not 
> required; however a MUST would mean that it would be an inconvinience 
> to many.


I don't understand why we need this. If the client PUTs something that 
conflicts with the state of  the resource, it's the server's 
responsibility to spot the conflict. All server code will have to assume 
that clients will be ignorantly PUTing things all over the place.

Robert Sayre



From owner-atom-syntax@mail.imc.org  Thu Jul 15 08:53: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 IAA16795
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 08:53: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 i6FChi5Y030727;
	Thu, 15 Jul 2004 05:43: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 i6FChiV4030726;
	Thu, 15 Jul 2004 05:43:44 -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 i6FChhfN030720
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 05:43:44 -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 i6FCiQAc018703
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 08:44:27 -0400
Message-ID: <40F67BF2.6060100@intertwingly.net>
Date: Thu, 15 Jul 2004 08:43:30 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: PaceMustBeWellFormed
References: <14be96d30407061142441f70ee@mail.gmail.com> <40F56B2A.8050500@intertwingly.net> <14be96d304071411092c2c44f4@mail.gmail.com> <p06110426bd1b3deea52a@10.20.30.249> <14be96d30407141427187f294d@mail.gmail.com> <p0611042bbd1b66fa15ef@[10.20.30.249]> <40F5C1F4.5080709@intertwingly.net> <40F62105.6080600@gmx.de> <40F66628.4010004@intertwingly.net>
In-Reply-To: <40F66628.4010004@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:
> 
> Until now, the discussion appears to have been framed in terms of 
> precedence rules: which charset/encoding "wins"?  The tradition is to 
> say that the above document is well-formed (and possibly even valid) and 
> that no error or even warning is proscribed.

Bah.  s/proscribed/prescribed/g.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Thu Jul 15 09:05: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 JAA17388
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 09:05: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 i6FCuQlt033292;
	Thu, 15 Jul 2004 05:56: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 i6FCuQG7033291;
	Thu, 15 Jul 2004 05:56:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.240])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6FCuQLE033273
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 05:56:26 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so1275420cwc
        for <atom-syntax@imc.org>; Thu, 15 Jul 2004 05:56:23 -0700 (PDT)
Received: by 10.11.99.41 with SMTP id w41mr56792cwb;
        Thu, 15 Jul 2004 05:56:22 -0700 (PDT)
Message-ID: <3f1451f504071505566985d8cd@mail.gmail.com>
Date: Thu, 15 Jul 2004 08:56:22 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Mark Baker <distobj@acm.org>
Subject: Re: GET before PUT on an EditURI
Cc: Atomlist Syntax <atom-syntax@imc.org>
In-Reply-To: <20040714044914.GT30868@markbaker.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <BC806156-D51B-11D8-8C42-000A95A51C9E@sun.com> <3f1451f5040713192666d217c4@mail.gmail.com> <20040714044914.GT30868@markbaker.ca>
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 Wed, 14 Jul 2004 00:49:14 -0400, Mark Baker <distobj@acm.org> wrote:
> On Tue, Jul 13, 2004 at 10:26:14PM -0400, Joe Gregorio wrote:
> >
> > On Tue, 13 Jul 2004 15:26:51 -0700, Tim Bray <tim.bray@sun.com> wrote:
> > > [page 5/sect 3.2] the description reads like it's forbidden to do a PUT
> > > without doing a GET first.  Is this true?  If I know the URI and I know
> > > what I want to put there, can't I just blast it in?
> >
> > You could, but you might not want to.
> >
> > Consider the case of a Wiki. Most Wiki HTML editing forms have
> > a nonce, either a hidden time or a hash value. This nonce is used
> > to protect against edits being lost in a race condition, i.e. user
> > A starts to edit a page, takes too long and later user B edits the
> > same page and commits before user A does.
> >
> > If the client does a GET on the EditURI then the server has a chance
> > to place a nonce in the entry. The client should preserve
> > that nonce and submit it with the entry when the edit entry
> > is PUT back to the EditURI.
> > 
> > For this scenario to work [...]
> 
> By "work", do you mean;
> 
> 1. user A is notified of a problem when they try to PUT? ... or
> 2. user B is denied the ability to PUT because A is editing it?
> 
> If #1, I suggest that [1] would suffice to detect the conflict.
> If #2, perhaps WebDAV LOCK should be considered.
> 
> But in both cases, a PUT without a preceding GET is not a problem.
> 
>  [1] http://www.w3.org/1999/04/Editing/

This does lead to a question of documentation. Should 
detection of lost updates when using the Atom Publishing 
Protocol be written into the spec? I don't believe
that every Atom server MUST support it, just that
*if* they are going to support detecting lost updates
than this is how you do it interoperably.

For example, a new section on Detecting Lost Updates 
could be added that covered that material
in http://www.w3.org/1999/04/Editing/
specifically applied to the EditURI.

    Thanks,
    -joe



From owner-atom-syntax@mail.imc.org  Thu Jul 15 09:12: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 JAA17639
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 09:12: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 i6FD3T63034559;
	Thu, 15 Jul 2004 06:03:29 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6FD3TVV034558;
	Thu, 15 Jul 2004 06:03:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.194])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6FD3Spf034551
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 06:03:28 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d78so402759rnf
        for <atom-syntax@imc.org>; Thu, 15 Jul 2004 06:03:29 -0700 (PDT)
Received: by 10.38.207.66 with SMTP id e66mr15840rng;
        Thu, 15 Jul 2004 06:03:29 -0700 (PDT)
Message-ID: <14be96d304071506034fb16820@mail.gmail.com>
Date: Thu, 15 Jul 2004 09:03:29 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Graham <dtcd@mac.com>
Subject: Re: Don't bake discrimination into the Atom core (was Re: Low-hanging fruit: multipart/alternative)
Cc: Atom-Syntax Syntax <atom-syntax@imc.org>
In-Reply-To: <2E0F8DF6-D610-11D8-B24C-000A95DC3D90@mac.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <2E0F8DF6-D610-11D8-B24C-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 Wed, 14 Jul 2004 23:36:38 -0400, Graham <dtcd@mac.com> wrote:
> 
> Mark Pilgrim wrote:
> 
> > The current design allows inaccessible content *and* accessible
> > alternatives.  Tim is recommending removing multipart/alternative but
> > *not* simplifying the content model.  This would leave the spec in a
> > state that publishers with a way to publish inaccessible content, but
> > no way to publish accessible alternatives, which is unacceptable.
> 
> <title>? <summary>? Can't the accessible content go in there? Summary
> especially seems like a good place for, say, a textual description of a
> picture or movie - it might even be the right place as well. Granted,
> inaccessible content can be placed in all three, but saying there's no
> place for alternate content is an outright lie.

That's not what title or summary are for.  Specifically, <title> "is a
Content construct that conveys a human-readable title for the entry." 
This is not the place for accessible alternate content.

<summary> "is a Content construct that conveys a short summary,
abstract or excerpt of the entry."  This is not the place for
accessible alternate content either.

I'm shocked, shocked that you, an aggregator developer of some note,
should recommend overloading core elements with different meanings. 
Didn't you complain about that wrt. some other format?  My memory is
fuzzy.  Or maybe it's all the outright lying I've been doing.  It
tends to get in the way of productive discussion.

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Thu Jul 15 09:19:41 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18252
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 09:19:40 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FDAsWu035709;
	Thu, 15 Jul 2004 06:10: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 i6FDAsnM035708;
	Thu, 15 Jul 2004 06:10:54 -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 i6FDArc9035684
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 06:10:53 -0700 (PDT)
	(envelope-from djpowell@djpowell.net)
Received: (qmail 49234 invoked from network); 15 Jul 2004 13:10:52 -0000
Received: from localhost.34sp.com (HELO localhost) (127.0.0.1)
  by localhost.34sp.com with SMTP; 15 Jul 2004 13:10:52 -0000
Received: from 194.203.191.188 ([194.203.191.188]) 
	by webmail.djpowell.net (IMP) with HTTP 
	for <davep@djpowell.net@localhost>; Thu, 15 Jul 2004 14:10:52 +0100
Message-ID: <1089897052.40f6825c8f5dd@webmail.djpowell.net>
Date: Thu, 15 Jul 2004 14:10:52 +0100
From: David Powell <djpowell@djpowell.net>
To: Sam Ruby <rubys@intertwingly.net>
Cc: "Roger B." <roger@agincourtmedia.com>, "'Dare Obasanjo'" <kpako@yahoo.com>,
        "'Atom-syntax Syntax'" <atom-syntax@imc.org>
Subject: Re: a methodical approach to defining what date  elements we need
References: <D6AD94D06307435B9CB78A9EBEF81D.MAI@journurl.com> <40F66F3E.6020604@intertwingly.net>
In-Reply-To: <40F66F3E.6020604@intertwingly.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.2
X-Originating-IP: 194.203.191.188
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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 Sam Ruby:

> Roger B. wrote:
> 
> > To Sam:
> > 
> >> You described this date as some fanciful user entered date that
> >> could potentially be meaningless. What MovableType and co provide
> >> is a way for the user to specify the issued date which is not the
> >> same as the user being able to say "43rd day of the 31st month of 
> >> the millionth year" as the date.
> > 
> > Yikes! If that's what people have been talking about when they
> > discuss "subjective" or "user-defined" dates, then I have been very,
> > very confused.
> 
> Roger, you weren't confused.

Sam, just to be clear, when you said that the user should be able to enter:
"43rd day of the 31st month of the millionth year" did you literally mean that
the value of the display date field could be that string as free form text?  I
thought that Roger was objecting to that, and I would object to that too.

If people want to associate fanciful future dates with an entry then that is
fine by me, as long as the date is a) machine readable, and b) a valid date:
43-31-1000000 is not a valid date, at least according to RFC 3339.

I would like this date to be machine readable so that it can be formatted
according to the local conventions and capabilities of the reader.

> I prefer something that more closely captures Tim's description [1]:
> 
> > The canonical case would be a travel diary, the entry for July 1 may
> > have been created on July 3 and modified on July 8, but from the
> > user's point of view it's still the entry for July 1.

Yes, I also think that Tim's example is a good use-case.


-- 
Dave



From owner-atom-syntax@mail.imc.org  Thu Jul 15 09:28: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 JAA18745
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 09:28: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 i6FDLLu0037815;
	Thu, 15 Jul 2004 06:21: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 i6FDLLZa037814;
	Thu, 15 Jul 2004 06:21: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.202])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6FDLKIh037807
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 06:21:21 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d78so403730rnf
        for <atom-syntax@imc.org>; Thu, 15 Jul 2004 06:21:22 -0700 (PDT)
Received: by 10.38.207.66 with SMTP id e66mr18537rng;
        Thu, 15 Jul 2004 06:21:22 -0700 (PDT)
Message-ID: <14be96d30407150621737bd1a8@mail.gmail.com>
Date: Thu, 15 Jul 2004 09:21:22 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Tim Bray <tim.bray@sun.com>
Subject: Re: Thought experiment
Cc: Atom-syntax Syntax <atom-syntax@imc.org>, Greg Stein <gstein@google.com>
In-Reply-To: <5E91DE20-D61C-11D8-A6EC-000A95A51C9E@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <5E91DE20-D61C-11D8-A6EC-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 Wed, 14 Jul 2004 22:03:54 -0700, Tim Bray <tim.bray@sun.com> wrote:
> So, the question we face, in the context of PaceMustBeWellFormed and
> PaceShouldBeWellFormed, is "how big a problem do we have?"

Early adopters (hosted providers):

$ lynx -head -dump http://chrisaralex.blogspot.com/atom.xml | grep Content-Type
Content-Type: text/xml

$ lynx -head -dump
http://groups-beta.google.com/group/comp.lang.python/feed/msgs.xml |
grep Content-Type
Content-Type text/xml

$ lynx -head -dump http://www.livejournal.com/users/jwz/data/atom |
grep Content-Type
Content-Type: text/xml; charset=utf-8

$ lynx -head -dump http://mena.typepad.com/dollarshort/atom.xml | grep
Content-Type
Content-Type: application/xml

Early adopters (tools):

$ lynx -head -dump http://wordpress.org/development/feed/ | grep Content-Type
Content-Type: text/xml

$ lynx -head -dump http://www.movabletype.org/index.xml | grep Content-Type
Content-Type: text/xml

$ lynx -head -dump http://www.sixapart.com/log/index.rdf | grep Content-Type
Content-Type: text/plain

$ lynx -head -dump http://www.textism.com/?atom=1 | grep Content-Type
Content-Type: text/xml;charset=UTF-8

Other notable tools:

$ lynx -head -dump http://blogs.sun.com/roller/rss/tbray | grep Content-Type
Content-Type: text/xml

$ lynx -head -dump http://blogs.msdn.com/oldnewthing/Rss.aspx | grep
Content-Type
Content-Type: text/xml; charset=utf-8

$ lynx -head -dump
http://www-106.ibm.com/developerworks/blogs/dw_blog_rss.jspa?blog=351
| grep Content-Type
Content-Type: text/xml

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Thu Jul 15 09:40: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 JAA19490
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 09:40: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 i6FDU1Be039103;
	Thu, 15 Jul 2004 06:30: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 i6FDU1YX039102;
	Thu, 15 Jul 2004 06:30: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 i6FDU1vK039096
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 06:30:01 -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 1Bl6JF-0008O0-N7; Thu, 15 Jul 2004 13:30:01 +0000
Message-ID: <40F686D7.2010302@franklinmint.fm>
Date: Thu, 15 Jul 2004 09:29:59 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sam Ruby <rubys@intertwingly.net>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Pace409Response marked incomplete?
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 noticed that the Pace's status was changed to "incomplete". I 
intentionally left out the section on the response format, if that's the 
reason it was marked as such.

Existing Atom implementations incorrectly return status code 400 for 
state conflicts. This Pace corrects that spec bug. The format of the 
response seems like a separate debate to me.

Robert Sayre



From owner-atom-syntax@mail.imc.org  Thu Jul 15 09: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 JAA19569
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 09: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 i6FDUGMc039155;
	Thu, 15 Jul 2004 06:30:16 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6FDUGia039154;
	Thu, 15 Jul 2004 06:30:16 -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 i6FDUFd6039146
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 06:30:15 -0700 (PDT)
	(envelope-from djpowell@djpowell.net)
Received: (qmail 54065 invoked from network); 15 Jul 2004 13:30:17 -0000
Received: from localhost.34sp.com (HELO localhost) (127.0.0.1)
  by localhost.34sp.com with SMTP; 15 Jul 2004 13:30:17 -0000
Received: from 194.203.191.188 ([194.203.191.188]) 
	by webmail.djpowell.net (IMP) with HTTP 
	for <davep@djpowell.net@localhost>; Thu, 15 Jul 2004 14:30:16 +0100
Message-ID: <1089898216.40f686e9039d7@webmail.djpowell.net>
Date: Thu, 15 Jul 2004 14:30:17 +0100
From: David Powell <djpowell@djpowell.net>
To: Sam Ruby <rubys@intertwingly.net>
Cc: "Roger B." <roger@agincourtmedia.com>, "'Dare Obasanjo'" <kpako@yahoo.com>,
        "'Atom-syntax Syntax'" <atom-syntax@imc.org>
Subject: Re: a methodical approach to defining what date  elements we need
References: <D6AD94D06307435B9CB78A9EBEF81D.MAI@journurl.com> <40F66F3E.6020604@intertwingly.net> <1089897052.40f6825c8f5dd@webmail.djpowell.net>
In-Reply-To: <1089897052.40f6825c8f5dd@webmail.djpowell.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.2
X-Originating-IP: 194.203.191.188
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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 myself: 
> Sam, just to be clear, when you said that the user should be able to enter:
> "43rd day of the 31st month of the millionth year" did you...

Sorry Sam, I just attributed the "43rd day..." quote to you when really it was
Dare that said it.

I don't think that either you or Dare was arguing that display dates should be
free form were you?

-- 
Dave



From owner-atom-syntax@mail.imc.org  Thu Jul 15 09: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 JAA20398
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 09:55: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 i6FDidP1041566;
	Thu, 15 Jul 2004 06:44: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 i6FDidNR041565;
	Thu, 15 Jul 2004 06:44: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 i6FDicUC041550
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 06:44: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 i6FDjKGN021980;
	Thu, 15 Jul 2004 09:45:20 -0400
Message-ID: <40F68A38.2020204@intertwingly.net>
Date: Thu, 15 Jul 2004 09:44:24 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <djpowell@djpowell.net>
CC: "Roger B." <roger@agincourtmedia.com>, "'Dare Obasanjo'" <kpako@yahoo.com>,
        "'Atom-syntax Syntax'" <atom-syntax@imc.org>
Subject: Re: a methodical approach to defining what date  elements we need
References: <D6AD94D06307435B9CB78A9EBEF81D.MAI@journurl.com> <40F66F3E.6020604@intertwingly.net> <1089897052.40f6825c8f5dd@webmail.djpowell.net>
In-Reply-To: <1089897052.40f6825c8f5dd@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: <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


David Powell wrote:

> Quoting Sam Ruby:
> 
>>Roger B. wrote:
>>
>>>To Sam:
>>>
>>>>You described this date as some fanciful user entered date that
>>>>could potentially be meaningless. What MovableType and co provide
>>>>is a way for the user to specify the issued date which is not the
>>>>same as the user being able to say "43rd day of the 31st month of 
>>>>the millionth year" as the date.
>>>
>>>Yikes! If that's what people have been talking about when they
>>>discuss "subjective" or "user-defined" dates, then I have been very,
>>>very confused.
>>
>>Roger, you weren't confused.
> 
> Sam, just to be clear, when you said that the user should be able to enter:
> "43rd day of the 31st month of the millionth year" did you literally mean that
> the value of the display date field could be that string as free form text?

Note that I did NOT say that.  It was said TO me.

Roger was not confused.

I would like people to be able to pick whatever date and time meets 
their fancy.  I would furthermore like such dates be accurately recorded 
consistently and correctly according to whatever profile of ISO 8601 
that we settle on.  (Current wording suggests W3CDTF; RFC 3339 is 
actively being discussed; and whether or a time zone indication is 
required on this one particular date remains an open question).

I hope this clears things up.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Thu Jul 15 10:15: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 KAA22299
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 10: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 i6FE2Rtj044120;
	Thu, 15 Jul 2004 07:02:27 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6FE2RTI044119;
	Thu, 15 Jul 2004 07:02: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 i6FE2QNs044113
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 07:02: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 i6FE391w022779;
	Thu, 15 Jul 2004 10:03:09 -0400
Message-ID: <40F68E65.1050906@intertwingly.net>
Date: Thu, 15 Jul 2004 10:02:13 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: mint@franklinmint.fm
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Pace409Response marked incomplete?
References: <40F686D7.2010302@franklinmint.fm>
In-Reply-To: <40F686D7.2010302@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:

> I noticed that the Pace's status was changed to "incomplete". I 
> intentionally left out the section on the response format, if that's the 
> reason it was marked as such.
> 
> Existing Atom implementations incorrectly return status code 400 for 
> state conflicts. This Pace corrects that spec bug. The format of the 
> response seems like a separate debate to me.

Yes, it was because I noted two instances of "[[ more about response 
body format ]]" in the Proposal section.  If you believe the proposal to 
be complete without such text, then please remove this indicator (and 
perhaps add a note).

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Thu Jul 15 10: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 KAA23013
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 10:22: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 i6FE34fY044210;
	Thu, 15 Jul 2004 07:03: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 i6FE34lP044209;
	Thu, 15 Jul 2004 07:03:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web41507.mail.yahoo.com (web41507.mail.yahoo.com [66.218.93.90])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6FE33vb044196
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 07:03:03 -0700 (PDT)
	(envelope-from randymorin@yahoo.com)
Message-ID: <20040715140300.56349.qmail@web41507.mail.yahoo.com>
Received: from [66.46.139.106] by web41507.mail.yahoo.com via HTTP; Thu, 15 Jul 2004 07:03:00 PDT
Date: Thu, 15 Jul 2004 07:03:00 -0700 (PDT)
From: Randy Charles Morin <randymorin@yahoo.com>
Reply-To: randy@kbcafe.com
Subject: Re: An alternative workable schema that's unordered? Yes!
To: "Asbjørn_Ulsberg" <asbjorn@tigerstaden.no>, randy@kbcafe.com
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <opsa5039wuuvpchu@quark>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1730670053-1089900180=:51932"
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>


--0-1730670053-1089900180=:51932
Content-Type: text/plain; charset=us-ascii

Thanks. Yes, feedinfo was just a tag name suggested in other threads on the Atom mailing list. I don't like tagnames w/ the parent tagname prepended. Looks weird. <head> is much better. I'm not concerned at all w/ the tagname, in fact, if Atom XML was obfuscated, I wouldn't complain.... much ;)
Thanks,
 
Randy
http://www.kbcafe.com


Asbjørn_Ulsberg <asbjorn@tigerstaden.no> wrote:
I've always thought it is kind of messy to not group the feed-level 
information together, so if this is all it takes to make Atom XSD 
friendly, I'm all for it. I'm not sure the elements should be called 
and , though. What about ?

-- 
Asbjørn Ulsberg -=|=- asbjornu@hotmail.com
«He's a loathsome offensive brute, yet I can't look away»



		
---------------------------------
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
--0-1730670053-1089900180=:51932
Content-Type: text/html; charset=us-ascii

<DIV>
<DIV>Thanks. Yes, feedinfo was just a tag name suggested in other threads on the Atom mailing list. I don't like tagnames w/ the parent tagname prepended. Looks weird. &lt;head&gt; is much better. I'm not concerned at all w/ the tagname, in fact, if Atom XML was obfuscated, I wouldn't complain.... much ;)</DIV>
<DIV>Thanks,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Randy</DIV>
<DIV><A href="http://www.kbcafe.com/">http://www.kbcafe.com</A></DIV>
<DIV><BR><BR><B><I>Asbjørn_Ulsberg &lt;asbjorn@tigerstaden.no&gt;</I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">I've always thought it is kind of messy to not group the feed-level <BR>information together, so if this is all it takes to make Atom XSD <BR>friendly, I'm all for it. I'm not sure the elements should be called <BR><FEEDINFO>and <ENTRYINFO>, though. What about ?<BR><BR>-- <BR>Asbjørn Ulsberg -=|=- asbjornu@hotmail.com<BR>«He's a loathsome offensive brute, yet I can't look away»<BR><BR></BLOCKQUOTE></DIV><p>
		<hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/mail_us/taglines/aac/*http://promotions.yahoo.com/new_mail/static/ease.html">Yahoo! Mail Address AutoComplete</a> - You start. We finish.
--0-1730670053-1089900180=:51932--



From owner-atom-syntax@mail.imc.org  Thu Jul 15 10: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 KAA24281
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 10:37:36 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FEToor048915;
	Thu, 15 Jul 2004 07:29:50 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6FETo6V048914;
	Thu, 15 Jul 2004 07:29:50 -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 i6FETnWw048894
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 07:29:50 -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 i6FETi53030756
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 09:29:44 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6FETipk030752;
	Thu, 15 Jul 2004 09:29:44 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: <atom-syntax@imc.org>
Subject: Re: a methodical approach to defining what date  elements we need
References: <D6AD94D06307435B9CB78A9EBEF81D.MAI@journurl.com>
	<40F66F3E.6020604@intertwingly.net>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 15 Jul 2004 09:29:43 -0500
In-Reply-To: <40F66F3E.6020604@intertwingly.net>
Message-ID: <m3vfgpjqco.fsf@bitsko.slc.ut.us>
Lines: 22
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: <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> writes:

> The RSS 2.0 definition of pubDate is as follows: "Its value is a
> date, indicating when the item was published. If it's a date in the
> future, aggregators may choose to not display the item until that
> date."
> 
> I prefer something that more closely captures Tim's description [1]:
> 
> > The canonical case would be a travel diary, the entry for July 1
> > may have been created on July 3 and modified on July 8, but from
> > the user's point of view it's still the entry for July 1.

I'm not sure if we're to the part about picking labels for these
meanings yet, so I'd just like to note that I think this meaning falls
outside of the meaning of DC 'issued' and Atom should use a different
element localname to encompass this meaning to avoid confusion with
DC.

I am fine with this meaning itself, if that works for us.

  -- Ken



From owner-atom-syntax@mail.imc.org  Thu Jul 15 10: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 KAA24806
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 10:45: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 i6FEPp34048196;
	Thu, 15 Jul 2004 07:25: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 i6FEPpfA048195;
	Thu, 15 Jul 2004 07:25:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web41501.mail.yahoo.com (web41501.mail.yahoo.com [66.218.93.84])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6FEPo3k048179
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 07:25:50 -0700 (PDT)
	(envelope-from randymorin@yahoo.com)
Message-ID: <20040715142548.9823.qmail@web41501.mail.yahoo.com>
Received: from [66.46.139.106] by web41501.mail.yahoo.com via HTTP; Thu, 15 Jul 2004 07:25:48 PDT
Date: Thu, 15 Jul 2004 07:25:48 -0700 (PDT)
From: Randy Charles Morin <randymorin@yahoo.com>
Reply-To: randy@kbcafe.com
Subject: Re: PacePutDelete Withdrawn 
To: Atomlist <atom-syntax@imc.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1902919008-1089901548=:8833"
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>


--0-1902919008-1089901548=:8833
Content-Type: text/plain; charset=us-ascii

Tim wrote:
>We have not yet taken up the cluster of issues around SOAP and 
>REST, and until we do, it is inappropriate to remove options 
>from consideration.
 
Let me start w/ Argggg!
 
Then a bit of, if anybody wants to own it, they should feel free to re-activate it and take up the battle. Any volunteers?
Thanks,
 
Randy
http://www.kbcafe.com
 

		
---------------------------------
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
--0-1902919008-1089901548=:8833
Content-Type: text/html; charset=us-ascii

<DIV><FONT face="Courier New">Tim wrote:</FONT></DIV>
<DIV><FONT face="Courier New">&gt;We have not yet taken up the cluster of issues around SOAP and </FONT></DIV>
<DIV><FONT face="Courier New">&gt;REST, and until we do, it is inappropriate to remove options </FONT></DIV>
<DIV><FONT face="Courier New">&gt;from consideration.</FONT></DIV>
<DIV><FONT face="Courier New"></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New">Let me start w/ Argggg!</FONT></DIV>
<DIV><FONT face="Courier New"></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New">Then a bit of, </FONT><FONT face="Courier New">if anybody wants to own it, they should feel free to re-activate it and take up the battle. Any volunteers?</FONT></DIV>
<DIV><FONT face="Courier New">Thanks,</FONT></DIV>
<DIV><FONT face="Courier New"></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New">Randy</FONT></DIV>
<DIV><FONT face="Courier New"><A href="http://www.kbcafe.com">http://www.kbcafe.com</A></FONT></DIV>
<DIV><FONT face="Courier New"></FONT>&nbsp;</DIV><p>
		<hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/mail_us/taglines/mobile/*http://mobile.yahoo.com/maildemo">Take Yahoo! Mail with you!</a> Get it on your mobile phone.
--0-1902919008-1089901548=:8833--



From owner-atom-syntax@mail.imc.org  Thu Jul 15 10:53: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 KAA25244
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 10:53: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 i6FEeY4P051163;
	Thu, 15 Jul 2004 07:40: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 i6FEeYMf051162;
	Thu, 15 Jul 2004 07:40:34 -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 i6FEeXDL051153
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 07:40:33 -0700 (PDT)
	(envelope-from distobj@acm.org)
Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian))
	id 1Bl7Q3-00066r-00
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 10:41:07 -0400
Date: Thu, 15 Jul 2004 10:41:07 -0400
To: Atomlist <atom-syntax@imc.org>
Subject: Re: PacePutDelete Withdrawn
Message-ID: <20040715144107.GU30868@markbaker.ca>
References: <20040715142548.9823.qmail@web41501.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040715142548.9823.qmail@web41501.mail.yahoo.com>
User-Agent: Mutt/1.3.28i
From: Mark Baker <distobj@acm.org>
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>


FWIW, it should be noted that this Pace includes an alternate proposal
which doesn't use SOAP. so it should be possible to move forward with
a solution to the PUT & DELETE problem without getting into the quagmire
that is REST vs. Web services.

On Thu, Jul 15, 2004 at 07:25:48AM -0700, Randy Charles Morin wrote:
> Tim wrote:
> >We have not yet taken up the cluster of issues around SOAP and 
> >REST, and until we do, it is inappropriate to remove options 
> >from consideration.
>  
> Let me start w/ Argggg!
>  
> Then a bit of, if anybody wants to own it, they should feel free to re-activate it and take up the battle. Any volunteers?
> Thanks,
>  
> Randy
> http://www.kbcafe.com
>  
> 
> 		
> ---------------------------------
> Do you Yahoo!?
> Take Yahoo! Mail with you! Get it on your mobile phone.

-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

  Seeking work on large scale application/data integration projects
  and/or the enabling infrastructure for same.



From owner-atom-syntax@mail.imc.org  Thu Jul 15 11: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 LAA25626
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 11: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 i6FElLlC052321;
	Thu, 15 Jul 2004 07:47:21 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6FElLDv052320;
	Thu, 15 Jul 2004 07:47:21 -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 i6FElKKW052270
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 07:47:21 -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 i6FElH53030990
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 09:47:18 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6FElHYw030986;
	Thu, 15 Jul 2004 09:47:17 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Regarding UseCases
References: <40F5D4F9.5070108@itst.org> <opsa51pdt8uvpchu@quark>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 15 Jul 2004 09:47:17 -0500
In-Reply-To: <opsa51pdt8uvpchu@quark>
Message-ID: <m3r7rdjpje.fsf@bitsko.slc.ut.us>
Lines: 19
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 i6FElLKW052315
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 <asbjorn@tigerstaden.no> writes:

> On Thu, 15 Jul 2004 02:51:05 +0200, Sascha Carlin <sc@itst.org> wrote:
> 
> > Discussions can be local and can spread over serveral places. How
> > are  discussions represented in Atom? What use cases exist for this
> > special  application?
> 
> I propose that we use Dublin Core's <relation>[1] element, which
> then would not distinguish between «local» and «distributed»
> discussions. All discussions are discussions, no matter how and
> where they are held. The appropriate attributes to use for a
> discussion, are 'References' and 'IsReferencedBy'.

I have some general disagreements about particular markup and meanings
surrounding this, is this part of PaceLinkParent or some other Pace?
Can we wait until that Pace comes up for discussion?

  -- Ken



From owner-atom-syntax@mail.imc.org  Thu Jul 15 11:15: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 LAA26617
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 11:15: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 i6FF4XZg055350;
	Thu, 15 Jul 2004 08:04:33 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6FF4X02055349;
	Thu, 15 Jul 2004 08:04: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 i6FF4W2E055343
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 08:04: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 1Bl7mj-0003hB-P3; Thu, 15 Jul 2004 15:04:33 +0000
Message-ID: <40F69CFF.6080802@franklinmint.fm>
Date: Thu, 15 Jul 2004 11:04:31 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: randy@kbcafe.com
CC: Atomlist <atom-syntax@imc.org>
Subject: Re: PacePutDelete Withdrawn
References: <20040715142548.9823.qmail@web41501.mail.yahoo.com>
In-Reply-To: <20040715142548.9823.qmail@web41501.mail.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - web02.designerslab.net
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - franklinmint.fm
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


Randy Charles Morin wrote:

> Tim wrote:
> >We have not yet taken up the cluster of issues around SOAP and
> >REST, and until we do, it is inappropriate to remove options
> >from consideration.
>  
> Let me start w/ Argggg!

I'll say it too.... Arggggg!

I understand we've only recently become an official WG, but we did beat 
this to death, once upon a time. The opinions following are all positive 
towards SOAP. In my search of the archives, I found two dissenters who 
didn't later change their opinion: Russell Beattie and Tim Bray.

Any WG starts with assumptions. At this point, it seems the group is 
overwhelmingly in favor of industry-standard firewall circumvention ;)

Robert Sayre


Joe Madia:
"If the Atom API doesn't support SOAP then it appears that you are 
literally signing up for *more* spec work that results in *less* people 
being able to access the API."
http://www.imc.org/atom-syntax/mail-archive/msg03109.html

Jonas Galvez
"I just wanted to add one more 'vote' for making SOAP a standard 
alternative for the Atom API."
http://www.imc.org/atom-syntax/mail-archive/msg03110.html

Anil Dash
"I have real people asking me for SOAP-enabled blogging tools."
http://www.imc.org/atom-syntax/mail-archive/msg03106.html

David Nielson
"SOAP should stay."
http://www.imc.org/atom-syntax/mail-archive/msg03104.html

Matt Croydon
"I was unhappy to see the proposed cutting of SOAP support in the Atom 
API in PacePutDelete"
http://www.imc.org/atom-syntax/mail-archive/msg03094.html

Jason Diamond
"I don't see any reason to invent yet another messaging technology when 
the SOAP syntax seems perfectly usable by those who are and are not 
using SOAP toolkits."
http://www.imc.org/atom-syntax/mail-archive/msg03082.html

Andrew Micone
"adopting SOAP means instant compatibility with a raft of middleware 
tools by half a dozen vendors."
http://www.imc.org/atom-syntax/mail-archive/msg03118.html

Joe Gregorio
"DifferentlyAbledClients is the best avenue for SOAP enabling which 
allows clients to use WSDL, which I agree, particularly with the 
screenshot of Flash MX importing a WSDL."
http://www.imc.org/atom-syntax/mail-archive/msg03141.html



From owner-atom-syntax@mail.imc.org  Thu Jul 15 11:20: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 LAA27000
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 11:20: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 i6FFBWjv056310;
	Thu, 15 Jul 2004 08:11: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 i6FFBWSZ056309;
	Thu, 15 Jul 2004 08:11:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from bitsko.slc.ut.us (dsl.76.41.networkiowa.com [209.234.76.41])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FFBUfd056293
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 08:11:31 -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 i6FFBS53031270
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 10:11:28 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6FFBRn1031266;
	Thu, 15 Jul 2004 10:11:27 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Feed of site events (was: Thought experiment: Using a synthetic feed to find out about other feeds)
References: <200407081614.BHM20108@ms8.netsolmail.com>
	<m3hdsiqspb.fsf@bitsko.slc.ut.us> <40EE7F98.6040207@intertwingly.net>
	<opsavggornuvpchu@quark> <40F59797.80104@AOL.NET>
	<m37jt6kxs6.fsf@bitsko.slc.ut.us> <40F5DFDF.3050700@AOL.NET>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 15 Jul 2004 10:11:27 -0500
In-Reply-To: <40F5DFDF.3050700@AOL.NET>
Message-ID: <m3n021jof4.fsf@bitsko.slc.ut.us>
Lines: 46
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


"John Panzer" <jpanzer@aol.net> writes:

> Hmm.  I think one of us isn't understanding the other here.
> 
> The "feed of site events" I'm talking about has absolutely nothing
> to do with the entries _inside_ the site.
> 
> In other words, if I post an entry, my "feed of site events" does
> not change in any way.
> 
> If I create a new site, however, my "feed of site events" for (say)
> my username, or for the host provider, produces a new entry, which
> represents the creation event.
> 
> I'm not trying to say that _every_ Atom feed is a "feed of events".

I'm quite ok with opening up <atom:feed> to contain other resources
that change, besides <atom:entry> resources.  We'd need to be clear
about that in the spec, so when clients come across
application/atom+xml resources with an {http://purl.org/atom/ns#}feed
element type that that element type may contain sets of changed
resources that aren't {http://purl.org/atom/ns#}entry element types.

Separate from that concern would be which pattern, or model, to
follow.  atom:entry are resource representations of entries, not
events describing changes in those representations.  The pattern to
follow would be to have a "feed if sites" be atom:site resource
representations, not atom:site-event elements describing changes in
those representations.

Or not.  I'm not strongly against "events" in a "notification system".
A "notification system" is a function I see syndication feeds
performing in addition to actual replication of representation.  HTTP
Events and Apache's mod_pubsub, for example, provide "events" that are
"change notifications of resources".  Those events tend to map HTTP
methods, "created" (PUT/POST), "updated" (PUT), "deleted" (DELETE).
WebDAV has a "search" function that can return "recent changed items
[of specified types]", in WebDAV's case you'd get metadata (partial
representation) of resources, not "events" in that sense.

I'm good with the exploration we're doing here.  I'm interested in
seeing it clearly modeled when we write the Paces to incorporate the
ideas, because we have to be clear and thorough about specifying these
features.

  -- Ken



From owner-atom-syntax@mail.imc.org  Thu Jul 15 11:32:33 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27605
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 11: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 i6FFPABf058349;
	Thu, 15 Jul 2004 08:25: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 i6FFPAO7058348;
	Thu, 15 Jul 2004 08:25: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 i6FFP975058341
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 08:25: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 1Bl86h-0004lB-Bc; Thu, 15 Jul 2004 15:25:11 +0000
Message-ID: <40F6A1D3.6060800@franklinmint.fm>
Date: Thu, 15 Jul 2004 11:25:07 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ken MacLeod <ken@bitsko.slc.ut.us>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Feed of site events
References: <200407081614.BHM20108@ms8.netsolmail.com>	<m3hdsiqspb.fsf@bitsko.slc.ut.us> <40EE7F98.6040207@intertwingly.net>	<opsavggornuvpchu@quark> <40F59797.80104@AOL.NET>	<m37jt6kxs6.fsf@bitsko.slc.ut.us> <40F5DFDF.3050700@AOL.NET> <m3n021jof4.fsf@bitsko.slc.ut.us>
In-Reply-To: <m3n021jof4.fsf@bitsko.slc.ut.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: <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


Ken MacLeod wrote:

>"John Panzer" <jpanzer@aol.net> writes:
>
>  
>
>>Hmm.  I think one of us isn't understanding the other here.
>>
>>The "feed of site events" I'm talking about has absolutely nothing
>>to do with the entries _inside_ the site.
>>
>>In other words, if I post an entry, my "feed of site events" does
>>not change in any way.
>>
>>If I create a new site, however, my "feed of site events" for (say)
>>my username, or for the host provider, produces a new entry, which
>>represents the creation event.
>>
>>I'm not trying to say that _every_ Atom feed is a "feed of events".
>>    
>>
>
>I'm quite ok with opening up <atom:feed> to contain other resources
>that change, besides <atom:entry> resources.  We'd need to be clear
>about that in the spec, so when clients come across
>application/atom+xml resources with an {http://purl.org/atom/ns#}feed
>element type that that element type may contain sets of changed
>resources that aren't {http://purl.org/atom/ns#}entry element types.
>  
>

I am probably missing the point here, but why is this better than making 
a normal feed? People already do this kind of thing with CVS checkins 
and whatnot. This is syndicating a logfile--that already works pretty well.

Robert Sayre



From owner-atom-syntax@mail.imc.org  Thu Jul 15 11:46:30 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28497
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 11:46:30 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FFZTCf060127;
	Thu, 15 Jul 2004 08:35: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 i6FFZTCn060126;
	Thu, 15 Jul 2004 08:35:29 -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 i6FFZSsV060120
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 08:35:29 -0700 (PDT)
	(envelope-from mcmay@w3.org)
Received: from [127.0.0.1] (homer.w3.org [18.29.0.30])
	by homer.w3.org (Postfix) with ESMTP id ED86A4EF06;
	Thu, 15 Jul 2004 11:35:30 -0400 (EDT)
Message-ID: <40F6A443.3060508@w3.org>
Date: Thu, 15 Jul 2004 08:35:31 -0700
From: Matt May <mcmay@w3.org>
User-Agent: Mozilla Thunderbird 0.7.1 (Macintosh/20040626)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Joe Gregorio <joe.gregorio@gmail.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Don't bake discrimination into the Atom core (was Re: Low-hanging
 fruit: multipart/alternative)
References: <A65D9796-D519-11D8-8C42-000A95A51C9E@textuality.com> <14be96d304071317541efca684@mail.gmail.com> <7FBABBD6-D531-11D8-A503-000A95A51C9E@textuality.com> <14be96d304071319181e2bf741@mail.gmail.com> <1393DBDA-D540-11D8-A503-000A95A51C9E@textuality.com> <opsa4zq3fhuvpchu@quark> <14be96d304071410083cc71f90@mail.gmail.com> <3f1451f5040714102129846420@mail.gmail.com>
In-Reply-To: <3f1451f5040714102129846420@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


Joe Gregorio wrote:
> Regardless I see no harm in removing something that is 
> broken and waiting until later to decide on what to replace it 
> with. It could even be replaced in the short term with an empty section
> titled "Accessibility" and just filled with "TBD".

Ack. In my experience, most specs that go this way end up reading 
"Accessibility: TBD" through 0.9, after which all spec-related decisions 
have been decided without adequate consideration for accessibility. I 
recommend marking up accessibility issues now, rather than expecting 
that they'll pop up later.

W3C/WAI published a document called the XML Accessibility Guidelines. A 
better title would be So You've Decided to Create an Accessible 
Language. It gives a list of accessibility-related needs, and the 
rationale for each. It's highly-recommended reading for language developers.

http://www.w3.org/TR/xag

If people find it useful, I can also arrange some sort of interaction 
between Atom and the WAI Protocols and Formats WG, whose job it is to 
review specs like Atom for accessibility issues. That can take the form 
of getting someone to join us on our weekly telecon, or just pointing 
them to threads where questions arise.

-
m



From owner-atom-syntax@mail.imc.org  Thu Jul 15 11:46: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 LAA28521
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 11:46: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 i6FFZ5Fp060058;
	Thu, 15 Jul 2004 08:35: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 i6FFZ5xE060057;
	Thu, 15 Jul 2004 08:35: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 (mproxy.gmail.com [216.239.56.242])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6FFZ4CX060051
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 08:35:04 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so1393469cwc
        for <atom-syntax@imc.org>; Thu, 15 Jul 2004 08:35:04 -0700 (PDT)
Received: by 10.11.99.74 with SMTP id w74mr63434cwb;
        Thu, 15 Jul 2004 08:35:04 -0700 (PDT)
Message-ID: <3f1451f50407150835211f90d4@mail.gmail.com>
Date: Thu, 15 Jul 2004 11:35:04 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: mint@franklinmint.fm
Subject: Re: PacePutDelete Withdrawn
Cc: randy@kbcafe.com, Atomlist <atom-syntax@imc.org>
In-Reply-To: <40F69CFF.6080802@franklinmint.fm>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <20040715142548.9823.qmail@web41501.mail.yahoo.com> <40F69CFF.6080802@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 Thu, 15 Jul 2004 11:04:31 -0400, Robert Sayre <mint@franklinmint.fm> wrote:
> Joe Gregorio
> "DifferentlyAbledClients is the best avenue for SOAP enabling which
> allows clients to use WSDL, which I agree, particularly with the
> screenshot of Flash MX importing a WSDL."
> http://www.imc.org/atom-syntax/mail-archive/msg03141.html

Sorry, but that quote isn't quite in context, but to be 
clear I do not like SOAP and believe it should be
dropped.

   Thanks,
   -joe



From owner-atom-syntax@mail.imc.org  Thu Jul 15 11: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 LAA28646
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 11: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 i6FFg2sL061063;
	Thu, 15 Jul 2004 08:42: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 i6FFg20X061062;
	Thu, 15 Jul 2004 08:42: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 i6FFg1ak061042
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 08:42: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 i6FFfw53031614
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 10:41:58 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6FFfwMM031610;
	Thu, 15 Jul 2004 10:41:58 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atomlist <atom-syntax@imc.org>
Subject: Re: PacePutDelete Withdrawn
References: <20040715142548.9823.qmail@web41501.mail.yahoo.com>
	<40F69CFF.6080802@franklinmint.fm>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 15 Jul 2004 10:41:58 -0500
In-Reply-To: <40F69CFF.6080802@franklinmint.fm>
Message-ID: <m3iscpjn09.fsf@bitsko.slc.ut.us>
Lines: 37
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 i6FFg1ak061057
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


Robert Sayre <mint@franklinmint.fm> writes:

> I understand we've only recently become an official WG, but we did
> beat this to death, once upon a time. The opinions following are all
> positive towards SOAP. In my search of the archives, I found two
> dissenters who didn't later change their opinion: Russell Beattie
> and Tim Bray.

I've been mostly ok with SOAP because it hasn't my itch to scratch,
except to spec, and that seemed to be straightforward at the time per
DifferentlyAbledClients.

The point where it became a concern for me with regards to speccing it
was when the mobile developers noted the CPU and/or bandwidth concerns
in gzipping and/or based64 encoding binary content to upload.

That was discussed heavily before, during, and following the June
face-to-face meeting.  PaceNonEntryResources first described binary
uploading using POST/PUT, and John Panzer followed up after the
meeting with PaceSimpleResourcePosting, which also supported POST,
then PUT.  John, Janne Jalkanen, Asbjørn Ulsberg, and I have been
working to merge these two Paces and are nearly complete.

Binary-upload using SOAP wrappers either leads back to base64 or
forward to MIME attachments or enclosures.  base64 doesn't solve the
mobile requirement, so it seems Atom would have to spec attachments as
well.  That's no longer straightforward.

PacePutDelete provided an alternate solution that was simpler and
didn't require base64 encoding of binary content: use an X-Atom-Method
header.

I hope that provides some background on discussing some of the
balancing points between SOAP-in-core, PacePutDelete, and multimedia
upload.

  -- Ken



From owner-atom-syntax@mail.imc.org  Thu Jul 15 11:53: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 LAA29026
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 11:53: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 i6FFdcb3060684;
	Thu, 15 Jul 2004 08:39: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 i6FFdcGY060683;
	Thu, 15 Jul 2004 08:39:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FFdbhx060674
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 08:39: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 1Bl8Kg-0005Jd-Lt; Thu, 15 Jul 2004 15:39:38 +0000
Message-ID: <40F6A538.7060203@franklinmint.fm>
Date: Thu, 15 Jul 2004 11:39:36 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Joe Gregorio <joe.gregorio@gmail.com>
CC: randy@kbcafe.com, Atomlist <atom-syntax@imc.org>
Subject: Re: PacePutDelete Withdrawn
References: <20040715142548.9823.qmail@web41501.mail.yahoo.com> <40F69CFF.6080802@franklinmint.fm> <3f1451f50407150835211f90d4@mail.gmail.com>
In-Reply-To: <3f1451f50407150835211f90d4@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - web02.designerslab.net
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - franklinmint.fm
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


Joe Gregorio wrote:

>On Thu, 15 Jul 2004 11:04:31 -0400, Robert Sayre <mint@franklinmint.fm> wrote:
>  
>
>>Joe Gregorio
>>"DifferentlyAbledClients is the best avenue for SOAP enabling which
>>allows clients to use WSDL, which I agree, particularly with the
>>screenshot of Flash MX importing a WSDL."
>>http://www.imc.org/atom-syntax/mail-archive/msg03141.html
>>    
>>
>
>Sorry, but that quote isn't quite in context, but to be 
>clear I do not like SOAP and believe it should be
>dropped.
>  
>

Oops. Sorry. Glad I included the link to the full email. Is it accurate 
that you would prefer SOAP to an <action> element?

Robert Sayre



From owner-atom-syntax@mail.imc.org  Thu Jul 15 12:09: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 MAA00031
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 12:09: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 i6FFosfK062473;
	Thu, 15 Jul 2004 08:50:54 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6FFos9Z062472;
	Thu, 15 Jul 2004 08:50:54 -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 i6FFos6J062449
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 08:50:54 -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 i6FFont27305
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 08:50:49 -0700 (PDT)
Received: from aol.net ([10.169.192.58]) by judge.mcom.com
          (Netscape Messaging Server 4.15) with ESMTP id I0WHCO03.I1P;
          Thu, 15 Jul 2004 08:50:48 -0700 
Message-ID: <40F6A7DB.4000908@aol.net>
Date: Thu, 15 Jul 2004 08:50:51 -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: Joe Gregorio <joe.gregorio@gmail.com>
CC: Ken MacLeod <ken@bitsko.slc.ut.us>, Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceIntrospection: New Examples for Feed-Based Introspection
References: <40F52038.4050101@spoonybards.net> <m3u0walm7v.fsf@bitsko.slc.ut.us> <3f1451f50407140749f045eb@mail.gmail.com>
In-Reply-To: <3f1451f50407140749f045eb@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------090003050607020602090805"
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>


This is a multi-part message in MIME format.
--------------090003050607020602090805
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Joe Gregorio wrote:

>On 14 Jul 2004 09:03:48 -0500, Ken MacLeod <ken@bitsko.slc.ut.us> wrote: 
>  
>
>>OK, this seems to be a very clear statement.  What this is saying is
>>that one should determine the content type of a resource at a
>>particular URI location:
>>
>> * not by its Internet Media Type (application/atom+xml),
>> * not by its XML namespace (http://purl.org/atom/ns#),
>> * not by its element type (namespace+localname), and
>> * not by any other local means indicated within the content
>>
>>but rather, solely by the external link property used to reference the
>>resource (<link rel="service.feed">).
>>
>>That doesn't work past the first time the link is copied to some other
>>location, for *any* other purpose (linking, documentation, storage).
>>Once the link reference "leaves its home", knowledge of what the
>>resource "is" is lost.
>>    
>>
>
>+1 
>
>The indication of the type of content needs to be provided
>by either the media type or the  root element name (
>localname + namespace), and introspection is a 
>different kind of content than a feed.
>  
>
I am not sure, but I _think_ that Bob Wyman's synthetic feed extension 
addresses the ambiguity issue between entry-data and feed-or-site-data.  
See thread starting at See 
http://www.imc.org/atom-syntax/mail-archive/msg06352.html, "Using a 
synthetic feed to find out about other feeds".

<?xml version='1.0'encoding="utf-8"?>
<feed version='0.3' xmlns='http://purl.org/atom/ns#' xmlns:ps='http://www.pubsub.com/xmlns'>
   <link rel='alternate' type='text/html' href='http://example.com/bugsbunny'/>
   <modified>2004-07-07T18:36:11-04:00</modified>
   <author>
      <name>Bugs Bunny</name>
   </author>
<title><![CDATA[Bugs Bunny's Blogs]]></title>

<entry>
  <ps:source-feed>
    <title><![CDATA[Title of my First Blog]]></title>
    <link rel='alternate' type='text/html' href='http://example.com/bugsbunny/MyFirstBlog'/>
    <link rel='???' type='application/atom+xml' href='http://example.com/bugsbunny/MyFirstBlog.atom'/>
    <link rel="service.post" type="application/atom+xml" href="" class="moz-txt-link-rfc2396E" href="http:/example.com/bugsbunny/MyFirstBlog/atompost.cgi">"http:/example.com/bugsbunny/MyFirstBlog/atompost.cgi"/>
  </ps:source-feed>
  <issued>2004-07-07T19:34:10-04:00</issued>
  <content>...</content>
</entry>

It's unambiguous which data is associated with the feed.  Synthetic 
feeds are also something that aggregators will have to deal with in any 
case.  Can these same mechanisms be used for introspection?  (My 
position is that introspection-like-things will happen using synthetic 
feeds in any case, because they're generally useful.)

I'd be interested to hear reactions to this concept.  Is it helpful, or 
just more noise?

-John

--------------090003050607020602090805
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Joe Gregorio wrote:<br>
<blockquote cite="mid3f1451f50407140749f045eb@mail.gmail.com"
 type="cite">
  <pre wrap="">On 14 Jul 2004 09:03:48 -0500, Ken MacLeod <a class="moz-txt-link-rfc2396E" href="mailto:ken@bitsko.slc.ut.us">&lt;ken@bitsko.slc.ut.us&gt;</a> wrote: 
  </pre>
  <blockquote type="cite">
    <pre wrap="">OK, this seems to be a very clear statement.  What this is saying is
that one should determine the content type of a resource at a
particular URI location:

 * not by its Internet Media Type (application/atom+xml),
 * not by its XML namespace (<a class="moz-txt-link-freetext" href="http://purl.org/atom/ns#">http://purl.org/atom/ns#</a>),
 * not by its element type (namespace+localname), and
 * not by any other local means indicated within the content

but rather, solely by the external link property used to reference the
resource (&lt;link rel="service.feed"&gt;).

That doesn't work past the first time the link is copied to some other
location, for *any* other purpose (linking, documentation, storage).
Once the link reference "leaves its home", knowledge of what the
resource "is" is lost.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
+1 

The indication of the type of content needs to be provided
by either the media type or the  root element name (
localname + namespace), and introspection is a 
different kind of content than a feed.
  </pre>
</blockquote>
I am not sure, but I _think_ that Bob Wyman's synthetic feed extension
addresses the ambiguity issue between entry-data and
feed-or-site-data.&nbsp; See thread starting at See
<a class="moz-txt-link-freetext" href="http://www.imc.org/atom-syntax/mail-archive/msg06352.html">http://www.imc.org/atom-syntax/mail-archive/msg06352.html</a>, "Using a
synthetic feed to find out about other feeds".<br>
<pre id="line46"><span class="pi">&lt;?xml version='1.0'encoding="utf-8"?&gt;</span>
&lt;<span class="start-tag">feed</span><span class="attribute-name"> version</span>=<span
 class="attribute-value">'0.3' </span><span class="attribute-name">xmlns</span>=<span
 class="attribute-value">'<a class="moz-txt-link-freetext"
 href="http://purl.org/atom/ns#">http://purl.org/atom/ns#</a>' </span><span
 class="attribute-name">xmlns:ps</span>=<span class="attribute-value">'<a
 class="moz-txt-link-freetext" href="http://www.pubsub.com/xmlns">http://www.pubsub.com/xmlns</a>'</span>&gt;
   &lt;<span class="start-tag">link</span><span class="attribute-name"> rel</span>=<span
 class="attribute-value">'alternate' </span><span class="attribute-name">type</span>=<span
 class="attribute-value">'text/html' </span><span class="attribute-name">href</span>=<span
 class="attribute-value">'<a class="moz-txt-link-freetext"
 href="http://example.com/bugsbunny">http://example.com/bugsbunny</a>'</span><span
 class="attribute-name">/</span>&gt;
   &lt;<span class="start-tag">modified</span>&gt;2004-07-07T18:36:11-04:00&lt;/<span
 class="end-tag">modified</span>&gt;
   &lt;<span class="start-tag">author</span>&gt;
      &lt;<span class="start-tag">name</span>&gt;Bugs Bunny&lt;/<span
 class="end-tag">name</span>&gt;
   &lt;/<span class="end-tag">author</span>&gt;
&lt;<span class="start-tag">title</span>&gt;<span class="cdata">&lt;![CDATA[Bugs Bunny's Blogs]]&gt;</span>&lt;/<span
 class="end-tag">title</span>&gt;

&lt;<span class="start-tag">entry</span>&gt;
  &lt;<span class="start-tag">ps:source-feed</span>&gt;
    &lt;<span class="start-tag">title</span>&gt;<span class="cdata">&lt;![CDATA[Title of my First Blog]]&gt;</span>&lt;/<span
 class="end-tag">title</span>&gt;
    &lt;<span class="start-tag">link</span><span class="attribute-name"> rel</span>=<span
 class="attribute-value">'alternate' </span><span class="attribute-name">type</span>=<span
 class="attribute-value">'text/html' </span><span class="attribute-name">href</span>=<span
 class="attribute-value">'<a class="moz-txt-link-freetext"
 href="http://example.com/bugsbunny/MyFirstBlog">http://example.com/bugsbunny/MyFirstBlog</a>'</span><span
 class="attribute-name">/</span>&gt;
    &lt;<span class="start-tag">link</span><span class="attribute-name"> rel</span>=<span
 class="attribute-value">'???' </span><span class="attribute-name">type</span>=<span
 class="attribute-value">'application/atom+xml' </span><span
 class="attribute-name">href</span>=<span class="attribute-value">'<a
 class="moz-txt-link-freetext"
 href="http://example.com/bugsbunny/MyFirstBlog">http://example.com/bugsbunny/MyFirstBlog.atom</a>'</span><span
 class="attribute-name">/</span>&gt;
    &lt;link rel="service.post" type="application/atom+xml" href="" class="moz-txt-link-rfc2396E" href=<a class="moz-txt-link-rfc2396E" href="http:/example.com/bugsbunny/MyFirstBlog/atompost.cgi">"http:/example.com/bugsbunny/MyFirstBlog/atompost.cgi"</a>&gt;<a class="moz-txt-link-rfc2396E" href="http:/example.com/bugsbunny/MyFirstBlog/atompost.cgi">"http:/example.com/bugsbunny/MyFirstBlog/atompost.cgi"</a>/&gt;
  &lt;/<span class="end-tag">ps:source-feed</span>&gt;
  &lt;<span class="start-tag">issued</span>&gt;2004-07-07T19:34:10-04:00&lt;/<span
 class="end-tag">issued</span>&gt;
  &lt;content&gt;...&lt;/content&gt;
&lt;/<span class="end-tag">entry</span>&gt;
</pre>
It's unambiguous which data is associated with the feed.&nbsp; Synthetic
feeds are also something that aggregators will have to deal with in any
case.&nbsp; Can these same mechanisms be used for introspection?&nbsp; (My
position is that introspection-like-things will happen using synthetic
feeds in any case, because they're generally useful.)<br>
<br>
I'd be interested to hear reactions to this concept.&nbsp; Is it helpful, or
just more noise?<br>
<br>
-John<br>
</body>
</html>

--------------090003050607020602090805--



From owner-atom-syntax@mail.imc.org  Thu Jul 15 12:12: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 MAA00280
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 12:12: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 i6FG1PXM064013;
	Thu, 15 Jul 2004 09:01: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 i6FG1Pa3064012;
	Thu, 15 Jul 2004 09:01:25 -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 i6FG1PpM064005
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 09:01:25 -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 i6FG1Rn6012007;
	Thu, 15 Jul 2004 09:01:27 -0700 (PDT)
Received: from [192.168.1.100] (h00080d858303.ne.client2.attbi.com [24.61.1.243])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id i6FG0rfk022908;
	Thu, 15 Jul 2004 09:01:16 -0700 (PDT)
In-Reply-To: <14be96d304071506034fb16820@mail.gmail.com>
References: <2E0F8DF6-D610-11D8-B24C-000A95DC3D90@mac.com> <14be96d304071506034fb16820@mail.gmail.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <207D9E11-D678-11D8-B24C-000A95DC3D90@mac.com>
Content-Transfer-Encoding: 7bit
Cc: Atom-Syntax Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: Don't bake discrimination into the Atom core
Date: Thu, 15 Jul 2004 12:00:43 -0400
To: Mark Pilgrim <pilgrim@gmail.com>
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>
Content-Transfer-Encoding: 7bit


On 15 Jul 2004, at 9:03 am, Mark Pilgrim wrote:

> <summary> "is a Content construct that conveys a short summary,
> abstract or excerpt of the entry."  This is not the place for
> accessible alternate content either.

It may not be "what it's for", but I don't see why accessible content 
is incompatible with it. Furthermore, could you stop advocating for 
five seconds and tell us what it is you want? You're the expert.

Graham



From owner-atom-syntax@mail.imc.org  Thu Jul 15 12:27: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 MAA01109
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 12:27: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 i6FG64Xm064856;
	Thu, 15 Jul 2004 09:06: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 i6FG64AV064855;
	Thu, 15 Jul 2004 09:06: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 i6FG63VJ064840
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 09:06: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 1Bl8kG-0006Vj-TN; Thu, 15 Jul 2004 16:06:05 +0000
Message-ID: <40F6AB6A.7030100@franklinmint.fm>
Date: Thu, 15 Jul 2004 12:06:02 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ken MacLeod <ken@bitsko.slc.ut.us>
CC: Atomlist <atom-syntax@imc.org>
Subject: Re: PacePutDelete Withdrawn
References: <20040715142548.9823.qmail@web41501.mail.yahoo.com>	<40F69CFF.6080802@franklinmint.fm> <m3iscpjn09.fsf@bitsko.slc.ut.us>
In-Reply-To: <m3iscpjn09.fsf@bitsko.slc.ut.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: <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


Ken MacLeod wrote:

>
>I've been mostly ok with SOAP because it hasn't my itch to scratch,
>except to spec, and that seemed to be straightforward at the time per
>DifferentlyAbledClients.
>
>The point where it became a concern for me with regards to speccing it
>was when the mobile developers noted the CPU and/or bandwidth concerns
>in gzipping and/or based64 encoding binary content to upload.
>
>
>PacePutDelete provided an alternate solution that was simpler and
>didn't require base64 encoding of binary content: use an X-Atom-Method
>header.
>  
>
OK. I always forget about the alternate X-Atom-Method approach mentioned 
there. Is it alleged that shipping J2ME HTTP classes allow setting of 
request headers, but not HTTP methods other than GET and POST? Are there 
any other clients that can set headers but not methods?

Robert Sayre



From owner-atom-syntax@mail.imc.org  Thu Jul 15 12:28:41 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01164
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 12:28: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 i6FGLU21067489;
	Thu, 15 Jul 2004 09:21: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 i6FGLU0n067488;
	Thu, 15 Jul 2004 09:21: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 i6FGLTNV067473
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 09:21:29 -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 i6FGLUil000283
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 10:21:30 -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 <0I0W003EHIRTWW@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Thu, 15 Jul 2004 10:21:30 -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 <0I0W00KP0IRT3N@mail.sun.net> for atom-syntax@imc.org; Thu,
 15 Jul 2004 10:21:29 -0600 (MDT)
Date: Thu, 15 Jul 2004 09:21:33 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Regarding UseCases
In-reply-to: <m3r7rdjpje.fsf@bitsko.slc.ut.us>
To: Ken MacLeod <ken@bitsko.slc.ut.us>
Cc: Atom-Syntax <atom-syntax@imc.org>
Message-id: <0970C35E-D67B-11D8-A6EC-000A95A51C9E@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.618)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
References: <40F5D4F9.5070108@itst.org> <opsa51pdt8uvpchu@quark>
 <m3r7rdjpje.fsf@bitsko.slc.ut.us>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6FGLUNV067476
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 Jul 15, 2004, at 7:47 AM, Ken MacLeod wrote:

>> I propose that we use Dublin Core's <relation>[1] element, which
>> then would not distinguish between «local» and «distributed»
>> discussions. All discussions are discussions, no matter how and
>> where they are held. The appropriate attributes to use for a
>> discussion, are 'References' and 'IsReferencedBy'.
>
> I have some general disagreements about particular markup and meanings
> surrounding this, is this part of PaceLinkParent or some other Pace?
> Can we wait until that Pace comes up for discussion?

If it's not part of one of the others, it needs its own Pace I'd say... 
it certainly feels like a large, meaty issue. -Tim




From owner-atom-syntax@mail.imc.org  Thu Jul 15 12:33: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 MAA01373
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 12:33: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 i6FGL6xE067431;
	Thu, 15 Jul 2004 09:21: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 i6FGL6x4067430;
	Thu, 15 Jul 2004 09:21:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FGL4Yh067419
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 09:21:05 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman
Message-Id: <p06110417bd1c5ec0c5a7@[10.20.30.249]>
Date: Thu, 15 Jul 2004 09:19:08 -0700
To: Atom WG <atom-syntax@imc.org>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Fwd: 60th IETF - Registration
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>


Just another reminder that, if you're coming to the IETF meeting, 
pre-registering saves you a lot of money...

>To: IETF-Announce@ietf.org
>Date: Wed, 14 Jul 2004 17:27:56 -0400
>From: Marcia Beaulieu <mbeaulie@cnri.reston.va.us>
>X-Mailman-Approved-At: Thu, 15 Jul 2004 07:27:40 -0400
>Cc: mbeaulie@foretec.com
>Subject: 60th IETF - Registration
>X-BeenThere: ietf-announce@ietf.org
>X-Mailman-Version: 2.1.5
>List-Id: ietf-announce.ietf.org
>List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>,
>	<mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
>List-Post: <mailto:ietf-announce@ietf.org>
>List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
>List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>,
>	<mailto:ietf-announce-request@ietf.org?subject=subscribe>
>Sender: ietf-announce-bounces@ietf.org
>
>REMINDER
>Pre-registration for the 60th IETF Meeting in San Diego, CA closes
>on Wednesday, July 21 at 12:00 noon ET.
>
>You can register on-line until that time at:
>http://www.ietf.org/meetings/IETF-60.html
>
>_______________________________________________
>IETF-Announce mailing list
>IETF-Announce@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf-announce



From owner-atom-syntax@mail.imc.org  Thu Jul 15 12:39: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 MAA01963
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 12:39: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 i6FGVZv7069100;
	Thu, 15 Jul 2004 09:31: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 i6FGVZKW069099;
	Thu, 15 Jul 2004 09:31: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 (mproxy.gmail.com [216.239.56.250])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6FGVZfb069092
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 09:31:35 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so1441484cwc
        for <atom-syntax@imc.org>; Thu, 15 Jul 2004 09:31:38 -0700 (PDT)
Received: by 10.11.99.56 with SMTP id w56mr65944cwb;
        Thu, 15 Jul 2004 09:31:38 -0700 (PDT)
Message-ID: <3f1451f504071509314ec4f592@mail.gmail.com>
Date: Thu, 15 Jul 2004 12:31:38 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Matt May <mcmay@w3.org>
Subject: Re: Re: Don't bake discrimination into the Atom core (was Re: Low-hanging fruit: multipart/alternative)
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <40F6A443.3060508@w3.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <A65D9796-D519-11D8-8C42-000A95A51C9E@textuality.com> <14be96d304071317541efca684@mail.gmail.com> <7FBABBD6-D531-11D8-A503-000A95A51C9E@textuality.com> <14be96d304071319181e2bf741@mail.gmail.com> <1393DBDA-D540-11D8-A503-000A95A51C9E@textuality.com> <opsa4zq3fhuvpchu@quark> <14be96d304071410083cc71f90@mail.gmail.com> <3f1451f5040714102129846420@mail.gmail.com> <40F6A443.3060508@w3.org>
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 Thu, 15 Jul 2004 08:35:31 -0700, Matt May <mcmay@w3.org> wrote:
> Joe Gregorio wrote:
> > Regardless I see no harm in removing something that is
> > broken and waiting until later to decide on what to replace it
> > with. It could even be replaced in the short term with an empty section
> > titled "Accessibility" and just filled with "TBD".
> 
> Ack. In my experience, most specs that go this way end up reading
> "Accessibility: TBD" through 0.9, after which all spec-related decisions
> have been decided without adequate consideration for accessibility. I
> recommend marking up accessibility issues now, rather than expecting
> that they'll pop up later.

We have Mark. That won't happen. Trust me.

   -joe



From owner-atom-syntax@mail.imc.org  Thu Jul 15 12:42: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 MAA02307
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 12:42: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 i6FGI59o066979;
	Thu, 15 Jul 2004 09:18: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 i6FGI5If066978;
	Thu, 15 Jul 2004 09:18:05 -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 i6FGI3rg066959
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 09:18:04 -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 i6FGI153032170
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 11:18:01 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6FGI1IA032165;
	Thu, 15 Jul 2004 11:18:01 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Feed of site events
References: <200407081614.BHM20108@ms8.netsolmail.com>
	<m3hdsiqspb.fsf@bitsko.slc.ut.us> <40EE7F98.6040207@intertwingly.net>
	<opsavggornuvpchu@quark> <40F59797.80104@AOL.NET>
	<m37jt6kxs6.fsf@bitsko.slc.ut.us> <40F5DFDF.3050700@AOL.NET>
	<m3n021jof4.fsf@bitsko.slc.ut.us> <40F6A1D3.6060800@franklinmint.fm>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 15 Jul 2004 11:18:01 -0500
In-Reply-To: <40F6A1D3.6060800@franklinmint.fm>
Message-ID: <m3ekndjlc6.fsf@bitsko.slc.ut.us>
Lines: 36
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: <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> writes:

> I am probably missing the point here, but why is this better than
> making a normal feed? People already do this kind of thing with CVS
> checkins and whatnot. This is syndicating a logfile--that already
> works pretty well.

If the augmented "normal feed" is for the intended syndication client
audience, I'm fine with that, that's what extensions are for.  If the
augmented "normal feed" is a hack to "re-use" the Atom format, that
seems less than optimal for both the producer and the consumer.  It's
simpler to use a separate resource type (which may be as simple as
different namespace).

If this is simply an augmented normal feed, then I'm not sure why
we're discussing it, because it presumes we all agree on what the Atom
publishing format and protocol model is.

On the other hand, it seems we're discussing it because we want to
extend, open up, or at least clarify the model.  As I said, I'm fine
with exploring that.

Beecher and John, if I understand John's proposal, have asserted that
the Atom model supports this kind of usage, I don't agree because I
don't see these alternate models as something Atom is speccing
properly.

What do we need to do to get in synch?

  -- Ken

PS.  There may be a class of "utility feeds" that it doesn't make
sense for human readers to subscribe to but may fit the model.  That's
a stretch, but I'm probably ok with those, too, as long as we
understand how it affects the model with respect to auto-subscription,
feed discovery, etc.



From owner-atom-syntax@mail.imc.org  Thu Jul 15 12:45: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 MAA02500
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 12:45: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 i6FGaLmd069726;
	Thu, 15 Jul 2004 09: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 i6FGaLuh069725;
	Thu, 15 Jul 2004 09:36:21 -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 i6FGaKUU069711
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 09:36:20 -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 i6FGYE53014063
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 10:34:14 -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 <0I0W003GUJGNWW@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Thu, 15 Jul 2004 10:36: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 <0I0W00K7JJGM3Q@mail.sun.net> for atom-syntax@imc.org; Thu,
 15 Jul 2004 10:36:23 -0600 (MDT)
Date: Thu, 15 Jul 2004 09:36:26 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PacePutDelete Withdrawn
In-reply-to: <40F69CFF.6080802@franklinmint.fm>
To: Atomlist <atom-syntax@imc.org>
Message-id: <1DFD193F-D67D-11D8-A6EC-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: <20040715142548.9823.qmail@web41501.mail.yahoo.com>
 <40F69CFF.6080802@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 Jul 15, 2004, at 8:04 AM, Robert Sayre wrote:

> I understand we've only recently become an official WG, but we did 
> beat this to death, once upon a time. The opinions following are all 
> positive towards SOAP. In my search of the archives, I found two 
> dissenters who didn't later change their opinion: Russell Beattie and 
> Tim Bray.

OK, in that case Paul Hoffman has a problem to solve, because you are 
asserting that we already have satisfactory rough consensus on the 
basic structure of the publishing protocol, and I'm unhappy, but then 
I'm a partisan so I have to take my co-chair's hat off and throw the 
problem to Paul.

Perhaps it would help if I explained what my real problem is.

First off, I'm not against putting in a SOAP interface.  (I'm also not 
in favor, I'm totally willing to go with the flow of the WG on that).

But, when I read back over the correspondence, it seemed there was a 
possibility that neither the REST nor SOAP modes of the protocol we're 
building would be usable by today's smart cellphones that have Java, 
Brew, or equivalent.  This seems to me violently unsatisfactory, given 
that there are tens of millions of these things out there, many 
equipped with cameras, many in the hands of geeky people who would be 
likely users of Atom, and a frightening number more are being sold 
every *day*.

However, I'm not technically competent to judge this, so I've asked 
Russell Beattie and some Java heavies inside Sun who I should go hunt 
down to drop by here and advise us.  Until we get such advice, I don't 
think we should take any of our options (e.g. those in Joe's original 
Pace) definitively off the table.

By the way, if there's someone already here who can step up and explain 
authoritatively why this isn't a problem, that would be great.

Until then [speaking once again with my co-chair's hat off] I dissent 
violently to any action by this WG which might potentially 
disenfranchise the tens of millions of users of smart phones.  I don't 
*think* this should be a controversial position.  -Tim



From owner-atom-syntax@mail.imc.org  Thu Jul 15 12: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 MAA03549
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 12:54: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 i6FGkA7V071475;
	Thu, 15 Jul 2004 09:46: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 i6FGkASY071474;
	Thu, 15 Jul 2004 09:46:10 -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 i6FGkAZ9071456
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 09:46:10 -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 JAA25539
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 09:46:08 -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 JAA02029
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 09:46:07 -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); Thu, 15 Jul 2004 09:46:07 -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 <0I0W0091MJWUZS@shazam.verity.com> for atom-syntax@imc.org; Thu,
 15 Jul 2004 09:46:07 -0700 (PDT)
Date: Thu, 15 Jul 2004 09:52:50 -0700
From: Walter Underwood <wunder@verity.com>
Subject: Re: PacePutDelete Withdrawn
In-reply-to: <6315ADDE-D623-11D8-A6EC-000A95A51C9E@sun.com>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <77058460BAC368B3D824DD7E@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: <3f1451f504071218365f8ebf05@mail.gmail.com>
 <6315ADDE-D623-11D8-A6EC-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 Wednesday, July 14, 2004 10:54:08 PM -0700 Tim Bray <Tim.Bray@Sun.COM> 
wrote:
> On Jul 12, 2004, at 6:36 PM, Joe Gregorio wrote:
>
>> I initially proposed PacePutDelete[1]
>> and now I would like to withdraw it.
>
> [Speaking as an individual, not co-chair] I dissent strongly on the
> withdrawing of this Pace at this time, and would like to see it go back
> into the "needs revisiting" queue.  We have not yet taken up the cluster
> of issues around SOAP and REST, and until we do, it is inappropriate to
> remove options from consideration. -Tim

I agree. Needs revisiting. Currently, our customers are asking us
about SOAP, but almost none of them are using our existing SOAP
search interface. At present, I see substantial additional cost in
SOAP compliance and very little benefit.

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek



From owner-atom-syntax@mail.imc.org  Thu Jul 15 13:22: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 NAA05492
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 13:22: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 i6FH030v073679;
	Thu, 15 Jul 2004 10:00:03 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6FH03aA073678;
	Thu, 15 Jul 2004 10:00: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 i6FH02fG073671
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 10:00: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 i6FH0lX4031818;
	Thu, 15 Jul 2004 13:00:47 -0400
Message-ID: <40F6B806.8060307@intertwingly.net>
Date: Thu, 15 Jul 2004 12:59:50 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <Tim.Bray@Sun.COM>
CC: Atomlist <atom-syntax@imc.org>
Subject: Re: PacePutDelete Withdrawn
References: <20040715142548.9823.qmail@web41501.mail.yahoo.com> <40F69CFF.6080802@franklinmint.fm> <1DFD193F-D67D-11D8-A6EC-000A95A51C9E@sun.com>
In-Reply-To: <1DFD193F-D67D-11D8-A6EC-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 Jul 15, 2004, at 8:04 AM, Robert Sayre wrote:
> 
>> I understand we've only recently become an official WG, but we did 
>> beat this to death, once upon a time. The opinions following are all 
>> positive towards SOAP. In my search of the archives, I found two 
>> dissenters who didn't later change their opinion: Russell Beattie and 
>> Tim Bray.
> 
> OK, in that case Paul Hoffman has a problem to solve, because you are 
> asserting that we already have satisfactory rough consensus on the basic 
> structure of the publishing protocol, and I'm unhappy, but then I'm a 
> partisan so I have to take my co-chair's hat off and throw the problem 
> to Paul.

For the record, I also would disagree with such an assertion, but as 
Secretary I also strongly agree with the comment by Randy [1] that 
Robert's comment was originally in response to.

In short, I believe that as long as this particular proposal does not 
have anybody willing to champion it, it should be retired quietly and 
Dismissed Without Prejudice[2].  To be clear, that is quite different 
than "evaluated and rejected".  It simply means that there hasn't yet 
been a proposal brought forward and evaluated by the working group to 
change what currently is in the draft.

Is somebody willing to step forward and say PacePutDelete is 
definitively THE best solution for J2ME MIDP 1.0/2.0, Flash, or any of 
the other platforms which have frowny faces on PutDeleteSupport [3]?

If not, is somebody willing to step forward and do the hard work of 
spec'ing what they think is the right solution for these platforms?

- Sam Ruby

[1] http://www.imc.org/atom-syntax/mail-archive/msg07103.html
[2] http://www.lectlaw.com/def/d062.htm
[3] http://www.intertwingly.net/wiki/pie/PutDeleteSupport



From owner-atom-syntax@mail.imc.org  Thu Jul 15 13:25: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 NAA05899
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 13:25: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 i6FHCZDw075538;
	Thu, 15 Jul 2004 10: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 i6FHCZQl075537;
	Thu, 15 Jul 2004 10:12: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 i6FHCXqT075527
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 10:12: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 i6FHDISw032471;
	Thu, 15 Jul 2004 13:13:19 -0400
Message-ID: <40F6BAF6.90102@intertwingly.net>
Date: Thu, 15 Jul 2004 13:12:22 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <joe.gregorio@gmail.com>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Don't bake discrimination into the Atom core (was Re: Low-hanging
 fruit: multipart/alternative)
References: <A65D9796-D519-11D8-8C42-000A95A51C9E@textuality.com> <14be96d304071317541efca684@mail.gmail.com> <7FBABBD6-D531-11D8-A503-000A95A51C9E@textuality.com> <14be96d304071319181e2bf741@mail.gmail.com> <1393DBDA-D540-11D8-A503-000A95A51C9E@textuality.com> <opsa4zq3fhuvpchu@quark> <14be96d304071410083cc71f90@mail.gmail.com> <3f1451f5040714102129846420@mail.gmail.com> <40F6A443.3060508@w3.org> <3f1451f504071509314ec4f592@mail.gmail.com>
In-Reply-To: <3f1451f504071509314ec4f592@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


Joe Gregorio wrote:
> 
> We have Mark. That won't happen. Trust me.

But didn't Mark recommend that we keep the current wording until there 
is an alternative proposal in place[1]?

"We have Mark, but we don't listen to him".

- Sam Ruby

[1] http://www.imc.org/atom-syntax/mail-archive/msg06991.html




From owner-atom-syntax@mail.imc.org  Thu Jul 15 13:25:31 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05983
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 13:25: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 i6FHHjtg076642;
	Thu, 15 Jul 2004 10:17: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 i6FHHjNY076641;
	Thu, 15 Jul 2004 10:17: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 SMTP id i6FHHhFj076635
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 10:17:44 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d19so601205rnf
        for <atom-syntax@imc.org>; Thu, 15 Jul 2004 10:17:47 -0700 (PDT)
Received: by 10.38.92.23 with SMTP id p23mr118723rnb;
        Thu, 15 Jul 2004 10:17:46 -0700 (PDT)
Message-ID: <14be96d304071510176c27045f@mail.gmail.com>
Date: Thu, 15 Jul 2004 13:17:46 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Graham <dtcd@mac.com>
Subject: Re: Don't bake discrimination into the Atom core
Cc: Atom-Syntax Syntax <atom-syntax@imc.org>
In-Reply-To: <207D9E11-D678-11D8-B24C-000A95DC3D90@mac.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <2E0F8DF6-D610-11D8-B24C-000A95DC3D90@mac.com> <14be96d304071506034fb16820@mail.gmail.com> <207D9E11-D678-11D8-B24C-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 Thu, 15 Jul 2004 12:00:43 -0400, Graham <dtcd@mac.com> wrote:
> On 15 Jul 2004, at 9:03 am, Mark Pilgrim wrote:
> 
> > <summary> "is a Content construct that conveys a short summary,
> > abstract or excerpt of the entry."  This is not the place for
> > accessible alternate content either.
> 
> It may not be "what it's for", but I don't see why accessible content
> is incompatible with it. Furthermore, could you stop advocating for
> five seconds and tell us what it is you want? You're the expert.

1. I want you to stop yelling at me.
2. I want someone to withdraw PaceNukeMultipart.
3. I want language in the spec that recommends that publishers who
link to inaccessible content also link to accessible alternatives.  I
will write up a Pace for this.
4. I want to wait until we decide whether we're going to simplify the
content model before making any further decisions on accessible
alternate content.  If Content constructs can only include (X)HTML or
plain text, that simplifies the accessibility picture enormously.
5. I want to go read http://www.w3.org/TR/xag (thanks Matt) to see
what else I haven't thought of.

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Thu Jul 15 13:33: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 NAA06777
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 13:33: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 i6FHLk1b077272;
	Thu, 15 Jul 2004 10:21:46 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6FHLkOk077271;
	Thu, 15 Jul 2004 10:21:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FHLjix077265
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 10:21:45 -0700 (PDT)
	(envelope-from mint@franklinmint.fm)
Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94])
	by web02.designerslab.net with asmtp (Exim 4.34)
	id 1Bl9vX-0001hJ-BT; Thu, 15 Jul 2004 17:21:47 +0000
Message-ID: <40F6BD27.4060805@franklinmint.fm>
Date: Thu, 15 Jul 2004 13:21:43 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tim Bray <Tim.Bray@Sun.COM>
CC: Atomlist <atom-syntax@imc.org>
Subject: Re: PacePutDelete Withdrawn
References: <20040715142548.9823.qmail@web41501.mail.yahoo.com> <40F69CFF.6080802@franklinmint.fm> <1DFD193F-D67D-11D8-A6EC-000A95A51C9E@sun.com>
In-Reply-To: <1DFD193F-D67D-11D8-A6EC-000A95A51C9E@sun.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - web02.designerslab.net
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - franklinmint.fm
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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:

>
> But, when I read back over the correspondence, it seemed there was a 
> possibility that neither the REST nor SOAP modes of the protocol we're 
> building would be usable by today's smart cellphones that have Java, 
> Brew, or equivalent.  This seems to me violently unsatisfactory, given 
> that there are tens of millions of these things out there, many 
> equipped with cameras, many in the hands of geeky people who would be 
> likely users of Atom, and a frightening number more are being sold 
> every *day*.


That's overstating the situation, I think. What we have been told is 
that certain versions of CLDC and MIDP don't support PUT/DELETE out of 
the box. I've been told that it's possible to subclass whatever class is 
implementing the HTTPConnection interface to allow any method you 
desire. I guess the ideal way to prove this would be a working demo.

Even if it's *impossible* to send a PUT with MIDP, that doesn't mean 
these phones can't use Atom. Developers can still use the underlying 
platform (e.g. Series60). In fact, I gather it's often necessary to do 
so to access some phone features like wallpaper, etc. Here is an 
already-deployed Series60 app (presumably written in C++) that uses the 
Atom Publishing Protocol:

http://www.futurice.fi/products.html

Robert Sayre



From owner-atom-syntax@mail.imc.org  Thu Jul 15 13:54: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 NAA08857
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 13: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 i6FHgZbe080630;
	Thu, 15 Jul 2004 10:42: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 i6FHgZEf080629;
	Thu, 15 Jul 2004 10:42:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from beta.verity.com (beta.verity.com [192.187.143.12])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FHgYe4080620
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 10:42: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 KAA00166
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 10:42:33 -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 KAA11565
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 10:42:32 -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); Thu, 15 Jul 2004 10:42:31 -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 <0I0W0092OMIUZS@shazam.verity.com> for atom-syntax@imc.org; Thu,
 15 Jul 2004 10:42:31 -0700 (PDT)
Date: Thu, 15 Jul 2004 10:42:31 -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: Unsynchronized clocks vs. author calendars
To: atom-syntax@imc.org
Message-id: <291D019B6DC48D73B1CD44AE@[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
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 timestamp discussions are confusing two different things,
and calling them both "subjective" timestamps.

Timestamps from an unknown timezone are not subjective. They are
measurements from a clock with a possibly large synchronization
error to UTC (+/-12 hours). Timestamps from one clock can be
ordered, but they cannot always be ordered against other clocks.
If two timestamps are more than 24 hours apart, they can be ordered.

In the LiveJournal case, unsynchronized timestamps can be used to
order entries from a single blog, but might not work for entries
from different blogs.

Author calendars are quite different. The timestamp can usually
be mapped to a UTC time, but the calendar is different. Some example
calendars are Gregorian, Hebrew, stardate, and Mars Rover Spirit
Mission Sol number (thanks to David Chase for that one).

Timestamps with an author calendar might be objective or subjective.
The date might be synchronized to UTC but expressed in a non-Gregorian
calendar.

Atom readers will not have all possible calendars for converting UTC
back into the preferred calendar. Those dates really must be formatted
by the author or the author's tools.

Atom doesn't have to support all kinds of timestamps, but we shouldn't
confuse them.

Hmm, I bet we could use timestamps of non-LiveJournal entries linked
to LiveJournal blogs to discover the synchronization offsets. Causality
and all that. Probably too much work, though.

NOTE: Please respond only to the list. I'm getting plenty of mail
without two copies of responses.

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Thu Jul 15 14:07: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 OAA09664
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 14:07: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 i6FHuW44083425;
	Thu, 15 Jul 2004 10:56: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 i6FHuWTo083424;
	Thu, 15 Jul 2004 10:56: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 (mproxy.gmail.com [216.239.56.244])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6FHuWgc083418
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 10:56:32 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so1505578cwc
        for <atom-syntax@imc.org>; Thu, 15 Jul 2004 10:56:36 -0700 (PDT)
Received: by 10.11.99.40 with SMTP id w40mr225858cwb;
        Thu, 15 Jul 2004 10:56:36 -0700 (PDT)
Message-ID: <3f1451f5040715105677a25d28@mail.gmail.com>
Date: Thu, 15 Jul 2004 13:56:36 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Tim Bray <tim.bray@sun.com>
Subject: Re: PacePutDelete Withdrawn
Cc: Atomlist <atom-syntax@imc.org>
In-Reply-To: <1DFD193F-D67D-11D8-A6EC-000A95A51C9E@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <20040715142548.9823.qmail@web41501.mail.yahoo.com>
 <40F69CFF.6080802@franklinmint.fm> <1DFD193F-D67D-11D8-A6EC-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 Thu, 15 Jul 2004 09:36:26 -0700, Tim Bray <tim.bray@sun.com> wrote:
> Until then [speaking once again with my co-chair's hat off] I dissent
> violently to any action by this WG which might potentially
> disenfranchise the tens of millions of users of smart phones.  I don't
> *think* this should be a controversial position.  -Tim

+1 with a caveat.

I don't think we should disenfranchise smart phones.
The caveat is that we do due dilligence to show that
we aren't twisting ourselves in knots over a small
percentage of platforms that have buggy implementations
that could be fixed with a software upgrade.

In general we need to come to some sort of decision 
on where to draw the line on asking for full
support of HTTP. As Sam pointed out, looking at the list of 
frowny faces on [1] we see some clients that have only crude
HTTP implementations. Do we not publish a protocol unless it
can be implemented on 100% of the client platforms listed?
I don't believe that is reasonable and I'd note that 
WebDAV would still be waiting to ship today
if that was the requirement.

The one bright side I would like to point out is that there 
are no frowny faces on any of the server-side platforms.

   Thanks,
   -joe

[1] http://www.intertwingly.net/wiki/pie/PutDeleteSupport



From owner-atom-syntax@mail.imc.org  Thu Jul 15 14:08: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 OAA09750
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 14:08:23 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FHxKEc084244;
	Thu, 15 Jul 2004 10: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 i6FHxKV6084243;
	Thu, 15 Jul 2004 10:59:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from w01.bloglines.com (w01.bloglines.com [216.148.212.183])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6FHxKbG084225
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 10:59:20 -0700 (PDT)
	(envelope-from kwark.1511609@bloglines.com)
Received: (qmail 23069 invoked by uid 99); 15 Jul 2004 17:59:19 -0000
Message-ID: <1089914359.550622863.23067.sendItem@bloglines.com>
Date: 15 Jul 2004 17:59:19 -0000
From: kwark.1511609@bloglines.com
To: mint@franklinmint.fm
CC: atom-syntax@imc.org
Subject: Re: PacePutDelete Withdrawn
MIME-Version: 1.0
Content-Type: text/plain
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


 
> That's overstating the situation, I think. What we have been told is

> that certain versions of CLDC and MIDP don't support PUT/DELETE out of

> the box. I've been told that it's possible to subclass whatever class
is 
> implementing the HTTPConnection interface to allow any method you 

> desire. I guess the ideal way to prove this would be a working demo.
>


I guess you have been told wrong.

MIDP1.0/2.0 only requires support
for GET, HEAD and POST methods. It might be that some implementations also
support other methods, but f.e. MIDP on series40/60 does not.

The workaround
you suggest is simply not possible for multiple reasons. PutDeleteSupport
also still mentions a non-workable workaround. Maybe, that's were you got
the idea from?

> Even if it's *impossible* to send a PUT with MIDP, that
doesn't mean 
> these phones can't use Atom. Developers can still use the
underlying 
> platform (e.g. Series60). 

The largest contigent of MIDP
enabled phones, f.e. Nokia's mass market series40, don't have an equivalent
open C++ development platform. They only support MIDlets.

- Peter




From owner-atom-syntax@mail.imc.org  Thu Jul 15 14:20:41 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10678
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 14:20:41 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FICwwB086495;
	Thu, 15 Jul 2004 11:12: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 i6FICwmj086494;
	Thu, 15 Jul 2004 11:12: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 i6FICvjT086486
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 11:12:58 -0700 (PDT)
	(envelope-from davep@dpawson.co.uk)
Received: (qmail 25975 invoked from network); 15 Jul 2004 18:33:24 -0000
Received: from dpawson.gotadsl.co.uk (HELO ?192.168.2.6?) (davep@dpawson.co.uk@81.6.251.105)
  by 0 with SMTP; 15 Jul 2004 18:33:24 -0000
Subject: Re: Don't bake discrimination into the Atom core (was Re:
	Low-hanging fruit: multipart/alternative)
From: Dave Pawson <davep@dpawson.co.uk>
Reply-To: davep@dpawson.co.uk
To: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <5C39B3EC-D5BF-11D8-AA19-000A95BD86C0@mnot.net>
References: <A65D9796-D519-11D8-8C42-000A95A51C9E@textuality.com>
	 <14be96d304071317541efca684@mail.gmail.com>
	 <7FBABBD6-D531-11D8-A503-000A95A51C9E@textuality.com>
	 <14be96d304071319181e2bf741@mail.gmail.com>
	 <1393DBDA-D540-11D8-A503-000A95A51C9E@textuality.com>
	 <opsa4zq3fhuvpchu@quark> <14be96d304071410083cc71f90@mail.gmail.com>
	 <50434192-D5BD-11D8-A6EC-000A95A51C9E@textuality.com>
	 <5C39B3EC-D5BF-11D8-AA19-000A95BD86C0@mnot.net>
Content-Type: text/plain
Message-Id: <1089915155.2692.30.camel@homer>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) 
Date: Thu, 15 Jul 2004 19:12:36 +0100
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 Wed, 2004-07-14 at 18:58, Mark Nottingham wrote:
> I'm confused. Mark says that the current design allows inaccessible 
> content, and therefore we shouldn't get rid of the current design?
> 
> What am I missing here?
> 
> Also, I'm not sure that allowing inaccessible content (i.e., images) in 
> Atom is the same as "baking discrimination into the core"; by that 
> logic, discrimination is baked into HTML.
Which is no reason to continue with a weak / inaccessible design IMHO.

> 
> I very much agree that we should take positive steps to accommodate 
> accessibility.

+1
Lessons from docbook perhaps?
<mediaobject>
  <mediaOne ..
  <alt 1 ..
  <alt 2 ..
</mediaobject>

I.e. present as a group with alternatives in other format.

regards DaveP  


-- 
Regards DaveP.
XSLT&Docbook  FAQ
http://www.dpawson.co.uk/xsl




From owner-atom-syntax@mail.imc.org  Thu Jul 15 14:26: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 OAA11036
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 14:26: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 i6FIGSLK087029;
	Thu, 15 Jul 2004 11:16: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 i6FIGSpr087028;
	Thu, 15 Jul 2004 11:16:28 -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 i6FIGSfm087008
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 11:16:28 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040715181624.90235.qmail@web41210.mail.yahoo.com>
Received: from [67.160.45.11] by web41210.mail.yahoo.com via HTTP; Thu, 15 Jul 2004 11:16:24 PDT
Date: Thu, 15 Jul 2004 11:16:24 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Unsynchronized clocks vs. author calendars
To: Walter Underwood <wunder@verity.com>, atom-syntax@imc.org
In-Reply-To: <291D019B6DC48D73B1CD44AE@[192.168.168.164]>
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>


I completely could not make head or tails of your
argument. Are you claiming that that Atom feeds will
have to deal with calendars other than the Gregorian
calendar? Since when? Every discussion I've seen has
assumed ISO 8601 commpliant dates. 

--- Walter Underwood <wunder@verity.com> wrote:
> 
> The timestamp discussions are confusing two
> different things,
> and calling them both "subjective" timestamps.
> 
> Timestamps from an unknown timezone are not
> subjective. They are
> measurements from a clock with a possibly large
> synchronization
> error to UTC (+/-12 hours). Timestamps from one
> clock can be
> ordered, but they cannot always be ordered against
> other clocks.
> If two timestamps are more than 24 hours apart, they
> can be ordered.
> 
> In the LiveJournal case, unsynchronized timestamps
> can be used to
> order entries from a single blog, but might not work
> for entries
> from different blogs.
> 
> Author calendars are quite different. The timestamp
> can usually
> be mapped to a UTC time, but the calendar is
> different. Some example
> calendars are Gregorian, Hebrew, stardate, and Mars
> Rover Spirit
> Mission Sol number (thanks to David Chase for that
> one).
> 
> Timestamps with an author calendar might be
> objective or subjective.
> The date might be synchronized to UTC but expressed
> in a non-Gregorian
> calendar.
> 
> Atom readers will not have all possible calendars
> for converting UTC
> back into the preferred calendar. Those dates really
> must be formatted
> by the author or the author's tools.
> 
> Atom doesn't have to support all kinds of
> timestamps, but we shouldn't
> confuse them.
> 
> Hmm, I bet we could use timestamps of
> non-LiveJournal entries linked
> to LiveJournal blogs to discover the synchronization
> offsets. Causality
> and all that. Probably too much work, though.
> 
> NOTE: Please respond only to the list. I'm getting
> plenty of mail
> without two copies of responses.
> 
> wunder
> --
> Walter Underwood
> Principal Architect, Verity
> 
> 


=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


	
		
__________________________________
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 Jul 15 14:30:39 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11209
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 14:30:38 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FINKFV088109;
	Thu, 15 Jul 2004 11:23: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 i6FINKqF088108;
	Thu, 15 Jul 2004 11:23: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 i6FINJah088094
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 11:23: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 i6FILE53002029
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 12:21:14 -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 <0I0W002FJOEY1U@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Thu, 15 Jul 2004 12:23: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 <0I0W00CPROEYE1@mail.sun.net> for atom-syntax@imc.org; Thu,
 15 Jul 2004 12:23:22 -0600 (MDT)
Date: Thu, 15 Jul 2004 11:23:26 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PacePutDelete Withdrawn
In-reply-to: <40F6BD27.4060805@franklinmint.fm>
To: mint@franklinmint.fm
Cc: Atomlist <atom-syntax@imc.org>
Message-id: <100CAC92-D68C-11D8-A6EC-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: <20040715142548.9823.qmail@web41501.mail.yahoo.com>
 <40F69CFF.6080802@franklinmint.fm>
 <1DFD193F-D67D-11D8-A6EC-000A95A51C9E@sun.com>
 <40F6BD27.4060805@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 Jul 15, 2004, at 10:21 AM, Robert Sayre wrote:

> That's overstating the situation, I think. What we have been told is 
> that certain versions of CLDC and MIDP don't support PUT/DELETE out of 
> the box. I've been told that it's possible to subclass whatever class 
> is implementing the HTTPConnection interface to allow any method you 
> desire. I guess the ideal way to prove this would be a working demo.

I hope you're right, but "I've been told" isn't good enough for me; I 
want to get a real expert in the room here to figure out what the right 
thing to do is.  Blogging from a smart/picture phone seems so obvious, 
if we tried to ship something that wasn't straightforward for those 
people we would be (justly) regarded as clueless, I suspect. -Tim



From owner-atom-syntax@mail.imc.org  Thu Jul 15 14:33: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 OAA11405
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 14:33: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 i6FIINFV087295;
	Thu, 15 Jul 2004 11:18: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 i6FIINBt087294;
	Thu, 15 Jul 2004 11:18:23 -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 i6FIIMtc087288
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 11:18:22 -0700 (PDT)
	(envelope-from davep@dpawson.co.uk)
Received: (qmail 28563 invoked from network); 15 Jul 2004 18:38:49 -0000
Received: from dpawson.gotadsl.co.uk (HELO ?192.168.2.6?) (davep@dpawson.co.uk@81.6.251.105)
  by 0 with SMTP; 15 Jul 2004 18:38:49 -0000
Subject: Re: Don't bake discrimination into the Atom core (was Re:
	Low-hanging fruit: multipart/alternative)
From: Dave Pawson <davep@dpawson.co.uk>
Reply-To: davep@dpawson.co.uk
To: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <20040714184022.GU3805@homer.w3.org>
References: <A65D9796-D519-11D8-8C42-000A95A51C9E@textuality.com>
	 <14be96d304071317541efca684@mail.gmail.com>
	 <7FBABBD6-D531-11D8-A503-000A95A51C9E@textuality.com>
	 <14be96d304071319181e2bf741@mail.gmail.com>
	 <1393DBDA-D540-11D8-A503-000A95A51C9E@textuality.com>
	 <opsa4zq3fhuvpchu@quark> <14be96d304071410083cc71f90@mail.gmail.com>
	 <50434192-D5BD-11D8-A6EC-000A95A51C9E@textuality.com>
	 <5C39B3EC-D5BF-11D8-AA19-000A95BD86C0@mnot.net>
	 <20040714184022.GU3805@homer.w3.org>
Content-Type: text/plain
Message-Id: <1089915475.2692.33.camel@homer>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) 
Date: Thu, 15 Jul 2004 19:17:55 +0100
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 Wed, 2004-07-14 at 19:40, Dan Brickley wrote:

> Rather than try to stop folk including (by value or reference; principle
> is the same) audio and image content in their feeds, I believe our
> energies would be better spent encouraging them to associate extra info
> with those items. I'm well aware that people don't like to take the time
> to add metadata, but also that folk do like their photos to be findable
> again and that extension namespaces can play a role in supporting that. 

Nice bonus with this approach is that the author can add the personal 
remark, name the people in the image,
tell us what kit was used for it etc. 


-- 
Regards DaveP.
XSLT&Docbook  FAQ
http://www.dpawson.co.uk/xsl




From owner-atom-syntax@mail.imc.org  Thu Jul 15 14:35:13 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11567
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 14:35: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 i6FIQ7us088470;
	Thu, 15 Jul 2004 11:26: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 i6FIQ7K4088469;
	Thu, 15 Jul 2004 11:26: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 i6FIQ6vp088463
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 11:26:07 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6FIQAil029783
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 12:26: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 <0I0W00MPWOJM98@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Thu, 15 Jul 2004 12:26:10 -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 <0I0W00CLGOJLE4@mail.sun.net> for atom-syntax@imc.org; Thu,
 15 Jul 2004 12:26:10 -0600 (MDT)
Date: Thu, 15 Jul 2004 11:26:14 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PacePutDelete Withdrawn
In-reply-to: <3f1451f5040715105677a25d28@mail.gmail.com>
To: Joe Gregorio <joe.gregorio@gmail.com>
Cc: Atomlist <atom-syntax@imc.org>
Message-id: <7480D32A-D68C-11D8-A6EC-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: <20040715142548.9823.qmail@web41501.mail.yahoo.com>
 <40F69CFF.6080802@franklinmint.fm>
 <1DFD193F-D67D-11D8-A6EC-000A95A51C9E@sun.com>
 <3f1451f5040715105677a25d28@mail.gmail.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 Jul 15, 2004, at 10:56 AM, Joe Gregorio wrote:

> In general we need to come to some sort of decision
> on where to draw the line on asking for full
> support of HTTP. As Sam pointed out, looking at the list of
> frowny faces on [1] we see some clients that have only crude
> HTTP implementations. Do we not publish a protocol unless it
> can be implemented on 100% of the client platforms listed?

Good point, but at the recent Java One I saw ordinary 
you-can-buy-em-today cellphones playing what looked like real 
sophisticated games, and back in 2003 Murata showed me a RelaxNG 
validator running on one, so it seems likely that we should be able to 
make Atom accessible to them.   -Tim



From owner-atom-syntax@mail.imc.org  Thu Jul 15 14:38: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 OAA11960
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 14:38: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 i6FINIVD088092;
	Thu, 15 Jul 2004 11:23: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 i6FINInd088091;
	Thu, 15 Jul 2004 11:23:18 -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 i6FINH1x088081
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 11:23:17 -0700 (PDT)
	(envelope-from davep@dpawson.co.uk)
Received: (qmail 31019 invoked from network); 15 Jul 2004 18:43:44 -0000
Received: from dpawson.gotadsl.co.uk (HELO ?192.168.2.6?) (davep@dpawson.co.uk@81.6.251.105)
  by 0 with SMTP; 15 Jul 2004 18:43:44 -0000
Subject: Re: a methodical approach to defining what date  elements we need
From: Dave Pawson <davep@dpawson.co.uk>
Reply-To: davep@dpawson.co.uk
To: =?ISO-8859-1?Q?Asbj=F8rn?= Ulsberg <asbjorn@tigerstaden.no>
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <opsa5bya0ruvpchu@quark>
References: <14B72756-D419-11D8-9D0B-003065EA6144@geckotribe.com>
	 <40F2C2CD.9020307@intertwingly.net>
	 <47071860-D42A-11D8-82B1-000A95DC3D90@mac.com>
	 <opsa1nlh1u6dxgxk@mail.online.no>
	 <6C2098C54ED33AE163D3E2F5@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
	 <opsa3eddg8uvpchu@quark> <1089832992.2849.16.camel@homer>
	 <opsa5bya0ruvpchu@quark>
Content-Type: text/plain; charset=
Message-Id: <1089915775.2692.38.camel@homer>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) 
Date: Thu, 15 Jul 2004 19:22:56 +0100
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


On Wed, 2004-07-14 at 22:14, AsbjÞrn Ulsberg wrote:
> On Wed, 14 Jul 2004 20:23:12 +0100, Dave Pawson <davep@dpawson.co.uk>  
> wrote:
> 
> > And what about people generating atom content?
> 
> Could you elaborate on «generating atom content»? Do you mean by hand?
Yes. Perhaps in an editor.
>  In  
> how many cases do you think that will happen,
No idea. tens of K's?

>  and nonetheless, don't you  
> think people that does this is able to read the specification to find out  
> what the different dates are to be used for?
  My point related to date formats, and being too complex, i.e. to the
second, rather than date+time.

Yes. I'm saying that the 'tools' to generate such a 'full' date may
not be to hand, which makes it harder to produce valid content.
If I look at the computer clock, and can type the date/time, I'll maybe
do it. If its hassle, its unlikely to be done at all.



Regards DaveP.
XSLT&Docbook  FAQ
http://www.dpawson.co.uk/xsl




From owner-atom-syntax@mail.imc.org  Thu Jul 15 14:39: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 OAA12075
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 14:39: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 i6FINlGJ088183;
	Thu, 15 Jul 2004 11:23: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 i6FINljm088182;
	Thu, 15 Jul 2004 11:23: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 i6FINk36088175
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 11:23:46 -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 i6FILf53002361
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 12:21:41 -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 <0I0W00MZHOFQ98@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Thu, 15 Jul 2004 12:23:50 -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 <0I0W00CPROEYE1@mail.sun.net> for atom-syntax@imc.org; Thu,
 15 Jul 2004 12:23:50 -0600 (MDT)
Date: Thu, 15 Jul 2004 11:23:56 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PacePutDelete Withdrawn
In-reply-to: <40F6B806.8060307@intertwingly.net>
To: Sam Ruby <rubys@intertwingly.net>
Cc: Atomlist <atom-syntax@imc.org>
Message-id: <2217DD02-D68C-11D8-A6EC-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: <20040715142548.9823.qmail@web41501.mail.yahoo.com>
 <40F69CFF.6080802@franklinmint.fm>
 <1DFD193F-D67D-11D8-A6EC-000A95A51C9E@sun.com>
 <40F6B806.8060307@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 Jul 15, 2004, at 9:59 AM, Sam Ruby wrote:

> In short, I believe that as long as this particular proposal does not 
> have anybody willing to champion it, it should be retired quietly and 
> Dismissed Without Prejudice[2].  To be clear, that is quite different 
> than "evaluated and rejected".  It simply means that there hasn't yet 
> been a proposal brought forward and evaluated by the working group to 
> change what currently is in the draft.

On that basis, I'm OK with that. -Tim



From owner-atom-syntax@mail.imc.org  Thu Jul 15 14:48:33 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12898
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 14:48: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 i6FIc4dR090556;
	Thu, 15 Jul 2004 11: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 i6FIc49o090555;
	Thu, 15 Jul 2004 11:38:04 -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 i6FIc2Y3090540
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 11:38:03 -0700 (PDT)
	(envelope-from davep@dpawson.co.uk)
Received: (qmail 5195 invoked from network); 15 Jul 2004 18:58:29 -0000
Received: from dpawson.gotadsl.co.uk (HELO ?192.168.2.6?) (davep@dpawson.co.uk@81.6.251.105)
  by 0 with SMTP; 15 Jul 2004 18:58:29 -0000
Subject: Re: Don't bake discrimination into the Atom core
From: Dave Pawson <davep@dpawson.co.uk>
Reply-To: davep@dpawson.co.uk
To: Graham <dtcd@mac.com>
Cc: Atom-Syntax Syntax <atom-syntax@imc.org>
In-Reply-To: <207D9E11-D678-11D8-B24C-000A95DC3D90@mac.com>
References: <2E0F8DF6-D610-11D8-B24C-000A95DC3D90@mac.com>
	 <14be96d304071506034fb16820@mail.gmail.com>
	 <207D9E11-D678-11D8-B24C-000A95DC3D90@mac.com>
Content-Type: text/plain
Message-Id: <1089916661.2692.45.camel@homer>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) 
Date: Thu, 15 Jul 2004 19:37:41 +0100
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 Thu, 2004-07-15 at 17:00, Graham wrote:
> On 15 Jul 2004, at 9:03 am, Mark Pilgrim wrote:
> 
> > <summary> "is a Content construct that conveys a short summary,
> > abstract or excerpt of the entry."  This is not the place for
> > accessible alternate content either.
> 
> It may not be "what it's for", but I don't see why accessible content 
> is incompatible with it.

A little bit high horse, but if it makes the point.
Assume you lose one of your relevant senses.
  You have the construct you proposed.
  Two channels are offered,
  A 2 minute video of whatever or
  A two line <summary>.
  I don't see any equality there?

  Just on semantic grounds, how might a 'summary' equate in terms of
information transmission to that video?

  If an author wants to publish an image, a video, an audio clip,
   let them offer equivalents.
   <mediaobject>
     <video src=' />
     <text>
        structured text alternative
     <whatever you feel like offering/>
   </mediaobject>

Not advocating that syntax, but to me that reads like viable equal
offerings. 






Regards DaveP.
XSLT&Docbook  FAQ
http://www.dpawson.co.uk/xsl




From owner-atom-syntax@mail.imc.org  Thu Jul 15 15:17: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 PAA15751
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 15:17: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 i6FJ6vGU095433;
	Thu, 15 Jul 2004 12:06: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 i6FJ6vvW095432;
	Thu, 15 Jul 2004 12:06: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 i6FJ6vLX095425
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 12:06:57 -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 i6FJ4q53028778
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 13:04: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 <0I0W003LZQFOWW@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Thu, 15 Jul 2004 13:07:00 -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 <0I0W003SNQFNL2@mail.sun.net> for atom-syntax@imc.org; Thu,
 15 Jul 2004 13:07:00 -0600 (MDT)
Date: Thu, 15 Jul 2004 12:07:03 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceEntryIdRequired
In-reply-to: <BD1B83CF.1FA92%eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <285FBCEB-D692-11D8-A6EC-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: <BD1B83CF.1FA92%eric.scheid@ironclad.net.au>
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 Jul 14, 2004, at 7:43 AM, Eric Scheid wrote:

>> If the same entry is syndicated in two atom:feeds published by the 
>> same
>> entity, the entry's atom:id MUST be the same in both feeds. 
>> atom:entry MUST
>> contain an atom:id element, but MUST NOT contain more than one. The 
>> content of
>> this element, when present, MUST be a URI.
>>
>
> (1) clarification please: if the same entry is syndicated in other
> atom:feeds published by NOT the same entity ... does the atom:id 
> remain the
> same? I would hope so ... can we reword to this?
>
>     If the same entry is syndicated in more than one atom:feed
>     the entry's atom:id MUST be the same in all those atom:feeds.
>
> (2) editorial: strike "when present" from last sentence, since it will
> always be present since it is now required ;-)
>
> (3) detour: would it be better if <id> was instead @id on <entry>?

+1 on all three suggestions, but #3 may be worthy of some more debate. 
-Tim



From owner-atom-syntax@mail.imc.org  Thu Jul 15 15:41: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 PAA17950
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 15:41: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 i6FJXpTL000679;
	Thu, 15 Jul 2004 12:33: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 i6FJXpVt000678;
	Thu, 15 Jul 2004 12:33:51 -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 i6FJXoq9000590
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 12:33:50 -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 i6FJXm53002324
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 14:33:48 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6FJXlQa002320;
	Thu, 15 Jul 2004 14:33:47 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Don't bake discrimination into the Atom core (was Re: Low-hanging fruit: multipart/alternative)
References: <A65D9796-D519-11D8-8C42-000A95A51C9E@textuality.com>
	<14be96d304071317541efca684@mail.gmail.com>
	<7FBABBD6-D531-11D8-A503-000A95A51C9E@textuality.com>
	<14be96d304071319181e2bf741@mail.gmail.com>
	<1393DBDA-D540-11D8-A503-000A95A51C9E@textuality.com>
	<opsa4zq3fhuvpchu@quark> <14be96d304071410083cc71f90@mail.gmail.com>
	<50434192-D5BD-11D8-A6EC-000A95A51C9E@textuality.com>
	<5C39B3EC-D5BF-11D8-AA19-000A95BD86C0@mnot.net>
	<20040714184022.GU3805@homer.w3.org> <1089915475.2692.33.camel@homer>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 15 Jul 2004 14:33:46 -0500
In-Reply-To: <1089915475.2692.33.camel@homer>
Message-ID: <m38ydljc9x.fsf@bitsko.slc.ut.us>
Lines: 39
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


Dave Pawson <davep@dpawson.co.uk> writes:

> On Wed, 2004-07-14 at 19:40, Dan Brickley wrote:
> 
> > Rather than try to stop folk including (by value or reference;
> > principle is the same) audio and image content in their feeds, I
> > believe our energies would be better spent encouraging them to
> > associate extra info with those items. I'm well aware that people
> > don't like to take the time to add metadata, but also that folk do
> > like their photos to be findable again and that extension
> > namespaces can play a role in supporting that.
> 
> Nice bonus with this approach is that the author can add the
> personal remark, name the people in the image, tell us what kit was
> used for it etc.

Note that there is some overlap here between "metadata about a
resource" and "what is an entry".  An entry is a resource that is
formally published (the thing that is added to the front page or feed)
whereas metadata is attached to resources.

The overlap occurs because often one can be used alongside or in place
of the other.  For example, one might upload a photo with its
metadata, and then later come back an make an entry with that photo as
the body content.  Naturally, the properties for the entry would
likely come mostly from the photo's metadata, but there could be lots
of other user supplied content for the entry that isn't metadata for
the photo.

PaceExtendedResourcePosting uses a technique similar to the earlier
PaceDontSyndicate proposal, of providing an alternate usage of <entry>
for attaching metadata to a resource, but without making that resource
a published entry in its own right.  My preference over that would be
to use the atom:resource element from PaceResource (make clear that
this is a resource metadata container resource, not an entry
resource).  My preference over *that* would be to use WebDAV
properties :-).

  -- Ken



From owner-atom-syntax@mail.imc.org  Thu Jul 15 15:54: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 PAA19399
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 15:54: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 i6FJib6j002330;
	Thu, 15 Jul 2004 12: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 i6FJibl9002329;
	Thu, 15 Jul 2004 12:44: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 i6FJiZWL002314
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 12:44:36 -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 i6FJiY53002502
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 14:44:34 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6FJiXRX002498;
	Thu, 15 Jul 2004 14:44:33 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom-Syntax Syntax <atom-syntax@imc.org>
Subject: PaceSimpleContentType updated (was Re: Don't bake discrimination into the Atom core)
References: <2E0F8DF6-D610-11D8-B24C-000A95DC3D90@mac.com>
	<14be96d304071506034fb16820@mail.gmail.com>
	<207D9E11-D678-11D8-B24C-000A95DC3D90@mac.com>
	<1089916661.2692.45.camel@homer>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 15 Jul 2004 14:44:33 -0500
In-Reply-To: <1089916661.2692.45.camel@homer>
Message-ID: <m34qo9jbry.fsf_-_@bitsko.slc.ut.us>
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: <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've updated PaceSimpleContentType.  A summary of what this Pace now
covers:

 * constrains the general use of the Content construct to inline XML
   text (markup or characters), as used for <name>, <title>,
   <tagline>, <copyright>, <info>, and <summary>.

 * includes spec text for the known profiles of inline representations

 * removes @type from the general Content construct, and removes
   base64 as @mode.

 * allows <content> to have a @src and @type, and only allows one
   <content> as the content with the most faithful representation of
   the content (MIME terminology there)

 * <content> can only be inline or @src, because

 * added a <content-alternate> element for alternate full body
   contents, it shares the element content model of atom:content.


Things I considered when updating this:

 * atom:summary might be a summary representation (thumbnail, short
   clip) of atom:content, and should also allow @src and @type, which
   means,

 * a corresponding atom:summary-alternate element, which would lead to,

 * possibly generalizing the Content-by-reference construct, and

 * moving "alternate" in as a type of attribute (not @rel!) of the now
   generalized Content-by-reference construct.

Thoughts?

  -- Ken



From owner-atom-syntax@mail.imc.org  Thu Jul 15 15:58: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 PAA19892
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 15:58: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 i6FJpWb5003463;
	Thu, 15 Jul 2004 12:51: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 i6FJpWm7003462;
	Thu, 15 Jul 2004 12:51:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FJpWRQ003443
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 12:51:32 -0700 (PDT)
	(envelope-from gstein@google.com)
Received: from computee.corp.google.com (computee.corp.google.com [10.32.46.2])
	by 216-239-45-4.google.com (8.12.11/8.12.9) with ESMTP id i6FJpT8h018960
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 15 Jul 2004 12:51:29 -0700
Received: from gstein by computee.corp.google.com with local (Exim 4.14 #4)
	id 1BlCGO-0001N2-4o by authid <gstein>; Thu, 15 Jul 2004 12:51:28 -0700
Date: Thu, 15 Jul 2004 12:51:28 -0700
From: Greg Stein <gstein@google.com>
To: Tim Bray <Tim.Bray@Sun.COM>
Cc: atom-syntax@imc.org
Subject: Apache mime.types (was: Thought experiment)
Message-ID: <20040715195128.GA5149@google.com>
References: <5E91DE20-D61C-11D8-A6EC-000A95A51C9E@sun.com> <20040715105633.GB17690@google.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040715105633.GB17690@google.com>
User-Agent: Mutt/1.4.1i
X-URL: http://www.lyra.org/greg/
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


On Thu, Jul 15, 2004 at 03:56:33AM -0700, Greg Stein wrote:
> On Wed, Jul 14, 2004 at 10:03:54PM -0700, Tim Bray wrote:
> >...
> > <sidenote>People of Earth to Greg Stein: could we change the Apache 
> > default media type for ".atom" to "application/atom+xml" ASAP, like 
> > right now, as a gesture in the right direction?</sidenote>
> 
> The mime.types that is shipped with Apache derives its information from
> two places: the IANA, and (apparently) some standardized W3C types. I
> don't know where Roy got the W3C list to incorporate, but will follow up
> (and report back here).

The W3C types were done ad-hoc since the W3C folks were not good about
registering their types with the IANA. They also don't have any kind
of single registry, so Roy just did a bunch of searches. Apparently,
the W3C has revamped their registration process to lose their internal
roadblocks, but that doesn't really matter here.

>...
> Of course, that is rather painful if the Apache file waits for the RFC --
> there would be a huge lag between when the type is settled in the spec
> process, when you really want to have it pushed out to users, and when it
> is finally published by the IANA. IOW, the pragmatic choice is for Apache
> to be optimistic/pragmatic: assume success and jam that in there today.
> Let me chat with Roy; I'm going to assume we can simply refer to section 8
> of our I-D as "sufficient", then remove the special quotation once the
> IANA publishes.

Yup. Roy had the same thoughts: if a MIME type appears in an I-D and
it contains an IANA registration section (like our sectoin 8), then
Apache should go ahead and put it into the mime.types file for our
distributions.

I've gone ahead and done this: the application/atom+xml (for .atom)
type will appear in our next releases (Apache 1.3.32 and Apache
2.0.51), whenever those come out.

Cheers,
-g



From owner-atom-syntax@mail.imc.org  Thu Jul 15 16:13:07 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21469
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 16:13:07 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FK5avr005921;
	Thu, 15 Jul 2004 13: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 i6FK5a2g005920;
	Thu, 15 Jul 2004 13:05:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-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 i6FK5ZDU005914
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 13:05:35 -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 i6FK3V53003037
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 14:03:31 -0600 (MDT)
Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0I0W0022ET5F1U@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Thu, 15 Jul 2004 14:05:40 -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 <0I0W00388T5EL5@mail.sun.net> for atom-syntax@imc.org; Thu,
 15 Jul 2004 14:05:39 -0600 (MDT)
Date: Thu, 15 Jul 2004 13:05:43 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Apache mime.types (was: Thought experiment)
In-reply-to: <20040715195128.GA5149@google.com>
To: Greg Stein <gstein@google.com>
Cc: atom-syntax@imc.org
Message-id: <5A2A046A-D69A-11D8-A6EC-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: <5E91DE20-D61C-11D8-A6EC-000A95A51C9E@sun.com>
 <20040715105633.GB17690@google.com> <20040715195128.GA5149@google.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 Jul 15, 2004, at 12:51 PM, Greg Stein wrote:

> The W3C types were done ad-hoc since the W3C folks were not good about
> registering their types with the IANA. They also don't have any kind
> of single registry, so Roy just did a bunch of searches. Apparently,
> the W3C has revamped their registration process to lose their internal
> roadblocks, but that doesn't really matter here.

Heh, and in the halls at the W3C you hear griping at how incredibly 
slow, painful, and non-deterministic it is to register a type.  Last 
time Roy was in the room he got mad and said "no, you're just not 
trying."  I have no idea who's right but you're correct that 
registration of W3C-generated data types has been *very* sluggish.

> I've gone ahead and done this: the application/atom+xml (for .atom)
> type will appear in our next releases (Apache 1.3.32 and Apache
> 2.0.51), whenever those come out.

Thanks on behalf of the community -Tim



From owner-atom-syntax@mail.imc.org  Thu Jul 15 17: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 RAA01789
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 17: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 i6FLP2sh018720;
	Thu, 15 Jul 2004 14:25: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 i6FLP2Du018719;
	Thu, 15 Jul 2004 14:25:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf13.cluster1.charter.net (mxsf13.cluster1.charter.net [209.225.28.213])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FLP0Ts018680
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 14:25:01 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip16.cluster1.charter.net (mxip16a.cluster1.charter.net [209.225.28.146])
	by mxsf13.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6FLTBd1023587
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 17:29:12 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip16.cluster1.charter.net with ESMTP; 15 Jul 2004 17:24:57 -0400
X-Ironport-AV: i="3.81R,171,1083556800"; 
   d="scan'208"; a="119355822:sNHT14774772"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BlDiP-00045U-00
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 17:24:29 -0400
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceEntryIdRequired
References: <BD1B83CF.1FA92%eric.scheid@ironclad.net.au>
	<285FBCEB-D692-11D8-A6EC-000A95A51C9E@sun.com>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Thu, 15 Jul 2004 17:24:19 -0400
In-Reply-To: <285FBCEB-D692-11D8-A6EC-000A95A51C9E@sun.com> (Tim Bray's
 message of "Thu, 15 Jul 2004 12:07:03 -0700")
Message-ID: <87hds96k1o.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: <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-Type: text/plain

/ Tim Bray <Tim.Bray@Sun.COM> was heard to say:
|> (3) detour: would it be better if <id> was instead @id on <entry>?
|
| +1 on all three suggestions, but #3 may be worthy of some more debate.

In particular, if we call it "id" people will think it's an XML ID and
we don't mean that, we mean a URI. Less confusing, I think, to make
it an element.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | The effects of weakness are
http://nwalsh.com/            | inconceivable, and more prodigious than
                              | those of the most violent
                              | passions.--Cardinal De Retz

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA9vYDOyltUcwYWjsRAif6AJ9nB++JwU1uDLCoYmtUIFu7DCO/bACeNXTb
bm6l8CFzatJxo5n9dMwx4JM=
=l6nK
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Thu Jul 15 17:56: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 RAA04554
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 17:56: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 i6FLhnd4021365;
	Thu, 15 Jul 2004 14: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 i6FLhnA0021364;
	Thu, 15 Jul 2004 14:43: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.190])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FLhm0w021345
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 14:43:48 -0700 (PDT)
	(envelope-from sewe@rbg.informatik.tu-darmstadt.de)
Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de)
	by moutng.kundenserver.de with esmtp (Exim 3.35 #1)
	id 1BlE16-00008v-00
	for atom-syntax@imc.org; Thu, 15 Jul 2004 23:43:48 +0200
Received: from [62.224.218.174] (helo=baron)
	by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1)
	id 1BlE16-0002x7-00
	for atom-syntax@imc.org; Thu, 15 Jul 2004 23:43:48 +0200
Message-ID: <012801c46ab4$eb709ce0$5b1a9d3e@baron>
From: "Andreas Sewe" <sewe@rbg.informatik.tu-darmstadt.de>
To: "[Atom]" <atom-syntax@imc.org>
References: <BD1B83CF.1FA92%eric.scheid@ironclad.net.au> <285FBCEB-D692-11D8-A6EC-000A95A51C9E@sun.com>
Subject: Re: PaceEntryIdRequired
Date: Thu, 15 Jul 2004 23:44:26 +0200
Organization: Fachbereich Informatik, TU Darmstadt
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:275eb74a6eb9feb006a62452721ee94c
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


>> (3) detour: would it be better if <id> was instead @id on <entry>?

> +1 on all three suggestions, but #3 may be worthy of some more debate.

Well, in my opinion URIs traditionally belong into attributes (especially
since there is no risk that the content model will ever include elements :-).
But a name of @id is also traditionally used for attributes of type xsd:ID,
not for those of type xsd:anyURI.

This being said I'm in principle in favour of #3, although the name of the
attribute should better be changed to something like @identifier to avoid any
confusion regarding its type.

Regards,

Andreas Sewe



From owner-atom-syntax@mail.imc.org  Thu Jul 15 18: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 SAA12147
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 18: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 i6FMMSoj027131;
	Thu, 15 Jul 2004 15:22: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 i6FMMS8J027130;
	Thu, 15 Jul 2004 15:22:28 -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 i6FMMSf1027117
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 15:22:28 -0700 (PDT)
	(envelope-from donpark@docuverse.com)
Received: from [192.168.0.100] (c-24-7-33-191.client.comcast.net[24.7.33.191])
          by comcast.net (rwcrmhc13) with ESMTP
          id <20040715222227015003lckce>
          (Authid: dopilpark);
          Thu, 15 Jul 2004 22:22:28 +0000
Message-ID: <40F70360.9060209@docuverse.com>
Date: Thu, 15 Jul 2004 15:21:20 -0700
From: Don Park <donpark@docuverse.com>
User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mark Nottingham <mnot@mnot.net>
CC: Tim Bray <Tim.Bray@Sun.COM>, Atom Syntax <atom-syntax@imc.org>
Subject: Re: Rough consensus on PaceElementOrder?
References: <A5F347BE-D42A-11D8-9DBF-000A95A51C9E@sun.com> <E82A9628-D44C-11D8-AFCB-000A95BD86C0@mnot.net>
In-Reply-To: <E82A9628-D44C-11D8-AFCB-000A95BD86C0@mnot.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


Another option is:

<atom>
  <feed/>*
  <entry/>*
</atom>

If feed/entry relationship is not implcit, then each entry could 
explicitly point to zero or more feeds.

Don

Mark Nottingham wrote:

>
> Sounds like a plan. I'm not crazy about "feedinfo", but can't think of 
> something to replace it.
>
>
>
> On Jul 12, 2004, at 10:41 AM, Tim Bray wrote:
>
>>
>> I think that we are approaching rough consensus on PaceElementOrder, 
>> like so:
>>
>> 1. I think we clearly have consensus that the feed-level elements 
>> should all appear before the <atom:entry> elements.
>>
>> 2. I think we have probably have good-enough rough consensus that 
>> it's worthwhile grouping all the non-entry stuff in an 
>> <atom:feedinfo> or some such, so that the content model for 
>> <atom:feed> is something like
>>
>>   atom:feedinfo, atom:entry*
>>
>> The cost of doing this seems effectively zero and there are some 
>> detectable advantages.
>>
>> 3. There has been some discussion around the notion that there are 
>> some feed-level things that are really mostly about providing 
>> defaults for the <atom:entries>, with the consequent suggestion that 
>> maybe they deserve their own top-level element, with further 
>> digressions into doing defaulting by reference rather than by 
>> inheritance.  I do not detect consensus in these discussions (in fact 
>> I'm not convinced that it's been demonstrated that there things that 
>> are have pure entry-default as opposed to feed-metadata semantics).
>>
>> SO: I propose that rather than tear this one apart any further, we 
>> ask the editors to, in the -01 drafts, recast the data format with 
>> the <atom:feedinfo> element (anyone should feel free to suggest a 
>> better name than "feedinfo"), and that those who care about 
>> defaulting cook up a Pace or three outlining specifically what the 
>> options are.  -Tim
>>
>
> -- 
> Mark Nottingham     http://www.mnot.net/
>
>
>



From owner-atom-syntax@mail.imc.org  Thu Jul 15 18: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 SAA12611
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 18:33:57 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FMNjiV027294;
	Thu, 15 Jul 2004 15:23: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 i6FMNjGw027293;
	Thu, 15 Jul 2004 15:23:45 -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 i6FMNjNK027277
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 15:23:45 -0700 (PDT)
	(envelope-from antone@geckotribe.com)
Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134])
          by comcast.net (rwcrmhc13) with SMTP
          id <20040715222345015003mnshe>; Thu, 15 Jul 2004 22:23:45 +0000
Date: Thu, 15 Jul 2004 16:23:44 -0600
Subject: Re: PaceEntryIdRequired
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: <012801c46ab4$eb709ce0$5b1a9d3e@baron>
Message-Id: <A22EEA4C-D6AD-11D8-88BF-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 Thursday, July 15, 2004, at 03:44  PM, Andreas Sewe wrote:
>>> (3) detour: would it be better if <id> was instead @id on <entry>?
>
>> +1 on all three suggestions, but #3 may be worthy of some more debate.
>
> Well, in my opinion URIs traditionally belong into attributes 
> (especially
> since there is no risk that the content model will ever include 
> elements :-).
> But a name of @id is also traditionally used for attributes of type 
> xsd:ID,
> not for those of type xsd:anyURI.
>
> This being said I'm in principle in favour of #3, although the name of 
> the
> attribute should better be changed to something like @identifier to 
> avoid any
> confusion regarding its type.

Perhaps @uid?  (But not @guid!)



From owner-atom-syntax@mail.imc.org  Thu Jul 15 18:48: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 SAA14664
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 18:48: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 i6FMd4rx029270;
	Thu, 15 Jul 2004 15:39: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 i6FMd4qr029269;
	Thu, 15 Jul 2004 15:39:04 -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 i6FMd3Zi029252
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 15:39:04 -0700 (PDT)
	(envelope-from donpark@docuverse.com)
Received: from [192.168.0.100] (c-24-7-33-191.client.comcast.net[24.7.33.191])
          by comcast.net (sccrmhc11) with ESMTP
          id <2004071522385001100t2pfie>
          (Authid: dopilpark);
          Thu, 15 Jul 2004 22:39:01 +0000
Message-ID: <40F70737.7080800@docuverse.com>
Date: Thu, 15 Jul 2004 15:37:43 -0700
From: Don Park <donpark@docuverse.com>
User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tim Bray <Tim.Bray@Sun.COM>
CC: Joe Gregorio <joe.gregorio@gmail.com>, Atomlist <atom-syntax@imc.org>
Subject: Re: PacePutDelete Withdrawn
References: <20040715142548.9823.qmail@web41501.mail.yahoo.com> <40F69CFF.6080802@franklinmint.fm> <1DFD193F-D67D-11D8-A6EC-000A95A51C9E@sun.com> <3f1451f5040715105677a25d28@mail.gmail.com> <7480D32A-D68C-11D8-A6EC-000A95A51C9E@sun.com>
In-Reply-To: <7480D32A-D68C-11D8-A6EC-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


While I am happy to hear that Joe offered to withdraw PacePutDelete, I 
agree with Tim that we need to more closely examine the options, 
particularly in the areas of mobile clients and clients with restricted 
capabilities such as J2ME and Flash.  The question is, do we have 
sufficient expertise in these areas?  Currently, people involved in this 
process are, for the most part, people with high interest in the 
blogging technology and not necessarily people with experience in 
developing applications for platforms like J2ME and Flash.



From owner-atom-syntax@mail.imc.org  Thu Jul 15 19:21: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 TAA18416
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 19:21: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 i6FND1KN034440;
	Thu, 15 Jul 2004 16:13: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 i6FND1bD034439;
	Thu, 15 Jul 2004 16:13:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from beattie.info (Debian-exim@26.69-93-195.reverse.theplanet.com [69.93.195.26] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FND0lb034432
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 16:13:01 -0700 (PDT)
	(envelope-from russ@russellbeattie.com)
Received: from [64.164.31.160] (helo=[192.168.0.160])
	by beattie.info with asmtp (Exim 4.33)
	id 1BlFSK-0000Vj-5I
	for atom-syntax@imc.org; Thu, 15 Jul 2004 16:16:00 -0700
Message-ID: <40F70F7C.6060701@russellbeattie.com>
Date: Thu, 15 Jul 2004 16:13:00 -0700
From: Russell Beattie <russ@russellbeattie.com>
User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040708)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Atomlist <atom-syntax@imc.org>
Subject: Re: PacePutDelete Withdrawn
References: <20040715142548.9823.qmail@web41501.mail.yahoo.com> <40F69CFF.6080802@franklinmint.fm> <1DFD193F-D67D-11D8-A6EC-000A95A51C9E@sun.com> <40F6B806.8060307@intertwingly.net>
In-Reply-To: <40F6B806.8060307@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




Tim understated the case for cellphones. There are currently 19 mobile 
phones being sold worldwide *per second* and the majority of those are 
Java enabled. However, none of these handsets will support PUT or DELETE 
(not even MIDP 2.0 or CDLC 1.1), and the majority of these handsets have 
resource limitations and no access to the underlying hardware (most 
aren't "smart phones").

The alternative as it is now is to use SOAP via POST, which because of 
the resource constraints on mobile devices is problematic: Processing 
power, storage and network speeds are all limited.

I can enumerate the problems (and did, but deleted them to make the 
email short), but I think this issue shouldn't be tabled without looking 
at it in detail.

-Russ





From owner-atom-syntax@mail.imc.org  Thu Jul 15 19:34: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 TAA18961
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 19: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 i6FNPiqs036088;
	Thu, 15 Jul 2004 16:25: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 i6FNPit9036087;
	Thu, 15 Jul 2004 16:25:44 -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 i6FNPhTm036072
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 16:25:44 -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 i6FNPh53004944
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 18:25:43 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6FNPhvO004940;
	Thu, 15 Jul 2004 18:25:43 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: atom-syntax@imc.org
Subject: PaceReduceMustMay: new editorial proposal
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 15 Jul 2004 18:25:43 -0500
Message-ID: <m3zn60j1jc.fsf@bitsko.slc.ut.us>
Lines: 60
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


This is the initial proposal for reducing the potentially unnecessary
use of RFC2119 imperatives in the Atom drafts.  I'm willing to do the
legwork of getting the proper "boilerplate" pattern from other RFCs
for specifying content models in a more readable and less formal tone,
and make those available to the editors.

I wanted to pause and make sure the WG and editors think this is a
necessary and useful thing before I do the legwork.  Please take a
quick scan of the RFC sections listed below for comparible usage.

  -- Ken

== Abstract ==

  The RFC2119 imperatives MUST, MUST NOT, MAY, and SHOULD are used
  extensively in the format and protocol drafts to describe XML
  content models, which is unnecessary.

== Status ==

  Open -- Editorial.

  Author: KenMacLeod

== Rationale ==

  The XML element content models within the Atom Internet Drafts are
  part of the "basic specification" of the Atom format and protocol,
  like the use of ABNF (RFC2234) in traditional RFCs.  It is
  unnecessary to use requirements imperatives for the cardinality or
  markup syntax except "where it is actually required for
  interoperation" (RFC2119, Sec 6).

  Example XML-based RFCs for comparison:

   * RFC3017 -- XML DTD for Roaming Access Phone Book. M. Riegel,
     G. Zorn. December 2000.

     http://www.ietf.org/rfc/rfc3017
     Sections 6.1 and 6.2.  Uses DTD syntax to describe content model.

   * RFC3275 -- (Extensible Markup Language) XML-Signature Syntax
     and Processing. D. Eastlake 3rd, J. Reagle, D. Solo. March 2002.

     http://www.ietf.org/rfc/rfc3275
     Section 4.  Uses XML Schema to describe content model.

   * RFC2518 -- HTTP Extensions for Distributed Authoring --
     WEBDAV. Y. Goland, E. Whitehead, A. Faizi, S. Carter,
     D. Jensen. February 1999.

     http://www.ietf.org/rfc/rfc2518
     Section 12.  Uses DTD syntax.

== Proposal ==

 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.



From owner-atom-syntax@mail.imc.org  Thu Jul 15 20: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 UAA20263
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 20: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 i6FNrM2m039756;
	Thu, 15 Jul 2004 16:53: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 i6FNrM2K039755;
	Thu, 15 Jul 2004 16:53: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 [18.29.0.30])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6FNrM3L039739
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 16:53:22 -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 891844F041
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 19:53:26 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040716085223.053b86b8@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Fri, 16 Jul 2004 08:53:25 +0900
To: atom-syntax@imc.org
From: Martin Duerst <duerst@w3.org>
Subject: Re: Unsynchronized clocks vs. author calendars
In-Reply-To: <291D019B6DC48D73B1CD44AE@[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: <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 10:42 04/07/15 -0700, Walter Underwood wrote:

>The timestamp discussions are confusing two different things,
>and calling them both "subjective" timestamps.
>
>Timestamps from an unknown timezone are not subjective. They are
>measurements from a clock with a possibly large synchronization
>error to UTC (+/-12 hours).

It's more like +/- 14 hours.


>Timestamps from one clock can be
>ordered, but they cannot always be ordered against other clocks.
>If two timestamps are more than 24 hours apart, they can be ordered.

That would then be something like 28 or so hours.

Regards,     Martin.



From owner-atom-syntax@mail.imc.org  Thu Jul 15 20:43:28 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22571
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 20:43: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 i6G0Z8bY046620;
	Thu, 15 Jul 2004 17:35: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 i6G0Z8pG046619;
	Thu, 15 Jul 2004 17:35:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6G0Z7Jl046597
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 17:35:07 -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 esmtp (Exim 4.34)
	id 1BlGgv-000536-7s; Fri, 16 Jul 2004 00:35:10 +0000
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Thu, 15 Jul 2004 20:35:15 -0400
Subject: Re: PacePutDelete Withdrawn
From: Robert Sayre <mint@franklinmint.fm>
To: Russell Beattie <russ@russellbeattie.com>,
        Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD1C9B03.13C0C%mint@franklinmint.fm>
In-Reply-To: <40F70F7C.6060701@russellbeattie.com>
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: <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 7/15/04 7:13 PM, "Russell Beattie" <russ@russellbeattie.com> wrote:

> 
> The alternative as it is now is to use SOAP via POST, which because of
> the resource constraints on mobile devices is problematic: Processing
> power, storage and network speeds are all limited.
> 

I don't understand why you think a full SOAP stack would be necessary. It's
been pointed out before that the difference between a SOAP doc and an Atom
doc with <action> element would come down to string constants.

Robert Sayre



From owner-atom-syntax@mail.imc.org  Thu Jul 15 21:13: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 VAA24527
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 21:13: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 i6G14Wdr050891;
	Thu, 15 Jul 2004 18:04: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 i6G14WHe050890;
	Thu, 15 Jul 2004 18:04:32 -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 i6G14V1L050875
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 18:04:31 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 21095 messnum 1912860 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 16 Jul 2004 01:04:32 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail02.svc.cra.dublin.eircom.net (qp 21095) with SMTP; 16 Jul 2004 01:04:32 -0000
Message-ID: <40F7299A.9090002@dehora.net>
Date: Fri, 16 Jul 2004 02:04:26 +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: PaceEntryIdRequired
References: <BD1B83CF.1FA92%eric.scheid@ironclad.net.au>	<285FBCEB-D692-11D8-A6EC-000A95A51C9E@sun.com> <87hds96k1o.fsf@nwalsh.com>
In-Reply-To: <87hds96k1o.fsf@nwalsh.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


Norman Walsh wrote:
> / Tim Bray <Tim.Bray@Sun.COM> was heard to say:
> |> (3) detour: would it be better if <id> was instead @id on <entry>?
> |
> | +1 on all three suggestions, but #3 may be worthy of some more debate.
> 
> In particular, if we call it "id" people will think it's an XML ID and
> we don't mean that, we mean a URI. Less confusing, I think, to make
> it an element.

The goal of anything to do with URI naming must surely be to attain 
increasingly higher levels of confusion.

I nominate '@reference', as there's no 'de' in it.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Thu Jul 15 22:38:02 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11119
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 22: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 i6G2TmLc065252;
	Thu, 15 Jul 2004 19:29: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 i6G2Tmbi065251;
	Thu, 15 Jul 2004 19:29:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6G2Tj6n065243
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 19:29:45 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i6G2Rh53006524
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 20:27:43 -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 <0I0X0062HAXRRS@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Thu, 15 Jul 2004 20:29:52 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0X00FXQAXR46@mail.sun.net> for atom-syntax@imc.org; Thu,
 15 Jul 2004 20:29:51 -0600 (MDT)
Date: Thu, 15 Jul 2004 19:29:55 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PacePutDelete Withdrawn
In-reply-to: <BD1C9B03.13C0C%mint@franklinmint.fm>
To: Robert Sayre <mint@franklinmint.fm>
Cc: Atom Syntax <atom-syntax@imc.org>,
        Russell Beattie <russ@russellbeattie.com>
Message-id: <0646779E-D6D0-11D8-A6EC-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: <BD1C9B03.13C0C%mint@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 Jul 15, 2004, at 5:35 PM, Robert Sayre wrote:

> I don't understand why you think a full SOAP stack would be necessary. 
> It's
> been pointed out before that the difference between a SOAP doc and an 
> Atom
> doc with <action> element would come down to string constants.

That sounds promising.  Is it OK to do brutally minimal profiles of 
SOAP?  Or do we run the risk of getting onto a slippery slope where 
people start assuming they can pack in arbitrary WS-* headers and other 
kinds of things that would be tractable for a general-purpose 
implementation and impossible for a handheld?

It might be really nice for someone to do a Pace to replace the current 
section 6 of draft-atompub-protocol-00 to lay out very explicitly what 
an AtomPub client has to do to use the SOAP interface.  It would be 
nice if a cellphone engineer didn't have to go and try to understand 
the entirety of the SOAP spec before starting to code. -Tim



From owner-atom-syntax@mail.imc.org  Thu Jul 15 23:06:58 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12492
	for <atompub-archive@lists.ietf.org>; Thu, 15 Jul 2004 23:06:58 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6G2wVMd070058;
	Thu, 15 Jul 2004 19:58: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 i6G2wV9u070057;
	Thu, 15 Jul 2004 19:58: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 i6G2wVav070050
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 19:58:31 -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 i6G2wbil013063
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 20:58:37 -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 <0I0X00M2TC9P98@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Thu, 15 Jul 2004 20:58:37 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.15])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0X00F2DC9O46@mail.sun.net> for atom-syntax@imc.org; Thu,
 15 Jul 2004 20:58:37 -0600 (MDT)
Date: Thu, 15 Jul 2004 19:58:40 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Work Queue Rotation #4
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <0AAE43E3-D6D4-11D8-A6EC-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: <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 one was deliberately short and lightweight, to snaffle up a couple 
more low-hanging fruit so our editors can pull the -01 drafts together 
before the IETF meeting deadline, which is 9AM Monday morning.

1. PaceEntryIdRequired

I think this one has consensus, plus I saw no pushback and some support 
for the first two of Eric Scheid's suggested improvements at 
http://imc.org/atom-syntax/mail-archive/msg06964.html

2. PaceLang

This one exhibited a massive lack of consensus support and as far as I 
can tell, should be closed.

Editors, start your engines.

OK, I think Sam is going to give us something big, hairy, and ugly to 
chew on next, since we can't do another official draft for quite some 
time anyhow (schedule constraints around the IETF meetings).  Sam, do 
your worst. -Tim



From owner-atom-syntax@mail.imc.org  Fri Jul 16 01:02: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 BAA19869
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 01:02: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 i6G4q7M3085852;
	Thu, 15 Jul 2004 21:52:07 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6G4q7x9085851;
	Thu, 15 Jul 2004 21:52:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.243])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6G4q74j085834
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 21:52:07 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id w29so1755663cwb
        for <atom-syntax@imc.org>; Thu, 15 Jul 2004 21:52:09 -0700 (PDT)
Received: by 10.11.118.46 with SMTP id q46mr92961cwc;
        Thu, 15 Jul 2004 21:52:09 -0700 (PDT)
Message-ID: <3f1451f5040715215273201e5e@mail.gmail.com>
Date: Fri, 16 Jul 2004 00:52:09 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Russell Beattie <russ@russellbeattie.com>
Subject: Re: PacePutDelete Withdrawn
Cc: Atomlist <atom-syntax@imc.org>
In-Reply-To: <40F70F7C.6060701@russellbeattie.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <20040715142548.9823.qmail@web41501.mail.yahoo.com> <40F69CFF.6080802@franklinmint.fm> <1DFD193F-D67D-11D8-A6EC-000A95A51C9E@sun.com> <40F6B806.8060307@intertwingly.net> <40F70F7C.6060701@russellbeattie.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 Thu, 15 Jul 2004 16:13:00 -0700, Russell Beattie
<russ@russellbeattie.com> wrote:
> 
> 
> Tim understated the case for cellphones. There are currently 19 mobile
> phones being sold worldwide *per second* and the majority of those are
> Java enabled. However, none of these handsets will support PUT or DELETE
> (not even MIDP 2.0 or CDLC 1.1), and the majority of these handsets have
> resource limitations and no access to the underlying hardware (most
> aren't "smart phones").

I'm not familiar with either MIDP or CDLC, could 
you explain a little of what they are and their relation
to the underlying HTTP protocol?


> The alternative as it is now is to use SOAP via POST, which because of
> the resource constraints on mobile devices is problematic: Processing
> power, storage and network speeds are all limited.
> 
> I can enumerate the problems (and did, but deleted them to make the
> email short), but I think this issue shouldn't be tabled without looking
> at it in detail.

I think enumerating all the problems that you know about 
would be most helpful.

    Thanks,
    -joe



From owner-atom-syntax@mail.imc.org  Fri Jul 16 01:33: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 BAA21487
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 01:33: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 i6G5PqVr098586;
	Thu, 15 Jul 2004 22:25: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 i6G5PqcZ098585;
	Thu, 15 Jul 2004 22:25:52 -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 i6G5Ppnn098573
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 22:25:51 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.26] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id D365D727D; Thu, 15 Jul 2004 22:25:58 -0700 (PDT)
In-Reply-To: <m3zn60j1jc.fsf@bitsko.slc.ut.us>
References: <m3zn60j1jc.fsf@bitsko.slc.ut.us>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <9DEF070C-D6E8-11D8-97B1-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: Re: PaceReduceMustMay: new editorial proposal
Date: Thu, 15 Jul 2004 22:25:57 -0700
To: Ken MacLeod <ken@bitsko.slc.ut.us>
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>
Content-Transfer-Encoding: 7bit


Hi Ken.

I think it's fine to replace the normative requirements in prose with 
some sort of schema language -- if one can be agreed upon -- but I'd 
like to have the replacement in place before we rip these out. Would 
your proposal extend to that?

Also, I'm a little uncomfortable with editorial work by Pace; it smacks 
of word-smithing by committee, something that IME doesn't work out 
well. I'm happy to take suggestions on board, but having people propose 
editorial changes word-for-word to be incorporated wholesale removes 
the ability of the editors to make a judgement call.

That said, could you expand upon what you mean by reducing the 
formality of the specs? I would grant that the prose is a bit turgid 
now -- something that I planned to address in an upcoming edit -- but 
on the whole, I prefer to err on the side of formality.

In my experience, more formal specs, while requiring a bit more effort 
on the part of the reader, usually result in much tighter, 
interoperable, and more correct specs; OTOH the looser, more 
conversational specs that I've been involved with have always been the 
ones that different people interpret in different ways.

Put another way, the spec itself has a very specific audience -- 
implementers -- and they have very exacting requirements that demand 
formal description. Material for a wider audience (e.g., evangelism, 
user guides, advice in a vehicle like a primer) can and should be less 
formal and more flowing.

Cheers,



On Jul 15, 2004, at 4:25 PM, Ken MacLeod wrote:

>
> This is the initial proposal for reducing the potentially unnecessary
> use of RFC2119 imperatives in the Atom drafts.  I'm willing to do the
> legwork of getting the proper "boilerplate" pattern from other RFCs
> for specifying content models in a more readable and less formal tone,
> and make those available to the editors.
>
> I wanted to pause and make sure the WG and editors think this is a
> necessary and useful thing before I do the legwork.  Please take a
> quick scan of the RFC sections listed below for comparible usage.
>
>   -- Ken
>
> == Abstract ==
>
>   The RFC2119 imperatives MUST, MUST NOT, MAY, and SHOULD are used
>   extensively in the format and protocol drafts to describe XML
>   content models, which is unnecessary.
>
> == Status ==
>
>   Open -- Editorial.
>
>   Author: KenMacLeod
>
> == Rationale ==
>
>   The XML element content models within the Atom Internet Drafts are
>   part of the "basic specification" of the Atom format and protocol,
>   like the use of ABNF (RFC2234) in traditional RFCs.  It is
>   unnecessary to use requirements imperatives for the cardinality or
>   markup syntax except "where it is actually required for
>   interoperation" (RFC2119, Sec 6).
>
>   Example XML-based RFCs for comparison:
>
>    * RFC3017 -- XML DTD for Roaming Access Phone Book. M. Riegel,
>      G. Zorn. December 2000.
>
>      http://www.ietf.org/rfc/rfc3017
>      Sections 6.1 and 6.2.  Uses DTD syntax to describe content model.
>
>    * RFC3275 -- (Extensible Markup Language) XML-Signature Syntax
>      and Processing. D. Eastlake 3rd, J. Reagle, D. Solo. March 2002.
>
>      http://www.ietf.org/rfc/rfc3275
>      Section 4.  Uses XML Schema to describe content model.
>
>    * RFC2518 -- HTTP Extensions for Distributed Authoring --
>      WEBDAV. Y. Goland, E. Whitehead, A. Faizi, S. Carter,
>      D. Jensen. February 1999.
>
>      http://www.ietf.org/rfc/rfc2518
>      Section 12.  Uses DTD syntax.
>
> == Proposal ==
>
>  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.
>

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Fri Jul 16 02:04:10 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25989
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 02:04:09 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6G5t0Rp015159;
	Thu, 15 Jul 2004 22:55:00 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6G5t0u5015158;
	Thu, 15 Jul 2004 22:55:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from adsl-67-113-138-114.dsl.sntc01.pacbell.net (adsl-67-113-138-114.dsl.sntc01.pacbell.net [67.113.138.114])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6G5sw3w015126
	for <atom-syntax@imc.org>; Thu, 15 Jul 2004 22:55:00 -0700 (PDT)
	(envelope-from soap@zaks.demon.co.uk)
Received: from coldcut.simonathome.com (coldcut.simonathome.com [192.168.1.70])
          by zaks.demon.co.uk with ESMTP (Mailtraq/2.5.1.1621) id ZAKSFBBEC1F4
          for atom-syntax@imc.org; Thu, 15 Jul 2004 22:54:53 -0700
From: Simon Fell <soap@zaks.demon.co.uk>
To: atom-syntax@imc.org
Subject: Re: PacePutDelete Withdrawn
Date: Thu, 15 Jul 2004 22:54:53 -0700
Organization: pocketsoap.com
Message-ID: <17ref0hsek1v46oj3rupmlfolffae9t0un@4ax.com>
References: <BD1C9B03.13C0C%mint@franklinmint.fm> <0646779E-D6D0-11D8-A6EC-000A95A51C9E@sun.com>
In-Reply-To: <0646779E-D6D0-11D8-A6EC-000A95A51C9E@sun.com>
X-Mailer: Forte Agent 2.0/32.652
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Hops: 1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6G5t03w015149
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 Thu, 15 Jul 2004 19:29:55 -0700, in soap you wrote:

>
>On Jul 15, 2004, at 5:35 PM, Robert Sayre wrote:
>
>> I don't understand why you think a full SOAP stack would be necessary. 
>> It's
>> been pointed out before that the difference between a SOAP doc and an 
>> Atom
>> doc with <action> element would come down to string constants.
>
>That sounds promising.  Is it OK to do brutally minimal profiles of 
>SOAP?  Or do we run the risk of getting onto a slippery slope where 
>people start assuming they can pack in arbitrary WS-* headers and other 
>kinds of things that would be tractable for a general-purpose 
>implementation and impossible for a handheld?
>
>It might be really nice for someone to do a Pace to replace the current 
>section 6 of draft-atompub-protocol-00 to lay out very explicitly what 
>an AtomPub client has to do to use the SOAP interface.  It would be 
>nice if a cellphone engineer didn't have to go and try to understand 
>the entirety of the SOAP spec before starting to code. -Tim

Hmmm, for other related specs, I've noticed that you've steared clear
of restating them in the atom spec, and just referencing them. Why
make the exception here ?. Now if you were talking primer material,
then i'm all for it.

For those you think SOAP purely defines a document structure, go read
the spec, there's a processing model as well you need to follow (not a
particularly onerous one, I seem to recall seeing Sam implement the
minimal processing rules in about 4 lines of python)

Cheers
Simon
www.pocketsoap.com



From owner-atom-syntax@mail.imc.org  Fri Jul 16 03: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 DAA10398
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 03: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 i6G72QUN047118;
	Fri, 16 Jul 2004 00: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 i6G72Qoo047117;
	Fri, 16 Jul 2004 00:02: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 i6G72PZl047020
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 00:02: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 15F6B7C0F3; Fri, 16 Jul 2004 09:59:55 +0200 (CEST)
To: "Eric Scheid" <eric.scheid@ironclad.net.au>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Q: modfied vs issued vs created
References: <BD1C71AD.1FD6C%eric.scheid@ironclad.net.au>
Message-ID: <opsa7xzhfxuvpchu@quark>
Date: Fri, 16 Jul 2004 09:05:31 +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: <BD1C71AD.1FD6C%eric.scheid@ironclad.net.au>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Thu, 15 Jul 2004 17:38:53 +1000, Eric Scheid  
<eric.scheid@ironclad.net.au> wrote:

> you just said that before saving an entry that it is empty (and no way of
> changing it).

Well, that was wrong. It's not empty, it's just not there. At all. It  
first shows up after you've saved once.

> Once a value is saved in that field then MT doesn't change it, only the
> user can. MT doesn't have to do any comparisons.

Yes it does, because when the field shows up after you've saved, it's  
filled out with the initial 'created' value. After having discussed this  
with Arve, MT obviously haven't got any notion of 'issued' at all, even if  
it has a separate 'Publish' state, even. That is really bad publishing  
practice, and no one with real knowledge of how publishing works would  
build something like that.

> There is this broad concept of "the date of the document" (which is
> different from "the date this document was communicated"). People like to
> specify the date of their documents.

Fine. Just don't stick it in as a *formal* date, based on the Dublin Core  
elements. Dublin Core has no notion of «subjective» dates, so if Atom  
needs it, use whatever element name fits for the purpose, but don't take  
it from Dublin Core. I think 'display' could be a good date.

> People using it for future publishing, when they don't actually mean  
> "date of this document", are simply hacking their tool (which is
> lacking a proper embargo date field).

Yes, I agree. The correct Dublin Core term for future publishing (and  
future removal of a story) is 'available'[1], even.

____
[1] <url: http://www.dublincore.org/documents/dcmi-terms/#available>

-- 
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 Jul 16 03: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 DAA10486
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 03:14: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 i6G76hCA048889;
	Fri, 16 Jul 2004 00:06: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 i6G76hxl048888;
	Fri, 16 Jul 2004 00:06: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 i6G76gCJ048845
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 00:06: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 A7C967C0F3; Fri, 16 Jul 2004 10:04:17 +0200 (CEST)
To: "Ken MacLeod" <ken@bitsko.slc.ut.us>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Regarding UseCases
References: <40F5D4F9.5070108@itst.org> <opsa51pdt8uvpchu@quark> <m3r7rdjpje.fsf@bitsko.slc.ut.us>
Message-ID: <opsa7x6ta5uvpchu@quark>
Date: Fri, 16 Jul 2004 09:09:55 +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: <m3r7rdjpje.fsf@bitsko.slc.ut.us>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 15 Jul 2004 09:47:17 -0500, Ken MacLeod <ken@bitsko.slc.ut.us> wrote:

>> I propose that we use Dublin Core's <relation>[1] element
>
> I have some general disagreements about particular markup and meanings
> surrounding this, is this part of PaceLinkParent or some other Pace?

I'm not sure. Seeing that <relation> solves a lot of problems and not only  
threading, I guess the element needs a pace of its own. But I'm not sure.

> Can we wait until that Pace comes up for discussion?

Of course.

-- 
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 Jul 16 03: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 DAA11337
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 03: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 i6G7FNaR052932;
	Fri, 16 Jul 2004 00: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 i6G7FN41052931;
	Fri, 16 Jul 2004 00:15: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 i6G7FMXi052884
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 00:15: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 329107C112; Fri, 16 Jul 2004 10:12:58 +0200 (CEST)
To: "Sam Ruby" <rubys@intertwingly.net>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: a methodical approach to defining what date  elements we need
References: <D6AD94D06307435B9CB78A9EBEF81D.MAI@journurl.com> <40F66F3E.6020604@intertwingly.net>
Message-ID: <opsa7ylch3uvpchu@quark>
Date: Fri, 16 Jul 2004 09:18: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: <40F66F3E.6020604@intertwingly.net>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Thu, 15 Jul 2004 07:49:18 -0400, Sam Ruby <rubys@intertwingly.net>  
wrote:

> I prefer something that more closely captures Tim's description [1]:

I strongly oppose having just two dates when one of them is unreliable and  
useless (the equivalent of 'Display') and the other is useless for  
syndication and publishing processes in general (the equivalent of  
'Modified' whatever it gets named).

It would be a great loss if Atom Core was not able to deliver an initial  
'created' or even better, 'issued' date in 1.0. It would have enormous  
effect on what Atom could be used for in publishing processes.

-- 
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 Jul 16 03: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 DAA12091
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 03: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 i6G7WLbr059856;
	Fri, 16 Jul 2004 00:32: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 i6G7WL1V059855;
	Fri, 16 Jul 2004 00:32: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 i6G7WK6D059806
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 00:32: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 50FA57C112; Fri, 16 Jul 2004 10:29:55 +0200 (CEST)
To: "Dare Obasanjo" <kpako@yahoo.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Non-Gregorian calendars (was: Re: Unsynchronized clocks vs. author calendars)
References: <20040715181624.90235.qmail@web41210.mail.yahoo.com>
Message-ID: <opsa7zdoyluvpchu@quark>
Date: Fri, 16 Jul 2004 09:35: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: <20040715181624.90235.qmail@web41210.mail.yahoo.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Thu, 15 Jul 2004 11:16:24 -0700 (PDT), Dare Obasanjo <kpako@yahoo.com>  
wrote:

> Are you claiming that that Atom feeds will have to deal with
> calendars other than the Gregorian calendar? Since when?

I don't think that's what he's saying, but either way; supporting a  
non-Gregorian calendar isn't stupid. ISO 8601 does not support any such to  
my knowledge, but it should at least be discussed what usages Atom has  
outside of «the western world», e.g. in the Arabic countries, Asia and so  
on.

After all, people using the Gregorian calendar is a minority, right?[1]

> Every discussion I've seen has assumed ISO 8601 commpliant dates.

Yup. That's been the assumption up to now. Non-Gregorian calendars have  
been discussed in brief on #atom, but no solution and even no  
specifications have been found on other calendars. Someone managed to dig  
out some Persian blogs, though, but we couldn't find out if those had any  
feeds (I speak very poor Persion. None, actually ;).

If Atom is not going to support non-Gregorian calendars, it should be  
clear that it doesn't, imho.

____
[1] I have to say that I don't know enough about the subject to say if the  
Gregorian calendar is more widely used than any other. If it isn't, Atom  
should be clear about not supporting others, and not just move along in  
ignorance.

-- 
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 Jul 16 03: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 DAA12217
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 03: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 i6G7ZTOI061139;
	Fri, 16 Jul 2004 00:35: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 i6G7ZT95061138;
	Fri, 16 Jul 2004 00:35: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 i6G7ZRjR061096
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 00:35: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 4618A7C117; Fri, 16 Jul 2004 10:33:03 +0200 (CEST)
To: "Tim Bray" <Tim.Bray@sun.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceEntryIdRequired
References: <BD1B83CF.1FA92%eric.scheid@ironclad.net.au> <285FBCEB-D692-11D8-A6EC-000A95A51C9E@sun.com>
Message-ID: <opsa7zixr2uvpchu@quark>
Date: Fri, 16 Jul 2004 09:38:47 +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: <285FBCEB-D692-11D8-A6EC-000A95A51C9E@sun.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Thu, 15 Jul 2004 12:07:03 -0700, Tim Bray <Tim.Bray@Sun.COM> wrote:

>> (3) detour: would it be better if <id> was instead @id on <entry>?
>
> +1 on all three suggestions, but #3 may be worthy of some more debate.

Yes, putting a non-XML ID into an @id attribute would not be a good idea,  
imho. When discussing this in the beginning, @id was dropped because an  
Atom ID couldn't fit the syntactical constraints of an XML ID. An URI is  
not a valid XML ID, and thus should the ID not look like on either.  
Another attribute is fine, 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  Fri Jul 16 05: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 FAA17261
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 05: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 i6G8tjXP094612;
	Fri, 16 Jul 2004 01:55:45 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6G8tjfo094610;
	Fri, 16 Jul 2004 01:55: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 [18.29.0.30])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6G8tj54094600
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 01:55:45 -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 109534EFE8;
	Fri, 16 Jul 2004 04:55:44 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040716173825.05692c40@localhost>
X-Sender: duerst@localhost (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Fri, 16 Jul 2004 17:41:22 +0900
To: Tim Bray <Tim.Bray@Sun.COM>, Atom-Syntax Syntax <atom-syntax@imc.org>
From: Martin Duerst <duerst@w3.org>
Subject: Re: PaceLang
In-Reply-To: <4B1F9CA8-D5F3-11D8-A6EC-000A95A51C9E@sun.com>
References: <14be96d3040714164534e0561c@mail.gmail.com>
 <D02C373E-D5A7-11D8-AE1C-003065EA6144@geckotribe.com>
 <14be96d304071409597134a601@mail.gmail.com>
 <opsa5at5hnuvpchu@quark>
 <14be96d3040714143410404efb@mail.gmail.com>
 <40F5B232.7000407@intertwingly.net>
 <14be96d3040714164534e0561c@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 17:09 04/07/14 -0700, Tim Bray wrote:

>On Jul 14, 2004, at 4:45 PM, Mark Pilgrim wrote:
>
>>I was under the impression that the current draft allowed xml:lang
>>anywhere, and this Pace was restricting it to Content constructs.  My
>>point is that there are several other places in feeds where xml:lang
>>would be useful.
>>
>>I think we should withdraw PaceLang and keep the language currently in 
>>the spec.
>
>+1  -Tim

I'd be okay with this, but the pace also tweaks the text about what
exactly can be a value of xml:lang.

The current spec text says:
"The content of this attribute element MUST be a registered language
tag [RFC3066]."

The proposed text for this says:
"When present, this attribute MUST be a registered language tag from RFC3066
or its successors; in addition, an empty string (xml:lang="") MAY be
specified to indicate that there is no language information available."

The later is clearly more in line with XML (3rd edition), and more
futureproof, and therefore should be used even if the rest is kept
as is.


Regards,    Martin.




From owner-atom-syntax@mail.imc.org  Fri Jul 16 05: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 FAA17341
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 05: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 i6G8u13d094770;
	Fri, 16 Jul 2004 01:56: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 i6G8u1aG094769;
	Fri, 16 Jul 2004 01:56:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from homer.w3.org (homer.w3.org [18.29.0.30])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6G8u0lU094760
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 01:56:01 -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 E85504F019;
	Fri, 16 Jul 2004 04:55:53 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040716174907.0568ef18@localhost>
X-Sender: duerst@localhost (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Fri, 16 Jul 2004 17:55:26 +0900
To: Walter Underwood <wunder@verity.com>, Atom-Syntax <atom-syntax@imc.org>
From: Martin Duerst <duerst@w3.org>
Subject: Re: PaceMustBeWellFormed
In-Reply-To: <B1CF7C5F3C9875E645F9C55A@adsl-64-166-133-244.dsl.snfc21.pa
 cbell.net>
References: <14be96d30407141427187f294d@mail.gmail.com>
 <14be96d30407061142441f70ee@mail.gmail.com>
 <40F56B2A.8050500@intertwingly.net>
 <14be96d304071411092c2c44f4@mail.gmail.com>
 <p06110426bd1b3deea52a@10.20.30.249>
 <14be96d30407141427187f294d@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 21:38 04/07/14 -0700, Walter Underwood wrote:

>Has anyone ever deployed a transcoding server? I've never seen
>on in real use.

I have. There were a lot of transcoding proxies in the early days
of the Web in Japan. There were some transcoding servers quite
recently in Russia. You have to retreive the same document both
from an Unix machine and a Windows machine or so to find out
that the same document is served with different encodings
(and that you can rely on the HTTP header, but not on the
<meta> tag). Some mobile providers may also do transcoding,
although I don't have any confirmation on this one.

What is more important, there are well-used script languages
where it's very easy to say 'serve this document in charset X',
which implies to add this info in the HTTP header. But the
document itself isn't changed.

Regards,    Martin.



From owner-atom-syntax@mail.imc.org  Fri Jul 16 05: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 FAA17374
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 05:16: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 i6G8tivG094588;
	Fri, 16 Jul 2004 01:55: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 i6G8tilG094587;
	Fri, 16 Jul 2004 01:55: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 i6G8thvx094575
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 01:55:44 -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 A2C614EF6E;
	Fri, 16 Jul 2004 04:55:42 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040716171935.053dbd70@localhost>
X-Sender: duerst@localhost (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Fri, 16 Jul 2004 17:31:11 +0900
To: Asbj=?ISO-2022-JP?B?GyRCj1MbKEI=?=n Ulsberg <asbjorn@tigerstaden.no>,
        "Dare Obasanjo" <kpako@yahoo.com>
From: Martin Duerst <duerst@w3.org>
Subject: Re: Non-Gregorian calendars (was: Re: Unsynchronized clocks
  vs. author calendars)
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <opsa7zdoyluvpchu@quark>
References: <20040715181624.90235.qmail@web41210.mail.yahoo.com>
 <20040715181624.90235.qmail@web41210.mail.yahoo.com>
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: <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


At 09:35 04/07/16 +0200, Asbj$BS(Bn Ulsberg wrote:

>On Thu, 15 Jul 2004 11:16:24 -0700 (PDT), Dare Obasanjo <kpako@yahoo.com>
>wrote:
>
>>Are you claiming that that Atom feeds will have to deal with
>>calendars other than the Gregorian calendar? Since when?
>
>I don't think that's what he's saying, but either way; supporting a
>non-Gregorian calendar isn't stupid. ISO 8601 does not support any such to
>my knowledge, but it should at least be discussed what usages Atom has
>outside of $B%)(Bthe western world$B%5(B, e.g. in the Arabic countries, Asia and so
>on.
>
>After all, people using the Gregorian calendar is a minority, right?[1]

[the following is just a short summary]
Not exactly. It's quite a serious majority, I would guess.
If you count North and South America, Europe, Russia, China,
and so on, you easily get there.
In some countries, for example Japan and Taiwan, a calendar is
used that works exactly the same for months and days, just the
years are numbered differently. In other places, in particular
Israel, the Arabic World, and Ethiopia, there are traditional
calendars that are not aligned in terms of months and days.
In all these cases, the Gregorian calendar is used side-by-side
with the 'traditional' one, but usage differs for each case.
Usually, the Gregorian calendar is more prevalent in business
and for international stuff, while the traditional calendar
is more prevalent for private and in particular for religious
events. Even in places that are (mostly) aligned with the Gregorian
calendar (e.g. China, Japan), there are things that still run
according to an older, traditional calendar, e.g. the Chinese
New Year or Japanese plannig of wedding ceremonies.



>>Every discussion I've seen has assumed ISO 8601 commpliant dates.
>
>Yup. That's been the assumption up to now. Non-Gregorian calendars have
>been discussed in brief on #atom, but no solution and even no
>specifications have been found on other calendars. Someone managed to dig
>out some Persian blogs, though, but we couldn't find out if those had any
>feeds (I speak very poor Persion. None, actually ;).
>
>If Atom is not going to support non-Gregorian calendars, it should be
>clear that it doesn't, imho.

I think that:
- Atom should concentrate on markup for machine readable dates
- Machine readable dates should be in ISO 8601 notation, which implies
   the Gregorian calendar
- The spec should make clear that this is a format for exchanging
   date/time information, and does not limit how these are being shown
   to a user, or input by a user.
- People who want to add anything else (such as "on a sunny Sunday
   in July" or so) can always put that into the title/description/
   actual item text/wherever appropriate.

Regards,    Martin.

>____
>[1] I have to say that I don't know enough about the subject to say if the
>Gregorian calendar is more widely used than any other. If it isn't, Atom
>should be clear about not supporting others, and not just move along in
>ignorance.
>
>--
>Asbj$BS(Bn Ulsberg         -=|=-        asbjornu@hotmail.com
>$B%)(BHe's a loathsome offensive brute, yet I can't look away$B%5(B



From owner-atom-syntax@mail.imc.org  Fri Jul 16 05:16: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 FAA17392
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 05:16:56 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6G8trfQ094709;
	Fri, 16 Jul 2004 01:55: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 i6G8trT7094708;
	Fri, 16 Jul 2004 01:55:53 -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 i6G8tqQj094697
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 01:55:52 -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 3282E4F019;
	Fri, 16 Jul 2004 04:55:51 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040716174406.05690470@localhost>
X-Sender: duerst@localhost (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Fri, 16 Jul 2004 17:46:03 +0900
To: Tim Bray <Tim.Bray@Sun.COM>, Atom Syntax <atom-syntax@imc.org>
From: Martin Duerst <duerst@w3.org>
Subject: Re: Work Queue Rotation #4
In-Reply-To: <0AAE43E3-D6D4-11D8-A6EC-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>


At 19:58 04/07/15 -0700, Tim Bray wrote:

>This one was deliberately short and lightweight, to snaffle up a couple 
>more low-hanging fruit so our editors can pull the -01 drafts together 
>before the IETF meeting deadline, which is 9AM Monday morning.

>2. PaceLang
>
>This one exhibited a massive lack of consensus support and as far as I can 
>tell, should be closed.

Objection. Not on the main point (namely that xml:lang should be on
every (or virtually every) element), but on loosing the description
of what goes into xml:lang that is more aligned with the current
(and future) XML spec in the Pace than in the current text.

Regards,    Martin.



From owner-atom-syntax@mail.imc.org  Fri Jul 16 05:18:04 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17445
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 05: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 i6G8tpx6094692;
	Fri, 16 Jul 2004 01:55: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 i6G8tpSp094691;
	Fri, 16 Jul 2004 01:55:51 -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 i6G8toLL094670
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 01:55:50 -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 91D604EFE8;
	Fri, 16 Jul 2004 04:55:50 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040716174226.0542f968@localhost>
X-Sender: duerst@localhost (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Fri, 16 Jul 2004 17:43:54 +0900
To: Eric Scheid <eric.scheid@ironclad.net.au>,
        Atom Syntax <atom-syntax@imc.org>
From: Martin Duerst <duerst@w3.org>
Subject: Re: PaceLang
In-Reply-To: <BD1C0BA8.1FBBC%eric.scheid@ironclad.net.au>
References: <14be96d3040714164534e0561c@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 10:23 04/07/15 +1000, Eric Scheid wrote:

>On 15/7/04 9:45 AM, "Mark Pilgrim" <pilgrim@gmail.com> wrote:
>
> > I was under the impression that the current draft allowed xml:lang
> > anywhere, and this Pace was restricting it to Content constructs.  My
> > point is that there are several other places in feeds where xml:lang
> > would be useful.
>
>the problem was someone pointed out that you can only *put* xml:lang in
>those places which are specified as allowing xml:lang (with the other places
>still being affected, but only by an ancestor xml:lang)

Both the current wording and the new wording proposed by the pace
do this. If the Atom spec says (as it currently does)
"Any element MAY have an xml:lang attribute ...", then this
is completely sufficient, and any DTD/Schema designer will
hopefully know what to do with it (namely declare xml:lang
on all elements).

Regards,     Martin.



From owner-atom-syntax@mail.imc.org  Fri Jul 16 05: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 FAA17974
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 05:32:04 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6G9GqRN003763;
	Fri, 16 Jul 2004 02:16: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 i6G9GqRp003762;
	Fri, 16 Jul 2004 02:16:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from w02.bloglines.com (w02.bloglines.com [216.148.212.184])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6G9GqdW003718
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 02:16:52 -0700 (PDT)
	(envelope-from kwark.1511609@bloglines.com)
Received: (qmail 28297 invoked by uid 99); 16 Jul 2004 09:16:47 -0000
Message-ID: <1089969407.2673166242.28295.sendItem@bloglines.com>
Date: 16 Jul 2004 09:16:47 -0000
From: kwark.1511609@bloglines.com
To: joe.gregorio@gmail.com
CC: atom-syntax@imc.org
Subject: Re: PacePutDelete Withdrawn
MIME-Version: 1.0
Content-Type: text/plain
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


--- Joe Gregorio <joe.gregorio@gmail.com wrote:

> I'm not familiar with
either MIDP or CDLC, could 
> you explain a little of what they are and their
relation
> to the underlying HTTP protocol?
> 

MIDP stands for Mobile
Information Device Profile and runs on top of CLDC (Connected Limited Device
Configuration). The CLDC defines a GCF (Generic Connection Framework) that
provides an API to communicate with the outside world (sockets, http, comm,
...). The MIDP running on top of CLDC defines and constrains the type of connections
possible for MIDP compatible devices. For MIDP 1.0 the only required connection
is HTTP and the only required methods to support are GET, HEAD and POST.

The reason why MIDP only allows for HTTP is simple: some phones run on networks
which don't have a native TCP/IP stack. These networks can still provide for
HTTP connectivity, by using the WSP (Wireless Session Protocol) stack, provided
by the WAP browser. WSP provides a HTTP mapping on top of most physical networks.


WSP has support for arbritrary HTTP methods (OPTIONS, PUT, DELETE, ...).
But because the main user of WSP stack is a WAP browser and this only ever
uses GET and POST, you can only rely on these two methods two work reliably.
Support for other methods on both phones and WAP gateways is very shaky. 


This is most likely the reason why the JSR expert group, which defined
MIDP, only required HTTP support and only mandated support for GET, HEAD and
POST.

>
> > The alternative as it is now is to use SOAP via POST, which
because of
> > the resource constraints on mobile devices is problematic:
Processing
> > power, storage and network speeds are all limited.
> > 

I  don't have any problem with a SOAP alternative for text objects. I can
live with the additional processing requirements and increased payload size
of the SOAP envelope.

I do have a problem with base64 encoding and additional
gzipping of binary content, in order to tunnel binary objects over SOAP, when
there exists no simple POST alternative.

Peter



From owner-atom-syntax@mail.imc.org  Fri Jul 16 05:42: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 FAA18418
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 05: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 i6G9ZjaR011689;
	Fri, 16 Jul 2004 02: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 i6G9ZjHO011688;
	Fri, 16 Jul 2004 02:35: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 [18.29.0.30])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6G9ZiJZ011677
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 02:35:44 -0700 (PDT)
	(envelope-from danbri@w3.org)
Received: by homer.w3.org (Postfix, from userid 13522)
	id 7C1234F0CE; Fri, 16 Jul 2004 05:35:45 -0400 (EDT)
Date: Fri, 16 Jul 2004 05:35:45 -0400
From: Dan Brickley <danbri@w3.org>
To: Martin Duerst <duerst@w3.org>
Cc: Walter Underwood <wunder@verity.com>, Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceMustBeWellFormed
Message-ID: <20040716093545.GG10836@homer.w3.org>
References: <14be96d30407141427187f294d@mail.gmail.com> <14be96d30407061142441f70ee@mail.gmail.com> <40F56B2A.8050500@intertwingly.net> <14be96d304071411092c2c44f4@mail.gmail.com> <p06110426bd1b3deea52a@10.20.30.249> <14be96d30407141427187f294d@mail.gmail.com> <4.2.0.58.J.20040716174907.0568ef18@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4.2.0.58.J.20040716174907.0568ef18@localhost>
User-Agent: Mutt/1.5.6+20040523i
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>


* Martin Duerst <duerst@w3.org> [2004-07-16 17:55+0900]
> 
> At 21:38 04/07/14 -0700, Walter Underwood wrote:
> 
> >Has anyone ever deployed a transcoding server? I've never seen
> >on in real use.
> 
> I have. There were a lot of transcoding proxies in the early days
> of the Web in Japan. There were some transcoding servers quite
> recently in Russia. You have to retreive the same document both
> from an Unix machine and a Windows machine or so to find out
> that the same document is served with different encodings
> (and that you can rely on the HTTP header, but not on the
> <meta> tag). Some mobile providers may also do transcoding,
> although I don't have any confirmation on this one.

http://www.burningdoor.com/steve/archives/000602.html claims that 
transcoding proxies are getting popular again. It cites Opera's 
proxy service (though I don't see direct evidence that it transcodes
charsets), Google's WAP proxy (http://www.google.com/wml), the 
Nokia One Business Server (http://www.nokia.com/nokia/0,8764,43106,00.html) and 
Feedburner (http://www.feedburner.com/fb/a/home). Hmm glancing at these
I wonder whether "transcoding server" is being used in different ways;
sometimes to refer to char encoding conversion and sometimes, more
broadly, to proxies that do other kinds of conversion (eg. HTML to WAP,
RSS to Atom, ...). 

Dan



From owner-atom-syntax@mail.imc.org  Fri Jul 16 06: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 GAA21865
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 06:52: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 i6GAgQDK039589;
	Fri, 16 Jul 2004 03:42: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 i6GAgQUU039588;
	Fri, 16 Jul 2004 03:42:26 -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 i6GAgPiD039574
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 03:42:25 -0700 (PDT)
	(envelope-from danbri@w3.org)
Received: by homer.w3.org (Postfix, from userid 13522)
	id 8C8B94F0A3; Fri, 16 Jul 2004 06:42:25 -0400 (EDT)
Date: Fri, 16 Jul 2004 06:42:25 -0400
From: Dan Brickley <danbri@w3.org>
To: Martin Duerst <duerst@w3.org>
Cc: =?utf-8?B?QXNiau+/vVNu?= Ulsberg <asbjorn@tigerstaden.no>,
        Dare Obasanjo <kpako@yahoo.com>, Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Non-Gregorian calendars (was: Re: Unsynchronized clocks vs. author calendars)
Message-ID: <20040716104224.GH10836@homer.w3.org>
References: <20040715181624.90235.qmail@web41210.mail.yahoo.com> <20040715181624.90235.qmail@web41210.mail.yahoo.com> <4.2.0.58.J.20040716171935.053dbd70@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4.2.0.58.J.20040716171935.053dbd70@localhost>
User-Agent: Mutt/1.5.6+20040523i
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


* Martin Duerst <duerst@w3.org> [2004-07-16 17:31+0900]
> 
> At 09:35 04/07/16 +0200, Asbj?Sn Ulsberg wrote:
> 
> >On Thu, 15 Jul 2004 11:16:24 -0700 (PDT), Dare Obasanjo <kpako@yahoo.com>
> >wrote:
> >
> >>Are you claiming that that Atom feeds will have to deal with
> >>calendars other than the Gregorian calendar? Since when?
> >
> >I don't think that's what he's saying, but either way; supporting a
> >non-Gregorian calendar isn't stupid. ISO 8601 does not support any such to
> >my knowledge, but it should at least be discussed what usages Atom has
> >outside of ォthe western worldサ, e.g. in the Arabic countries, Asia and 
> >so
> >on.
> >
> >After all, people using the Gregorian calendar is a minority, right?[1]
> 
> [the following is just a short summary]
> Not exactly. It's quite a serious majority, I would guess.
> If you count North and South America, Europe, Russia, China,
> and so on, you easily get there.
> In some countries, for example Japan and Taiwan, a calendar is
> used that works exactly the same for months and days, just the
> years are numbered differently. In other places, in particular
> Israel, the Arabic World, and Ethiopia, there are traditional
> calendars that are not aligned in terms of months and days.
> In all these cases, the Gregorian calendar is used side-by-side
> with the 'traditional' one, but usage differs for each case.
> Usually, the Gregorian calendar is more prevalent in business
> and for international stuff, while the traditional calendar
> is more prevalent for private and in particular for religious
> events. Even in places that are (mostly) aligned with the Gregorian
> calendar (e.g. China, Japan), there are things that still run
> according to an older, traditional calendar, e.g. the Chinese
> New Year or Japanese plannig of wedding ceremonies.
> 
> 
> 
> >>Every discussion I've seen has assumed ISO 8601 commpliant dates.
> >
> >Yup. That's been the assumption up to now. Non-Gregorian calendars have
> >been discussed in brief on #atom, but no solution and even no
> >specifications have been found on other calendars. Someone managed to dig
> >out some Persian blogs, though, but we couldn't find out if those had any
> >feeds (I speak very poor Persion. None, actually ;).
> >
> >If Atom is not going to support non-Gregorian calendars, it should be
> >clear that it doesn't, imho.
> 
> I think that:
> - Atom should concentrate on markup for machine readable dates
> - Machine readable dates should be in ISO 8601 notation, which implies
>   the Gregorian calendar
> - The spec should make clear that this is a format for exchanging
>   date/time information, and does not limit how these are being shown
>   to a user, or input by a user.
> - People who want to add anything else (such as "on a sunny Sunday
>   in July" or so) can always put that into the title/description/
>   actual item text/wherever appropriate.

I'd agree with all this, but would also like to keep open possibility of 
non-Gregorian dates being allowed in feeds using extension namespaces.

I've already been gently flamed offlist for "political correctness" so perhaps
I should clarify that I see this as one of many motivations for a
principled approach to namespace extension. If a community of Atom
producers and consumers, say in Iran, decide they would like to expose
their favourite date notation as a property of feeds and items, and
eg. write XSLT to consume it... wouldn't that be a good thing? (assuming
they include the standard gregorian dates too). This to me seems
broadly analagous to movie site feeds exposing showtime info, personal banking 
feeds exposing payment time info, and the general
utility of representing other kinds of date/time info associated with
the topic of feed items, and doing so in nice clean XML, rather than
mixed up in the textual payload of "title/description/actual item text".

The RSS0.9x world already suffered from people squeezing structured info
(more dates, topics, etc) into textual/prose fields. I'd prefer Atom to create
a market where producers and consumers of interesting feeds can deploy 
stuff using namespace'd extensions, rather than encourage overloading. 

Longwinded way of saying, +1 to: 

> - People who want to add anything else (such as "on a sunny Sunday
>   in July" or so) can always put that into the title/description/
>   actual item text/wherever appropriate.

...though I'd explicitly note something like:

   "...actual item text / wherever appropriate, which might include 
   the use of extension XML namespaces within the Atom feed."

cheers,

Dan


ps. do XSLTs exist to go to/from gregorian and non-gregorian dates? I
looked around for a convertor for the Persian calendar, with an
Atom2HTML.xsl use case in mind, but didn't find anything. Quite likely
wrong search term...



From owner-atom-syntax@mail.imc.org  Fri Jul 16 07: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 HAA22259
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 07:01: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 i6GAt5KE041461;
	Fri, 16 Jul 2004 03:55: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 i6GAt5MN041460;
	Fri, 16 Jul 2004 03:55:05 -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 i6GAt34K041442
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 03:55:04 -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 i6GAt2s07522
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 13:55:02 +0300 (EET DST)
X-Scanned: Fri, 16 Jul 2004 13:54:55 +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 i6GAstVh014567
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 13:54:55 +0300
Received: from mgw-int1.ntc.nokia.com (172.21.143.96)
	by esdks004.ntc.nokia.com 00lG2qvf; Fri, 16 Jul 2004 13:54:53 EEST
Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82])
	by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6GAsmn17092
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 13:54:49 +0300 (EET DST)
Received: from nokia.com ([172.21.60.114]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Fri, 16 Jul 2004 13:54:45 +0300
Message-ID: <40F7B3F3.5080008@nokia.com>
Date: Fri, 16 Jul 2004 13:54:43 +0300
From: Janne Jalkanen <Janne.Jalkanen@nokia.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040122
X-Accept-Language: fi, en-us, en
MIME-Version: 1.0
To: Atomlist Syntax <atom-syntax@imc.org>
Subject: Re: GET before PUT on an EditURI
References: <BC806156-D51B-11D8-8C42-000A95A51C9E@sun.com> <3f1451f5040713192666d217c4@mail.gmail.com> <8B1D1724-D540-11D8-A503-000A95A51C9E@sun.com> <3f1451f50407132005ec21d76@mail.gmail.com> <40F67602.2000002@nokia.com> <40F67BAD.6070708@franklinmint.fm>
In-Reply-To: <40F67BAD.6070708@franklinmint.fm>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 Jul 2004 10:54:45.0191 (UTC) FILETIME=[4E1F2D70:01C46B23]
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 don't understand why we need this. If the client PUTs something that 
> conflicts with the state of  the resource, it's the server's 
> responsibility to spot the conflict. All server code will have to 
> assume that clients will be ignorantly PUTing things all over the place. 

Err... That's what I thought what I was saying :-).

Of course the server code needs to be checking for ignorant PUTs.  I 
mean, someone might write even a client which does not obey the Atom 
spec, and would break thus every server it touches :-).

I'm just saying that there should probably be a way for a server to 
return a nonce value to the client, so that when it does a PUT, a 
conflict will not occur.  ETags are probably the best way of doing this, 
says my intuition.  But perhaps this practice should be codified somehow.

/Janne



From owner-atom-syntax@mail.imc.org  Fri Jul 16 07:04: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 HAA22365
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 07:04: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 i6GAvWaF042377;
	Fri, 16 Jul 2004 03:57: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 i6GAvWA6042376;
	Fri, 16 Jul 2004 03:57:32 -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 i6GAvVlo042354
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 03:57:31 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 98655 messnum 2841868 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 16 Jul 2004 10:57:27 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail07.svc.cra.dublin.eircom.net (qp 98655) with SMTP; 16 Jul 2004 10:57:27 -0000
Message-ID: <40F7B48C.9060705@dehora.net>
Date: Fri, 16 Jul 2004 11:57:16 +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: Dan Brickley <danbri@w3.org>
CC: Martin Duerst <duerst@w3.org>, Walter Underwood <wunder@verity.com>,
        Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceMustBeWellFormed
References: <14be96d30407141427187f294d@mail.gmail.com> <14be96d30407061142441f70ee@mail.gmail.com> <40F56B2A.8050500@intertwingly.net> <14be96d304071411092c2c44f4@mail.gmail.com> <p06110426bd1b3deea52a@10.20.30.249> <14be96d30407141427187f294d@mail.gmail.com> <4.2.0.58.J.20040716174907.0568ef18@localhost> <20040716093545.GG10836@homer.w3.org>
In-Reply-To: <20040716093545.GG10836@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:

> I wonder whether "transcoding server" is being used in different ways;
> sometimes to refer to char encoding conversion and sometimes, more
> broadly, to proxies that do other kinds of conversion (eg. HTML to WAP,
> RSS to Atom, ...). 

In a past life I worked on 'transcoding' proxy. I can confirm their 
  potential use is far more than character encodings (such as 
manipulating sessions, css, javascript, java classes, soap headers, 
porn filtering, etc).

cheers
Bill



From owner-atom-syntax@mail.imc.org  Fri Jul 16 07:29: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 HAA23413
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 07:29: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 i6GBMaQs046966;
	Fri, 16 Jul 2004 04:22: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 i6GBMadx046965;
	Fri, 16 Jul 2004 04:22:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GBMY0R046955
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 04:22: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-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6GBMSo13109;
	Fri, 16 Jul 2004 14:22:28 +0300 (EET DST)
X-Scanned: Fri, 16 Jul 2004 14:22:19 +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 i6GBMJNm016158;
	Fri, 16 Jul 2004 14:22:19 +0300
Received: from mgw-int1.ntc.nokia.com (172.21.143.96)
	by esdks004.ntc.nokia.com 00vLjgFz; Fri, 16 Jul 2004 14:22:18 EEST
Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77])
	by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6GBM5n08464;
	Fri, 16 Jul 2004 14:22:10 +0300 (EET DST)
Received: from nokia.com ([172.21.60.114]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Fri, 16 Jul 2004 14:21:51 +0300
Message-ID: <40F7BA4D.1040404@nokia.com>
Date: Fri, 16 Jul 2004 14:21:49 +0300
From: Janne Jalkanen <Janne.Jalkanen@nokia.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040122
X-Accept-Language: fi, en-us, en
MIME-Version: 1.0
To: ext Tim Bray <Tim.Bray@Sun.COM>
CC: Atomlist <atom-syntax@imc.org>
Subject: J2ME limitations Was: PacePutDelete Withdrawn
References: <20040715142548.9823.qmail@web41501.mail.yahoo.com> <40F69CFF.6080802@franklinmint.fm> <1DFD193F-D67D-11D8-A6EC-000A95A51C9E@sun.com>
In-Reply-To: <1DFD193F-D67D-11D8-A6EC-000A95A51C9E@sun.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 Jul 2004 11:21:51.0500 (UTC) FILETIME=[177A3CC0:01C46B27]
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



> However, I'm not technically competent to judge this, so I've asked 
> Russell Beattie and some Java heavies inside Sun who I should go hunt 
> down to drop by here and advise us.  Until we get such advice, I don't 
> think we should take any of our options (e.g. those in Joe's original 
> Pace) definitively off the table.

The issue is with the default Java J2ME MIDP implementation, and 
specifically the HttpConnection class which only allows the verbs GET, 
HEAD and POST.  I have no idea why this decision was made.  Probably 
because those cover 99.99% of all HTTP traffic.  Note that this also 
affects any prospective WebDAV clients on J2ME.

However, there are two - no, three - ways around this:

a) you can write your own HttpConnection class, which allows any verb.  
It'll just increase the size of your application, no worries.  You can 
even take Sun's source code and modify it slightly, and then use that (I 
haven't looked at license issues here).  This is however possible only 
on MIDP 2.0, as 1.0 does not have a SocketConnection.
2) Do not use Java, code directly on top of the Operating System (say, 
Symbian or PocketPC).  For many purposes, this is already the preferable 
choice.  No such restrictions are in place when you access the code 
natively.  It also allows you to do other cool stuff like link to the 
phone internal databases, or access the multimedia functionality (such 
as the camera).
iii) Write a proxy that can translate your near-atom-protocol into 
fully-fledged Atom protocol.

My guess is that most complicated blog clients will be OS native anyway, 
so they are not hampered by J2ME limitations.  However, there are plenty 
of phones (such as the Nokia Series 40 phones) which do not provide user 
access to the native OS, and Java is the only way you can install 
software on those.  (These are not in general, BTW, referred to as 
"smart phones" :).

I would however, like to point out that XML-RPC/MetaweblogAPI still 
exists and works.  Atom is not going to kill it for a long time.  So, 
the question is, do we want to ensure maximum support for all mid- and 
low-end cell phones (where the average replacement time is very fast 
anyway) now, or do we just say that "work around it, or use XML-RPC, the 
situation will get better in two years."

The first choice will increase the complexity of the spec, the latter 
will make it simpler, but the adoption rate will slow down.

However, it's not like "by ditching SOAP, we'll prevent anyone with a 
cell phone from ever again blogging."  The situation is not that grim.

/Janne



From owner-atom-syntax@mail.imc.org  Fri Jul 16 07:30: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 HAA23466
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 07:29:59 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GBOH5u047202;
	Fri, 16 Jul 2004 04:24:17 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6GBOHGt047201;
	Fri, 16 Jul 2004 04:24:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GBOFIX047187
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 04:24:16 -0700 (PDT)
	(envelope-from Janne.Jalkanen@nokia.com)
Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120])
	by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6GBOEo15076;
	Fri, 16 Jul 2004 14:24:14 +0300 (EET DST)
X-Scanned: Fri, 16 Jul 2004 14:23:51 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost)
	by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i6GBNpds018844;
	Fri, 16 Jul 2004 14:23:51 +0300
Received: from mgw-int2.ntc.nokia.com (172.21.143.97)
	by esdks001.ntc.nokia.com 002nKnwM; Fri, 16 Jul 2004 14:23:49 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 i6GBNmu20122;
	Fri, 16 Jul 2004 14:23:48 +0300 (EET DST)
Received: from nokia.com ([172.21.60.114]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Fri, 16 Jul 2004 14:23:48 +0300
Message-ID: <40F7BAC2.4050204@nokia.com>
Date: Fri, 16 Jul 2004 14:23:46 +0300
From: Janne Jalkanen <Janne.Jalkanen@nokia.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040122
X-Accept-Language: fi, en-us, en
MIME-Version: 1.0
To: mint@franklinmint.fm
CC: Tim Bray <Tim.Bray@Sun.COM>, Atomlist <atom-syntax@imc.org>
Subject: Re: PacePutDelete Withdrawn
References: <20040715142548.9823.qmail@web41501.mail.yahoo.com> <40F69CFF.6080802@franklinmint.fm> <1DFD193F-D67D-11D8-A6EC-000A95A51C9E@sun.com> <40F6BD27.4060805@franklinmint.fm>
In-Reply-To: <40F6BD27.4060805@franklinmint.fm>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 Jul 2004 11:23:48.0142 (UTC) FILETIME=[5D0064E0:01C46B27]
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



> Even if it's *impossible* to send a PUT with MIDP, that doesn't mean 
> these phones can't use Atom. Developers can still use the underlying 
> platform (e.g. Series60). In fact, I gather it's often necessary to do 
> so to access some phone features like wallpaper, etc. Here is an 
> already-deployed Series60 app (presumably written in C++) that uses 
> the Atom Publishing Protocol:
>
> http://www.futurice.fi/products.html

True, it's C++ and native Symbian.

(Teaches me to read all the emails before starting to reply to them :)

/Janne



From owner-atom-syntax@mail.imc.org  Fri Jul 16 07: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 HAA23766
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 07: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 i6GBTXqN047933;
	Fri, 16 Jul 2004 04: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 i6GBTXmQ047932;
	Fri, 16 Jul 2004 04:29:33 -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 i6GBTWO5047925
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 04:29:32 -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 i6GBUGdF019475;
	Fri, 16 Jul 2004 07:30:16 -0400
Message-ID: <40F7BC15.5050903@intertwingly.net>
Date: Fri, 16 Jul 2004 07:29:25 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: kwark.1511609@bloglines.com
CC: atom-syntax@imc.org
Subject: Re: PacePutDelete Withdrawn
References: <1089969407.2673166242.28295.sendItem@bloglines.com>
In-Reply-To: <1089969407.2673166242.28295.sendItem@bloglines.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


kwark.1511609@bloglines.com wrote:
> 
> I  don't have any problem with a SOAP alternative for text objects. I can
> live with the additional processing requirements and increased payload size
> of the SOAP envelope.
> 
> I do have a problem with base64 encoding and additional
> gzipping of binary content, in order to tunnel binary objects over SOAP, when
> there exists no simple POST alternative.

Peter, you impress me as an engineer that understands tradeoffs.  My 
question to you is how important is the ability to not have to 
base64/gzip in the specific scenario of a PUT (i.e., replacement) 
operation?  My presumption is that editing of existing documents is a 
relatively infrequent operation.

Now, the thought process behind that question.

I don't want Atom to have to cater to the least common denominator.  If 
someday we see a need for the WebDav LOCK method, I would like to be 
able to consider it without having to worry about it being blocked or 
eaten by some legacy gateway.

And, on the other hand, I don't want whatever XML POST fallback we 
decide on to be evolved randomly and in the same way that most gateways 
seem to have been - by sampling actual usage and reacting to complaints.

HTTP seems to go well beyond the 80/20 point.  Enough so that there 
really should only be one fallback, not a separate one for web services, 
another one for cell phones, and another one for whatever.

Therefore, I'd like the fallback to be comprehensive - a 1 to 1 and onto 
mapping of requests that can be done - methods, auth, the works.  I'd 
also like the fallback to be considered in much the same way as HTTP 
stacks treat content-transfer-encoding: something that may be necessary 
to achieve the transfer across a given gateway, but not something that 
conveys any additional signal or state to the target application.

Net: if the servers implement the fallback mechanism as a simple mapping 
onto the primary mechanism, and then process the request as if they had 
received the primary form; then clients should be able to mix and match 
with impunity.

To take a concrete example: there will be a sleek and simple way to do a 
DELETE.  If for some reason you find that you can't use it, you are 
provided with an alternative.  The amount of bloat in the alternative is 
non-negotiable: if you don't like it, fix your gateway.  We picked the 
most popular protocol on the planet and provided a fully functional 
fallback: I believe that more than qualifies as going above and beyond 
the call of duty.

I suspect that most people who can't use the primary mechanism defined 
for DELETE will not complain too loudly, as the overhead of the fallback 
in this case is constant, and the usage profile of this operation is 
relatively small.

With this background in place, the more general form of the question 
above is whether there is ANY operation for which BOTH the primary AND 
fallback defined are untenable for any given client and usage profile?

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Fri Jul 16 07:43: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 HAA24000
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 07:43: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 i6GBWv5g048519;
	Fri, 16 Jul 2004 04:32: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 i6GBWvi0048517;
	Fri, 16 Jul 2004 04:32:57 -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 i6GBWt9p048473
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 04:32:56 -0700 (PDT)
	(envelope-from Janne.Jalkanen@nokia.com)
Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120])
	by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6GBWrs23390;
	Fri, 16 Jul 2004 14:32:53 +0300 (EET DST)
X-Scanned: Fri, 16 Jul 2004 14:31:34 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost)
	by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i6GBVYO3030353;
	Fri, 16 Jul 2004 14:31:34 +0300
Received: from mgw-int2.ntc.nokia.com (172.21.143.97)
	by esdks001.ntc.nokia.com 00xhEpvZ; Fri, 16 Jul 2004 14:31:33 EEST
Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28])
	by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6GBVXu23459;
	Fri, 16 Jul 2004 14:31:33 +0300 (EET DST)
Received: from nokia.com ([172.21.60.114]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Fri, 16 Jul 2004 14:31:33 +0300
Message-ID: <40F7BC93.5050901@nokia.com>
Date: Fri, 16 Jul 2004 14:31:31 +0300
From: Janne Jalkanen <Janne.Jalkanen@nokia.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040122
X-Accept-Language: fi, en-us, en
MIME-Version: 1.0
To: ext Ken MacLeod <ken@bitsko.slc.ut.us>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Don't bake discrimination into the Atom core (was Re: Low-hanging
 fruit: multipart/alternative)
References: <A65D9796-D519-11D8-8C42-000A95A51C9E@textuality.com>	<14be96d304071317541efca684@mail.gmail.com>	<7FBABBD6-D531-11D8-A503-000A95A51C9E@textuality.com>	<14be96d304071319181e2bf741@mail.gmail.com>	<1393DBDA-D540-11D8-A503-000A95A51C9E@textuality.com>	<opsa4zq3fhuvpchu@quark> <14be96d304071410083cc71f90@mail.gmail.com>	<50434192-D5BD-11D8-A6EC-000A95A51C9E@textuality.com>	<5C39B3EC-D5BF-11D8-AA19-000A95BD86C0@mnot.net>	<20040714184022.GU3805@homer.w3.org> <1089915475.2692.33.camel@homer> <m38ydljc9x.fsf@bitsko.slc.ut.us>
In-Reply-To: <m38ydljc9x.fsf@bitsko.slc.ut.us>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 Jul 2004 11:31:33.0521 (UTC) FILETIME=[72639810:01C46B28]
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



>PaceExtendedResourcePosting uses a technique similar to the earlier
>PaceDontSyndicate proposal, of providing an alternate usage of <entry>
>for attaching metadata to a resource, but without making that resource
>a published entry in its own right.  My preference over that would be
>to use the atom:resource element from PaceResource (make clear that
>this is a resource metadata container resource, not an entry
>resource).  My preference over *that* would be to use WebDAV
>properties :-).
>  
>
WebDAV is cool, too, but note that it's also restricted by the same 
problems on the MIDP platform - and you'd have to do PROPPATCH and 
PROPFIND support in addition to DELETE and PUT :-)

PaceExtendedResourcePosting has a couple of good sides:
* Suits well with the current Atom structure (uses same syntax, Resource 
Metadata is exactly an EditURI)
* Is not as complex as a full WebDAV class 1 system
* Does not require the server side to implement a DAV server as well
* Simple to implement
* Does not require extending HTTP

But on the other hand
* It duplicates some of the DAV functionality
* Is not as powerful.

I have really no opinion on using <resource> instead of <entry>.

/Janne



From owner-atom-syntax@mail.imc.org  Fri Jul 16 08: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 IAA24786
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 08: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 i6GBsSsl051364;
	Fri, 16 Jul 2004 04:54: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 i6GBsSkk051363;
	Fri, 16 Jul 2004 04:54:28 -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 i6GBsQs3051356
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 04:54:27 -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 i6GBsRs23735;
	Fri, 16 Jul 2004 14:54:27 +0300 (EET DST)
X-Scanned: Fri, 16 Jul 2004 14:53:30 +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 i6GBrUcs025086;
	Fri, 16 Jul 2004 14:53:30 +0300
Received: from mgw-int1.ntc.nokia.com (172.21.143.96)
	by esdks004.ntc.nokia.com 00IDq6HK; Fri, 16 Jul 2004 14:53:29 EEST
Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82])
	by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6GBrSn01781;
	Fri, 16 Jul 2004 14:53:28 +0300 (EET DST)
Received: from nokia.com ([172.21.60.114]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Fri, 16 Jul 2004 14:53:27 +0300
Message-ID: <40F7C1B5.7060108@nokia.com>
Date: Fri, 16 Jul 2004 14:53:25 +0300
From: Janne Jalkanen <Janne.Jalkanen@nokia.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040122
X-Accept-Language: fi, en-us, en
MIME-Version: 1.0
To: ext Sam Ruby <rubys@intertwingly.net>
CC: kwark.1511609@bloglines.com, atom-syntax@imc.org
Subject: Re: PacePutDelete Withdrawn
References: <1089969407.2673166242.28295.sendItem@bloglines.com> <40F7BC15.5050903@intertwingly.net>
In-Reply-To: <40F7BC15.5050903@intertwingly.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 Jul 2004 11:53:27.0750 (UTC) FILETIME=[81BB0660:01C46B2B]
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



> Peter, you impress me as an engineer that understands tradeoffs.  My 
> question to you is how important is the ability to not have to 
> base64/gzip in the specific scenario of a PUT (i.e., replacement) 
> operation?  My presumption is that editing of existing documents is a 
> relatively infrequent operation.

It is infrequent for binaries on a cell phone.  I think we can live 
without it.  You can't put a very big editor inside a J2ME application 
anyway.

PaceExtendedResourcePosting uses POST to send the binaries, so it should 
be safe.

But *requiring* the use of gzip/base64 is a big no-no.

> I don't want Atom to have to cater to the least common denominator.  
> If someday we see a need for the WebDav LOCK method, I would like to 
> be able to consider it without having to worry about it being blocked 
> or eaten by some legacy gateway.

Me neither.

> Therefore, I'd like the fallback to be comprehensive - a 1 to 1 and 
> onto mapping of requests that can be done - methods, auth, the works.  
> I'd also like the fallback to be considered in much the same way as 
> HTTP stacks treat content-transfer-encoding: something that may be 
> necessary to achieve the transfer across a given gateway, but not 
> something that conveys any additional signal or state to the target 
> application.

I'd still go for putting the "action" in a header, simply because that 
would not assume that the transported entry is XML (as in case with a 
resource PUT).

/Janne



From owner-atom-syntax@mail.imc.org  Fri Jul 16 08:03:21 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24814
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 08:03:21 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GBtIpj051462;
	Fri, 16 Jul 2004 04:55: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 i6GBtI6v051461;
	Fri, 16 Jul 2004 04:55:18 -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 ([216.126.80.155])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GBtHs2051395
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 04:55:18 -0700 (PDT)
	(envelope-from distobj@acm.org)
Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian))
	id 1BlRJA-0001M7-00; Fri, 16 Jul 2004 07:55:20 -0400
Date: Fri, 16 Jul 2004 07:55:19 -0400
To: Joe Gregorio <joe.gregorio@gmail.com>
Cc: Atomlist Syntax <atom-syntax@imc.org>
Subject: Re: GET before PUT on an EditURI
Message-ID: <20040716115519.GV30868@markbaker.ca>
References: <BC806156-D51B-11D8-8C42-000A95A51C9E@sun.com> <3f1451f5040713192666d217c4@mail.gmail.com> <20040714044914.GT30868@markbaker.ca> <3f1451f504071505566985d8cd@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3f1451f504071505566985d8cd@mail.gmail.com>
User-Agent: Mutt/1.3.28i
From: Mark Baker <distobj@acm.org>
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>


Sounds good!

By "covered" though, I don't think anything more than a blurb saying
"Atom enabled agents MAY support lost update detection.  Those doing
so SHOULD support the mechanism described in
http://www.w3.org/1999/04/Editing/"

Mark.

On Thu, Jul 15, 2004 at 08:56:22AM -0400, Joe Gregorio wrote:
> This does lead to a question of documentation. Should 
> detection of lost updates when using the Atom Publishing 
> Protocol be written into the spec? I don't believe
> that every Atom server MUST support it, just that
> *if* they are going to support detecting lost updates
> than this is how you do it interoperably.
>
> For example, a new section on Detecting Lost Updates 
> could be added that covered that material
> in http://www.w3.org/1999/04/Editing/
> specifically applied to the EditURI.

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

  Seeking work on large scale application/data integration projects
  and/or the enabling infrastructure for same.



From owner-atom-syntax@mail.imc.org  Fri Jul 16 08:15: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 IAA25731
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 08: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 i6GC6dsx053110;
	Fri, 16 Jul 2004 05:06: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 i6GC6daH053109;
	Fri, 16 Jul 2004 05:06:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from w02.bloglines.com (w02.bloglines.com [216.148.212.184])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6GC6ddp053101
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 05:06:39 -0700 (PDT)
	(envelope-from kwark.1511609@bloglines.com)
Received: (qmail 7757 invoked by uid 99); 16 Jul 2004 12:06:36 -0000
Message-ID: <1089979596.1176643168.7751.sendItem@bloglines.com>
Date: 16 Jul 2004 12:06:36 -0000
From: kwark.1511609@bloglines.com
To: Janne.Jalkanen@nokia.com
CC: atom-syntax@imc.org
Subject: Re: J2ME limitations Was: PacePutDelete Withdrawn
MIME-Version: 1.0
Content-Type: text/plain
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


--- Janne Jalkanen <Janne.Jalkanen@nokia.com wrote:

> The issue is with
the default Java J2ME MIDP implementation, and 
> specifically the HttpConnection
class which only allows the verbs GET, 
> HEAD and POST.  I have no idea
why this decision was made.  Probably 
> because those cover 99.99% of all
HTTP traffic.  Note that this also 
> affects any prospective WebDAV clients
on J2ME.
> 

I have explained the possible reasons in my previous mail
to the group, but everybody seems to be ignoring the opinion of a wireless
expert.

> However, there are two - no, three - ways around this:
> 


> a) you can write your own HttpConnection class, which allows any verb.
 
> It'll just increase the size of your application, no worries.  You can

> even take Sun's source code and modify it slightly, and then use that
(I 
> haven't looked at license issues here).  
> This is however possible
only 
> on MIDP 2.0, as 1.0 does not have a SocketConnection.

I would
not advice anybody to do this because:
a) it leads to usability issues. F.e.
if your network operator requires a http proxy, you will have to provide a
different input screen for the user to enter the proxy address. This will
not only confuse the user, because he needs to enter it twice on his phone,
but sometimes the phone comes preconfigured by the network operator and the
user might not even know what a proxy is.
b) it leads to considerable bloat
of the application code: about 15 KiB extra, which for something simple as
an atom client could be up to half of the application.
c) It will not always
work on all phones. If a user is only connection over WAP by the operator,
he not be able to use this workaround.

> 2) Do not use Java, code directly
on top of the Operating System (say, 
> Symbian or PocketPC).  For many purposes,
this is already the preferable 
> choice.  No such restrictions are in place
when you access the code 
> natively.  It also allows you to do other cool
stuff like link to the 
> phone internal databases, or access the multimedia
functionality (such 
> as the camera).
> iii) Write a proxy that can translate
your near-atom-protocol into 
> fully-fledged Atom protocol.
> 

This
is not a workaround for MIDP, this is just ignoring the most viable existing
phone application platform in the galaxy.

> I would however, like to point
out that XML-RPC/MetaweblogAPI still 
> exists and works.  Atom is not going
to kill it for a long time.  So, 
> the question is, do we want to ensure
maximum support for all mid- and 
> low-end cell phones (where the average
replacement time is very fast 
> anyway) now, or do we just say that "work
around it, or use XML-RPC, the 
> situation will get better in two years."

> 

Aha, are you suggesting to require Atom servers to support MetaWebLog
API?
Also the base64 encoding for uploading binary objects through metaweblog
API is still a problem.

> The first choice will increase the complexity
of the spec, the latter 
> will make it simpler, but the adoption rate will
slow down.
> 
> However, it's not like "by ditching SOAP, we'll prevent
anyone with a 
> cell phone from ever again blogging."  The situation is
not that grim.
> 

No, it's more like: by requiring other methods such
then GET, HEAD and POST in Atom, you will make it impossible to deploy Atom
on 80% or more of the cell phones, capable of running downloadable applications.


Peter



From owner-atom-syntax@mail.imc.org  Fri Jul 16 08:42: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 IAA26951
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 08: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 i6GCXFNm056986;
	Fri, 16 Jul 2004 05:33: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 i6GCXFM6056985;
	Fri, 16 Jul 2004 05:33: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 i6GCXEsw056970
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 05:33:14 -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 i6GCXxik021966
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 08:33:59 -0400
Message-ID: <40F7CB03.8090009@intertwingly.net>
Date: Fri, 16 Jul 2004 08:33:07 -0400
From: Sam Ruby <rubys@intertwingly.net>
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@imc.org
Subject: Re: PacePutDelete Withdrawn
References: <BD1C9B03.13C0C%mint@franklinmint.fm> <0646779E-D6D0-11D8-A6EC-000A95A51C9E@sun.com> <17ref0hsek1v46oj3rupmlfolffae9t0un@4ax.com>
In-Reply-To: <17ref0hsek1v46oj3rupmlfolffae9t0un@4ax.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


Simon Fell wrote:

> On Thu, 15 Jul 2004 19:29:55 -0700, in soap you wrote:
> 
>>On Jul 15, 2004, at 5:35 PM, Robert Sayre wrote:
>>
>>>I don't understand why you think a full SOAP stack would be necessary. 
>>>It's
>>>been pointed out before that the difference between a SOAP doc and an 
>>>Atom
>>>doc with <action> element would come down to string constants.
>>
>>That sounds promising.  Is it OK to do brutally minimal profiles of 
>>SOAP?  Or do we run the risk of getting onto a slippery slope where 
>>people start assuming they can pack in arbitrary WS-* headers and other 
>>kinds of things that would be tractable for a general-purpose 
>>implementation and impossible for a handheld?
>>
>>It might be really nice for someone to do a Pace to replace the current 
>>section 6 of draft-atompub-protocol-00 to lay out very explicitly what 
>>an AtomPub client has to do to use the SOAP interface.  It would be 
>>nice if a cellphone engineer didn't have to go and try to understand 
>>the entirety of the SOAP spec before starting to code. -Tim
> 
> Hmmm, for other related specs, I've noticed that you've steared clear
> of restating them in the atom spec, and just referencing them. Why
> make the exception here ?. Now if you were talking primer material,
> then i'm all for it.
> 
> For those you think SOAP purely defines a document structure, go read
> the spec, there's a processing model as well you need to follow (not a
> particularly onerous one, I seem to recall seeing Sam implement the
> minimal processing rules in about 4 lines of python)

First, as background, to the best of my knowledge, neither Blogger's nor 
TypePad's implementation of the SOAP form of that Atom API makes use of 
anything more than an XML parser.  Both of these implementations were 
written by competent programmers with access to excellent SOAP stacks. 
It was my recommendation that such stacks (including Axis, one that I 
heavily contributed to) were overkill for this application.

I bring this up as I believe that running code is a much more effective 
argument than any amount of prose.

Simon mentions a processing model.  Much of that deals with agents and 
intermediaries.  If you are the final destination of a SOAP message, 
here is what you have to worry about:

  = = = Begin SOAP for the Squeamish = = =

1) You must be able to produce a fault.  Here[1] is a template. 
faultcode is a qname.  faultstring is a string.  detail is an any xml 
element you like in any namespace you like.  Beyond this, the values of 
these three are completely up to you.  In fact, if your application ONLY 
produces faults, you are SOAP compliant.

2) If you ever intend to do something OTHER than fault, there is still a 
case where you MUST produce a fault.  A soap:Envelope may have a single 
soap:Header.  If any of the immediate children of soap:Header have a 
soap:mustUnderstand="1" attribute, and you don't understand the header, 
then you MUST fault.

  = = = End SOAP for the Squeamish = = =

These rules can be implemented with an XML parser, one page of code, and 
one or perhaps two templates.

Applications like Atom are free to fully specify and constrain the 
schema of messages that they will accept in the Body.  Implementations 
are encouraged to ignore headers that they don't understand, unless of 
course such headers are marked mustUnderstand.

Three elements (Envelope, Body, Header) and one attribute 
(mustUnderstand) are added to your vocabulary for normal requests. 
soap:Fault, faultcode, faultstring, detail, and action (not mentioned 
above, but can be safely ignored) complete the set.

At the moment, I would recommend SOAP 1.1 as opposed to SOAP 1.2, for 
reasons similar to the request that we support XML 1.0 instead of XML 1.1.

- Sam Ruby

[1] http://www.intertwingly.net/code/mombo/template/soapfault.tmpl



From owner-atom-syntax@mail.imc.org  Fri Jul 16 09:04: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 JAA28253
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 09:04: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 i6GCue2j060624;
	Fri, 16 Jul 2004 05:56: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 i6GCuenc060623;
	Fri, 16 Jul 2004 05:56:40 -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 i6GCuco4060615
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 05:56:39 -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 i6GCvOcI022997;
	Fri, 16 Jul 2004 08:57:24 -0400
Message-ID: <40F7D080.40005@intertwingly.net>
Date: Fri, 16 Jul 2004 08:56:32 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Janne Jalkanen <Janne.Jalkanen@nokia.com>
CC: atom-syntax@imc.org
Subject: Re: PacePutDelete Withdrawn
References: <1089969407.2673166242.28295.sendItem@bloglines.com> <40F7BC15.5050903@intertwingly.net> <40F7C1B5.7060108@nokia.com>
In-Reply-To: <40F7C1B5.7060108@nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


Janne Jalkanen wrote:
> 
>> Peter, you impress me as an engineer that understands tradeoffs.  My 
>> question to you is how important is the ability to not have to 
>> base64/gzip in the specific scenario of a PUT (i.e., replacement) 
>> operation?  My presumption is that editing of existing documents is a 
>> relatively infrequent operation.
> 
> It is infrequent for binaries on a cell phone.  I think we can live 
> without it.  You can't put a very big editor inside a J2ME application 
> anyway.
> 
> PaceExtendedResourcePosting uses POST to send the binaries, so it should 
> be safe.
> 
> But *requiring* the use of gzip/base64 is a big no-no.

I am suggesting the requirement to *either* use HTTP method PUT *or* to 
base64 the content in the scenario of replacement.

I've never heard of anybody suggesting the requirement of gzip, but I 
have heard it mentioned as a potential way for trading bandwidth 
problems for battery life problems.

For those who have not ever had the opportunity to talk to an engineer 
from a cell phone manufacturer, I highly recommend it.  It gives you an 
interesting perspective.  You gain an newfound appreciation for the laws 
of thermodynamics, which when applied here boil down to:

   Every time you flip a bit, you generate heat, and drain your battery.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Fri Jul 16 09:04: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 JAA28271
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 09:04: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 i6GCvmnx060774;
	Fri, 16 Jul 2004 05:57: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 i6GCvmsk060773;
	Fri, 16 Jul 2004 05:57:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GCvl88060767
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 05:57:48 -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 i6GCwW2W023046;
	Fri, 16 Jul 2004 08:58:32 -0400
Message-ID: <40F7D0C5.2080607@intertwingly.net>
Date: Fri, 16 Jul 2004 08:57:41 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: kwark.1511609@bloglines.com
CC: atom-syntax@imc.org
Subject: Re: J2ME limitations Was: PacePutDelete Withdrawn
References: <1089979596.1176643168.7751.sendItem@bloglines.com>
In-Reply-To: <1089979596.1176643168.7751.sendItem@bloglines.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


kwark.1511609@bloglines.com wrote:

> I have explained the possible reasons in my previous mail
> to the group, but everybody seems to be ignoring the opinion of a wireless
> expert.

Please don't give up on us yet.  I'm pretty sure that we will get it 
eventually.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Fri Jul 16 09:12: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 JAA28864
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 09:12: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 i6GD2ipn062060;
	Fri, 16 Jul 2004 06:02:44 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6GD2iMn062059;
	Fri, 16 Jul 2004 06:02:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-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 i6GD2iQw062045
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 06:02:44 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from phys-bur-1 ([129.148.9.72])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i6GD0H53013407
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 07:00:37 -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 <0I0Y001014123H@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com)
 for atom-syntax@imc.org; Fri, 16 Jul 2004 09:02:25 -0400 (EDT)
Received: from mercury (vpn-129-150-33-38.Central.Sun.COM [129.150.33.38])
 by bur-mail1.east.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
 with ESMTP id <0I0Y00LUD47WGA@bur-mail1.east.sun.com> for atom-syntax@imc.org;
 Fri, 16 Jul 2004 09:02:25 -0400 (EDT)
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BlSLa-00065e-00	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 09:01:54 -0400
X-URL: http://nwalsh.com/
Date: Fri, 16 Jul 2004 09:01:54 -0400
From: Norman Walsh <ndw@nwalsh.com>
Subject: Re: Low-hanging fruit: compulsory namespaces
In-reply-to: <40F65098.1070708@dehora.net>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <87hds85cn1.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: <20040715004213.95239.qmail@web41204.mail.yahoo.com>
 <40F65098.1070708@dehora.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-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

/ Bill de h=D3ra <bill@dehora.net> was heard to say:
| Dare Obasanjo wrote:
|
|> This implies that Blogger is not using XML tools to
|> generate their feeds. No XML tools I've come across
|> would make such mistakes unless they are extremely
|> buggy. I think adding this text to the normative spec
|> is akin to adding stuff like 'best practices for
|> parsing XML with regexes' in the spec.
|
| Can you show me the spec text that indicates this is a bug? I couldn't
| find it.

I can't help answer that question until I understand the antecedent of
"this" in that sentence. I tried[1] to get an answer to that question
before, but we failed[2] to communicate. I'll try again momentarily.


                                        Be seeing you,
                                          norm

[1] http://www.imc.org/atom-syntax/mail-archive/msg06975.html
[2] http://www.imc.org/atom-syntax/mail-archive/msg06981.html

=2D-=20
Norman Walsh <ndw@nwalsh.com> | 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)

iD8DBQBA99HCOyltUcwYWjsRAsCZAJ414+5fvwbKpXUQDfjMDWF1WDszmQCfVDFB
BNUd49sWElAgsZmG7nSO69s=
=Y8iq
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Fri Jul 16 09: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 JAA28959
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 09:14: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 i6GD5b7A062660;
	Fri, 16 Jul 2004 06:05:37 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6GD5bdT062659;
	Fri, 16 Jul 2004 06:05: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 (mproxy.gmail.com [216.239.56.246])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6GD5aga062639
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 06:05:36 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id w29so1995054cwb
        for <atom-syntax@imc.org>; Fri, 16 Jul 2004 06:05:29 -0700 (PDT)
Received: by 10.11.118.46 with SMTP id q46mr98309cwc;
        Fri, 16 Jul 2004 06:05:29 -0700 (PDT)
Message-ID: <3f1451f504071606055f8ca365@mail.gmail.com>
Date: Fri, 16 Jul 2004 09:05:29 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: "kwark.1511609@bloglines.com" <kwark.1511609@bloglines.com>
Subject: Re: PacePutDelete Withdrawn
Cc: atom-syntax@imc.org
In-Reply-To: <1089969407.2673166242.28295.sendItem@bloglines.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <1089969407.2673166242.28295.sendItem@bloglines.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 16 Jul 2004 09:16:47 -0000, kwark.1511609@bloglines.com
<kwark.1511609@bloglines.com> wrote:
> --- Joe Gregorio <joe.gregorio@gmail.com wrote:
> 
> > I'm not familiar with
> either MIDP or CDLC, could
> > you explain a little of what they are and their
> relation
> > to the underlying HTTP protocol?
> >
> 
> MIDP stands for Mobile
> Information Device Profile and runs on top of CLDC (Connected Limited Device
> Configuration). The CLDC defines a GCF (Generic Connection Framework) that
> provides an API to communicate with the outside world (sockets, http, comm,
> ...). The MIDP running on top of CLDC defines and constrains the type of connections
> possible for MIDP compatible devices. For MIDP 1.0 the only required connection
> is HTTP and the only required methods to support are GET, HEAD and POST.
> 
> The reason why MIDP only allows for HTTP is simple: some phones run on networks
> which don't have a native TCP/IP stack.

Which is fine since HTTP isn't defined to run over TCP/IP.

> These networks can still provide for
> HTTP connectivity, by using the WSP (Wireless Session Protocol) stack, provided
> by the WAP browser. WSP provides a HTTP mapping on top of most physical networks.
> 
> WSP has support for arbritrary HTTP methods (OPTIONS, PUT, DELETE, ...).
> But because the main user of WSP stack is a WAP browser and this only ever
> uses GET and POST, you can only rely on these two methods two work reliably.
> Support for other methods on both phones and WAP gateways is very shaky.

I was following along up until here. I'm thinking of a wire trace 
of an HTTP session and I'm having trouble understanding
how different methods could be problematic. I am surely 
missing something here.

    Thanks,
    -joe



From owner-atom-syntax@mail.imc.org  Fri Jul 16 09:14: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 JAA28977
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 09:14: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 i6GCwAaH060861;
	Fri, 16 Jul 2004 05:58: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 i6GCwAnk060860;
	Fri, 16 Jul 2004 05:58:10 -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 i6GCw9OZ060854
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 05:58:09 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from phys-bur-1 ([129.148.9.72])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6GCwBil011433
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 06:58: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 <0I0Y00M013K2X8@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com)
 for atom-syntax@imc.org; Fri, 16 Jul 2004 08:58:10 -0400 (EDT)
Received: from mercury (vpn-129-150-33-38.Central.Sun.COM [129.150.33.38])
 by bur-mail1.east.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
 with ESMTP id <0I0Y00LAK40YGA@bur-mail1.east.sun.com> for atom-syntax@imc.org;
 Fri, 16 Jul 2004 08:58:10 -0400 (EDT)
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BlSHU-00063r-00	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 08:57:40 -0400
X-URL: http://nwalsh.com/
Date: Fri, 16 Jul 2004 08:57:39 -0400
From: Norman Walsh <ndw@nwalsh.com>
Subject: Re: Low-hanging fruit: compulsory namespaces
In-reply-to: <2359AA70-D5F8-11D8-9B45-000A95B09B46@google.com>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <87llhk5cu4.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: <20040715004213.95239.qmail@web41204.mail.yahoo.com>
 <2359AA70-D5F8-11D8-9B45-000A95B09B46@google.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-Type: text/plain

/ steve jenson <stevej@google.com> was heard to say:
| I'm using the DOM provided with Java 1.4.2. It does have
| plenty of bugs. I guess this is another one.

Maybe I'm just being sensitive :-), but I expect that's got more
to do with DOM's support for namespaces than a bug in 1.4.2.
It also depends on which DOM interfaces you're using.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Extinction, n. The raw material out of
http://nwalsh.com/            | which theology created the future
                              | state.--Ambrose Bierce

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA99DDOyltUcwYWjsRAtKSAJ9BkpDZfkC8Shn3wfdfTsxsQVgclwCgn1Cs
Lm0HQjuNHZWFrn8a2vj/9s4=
=h4oc
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Fri Jul 16 09: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 JAA00092
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 09:28: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 i6GDLISB064705;
	Fri, 16 Jul 2004 06:21:18 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6GDLIMB064704;
	Fri, 16 Jul 2004 06:21:18 -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 i6GDLF3p064669
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 06:21:17 -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 i6GDLAJ6005631
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 06:21:10 -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 <0I0Y004014YYLG@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com)
 for atom-syntax@imc.org; Fri, 16 Jul 2004 09:21:10 -0400 (EDT)
Received: from mercury (vpn-129-150-33-38.Central.Sun.COM [129.150.33.38])
 by bur-mail1.east.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
 with ESMTP id <0I0Y00L4J539GA@bur-mail1.east.sun.com> for atom-syntax@imc.org;
 Fri, 16 Jul 2004 09:21:10 -0400 (EDT)
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BlSdn-0006Un-00	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 09:20:43 -0400
X-URL: http://nwalsh.com/
Date: Fri, 16 Jul 2004 09:20:38 -0400
From: Norman Walsh <ndw@nwalsh.com>
Subject: Re: Low-hanging fruit: compulsory namespaces
In-reply-to: <40F55860.7000800@dehora.net>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <87d62w5brt.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: <6D6BAC41-D517-11D8-8C42-000A95A51C9E@sun.com>
 <40F46DAC.3030900@dehora.net> <D4AC57AE-D527-11D8-A503-000A95A51C9E@sun.com>
 <40F48A82.2020408@dehora.net> <3F81CFBF-D59D-11D8-A6EC-000A95A51C9E@sun.com>
 <40F5415E.5070100@dehora.net> <87k6x6mwef.fsf@nwalsh.com>
 <40F55860.7000800@dehora.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-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

/ Bill de h=D3ra <bill@dehora.net> was heard to say:
| Norman Walsh wrote:
|
|> I'm not actually sure what you're asking. Given this document
|>   <atom:feed xmlns:atom=3D"http://example.org/atom">
|>     <atom:content mode=3D"xml">
|>       <no-ns>Non-namespaced element</no-ns>
|>     </atom:content>
|>   </atom:feed>
|> What transformation do you think should be valid that you believe
|> I think is not valid?
|
| I'm not sure what you mean. To me, this is not about what I think
| about valid transformations in and out of default namespaces. It's
| about whether those transformations are specified.

This is where we're failing to communicate. Let's take a closer look
at my example:

1   <atom:feed xmlns:atom=3D"http://example.org/atom">
2     <atom:content mode=3D"xml">
3       <no-ns>Non-namespaced element</no-ns>
4     </atom:content>
5   </atom:feed>

On line 1, the atom:feed element is in the namespace
"http://example.org/atom". I expect that's uncontroversial. It follows
directly from Section 2 of the NS Rec.

Similarly, on Line 2, the atom:content element is in the namespace
"http://example.org/atom". This follows from Section 5.1 of the NS Rec.

Line 3 is probably the source of contention, but I may be wrong. I
contend that the element "no-ns" is not in any namespace. I base this
conclusion on the following statements from the NS Rec.

  1. From Section 5.2: "A default namespace is considered to apply to
     the element where it is declared (if that element has no
     namespace prefix), and to all elements with no prefix within the
     content of that element."

     There is no declaration for the default namespace in this
     document, so this rule does not apply.

  2. From Section 5.1: "The namespace declaration is considered to
     apply to the element where it is specified and to all elements
     within the content of that element, unless overridden by another
     namespace declaration with the same NSAttName part"

     Now, this says that the atom: prefix is in scope for the
     no-ns element, but

  3. From Section 3: "The Prefix provides the namespace prefix part of
     the qualified name, and must be associated with a namespace URI
     reference in a namespace declaration."

     The element "no-ns" does not have a prefix so it is not
     in that namespace.

If the no-ns element isn't in the namespace associated with the atom:
prefix (because it doesn't have a qualified name with the atom:
prefix), and if there's no default namespace declared, the element
no-ns is in no namespace.

I grant you that the NS Rec doesn't actually say that the default
default for the default namespace is "not in any namespace", but I
don't believe that any other interpretation is justified.

| Honestly, in the absence of being to point at normative text and say
| 'clown, your processing is broken',

If you agree with my description above, then "no-ns" is not in any
namespace. Any tool that loses that information and allows it to
"leak" into another namespace is broken.

If you don't agree with my description above, please tell me how you
interpret the spec differently.

                                        Be seeing you,
                                          norm

[1] http://www.w3.org/TR/REC-xml-names/

=2D-=20
Norman Walsh <ndw@nwalsh.com> | Life always comes to a bad end.--Marcel
http://nwalsh.com/            | Aym=C3=A9

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA99YmOyltUcwYWjsRAmolAJ43xsRUtqneNVCdIcK61+4qPZhj6QCgl9Xs
YR+sg7MDd+UA1dGJkNf0c48=
=LhV/
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Fri Jul 16 09: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 JAA01561
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 09:56:43 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GDlhDC068396;
	Fri, 16 Jul 2004 06: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 i6GDlh6K068395;
	Fri, 16 Jul 2004 06:47: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 i6GDlg98068377
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 06:47:42 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 80014 messnum 402900 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 16 Jul 2004 13:47:38 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail05.svc.cra.dublin.eircom.net (qp 80014) with SMTP; 16 Jul 2004 13:47:38 -0000
Message-ID: <40F7DC76.5050508@dehora.net>
Date: Fri, 16 Jul 2004 14:47:34 +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: Norman Walsh <ndw@nwalsh.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Low-hanging fruit: compulsory namespaces
References: <6D6BAC41-D517-11D8-8C42-000A95A51C9E@sun.com> <40F46DAC.3030900@dehora.net> <D4AC57AE-D527-11D8-A503-000A95A51C9E@sun.com> <40F48A82.2020408@dehora.net> <3F81CFBF-D59D-11D8-A6EC-000A95A51C9E@sun.com> <40F5415E.5070100@dehora.net> <87k6x6mwef.fsf@nwalsh.com> <40F55860.7000800@dehora.net> <87d62w5brt.fsf@nwalsh.com>
In-Reply-To: <87d62w5brt.fsf@nwalsh.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


Norman Walsh wrote:


> This is where we're failing to communicate. Let's take a closer look
> at my example:


   0   <outer xmlns="...">
> 1   <atom:feed xmlns:atom="http://example.org/atom">
> 2     <atom:content mode="xml">
> 3       <no-ns>Non-namespaced element</no-ns>
> 4     </atom:content>
> 5   </atom:feed>
   6   </outer>


> If you don't agree with my description above, please tell me how you
> interpret the spec differently.

See above.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Fri Jul 16 10: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 KAA03330
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 10:11: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 i6GE2dlu071025;
	Fri, 16 Jul 2004 07: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 i6GE2dOS071024;
	Fri, 16 Jul 2004 07: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 i6GE2cnm070821
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 07:02:38 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 17 Jul 2004 00:07:28 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sat, 17 Jul 2004 00:02:07 +1000
Subject: Re: PaceEntryIdRequired
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD1E1CFF.2016B%eric.scheid@ironclad.net.au>
In-Reply-To: <opsa7zixr2uvpchu@quark>
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 i6GE2dnm071018
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 16/7/04 5:38 PM, "Asbjørn Ulsberg" <asbjorn@tigerstaden.no> wrote:

>>> (3) detour: would it be better if <id> was instead @id on <entry>?
>> 
>> +1 on all three suggestions, but #3 may be worthy of some more debate.
> 
> Yes, putting a non-XML ID into an @id attribute would not be a good idea,
> imho. When discussing this in the beginning, @id was dropped because an
> Atom ID couldn't fit the syntactical constraints of an XML ID. An URI is
> not a valid XML ID, and thus should the ID not look like on either.
> Another attribute is fine, though.

+1




From owner-atom-syntax@mail.imc.org  Fri Jul 16 10:42: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 KAA06063
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 10:42: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 i6GEY9ht075456;
	Fri, 16 Jul 2004 07: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 i6GEY98P075447;
	Fri, 16 Jul 2004 07:34:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GEY7fI075439
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 07:34:08 -0700 (PDT)
	(envelope-from Janne.Jalkanen@nokia.com)
Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121])
	by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6GEY8b23020;
	Fri, 16 Jul 2004 17:34:09 +0300 (EET DST)
X-Scanned: Fri, 16 Jul 2004 17:33:12 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost)
	by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i6GEXCK7006406;
	Fri, 16 Jul 2004 17:33:12 +0300
Received: from mgw-int2.ntc.nokia.com (172.21.143.97)
	by esdks002.ntc.nokia.com 00kbqxyd; Fri, 16 Jul 2004 17:33:12 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 i6GEXCu19313;
	Fri, 16 Jul 2004 17:33:12 +0300 (EET DST)
Received: from nokia.com ([172.21.60.114]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Fri, 16 Jul 2004 17:33:11 +0300
Message-ID: <40F7E726.7000504@nokia.com>
Date: Fri, 16 Jul 2004 17:33:10 +0300
From: Janne Jalkanen <Janne.Jalkanen@nokia.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040122
X-Accept-Language: fi, en-us, en
MIME-Version: 1.0
To: "ext kwark.1511609@bloglines.com" <kwark.1511609@bloglines.com>
CC: atom-syntax@imc.org
Subject: Re: J2ME limitations Was: PacePutDelete Withdrawn
References: <1089979596.1176643168.7751.sendItem@bloglines.com>
In-Reply-To: <1089979596.1176643168.7751.sendItem@bloglines.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 Jul 2004 14:33:11.0555 (UTC) FILETIME=[D21F9D30:01C46B41]
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 have explained the possible reasons in my previous mail
>to the group, but everybody seems to be ignoring the opinion of a wireless
>expert.
>  
>
Well, yeah.  I didn't see your email before I sent mine :-).  I just 
wanted to provide another point of view, which is that the situation is 
not that grim.

But it is something that *needs* to be considered.

>
>I would
>not advice anybody to do this because:
>a) it leads to usability issues. F.e.
>if your network operator requires a http proxy, you will have to provide a
>different input screen for the user to enter the proxy address. This will
>not only confuse the user, because he needs to enter it twice on his phone,
>but sometimes the phone comes preconfigured by the network operator and the
>user might not even know what a proxy is.
>b) it leads to considerable bloat
>of the application code: about 15 KiB extra, which for something simple as
>an atom client could be up to half of the application.
>c) It will not always
>work on all phones. If a user is only connection over WAP by the operator,
>he not be able to use this workaround.
>  
>
I agree on all points.  But it is *still* a workaround.  I can't even 
say whether our own phones use the default HttpConnection class... It 
might be that it's slightly modified, in which case this workaround 
might fail horribly on some devices.

>
>This
>is not a workaround for MIDP, this is just ignoring the most viable existing
>phone application platform in the galaxy.
>  
>
In the galaxy?  :)

Well, it is workaround to the problem as such.

> Aha, are you suggesting to require Atom servers to support MetaWebLog
>
>API?
>  
>
No, but I am just suggesting that *most* servers that will support Atom 
already support MetaWeblog API, and Atom will *not* obsolete it 
immediately.  So it is possible to use it as a workaround.  Of course, 
there's a penalty involved.

>Also the base64 encoding for uploading binary objects through metaweblog
>API is still a problem.
>  
>
True.

>No, it's more like: by requiring other methods such
>then GET, HEAD and POST in Atom, you will make it impossible to deploy Atom
>on 80% or more of the cell phones, capable of running downloadable applications.
>  
>
Not impossible.  Just more difficult.

It's just a question of priorities.  My point of view is that this *is* 
an important subject, and that unless we want to ignore a very rapidly 
growing user segment (and make many developers rather unhappy), we do 
want to support a GET/HEAD/POST -only way of using Atom.  We *can* 
ignore it, which will result in a bunch of unstable and hackish 
applications, but it does not make it impossible to make an Atom client 
on Java MIDP.

Actually, I'm all for a Atom-Action header wrapped inside a POST (the 
alternate solution in PacePutDelete).  That would solve most of the 
problems in a rather simple way.  We wouldn't even need to go for base64 
in binary uploads (like in PaceSimpleResourcePosting).

So +1 for reworking PacePutDelete and using the alternate solution.  In 
case nobody else does it by Monday, I can grab it and rewrite the pace.

/Janne



From owner-atom-syntax@mail.imc.org  Fri Jul 16 10: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 KAA06237
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 10: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 i6GEeG4D076310;
	Fri, 16 Jul 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 i6GEeGN4076309;
	Fri, 16 Jul 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 w02.bloglines.com (w02.bloglines.com [216.148.212.184])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6GEeF3w076287
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 07:40:15 -0700 (PDT)
	(envelope-from kwark.1511609@bloglines.com)
Received: (qmail 1194 invoked by uid 99); 16 Jul 2004 14:40:13 -0000
Message-ID: <1089988813.3742655159.1191.sendItem@bloglines.com>
Date: 16 Jul 2004 14:40:13 -0000
From: kwark.1511609@bloglines.com
To: rubys@intertwingly.net
CC: atom-syntax@imc.org
Subject: Re: PacePutDelete Withdrawn
MIME-Version: 1.0
Content-Type: text/plain
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


--- Sam Ruby <rubys@intertwingly.net wrote:

> kwark.1511609@bloglines.com
wrote:
> > 
> > I  don't have any problem with a SOAP alternative for text
objects. I can
> > live with the additional processing requirements and increased
payload size
> > of the SOAP envelope.
> > 
> > I do have a problem with
base64 encoding and additional
> > gzipping of binary content, in order to
tunnel binary objects over SOAP, when
> > there exists no simple POST alternative.

> 
> Peter, you impress me as an engineer that understands tradeoffs.  My

> question to you is how important is the ability to not have to 
> base64/gzip
in the specific scenario of a PUT (i.e., replacement) 
> operation?  My presumption
is that editing of existing documents is a 
> relatively infrequent operation.

> 

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.

I'll try to do some on device benchmarking for base64/gzip
action this weekend. Running code and all that.

> Now, the thought process
behind that question.
> 
> I don't want Atom to have to cater to the least
common denominator.  

I see MIDP enabled Atom clients as possibly the largest
Atom user base. So, I do see value in this group trying to cater to MIDPs
needs. 

If we can make sure that most of the basic Atom operations can
be executed by a Midlet, I'm a happy puppy.

> If someday we see a need
for the WebDav LOCK method, I would like to be 
> able to consider it without
having to worry about it being blocked or 
> eaten by some legacy gateway.

> 

When that LOCK method is just required for some additional functionality,
that's fine. When it is required to do most of the basic stuff, it's not.


> And, on the other hand, I don't want whatever XML POST fallback we 
> decide on to be evolved randomly and in the same way that most gateways

> seem to have been - by sampling actual usage and reacting to complaints.

> 
> HTTP seems to go well beyond the 80/20 point.  Enough so that there

> really should only be one fallback, not a separate one for web services,

> another one for cell phones, and another one for whatever.
> 
> Therefore,
I'd like the fallback to be comprehensive - a 1 to 1 and onto 
> mapping
of requests that can be done - methods, auth, the works.  I'd 
> also like
the fallback to be considered in much the same way as HTTP 
> stacks treat
content-transfer-encoding: something that may be necessary 
> to achieve
the transfer across a given gateway, but not something that 
> conveys any
additional signal or state to the target application.
> 
> Net: if the servers
implement the fallback mechanism as a simple mapping 
> onto the primary
mechanism, and then process the request as if they had 
> received the primary
form; then clients should be able to mix and match 
> with impunity.
> 


> To take a concrete example: there will be a sleek and simple way to do
a 
> DELETE.  If for some reason you find that you can't use it, you are

> provided with an alternative.  The amount of bloat in the alternative
is 
> non-negotiable: if you don't like it, fix your gateway.  We picked
the 
> most popular protocol on the planet and provided a fully functional

> fallback: I believe that more than qualifies as going above and beyond

> the call of duty.
> I suspect that most people who can't use the primary
mechanism defined 
> for DELETE will not complain too loudly, as the overhead
of the fallback 
> in this case is constant, and the usage profile of this
operation is 
> relatively small.
> 
> With this background in place, the
more general form of the question 
> above is whether there is ANY operation
for which BOTH the primary AND 
> fallback defined are untenable for any
given client and usage profile?
> 

I was just a bit worried about the
direction this WG has taken recently. It used to be all about Bob (and Alice)
and interoperability. Recently I have noticed voices which want to remove
WSSE, SOAP alternatives from the spec (at least normative) and introduce WebDav
methods to get a feed index.
 IMHO this negatively impacts operability.

Your message provides me with enough confidence that this will not happen.


Thanks,

Peter



From owner-atom-syntax@mail.imc.org  Fri Jul 16 11:04: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 LAA07403
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 11:04: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 i6GEugSN078630;
	Fri, 16 Jul 2004 07:56:42 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6GEugqD078629;
	Fri, 16 Jul 2004 07:56: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 ([216.126.80.155])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GEuab2078557
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 07:56:42 -0700 (PDT)
	(envelope-from distobj@acm.org)
Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian))
	id 1BlU8h-0001wW-00
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 10:56:43 -0400
Date: Fri, 16 Jul 2004 10:56:43 -0400
To: atom-syntax@imc.org
Subject: Re: J2ME limitations Was: PacePutDelete Withdrawn
Message-ID: <20040716145643.GW30868@markbaker.ca>
References: <1089979596.1176643168.7751.sendItem@bloglines.com> <40F7E726.7000504@nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <40F7E726.7000504@nokia.com>
User-Agent: Mutt/1.3.28i
From: Mark Baker <distobj@acm.org>
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 Fri, Jul 16, 2004 at 05:33:10PM +0300, Janne Jalkanen wrote:
> So +1 for reworking PacePutDelete and using the alternate solution.  In 
> case nobody else does it by Monday, I can grab it and rewrite the pace.

-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

  Seeking work on large scale application/data integration projects
  and/or the enabling infrastructure for same.



From owner-atom-syntax@mail.imc.org  Fri Jul 16 11:17:25 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08255
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 11:17:25 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GFAJwM081880;
	Fri, 16 Jul 2004 08:10: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 i6GFAJN1081879;
	Fri, 16 Jul 2004 08:10:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GFAIgo081873
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 08:10:18 -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 i6GFB4LG028711
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 11:11:04 -0400
Message-ID: <40F7EFD4.1090608@intertwingly.net>
Date: Fri, 16 Jul 2004 11:10:12 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: New AtomPubIssuesList for 2004/07/16
References: <40E16215.6070507@intertwingly.net> <40EC9915.4050406@intertwingly.net> <40F539FE.7010600@intertwingly.net>
In-Reply-To: <40F539FE.7010600@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:

http://www.intertwingly.net/wiki/pie/AtomPubIssuesList

I've scheduled Pace409Response and PaceEntryTopLevel, the first to toss 
the protocol people something to bone, and the second is minor/editorial.

But mostly, and as Tim indicated [1], I tossed "something big, hairy, 
and ugly", namely link/service tags.  This is becoming a bit of a log 
jam.  There are six in all, and frankly if all we achieved was to close 
some and given the others an indication of what they need to address, 
then I would be happy.  I suspect, however, that we can do more: perhaps 
even come to consensus on the concepts expressed in one or more of these 
paces.

Hopefully, we can get into a rhythm with whereby big changes are 
discussed at the beginning of edit cycles and cleanup is done at the end 
of cycles.

- Sam Ruby

[1] http://www.imc.org/atom-syntax/mail-archive/msg07152.html



From owner-atom-syntax@mail.imc.org  Fri Jul 16 11:18: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 LAA08343
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 11:18: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 i6GF9NMO081559;
	Fri, 16 Jul 2004 08:09: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 i6GF9NOE081558;
	Fri, 16 Jul 2004 08:09:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from w02.bloglines.com (w02.bloglines.com [216.148.212.184])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6GF9MiT081519
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 08:09:22 -0700 (PDT)
	(envelope-from kwark.1511609@bloglines.com)
Received: (qmail 26984 invoked by uid 99); 16 Jul 2004 15:09:20 -0000
Message-ID: <1089990560.1020723103.26983.sendItem@bloglines.com>
Date: 16 Jul 2004 15:09:20 -0000
From: kwark.1511609@bloglines.com
To: joe.gregorio@gmail.com
CC: atom-syntax@imc.org
Subject: Re: PacePutDelete Withdrawn
MIME-Version: 1.0
Content-Type: text/plain
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


Joe,

--- Joe Gregorio <joe.gregorio@gmail.com wrote:

> 
> Which is
fine since HTTP isn't defined to run over TCP/IP.
> 
> > These networks
can still provide for
> > HTTP connectivity, by using the WSP (Wireless Session
Protocol) stack, provided
> > by the WAP browser. WSP provides a HTTP mapping
on top of most physical networks.
> > 
> > WSP has support for arbritrary
HTTP methods (OPTIONS, PUT, DELETE, ...).
> > But because the main user of
WSP stack is a WAP browser and this only ever
> > uses GET and POST, you
can only rely on these two methods two work reliably.
> > Support for other
methods on both phones and WAP gateways is very shaky.
> 
> I was following
along up until here. I'm thinking of a wire trace 
> of an HTTP session and
I'm having trouble understanding
> how different methods could be problematic.
I am surely 
> missing something here.
> 

Joe,

A WSP stack encodes
the HTTP request into a binary format and send that over WTP (Wireless Transport
Protocol) to a WAP gateway. The gateway decodes the request and send a normal
HTTP request to the designated web server. The gateway subsequently receives
the response, encodes it again and sends it enroute to the mobile phone.

The WSP stack is used by the WAP browser. It renders WML and allows the
user to interact with these pages. Similar to HTML it uses GET to follow links
and has functionality similar to HTML forms, which allow the user to POST
data to a web server.

So, even though the WSP specification allows for
arbitrary HTTP methods to be encoded, not all mobile phones and WAP gateways
support this and only support GET and POST.

In the early WAP days, even
POST support was not supported on some phones.

I guess this was the main
motivation for the MIDP JSR expert group to limit the number of required HTTP
methods. It ensures interoperability.

Net result: if your MIDlet opens
an HttpConnection on a Nokia3650 and call setRequestMethod("PUT") you get
an IOException.

If you are looking for someone, something to blaim, blaim
HTML.

Regards,

Peter



From owner-atom-syntax@mail.imc.org  Fri Jul 16 11:18: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 LAA08475
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 11:18: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 i6GF6lbs080276;
	Fri, 16 Jul 2004 08:06: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 i6GF6lp7080275;
	Fri, 16 Jul 2004 08:06:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from dns03.mail.yahoo.co.jp (dns03.mail.yahoo.co.jp [211.14.15.206])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6GF6k9q080184
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 08:06:46 -0700 (PDT)
	(envelope-from torumyax@yahoo.co.jp)
Received: from unknown (HELO yahoo.co.jp) (210.151.150.2 with poptime)
  by dns03.mail.yahoo.co.jp with SMTP; 16 Jul 2004 15:06:20 -0000
X-Apparently-From: <torumyax@yahoo.co.jp>
From: Toru Marumoto <torumyax@yahoo.co.jp>
To: atom-syntax@imc.org
Subject: Q: Put request should return Atom entry?
Date: Sat, 17 Jul 2004 00:04:48 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: TuruKame 3.55
Message-Id: <28C46B463CC0E9torumyax@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



I can't seem to find the answer in the Atom draft spec...

When a client sends a PUT request, what kind of a response should 
the client expects?

response code 301 and Atom entry?

Blooger returns "response code 301" AND an updated Atom entry, 
but some system return just "response code 200".




Toru Marumoto
     see you on the web!
________________________________


__________________________________________________
Do You Yahoo!?
http://bb.yahoo.co.jp/



From owner-atom-syntax@mail.imc.org  Fri Jul 16 11:31: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 LAA09459
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 11: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 i6GFLbYp084305;
	Fri, 16 Jul 2004 08:21: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 i6GFLbto084304;
	Fri, 16 Jul 2004 08:21:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from w02.bloglines.com (w02.bloglines.com [216.148.212.184])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6GFLbri084264
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 08:21:37 -0700 (PDT)
	(envelope-from kwark.1511609@bloglines.com)
Received: (qmail 4839 invoked by uid 99); 16 Jul 2004 15:21:35 -0000
Message-ID: <1089991295.4229176152.4838.sendItem@bloglines.com>
Date: 16 Jul 2004 15:21:35 -0000
From: kwark.1511609@bloglines.com
To: Tim.Bray@Sun.COM
CC: atom-syntax@imc.org
Subject: Re: PacePutDelete Withdrawn
MIME-Version: 1.0
Content-Type: text/plain
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 <Tim.Bray@Sun.COM wrote:
Thanks for your recent contributions
to Atom Syntax; they have been 
> very helpful.  Perhaps you'd like to introduce
yourself to the group?
> 

Ok, my name is Peter Mortier.

I'm a consultant/contract
programmer living and working in Belgium. I have been dabbling in Java since
1996. I've worked on everything from desktop applications (J2SE) to servers
(J2EE) and since 1999 also mobile phones (J2ME/MIDP), then known as KVM.

I have been lurking on this mailing list since it's started and finally
managed to decloack.

If your wondering about the strange e-mail address:
I'm subscribed to this mailing list through Bloglines, which provides me the
benefits of not having to worry about spam and being able to track this very
active mailing list in my preferred aggregator.

Regards,

Peter



From owner-atom-syntax@mail.imc.org  Fri Jul 16 11: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 LAA09567
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 11:33: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 i6GFPHve084820;
	Fri, 16 Jul 2004 08: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 i6GFPHxR084819;
	Fri, 16 Jul 2004 08:25: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.87])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GFPHhC084813
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 08:25:17 -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 i6GFPJBC004882;
	Fri, 16 Jul 2004 08:25:19 -0700 (PDT)
Received: from [192.168.1.107] (66-65-118-184.nyc.rr.com [66.65.118.184])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id i6GFP8fk028456;
	Fri, 16 Jul 2004 08:25:16 -0700 (PDT)
In-Reply-To: <40F7EFD4.1090608@intertwingly.net>
References: <40E16215.6070507@intertwingly.net> <40EC9915.4050406@intertwingly.net> <40F539FE.7010600@intertwingly.net> <40F7EFD4.1090608@intertwingly.net>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <4EDFDA4D-D73C-11D8-9D94-000A95DC3D90@mac.com>
Content-Transfer-Encoding: 7bit
Cc: Atom-Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: New AtomPubIssuesList for 2004/07/16
Date: Fri, 16 Jul 2004 11:25:02 -0400
To: Sam Ruby <rubys@intertwingly.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>
Content-Transfer-Encoding: 7bit


On 16 Jul 2004, at 11:10 am, Sam Ruby wrote:

> But mostly, and as Tim indicated [1], I tossed "something big, hairy, 
> and ugly", namely link/service tags.  This is becoming a bit of a log 
> jam.  There are six in all, and frankly if all we achieved was to 
> close some and given the others an indication of what they need to 
> address, then I would be happy.  I suspect, however, that we can do 
> more: perhaps even come to consensus on the concepts expressed in one 
> or more of these paces.

There's not a PaceNukeTheLinkTag (and turn each @rel into a new 
element) or equivalent, is there? I think someone needs to write one.

(I started, but found there wasn't clear spec text for each of the rel 
values to include specs for each new element in the Pace - would it be 
alright to write a Pace that just said "Replace [section about the link 
element] with descriptions of each new element as determined by the 
WG"?)

Graham



From owner-atom-syntax@mail.imc.org  Fri Jul 16 11: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 LAA10755
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 11: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 i6GFgtwZ087586;
	Fri, 16 Jul 2004 08:42: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 i6GFgtQl087585;
	Fri, 16 Jul 2004 08:42:55 -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 i6GFgr7K087574
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 08:42:54 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p06110449bd1da5c41a28@[10.20.30.249]>
In-Reply-To: <40F7EFD4.1090608@intertwingly.net>
References: <40E16215.6070507@intertwingly.net>
 <40EC9915.4050406@intertwingly.net> <40F539FE.7010600@intertwingly.net>
 <40F7EFD4.1090608@intertwingly.net>
Date: Fri, 16 Jul 2004 08:43:24 -0700
To: atom-syntax@imc.org
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: On discussions and Internet Drafts
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>


Greetings again. We got the -00 drafts out last week, and it looks 
like we'll have the -01 drafts published later next week. Even though 
the editors will turn the -01s in over the weekend, it will probably 
take most of the week to get them in the official repository because 
of the last-minute crush before Monday's deadline.

Around IETF meetings, there is a three-week "no drafts" zone. This 
means that no drafts will be accepted by the IETF from 9AM EST on 
Monday until the beginning of the meeting two weeks later, and even 
those turned in during the week of the IETF won't get published until 
after the meeting. The purpose of this so that people can actually 
read the drafts before the meeting without being bombarded with 
truly-last-minute drafts.

Of course, this doesn't mean that we don't need to work during this 
period. The list is having very productive, active discussions about 
the issues that Sam is feeding us from the AtomPubIssuesList. The -02 
drafts will reflect even more changes from these discussions and the 
discussions in San Diego.

However, the fairly strict rule in the IETF is that no decisions are 
ever made at the face-to-face meetings that are not ratified on the 
mailing list. Thus, if we come to some verbal consensus in San Diego 
on some open topics, that will get brought to the mailing list and 
the discussion will continue.

Thus, my guess is that the -02 drafts won't be turned in until about 
a month from now, and possibly later if the post-meeting discussion 
brings up objections that weren't heard in the meeting. It is 
perfectly fine for the drafts to come out in irregular intervals, as 
long as they come out often enough to help the group's discussion 
process move steadily towards completion.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Fri Jul 16 12: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 MAA11631
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 12: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 i6GFueNR089523;
	Fri, 16 Jul 2004 08:56: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 i6GFue5d089522;
	Fri, 16 Jul 2004 08:56:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.mnot.net (adsl-67-119-69-242.dsl.sntc01.pacbell.net [67.119.69.242])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GFudKk089516
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 08:56:39 -0700 (PDT)
	(envelope-from mnot@mnot.net)
Received: from [10.0.1.26] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243])
	by mail.mnot.net (Postfix) with ESMTP
	id 8FA06727D; Fri, 16 Jul 2004 08:56:42 -0700 (PDT)
In-Reply-To: <40F7BAC2.4050204@nokia.com>
References: <20040715142548.9823.qmail@web41501.mail.yahoo.com> <40F69CFF.6080802@franklinmint.fm> <1DFD193F-D67D-11D8-A6EC-000A95A51C9E@sun.com> <40F6BD27.4060805@franklinmint.fm> <40F7BAC2.4050204@nokia.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <BA3E4E6E-D740-11D8-97B1-000A95BD86C0@mnot.net>
Content-Transfer-Encoding: 7bit
Cc: Tim Bray <Tim.Bray@Sun.COM>, Atomlist <atom-syntax@imc.org>,
        mint@franklinmint.fm
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: PacePutDelete Withdrawn
Date: Fri, 16 Jul 2004 08:56:40 -0700
To: Janne Jalkanen <Janne.Jalkanen@nokia.com>
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>
Content-Transfer-Encoding: 7bit


+1 and well put.


On Jul 16, 2004, at 4:23 AM, Janne Jalkanen wrote:

>
>
>> Even if it's *impossible* to send a PUT with MIDP, that doesn't mean 
>> these phones can't use Atom. Developers can still use the underlying 
>> platform (e.g. Series60). In fact, I gather it's often necessary to 
>> do so to access some phone features like wallpaper, etc. Here is an 
>> already-deployed Series60 app (presumably written in C++) that uses 
>> the Atom Publishing Protocol:
>>
>> http://www.futurice.fi/products.html
>
> True, it's C++ and native Symbian.
>
> (Teaches me to read all the emails before starting to reply to them :)
>
> /Janne
>

--
Mark Nottingham     http://www.mnot.net/



From owner-atom-syntax@mail.imc.org  Fri Jul 16 12:29: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 MAA13559
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 12:29: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 i6GGHWaZ092625;
	Fri, 16 Jul 2004 09:17: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 i6GGHWtW092624;
	Fri, 16 Jul 2004 09:17:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GGHV3M092606
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 09:17:32 -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 <2004071616172101200fqgale>; Fri, 16 Jul 2004 16:17:26 +0000
Date: Fri, 16 Jul 2004 10:17:20 -0600
Mime-Version: 1.0 (Apple Message framework v553)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Subject: PaceLinkPurpose
From: Antone Roundy <antone@geckotribe.com>
To: atom-syntax@imc.org
Content-Transfer-Encoding: 7bit
Message-Id: <9CCBA856-D743-11D8-8968-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


Well, here we go.  This is either going to be fun or painful.  I for 
one am optimistic that it will be fun--that we'll finally resolve the 
link/@rel vs. various link constructs issue.

Taking the "Key Questions" section of PaceLinkPurpose as a starting 
point:

> 1. Do we want an extensible linking mechanism to enable software 
> agents that don't understand the extension to be able to render 
> extended links without the risk of rendering them in a manner 
> inconsistent with their purpose?
> 2. Are there preferable methods for specifying an extensible linking 
> mechanism? (For example, could we say that any element with an href 
> attribute MUST be a Link Construct, with all the specified attributes 
> for Link Constructs, which could be rendered as a user-activatable 
> link to be loaded using GET, and which does not require understanding 
> of any additional attributes in order to process it in an acceptable 
> way?)
> 3. Are we satisfied with <link> as it is, with a closed list of @rel 
> values?
> 4. Do we want a multiplicity of Link Constructs, or one <link> element 
> whose @rel (ore @rev) attribute determines what it is?

My current thinking is that I'd be happy with either link/@rel or 
various Link Constucts (and no @rel) as long as Link Constructs are 
recognizable, so that they can be used for extensibility.  If we go 
either of those directions, I'd definitely advocate adopting the 
following spec text from the Pace, or something substantially similar:

> 3.4 Link Constructs A Link construct specifies a hyperlink primarily 
> intended to be activated through explicit user interactions such as 
> clicking, selecting a menu item, drag and drop, etc. When accessing 
> the resource pointed to by the href attribute using HTTP, the GET 
> method MUST be used. It MUST NOT have any child content. The Link 
> Construct has the following attributes:

If we dump link/@rel and DON'T specify some way to recognize unknown 
Link Constructs, then I DON'T think the limitations of that text are of 
much value.

I think the core question that precedes all others is whether Link 
Constructs are going to be used for extensibility.  If yes, the second 
question is whether to use link/@rel with an open @rel list or whether 
to have multiple Link Construct elements which are all recognizable as 
Link Constructs in some way.  If link/@rel, the third question is how 
extensions will specify their @rel values; otherwise, how to recognize 
Link Constructs defined in extensions.  Once those questions are 
settled, it should be relatively easy to hammer out a list of either 
@rel values or Link Construct elements to include in the core spec.

Antone



From owner-atom-syntax@mail.imc.org  Fri Jul 16 12:32: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 MAA13823
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 12:32: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 i6GGMxg2093438;
	Fri, 16 Jul 2004 09: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 i6GGMx9B093437;
	Fri, 16 Jul 2004 09:22: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 i6GGMt1o093401
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 09:22: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 JAA28453
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 09:22:51 -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 JAA24902
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 09:22:51 -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, 16 Jul 2004 09:22:51 -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 <0I0Y00CMADI1HR@shazam.verity.com> for atom-syntax@imc.org; Fri,
 16 Jul 2004 09:22:50 -0700 (PDT)
Date: Fri, 16 Jul 2004 09:22:49 -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: Non-Gregorian calendars (was: Re: Unsynchronized clocks vs. author
 calendars)
In-reply-to: <opsa7zdoyluvpchu@quark>
To: Atom-Syntax <atom-syntax@imc.org>
Message-id: 
 <DC9BCC57D8F56B93BA8F2EE3@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: <20040715181624.90235.qmail@web41210.mail.yahoo.com>
 <opsa7zdoyluvpchu@quark>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6GGMx1o093432
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 Friday, July 16, 2004 9:35 AM +0200 Asbjørn Ulsberg <asbjorn@tigerstaden.no> wrote:
> On Thu, 15 Jul 2004 11:16:24 -0700 (PDT), Dare Obasanjo <kpako@yahoo.com>  wrote:
>
>> Are you claiming that that Atom feeds will have to deal with
>> calendars other than the Gregorian calendar? Since when?
>
> I don't think that's what he's saying, ...

You think correctly. The main point is to distinguish between
unsynchronized dates (LiveJournal) and author-expressed dates.
The latter can be accurate dates in non-Gregorian calendars or
something else (my biorhythms).

Requiring support for non-Gregorian calendars in every Atom
implementation is nuts. It isn't even possible to make a list
of all calendars, so you can't require it.

I can see some use in an Atom element for author-expressed dates
as a string. I would not expect implementations to parse them
as dates. Maybe it will show up as an extension.

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Fri Jul 16 12:35: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 MAA13975
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 12:35: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 i6GGSjiM094209;
	Fri, 16 Jul 2004 09:28: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 i6GGSjbp094208;
	Fri, 16 Jul 2004 09:28:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-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 i6GGSiaF094191
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 09:28:44 -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 i6GGSjil023274
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 10:28:45 -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 <0I0Y007PTDRWO5@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Fri, 16 Jul 2004 10:28:45 -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 <0I0Y00C4VDRWE4@mail.sun.net> for atom-syntax@imc.org; Fri,
 16 Jul 2004 10:28:45 -0600 (MDT)
Date: Fri, 16 Jul 2004 09:28:48 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: PaceLinkConstruct central?
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <37675036-D745-11D8-92AF-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: <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 Jul 16, 2004, at 8:25 AM, Graham wrote:
> On 16 Jul 2004, at 11:10 am, Sam Ruby wrote:
>> But mostly, and as Tim indicated [1], I tossed "something big, hairy, 
>> and ugly", namely link/service tags.  This is becoming a bit of a log 
>> jam.  There are six in all
> There's not a PaceNukeTheLinkTag (and turn each @rel into a new 
> element) or equivalent, is there? I think someone needs to write one.

Ouch, I just spent a couple of minutes glancing at all those things in 
the "Currently Under Discussion" section, and while I think I have a 
general feel for the issues, it's going to be hard to get a 
well-structured discussion going.

So, here's a strawman, part 1: First of all, we address the basic 
question of whether
(a) we try to use <link rel="this" href="">, <link rel="that" href="">, 
etc for all our link-flavoured constructs, or
(b) we break 'em out and make a bunch of <this href="">, <that href=""> 
(Graham's NukeTheLinkTag)

It seems to me that if we can solve this syntax problem, it will clear 
the air so we can see the others more quickly (and as a side-effect 
cause most of those six Paces to be retired or rewritten).

My opinion:
Yes, let's sort the syntax mess first, and
(b), just because I hate <link rel="alternate"> for maybe atom's most 
important single tag.

  -Tim 



From owner-atom-syntax@mail.imc.org  Fri Jul 16 13:11: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 NAA16449
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 13:11: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 i6GGvprI098735;
	Fri, 16 Jul 2004 09:57: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 i6GGvp1R098734;
	Fri, 16 Jul 2004 09:57: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 (mproxy.gmail.com [216.239.56.252])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6GGvpJw098706
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 09:57:51 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so2608648cwc
        for <atom-syntax@imc.org>; Fri, 16 Jul 2004 09:57:47 -0700 (PDT)
Received: by 10.11.99.74 with SMTP id w74mr102762cwb;
        Fri, 16 Jul 2004 09:57:47 -0700 (PDT)
Message-ID: <3f1451f504071609577d59d493@mail.gmail.com>
Date: Fri, 16 Jul 2004 12:57:47 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: "kwark.1511609@bloglines.com" <kwark.1511609@bloglines.com>
Subject: Re: PacePutDelete Withdrawn
Cc: atom-syntax@imc.org
In-Reply-To: <1089990560.1020723103.26983.sendItem@bloglines.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <1089990560.1020723103.26983.sendItem@bloglines.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 16 Jul 2004 15:09:20 -0000, kwark.1511609@bloglines.com 
> Joe,
> 
> A WSP stack encodes
> the HTTP request into a binary format and send that over WTP (Wireless Transport
> Protocol) to a WAP gateway. The gateway decodes the request and send a normal
> HTTP request to the designated web server. The gateway subsequently receives
> the response, encodes it again and sends it enroute to the mobile phone.
> 
> The WSP stack is used by the WAP browser. It renders WML and allows the
> user to interact with these pages. Similar to HTML it uses GET to follow links
> and has functionality similar to HTML forms, which allow the user to POST
> data to a web server.
> 
> So, even though the WSP specification allows for
> arbitrary HTTP methods to be encoded, not all mobile phones and WAP gateways
> support this and only support GET and POST.
> 
> In the early WAP days, even
> POST support was not supported on some phones.
> 
> I guess this was the main
> motivation for the MIDP JSR expert group to limit the number of required HTTP
> methods. It ensures interoperability.

Given the above explaination I would be concerned that
you could not POST arbitrary mime-types including
binary content without it being restricted to mulit-part mime.
Is this a concern?

    Thanks,
    -joe



From owner-atom-syntax@mail.imc.org  Fri Jul 16 13: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 NAA16851
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 13: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 i6GH6itl000194;
	Fri, 16 Jul 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 i6GH6iYV000193;
	Fri, 16 Jul 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.85])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GH6i3p000187
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 10:06:44 -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 i6GH6mas012793
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 10:06:48 -0700 (PDT)
Received: from [149.123.77.134] ([149.123.77.134])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id i6GH6aKR020714
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 10:06:47 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v618)
To: Atom-Syntax Syntax <atom-syntax@imc.org>
Message-Id: <7ABCBE9A-D74A-11D8-9D94-000A95DC3D90@mac.com>
Content-Type: multipart/mixed; boundary=Apple-Mail-2-21239773
From: Graham <dtcd@mac.com>
Subject: PaceReplaceLinkElement created
Date: Fri, 16 Jul 2004 13:06:29 -0400
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-21239773
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

(it might be helpful to add this to today's issues list)

http://www.intertwingly.net/wiki/pie/PaceReplaceLinkElement

Abstract

  Replace the link element with several different elements, named for 
the various proposed link@rel values.

Status

  Open

Rationale

  Semantically-different link constructs are currently distinguished by 
an attribute named "rel", inherited  from the HTML link construct. This 
causes many problems:
	1. No extension mechanism
	2. Inconsistent with Date, Person and Content constructs, which all 
distinguish semantics using the element name.
	3. Typing based on attribute value is bad practice 
--Apple-Mail-2-21239773
Content-Type: image/png;
	x-unix-mode=0666;
	name="moin-www.png"
Content-Disposition: inline;
	filename=moin-www.png
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAAAsAAAALAgMAAADUwp+1AAAACVBMVEUA/wC/v78AAP+0MGACAAAA
AnRSTlP/AOW3MEoAAAABYktHRAJmC3xkAAAALUlEQVR42mMIZQgBwikMEUxLGLIUVjBkaS1gyGKA
4CigWFjXFIbQVSEMoaEhAPFLC8/vqdQnAAAAAElFTkSuQmCC

--Apple-Mail-2-21239773
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

whole approach of "bottom-typing"... leaves a strongly-typed guy like 
me with the whillies

Proposal

Remove:

  3.4.1 "rel" Attribute
  The "rel" attribute indicates the type of relationship that the link

  represents. Link constructs MUST have a rel attribute, whose value 
MUST be a string, and MUST be one of the values enumerated in the Atom 
Protocol specification [Atom-protocol].

  Replace 4.4 "atom:link" Element with sections detailing rel values 
defined in atom-protocol-00 3.4.1. For example:

  atom:alternate

The "atom:alternate" element is a Link construct that points to an 
alternate representation of the containing resource.

  atom:feed elements MUST contain at least one atom:alternate element. 
atom:feed elements MUST NOT contain more than one atom:alternate 
element that has the same type attribute value.

  Replace 4.13.2 "atom:link" Element with a similar list, eg:

  atom:alternate

The "atom:alternate" element is a Link construct that points to an 
alternate representation of the containing resource.

  atom:entry elements MUST contain at least one atom:alternate element. 
atom:entry elements MUST NOT contain more than one atom:alternate 
element that has the same type attribute value.

  Impacts

Some other proposals (eg PaceLinkPurpose) will no longer be relevant. 
There will not be a defined way to extract all Link Constructs from 
atom document.

  Notes

Currently the meanings of the link@rel values are not currently 
defined, thus it was not possible to include within the proposal spec 
text for each of the new elements created by the proposal.

--Apple-Mail-2-21239773--



From owner-atom-syntax@mail.imc.org  Fri Jul 16 13:19: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 NAA17030
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 13:19: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 i6GHA5Jx000819;
	Fri, 16 Jul 2004 10: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 i6GHA5PJ000818;
	Fri, 16 Jul 2004 10:10: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 i6GHA4j2000809
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 10:10:05 -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 i6GHApDj001976;
	Fri, 16 Jul 2004 13:10:52 -0400
Message-ID: <40F80BE7.4020509@intertwingly.net>
Date: Fri, 16 Jul 2004 13:09:59 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <Tim.Bray@Sun.COM>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceLinkConstruct central?
References: <37675036-D745-11D8-92AF-000A95A51C9E@sun.com>
In-Reply-To: <37675036-D745-11D8-92AF-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 Jul 16, 2004, at 8:25 AM, Graham wrote:
> 
>> On 16 Jul 2004, at 11:10 am, Sam Ruby wrote:
>>
>>> But mostly, and as Tim indicated [1], I tossed "something big, hairy, 
>>> and ugly", namely link/service tags.  This is becoming a bit of a log 
>>> jam.  There are six in all
>>
>> There's not a PaceNukeTheLinkTag (and turn each @rel into a new 
>> element) or equivalent, is there? I think someone needs to write one.
> 
> Ouch, I just spent a couple of minutes glancing at all those things in 
> the "Currently Under Discussion" section, and while I think I have a 
> general feel for the issues, it's going to be hard to get a 
> well-structured discussion going.

In many ways, the primary thing that they had in common was that each 
were being either held back (or tossed back) in wait for a pace that had 
yet to be written.  If this fact is the only thing that this cycle has 
highlighted, then it still was a productive cycle.

> So, here's a strawman, part 1: First of all, we address the basic 
> question of whether
> (a) we try to use <link rel="this" href="">, <link rel="that" href="">, 
> etc for all our link-flavoured constructs, or
> (b) we break 'em out and make a bunch of <this href="">, <that href=""> 
> (Graham's NukeTheLinkTag)
> 
> It seems to me that if we can solve this syntax problem, it will clear 
> the air so we can see the others more quickly (and as a side-effect 
> cause most of those six Paces to be retired or rewritten).

+1 on solving that first (even if it means that all six get tossed back)

> My opinion:
> Yes, let's sort the syntax mess first, and
> (b), just because I hate <link rel="alternate"> for maybe atom's most 
> important single tag.

If that is the biggest problem: there is a simple solution.  Make 
"alternate" the default for the rel attribute.

I have expressed support[1] for the current link tag before, but I 
certainly will go along with consensus.  I do have one request, however. 
  We don't make decisions based on formulations such as the "this or 
that" paragraph above, but based on somebody doing the hard work of 
drafting spec language for the new approach.

This is harder than one might think...

- Sam Ruby

[1] http://www.imc.org/atom-syntax/mail-archive/msg04224.html



From owner-atom-syntax@mail.imc.org  Fri Jul 16 13:36: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 NAA17862
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 13:36: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 i6GHJ2qu002284;
	Fri, 16 Jul 2004 10:19:02 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6GHJ2tH002283;
	Fri, 16 Jul 2004 10:19:02 -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 i6GHJ1in002277
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 10:19:01 -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 i6GHJmj2002372;
	Fri, 16 Jul 2004 13:19:48 -0400
Message-ID: <40F80E00.80202@intertwingly.net>
Date: Fri, 16 Jul 2004 13:18:56 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Antone Roundy <antone@geckotribe.com>
CC: atom-syntax@imc.org
Subject: Re: PaceLinkPurpose
References: <9CCBA856-D743-11D8-8968-003065EA6144@geckotribe.com>
In-Reply-To: <9CCBA856-D743-11D8-8968-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:
> 
> I think the core question that precedes all others is whether Link 
> Constructs are going to be used for extensibility.  If yes, the second 
> question is whether to use link/@rel with an open @rel list or whether 
> to have multiple Link Construct elements which are all recognizable as 
> Link Constructs in some way.  If link/@rel, the third question is how 
> extensions will specify their @rel values; otherwise, how to recognize 
> Link Constructs defined in extensions.  Once those questions are 
> settled, it should be relatively easy to hammer out a list of either 
> @rel values or Link Construct elements to include in the core spec.

I agree that that is the core question, but I think we can't answer that 
question separate from hammering out the specification language.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Fri Jul 16 13:37: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 NAA17929
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 13:37: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 i6GHPi90004156;
	Fri, 16 Jul 2004 10:25: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 i6GHPiwA004155;
	Fri, 16 Jul 2004 10:25:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GHPhpk004149
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 10:25: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 i6GHPkil021834
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 11:25: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 <0I0Y000JJGEYDZ@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Fri, 16 Jul 2004 11:25: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 <0I0Y00KJ1GEU3N@mail.sun.net> for atom-syntax@imc.org; Fri,
 16 Jul 2004 11:25:45 -0600 (MDT)
Date: Fri, 16 Jul 2004 10:25:47 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceReplaceLinkElement created
In-reply-to: <7ABCBE9A-D74A-11D8-9D94-000A95DC3D90@mac.com>
To: Graham <dtcd@mac.com>
Cc: Atom-Syntax Syntax <atom-syntax@imc.org>
Message-id: <2D333BDC-D74D-11D8-92AF-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: <7ABCBE9A-D74A-11D8-9D94-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 Jul 16, 2004, at 10:06 AM, Graham wrote:

> (it might be helpful to add this to today's issues list)
>
> http://www.intertwingly.net/wiki/pie/PaceReplaceLinkElement
>
> Abstract
>
>  Replace the link element with several different elements, named for 
> the various proposed link@rel values.

Couldn't you do this and still make link-ish elements recognizable by 
insisting on the use of the href= attribute, and only the href= 
attribute in all these descendents of <link? -Tim



From owner-atom-syntax@mail.imc.org  Fri Jul 16 13:50: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 NAA19104
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 13:50: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 i6GHbdri006087;
	Fri, 16 Jul 2004 10:37:39 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6GHbdAX006086;
	Fri, 16 Jul 2004 10:37: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 i6GHbcwZ006080
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 10:37: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 i6GHcO1p003186;
	Fri, 16 Jul 2004 13:38:24 -0400
Message-ID: <40F8125C.5020206@intertwingly.net>
Date: Fri, 16 Jul 2004 13:37:32 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <dtcd@mac.com>
CC: Atom-Syntax Syntax <atom-syntax@imc.org>
Subject: Re: PaceReplaceLinkElement created
References: <7ABCBE9A-D74A-11D8-9D94-000A95DC3D90@mac.com>
In-Reply-To: <7ABCBE9A-D74A-11D8-9D94-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: <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:
> (it might be helpful to add this to today's issues list)
> 
> http://www.intertwingly.net/wiki/pie/PaceReplaceLinkElement

Added.

>  Replace 4.4 "atom:link" Element with sections detailing rel values 
> defined in atom-protocol-00 3.4.1. For example:

>  Replace 4.13.2 "atom:link" Element with a similar list, eg:

My experience is that the devil's in the details, and by not spelling 
out the details, it makes it hard to spot potential problem areas.

Meanwhile, an extensibility question.  If somebody wants to define a new 
element, in a new namespace, are we supposed to wantonly assume that any 
attribute spelled "href" is an indication that an atom LinkConstruct is 
what is intended?

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Fri Jul 16 14:10:44 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20448
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 14:10: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 i6GHxqG3009884;
	Fri, 16 Jul 2004 10: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 i6GHxqqa009883;
	Fri, 16 Jul 2004 10: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.44])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GHxpMa009877
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 10:59:51 -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 i6GHxtOo028309;
	Fri, 16 Jul 2004 10:59:55 -0700 (PDT)
Received: from [149.123.77.134] ([149.123.77.134])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id i6GHxhKR008931;
	Fri, 16 Jul 2004 10:59:54 -0700 (PDT)
In-Reply-To: <40F8125C.5020206@intertwingly.net>
References: <7ABCBE9A-D74A-11D8-9D94-000A95DC3D90@mac.com> <40F8125C.5020206@intertwingly.net>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <E6A5DA82-D751-11D8-9D94-000A95DC3D90@mac.com>
Content-Transfer-Encoding: 7bit
Cc: Atom-Syntax Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: PaceReplaceLinkElement created
Date: Fri, 16 Jul 2004 13:59:36 -0400
To: Sam Ruby <rubys@intertwingly.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>
Content-Transfer-Encoding: 7bit


On 16 Jul 2004, at 1:37 pm, Sam Ruby wrote:

> My experience is that the devil's in the details, and by not spelling 
> out the details, it makes it hard to spot potential problem areas.

That's the best I could do. The various rel values are not properly 
defined yet.

> Meanwhile, an extensibility question.  If somebody wants to define a 
> new element, in a new namespace, are we supposed to wantonly assume 
> that any attribute spelled "href" is an indication that an atom 
> LinkConstruct is what is intended?

I personally don't understand why there is such desperate need to 
recognize extension link constructs.

(because it is only extensions that the current link syntax* helps 
with. A dumb aggregator can still find all of the core links by name)

Graham

(* not that the current link syntax has any viable extension mechanism)



From owner-atom-syntax@mail.imc.org  Fri Jul 16 14:15:10 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20864
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 14:15:09 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GI3DCs010358;
	Fri, 16 Jul 2004 11:03: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 i6GI3DuP010357;
	Fri, 16 Jul 2004 11:03:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.241])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6GI3D5J010351
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 11:03:13 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so2648332cwc
        for <atom-syntax@imc.org>; Fri, 16 Jul 2004 11:03:17 -0700 (PDT)
Received: by 10.11.99.74 with SMTP id w74mr104292cwb;
        Fri, 16 Jul 2004 11:03:16 -0700 (PDT)
Message-ID: <3f1451f50407161103319b3ea5@mail.gmail.com>
Date: Fri, 16 Jul 2004 14:03:16 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Toru Marumoto <torumyax@yahoo.co.jp>
Subject: Re: Q: Put request should return Atom entry?
Cc: atom-syntax@imc.org
In-Reply-To: <28C46B463CC0E9torumyax@yahoo.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <28C46B463CC0E9torumyax@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


On Sat, 17 Jul 2004 00:04:48 +0900, Toru Marumoto <torumyax@yahoo.co.jp> wrote:
> 
> 
> I can't seem to find the answer in the Atom draft spec...
> 
> When a client sends a PUT request, what kind of a response should
> the client expects?
> 
> response code 301 and Atom entry?

I expect the response to a successful PUT should be 200
and no Atom entry returned. That needs to be added to the spec.

    Thanks,
    -joe



From owner-atom-syntax@mail.imc.org  Fri Jul 16 14:23: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 OAA21347
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 14:23: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 i6GI9QjK011526;
	Fri, 16 Jul 2004 11:09: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 i6GI9PEG011525;
	Fri, 16 Jul 2004 11:09:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GI9PIn011519
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 11:09:25 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i6GI7G53009659
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 12:07: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 <0I0Y00601IFORS@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Fri, 16 Jul 2004 12:09:24 -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 <0I0Y00CUYIFHE4@mail.sun.net> for atom-syntax@imc.org; Fri,
 16 Jul 2004 12:09:18 -0600 (MDT)
Date: Fri, 16 Jul 2004 11:09:22 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceReplaceLinkElement created
In-reply-to: <40F8125C.5020206@intertwingly.net>
To: Sam Ruby <rubys@intertwingly.net>
Cc: Graham <dtcd@mac.com>, Atom-Syntax Syntax <atom-syntax@imc.org>
Message-id: <43BF25A7-D753-11D8-92AF-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: <7ABCBE9A-D74A-11D8-9D94-000A95DC3D90@mac.com>
 <40F8125C.5020206@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 Jul 16, 2004, at 10:37 AM, Sam Ruby wrote:

> Meanwhile, an extensibility question.  If somebody wants to define a 
> new element, in a new namespace, are we supposed to wantonly assume 
> that any attribute spelled "href" is an indication that an atom 
> LinkConstruct is what is intended?

It's kind of a hack, but also kind of plausible; I'm not sure that 
"wantonly" is the appropriate word. -Tim



From owner-atom-syntax@mail.imc.org  Fri Jul 16 14:26: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 OAA21544
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 14:26:20 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GIDFmL012178;
	Fri, 16 Jul 2004 11:13: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 i6GIDFdk012177;
	Fri, 16 Jul 2004 11:13:15 -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 i6GIDFn7012167
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 11:13:15 -0700 (PDT)
	(envelope-from antone@geckotribe.com)
Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134])
          by comcast.net (rwcrmhc13) with SMTP
          id <20040716181313015003mo1le>; Fri, 16 Jul 2004 18:13:14 +0000
Date: Fri, 16 Jul 2004 12:13:11 -0600
Subject: Re: PaceReplaceLinkElement created
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: <7ABCBE9A-D74A-11D8-9D94-000A95DC3D90@mac.com>
Message-Id: <CC4A7A8C-D753-11D8-8968-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 Friday, July 16, 2004, at 11:06  AM, Graham wrote:
>  Semantically-different link constructs are currently distinguished by 
> an attribute named "rel", inherited  from the HTML link construct. 
> This causes many problems:
> 	1. No extension mechanism
Just to make sure we're clear, by "Semantically-different link 
constructs", are you referring to something like the fact that some 
link constructs point to places where a person might send their feed 
reader or web browser next by clicking a link, while others point to 
places their feed editor might post (not limited to HTTP POST) new or 
updated entries, and still others (proposed but not in the current spec 
draft) point to things that their feed reader or web browser might load 
automatically while rendering the feed in which the <link> appears?  Or 
is there some other distinction between different link constructs 
you're referring to?

If that is what you're meaning, PaceServiceElement proposes a 
replacement element for the @rel values appearing in the current API 
spec which aren't in the first group.

>  Impacts
>
> Some other proposals (eg PaceLinkPurpose) will no longer be relevant. 
> There will not be a defined way to extract all Link Constructs from 
> atom document.
Portions of PaceLinkPurpose could still be relevant even if the link 
element is replaced (we could still limit what Link Constructs can be 
used for), and as Tim & Sam's responses pointed out, we COULD still 
define a way to extract all Link Constructs.



From owner-atom-syntax@mail.imc.org  Fri Jul 16 14:29:48 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21930
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 14:29:47 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GIH7HZ012700;
	Fri, 16 Jul 2004 11:17: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 i6GIH7T8012699;
	Fri, 16 Jul 2004 11:17:07 -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 i6GIH5mg012692;
	Fri, 16 Jul 2004 11:17:05 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p06110450bd1dcbf80e59@[10.20.30.249]>
In-Reply-To: <40F8125C.5020206@intertwingly.net>
References: <7ABCBE9A-D74A-11D8-9D94-000A95DC3D90@mac.com>
 <40F8125C.5020206@intertwingly.net>
Date: Fri, 16 Jul 2004 11:17:36 -0700
To: Sam Ruby <rubys@intertwingly.net>, Graham <dtcd@mac.com>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: PaceReplaceLinkElement created
Cc: Atom-Syntax Syntax <atom-syntax@imc.org>
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:37 PM -0400 7/16/04, Sam Ruby wrote:
>Meanwhile, an extensibility question.  If somebody wants to define a 
>new element, in a new namespace, are we supposed to wantonly assume 
>that any attribute spelled "href" is an indication that an atom 
>LinkConstruct is what is intended?

We can make that wanton assumption if we say in the spec something to 
the effect of "The use of attributes called 'href' mean that they are 
links to the outside world, and anyone extending Atom should only use 
'href' in a way similar to the items in the core spec."

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Fri Jul 16 14:30:40 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22144
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 14:30: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 i6GIJSpB013044;
	Fri, 16 Jul 2004 11:19:28 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6GIJSJW013043;
	Fri, 16 Jul 2004 11:19:28 -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 i6GIJSaJ013025
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 11:19:28 -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 <20040716181917013003p9r9e>; Fri, 16 Jul 2004 18:19:27 +0000
Date: Fri, 16 Jul 2004 12:19:16 -0600
Subject: Re: PaceReplaceLinkElement created
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: <40F8125C.5020206@intertwingly.net>
Message-Id: <A5C418F0-D754-11D8-8968-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 Friday, July 16, 2004, at 11:37  AM, Sam Ruby wrote:
> Meanwhile, an extensibility question.  If somebody wants to define a 
> new element, in a new namespace, are we supposed to wantonly assume 
> that any attribute spelled "href" is an indication that an atom 
> LinkConstruct is what is intended?
>
We'd have to explicitly state that in the spec if we wanted to be able 
to do that--we'd have to forbid extensions from having an href 
attribute in an element that wasn't a Link Construct.  We should 
explore other possible methods for identifying Link Constructs too.  
The first that comes to mind, which I imaging some people will oppose, 
is that all Link Constructs have names beginning with "link-".  For 
example, <link-alternate ... />.  That should be much easier for 
extension writers to live with if they need an element with a URI in 
it.  It would also be somewhat easier to identify.



From owner-atom-syntax@mail.imc.org  Fri Jul 16 14: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 OAA22287
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 14: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 i6GIO3Mw013792;
	Fri, 16 Jul 2004 11: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 i6GIO3ie013791;
	Fri, 16 Jul 2004 11:24:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GIO2Cm013784
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 11:24:02 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p06110451bd1dcd57607e@[10.20.30.249]>
Date: Fri, 16 Jul 2004 11:24:35 -0700
To: Atom WG <atom-syntax@imc.org>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Who's attending the IETF meeting in San Diego?
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>


Greetings again. It would be useful to know who here is attending the 
IETF meeting so we can think about the agenda. If you're attending, 
please send me AN OFF-LIST RESPONSE so Tim and I can stare at it a 
bit.

FWIW, the official list of who has registered is at 
<http://www.ietf.org/meetings/attendees_60.htm>; I'm collecting these 
informally because not everyone has signed up.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Fri Jul 16 14:36: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 OAA22618
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 14:36: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 i6GISIA1014397;
	Fri, 16 Jul 2004 11:28: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 i6GISIcI014396;
	Fri, 16 Jul 2004 11:28:18 -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 i6GISIec014381
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 11:28:18 -0700 (PDT)
	(envelope-from distobj@acm.org)
Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian))
	id 1BlXS4-0002m4-00
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 14:28:56 -0400
Date: Fri, 16 Jul 2004 14:28:56 -0400
To: atom-syntax@imc.org
Subject: Re: Q: Put request should return Atom entry?
Message-ID: <20040716182856.GX30868@markbaker.ca>
References: <28C46B463CC0E9torumyax@yahoo.co.jp> <3f1451f50407161103319b3ea5@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3f1451f50407161103319b3ea5@mail.gmail.com>
User-Agent: Mutt/1.3.28i
From: Mark Baker <distobj@acm.org>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


On Fri, Jul 16, 2004 at 02:03:16PM -0400, Joe Gregorio wrote:
> > I can't seem to find the answer in the Atom draft spec...
> > 
> > When a client sends a PUT request, what kind of a response should
> > the client expects?
> > 
> > response code 301 and Atom entry?
> 
> I expect the response to a successful PUT should be 200
> and no Atom entry returned. That needs to be added to the spec.

Let's not be too restrictive!  I think the minimum that needs specifying
would be to say;

- servers MUST indicate successful PUT requests with a 2xx response
- servers MAY include additional information in the PUT response
- clients SHOULD NOT expect any additional information in a PUT
response

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

  Seeking work on large scale application/data integration projects
  and/or the enabling infrastructure for same.



From owner-atom-syntax@mail.imc.org  Fri Jul 16 14: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 OAA23066
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 14: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 i6GITWPs014595;
	Fri, 16 Jul 2004 11:29: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 i6GITWN3014594;
	Fri, 16 Jul 2004 11:29:32 -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 i6GITWtc014588
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 11:29:32 -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 i6GITTRG009058;
	Fri, 16 Jul 2004 11:29:30 -0700 (PDT)
Received: from [149.123.77.134] ([149.123.77.134])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id i6GITRaA014434;
	Fri, 16 Jul 2004 11:29:29 -0700 (PDT)
In-Reply-To: <CC4A7A8C-D753-11D8-8968-003065EA6144@geckotribe.com>
References: <CC4A7A8C-D753-11D8-8968-003065EA6144@geckotribe.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3-26212193; protocol="application/pkcs7-signature"
Message-Id: <0E87C81A-D756-11D8-9D94-000A95DC3D90@mac.com>
Cc: atom-syntax@imc.org
From: Graham <dtcd@mac.com>
Subject: Re: PaceReplaceLinkElement created
Date: Fri, 16 Jul 2004 14:29:21 -0400
To: Antone Roundy <antone@geckotribe.com>
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-26212193
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 16 Jul 2004, at 2:13 pm, Antone Roundy wrote:

> On Friday, July 16, 2004, at 11:06  AM, Graham wrote:
>>  Semantically-different link constructs are currently distinguished 
>> by an attribute named "rel", inherited  from the HTML link construct. 
>> This causes many problems:
>> 	1. No extension mechanism
> Just to make sure we're clear, by "Semantically-different link 
> constructs", are you referring to something like the fact that some 
> link constructs point to places where a person might send their feed 
> reader or web browser next by clicking a link, while others point to 
> places their feed editor might post (not limited to HTTP POST) new or 
> updated entries, and still others (proposed but not in the current 
> spec draft) point to things that their feed reader or web browser 
> might load automatically while rendering the feed in which the <link> 
> appears?  Or is there some other distinction between different link 
> constructs you're referring to?

By semantically different I mean they have different @rel values, 
nothing deeper.

Graham
--Apple-Mail-3-26212193
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
9w0BCQUxDxcNMDQwNzE2MTgyOTIyWjAjBgkqhkiG9w0BCQQxFgQU5xphgDV+lLFpJLVQCMYs2uzk
8DIweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAbiTCQj1Dlg9ELZjca7iRhDFO
NwkBh7Ce205E49py9TUrCjq5Nz5YN0d7Ik7MzjEsjhJYP5s4JUYJD4436Wh0Ypjxufj5h9lEmAm+
cKUhFOAUMGxMOhyskR1kxfalnTSRB+YWgyuOySrUEUumSBFCSSn/vXOaUod0xTuG4x8PA//164Rk
HGYPgoAtfQcDFTVNxvIMQUxL73G24F7ETFNVaLDNsmwvlZXcVr6p3+nJJKugsplpPmE+MSfulCP2
eWqOVCiw9Iw7rYcdd0hekWtK9Q6NeUKlxSZtKK1NjLnVw2IJJn6YgF7DOpLnp/s4kdN1B/u4UR56
YANa5THnPhLIuAAAAAAAAA==

--Apple-Mail-3-26212193--



From owner-atom-syntax@mail.imc.org  Fri Jul 16 14:54: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 OAA23848
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 14:54: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 i6GIfDoU016708;
	Fri, 16 Jul 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 i6GIfDKQ016707;
	Fri, 16 Jul 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 smtpout.mac.com (smtpout.mac.com [17.250.248.86])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GIfDps016701
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 11:41:13 -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 i6GIfGRG015782;
	Fri, 16 Jul 2004 11:41:16 -0700 (PDT)
Received: from [149.123.77.134] ([149.123.77.134])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id i6GIfBfk012103;
	Fri, 16 Jul 2004 11:41:16 -0700 (PDT)
In-Reply-To: <A5C418F0-D754-11D8-8968-003065EA6144@geckotribe.com>
References: <A5C418F0-D754-11D8-8968-003065EA6144@geckotribe.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4-26915825; protocol="application/pkcs7-signature"
Message-Id: <B1ED8071-D757-11D8-9D94-000A95DC3D90@mac.com>
Cc: atom-syntax@imc.org
From: Graham <dtcd@mac.com>
Subject: Re: PaceReplaceLinkElement created
Date: Fri, 16 Jul 2004 14:41:05 -0400
To: Antone Roundy <antone@geckotribe.com>
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-4-26915825
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 16 Jul 2004, at 2:19 pm, Antone Roundy wrote:

> We should explore other possible methods for identifying Link 
> Constructs too.

Before we can even discuss the appropriate syntax for link, we need a 
sensible answer to this question:

  Why do we need any method for identifying extension Link Constructs?

(I've decided I want a mechanism for identifying all Date constructs, 
core and extension, from any Atom document. I will protest and break 
consensus on any spec that doesn't have one)

Graham
--Apple-Mail-4-26915825
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
9w0BCQUxDxcNMDQwNzE2MTg0MTA1WjAjBgkqhkiG9w0BCQQxFgQUFuQTJDcPPiJSByka2yDSs059
Fe8weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAhSCJFxy0mvYio6Sa4G+qAQLh
iLGZ/TNL8KczK9e64ki9zqFCiRZzw5obkr5bt2mcDbU4MNqFAOUTgPOfZ6ycBkzOyIs2qwSp1xWF
4djgmjvMFVVR9WUEz3UseneNLoQ6qvUkCGZnJ9lntNOFKlo9tqmRxCkEkYAFIvzF5yEo68eYasg3
0hCvumYaI7CyAtbp5CP14jNoNO+Cpq3yEjDDbh+vLhArEm978FoE8EOOvGKl91iD5g/xc0sNXGc9
xyUSzhe4LxI3xtXQPIcYDfBZM+Z+GkHSTyzwE7iyDis7Freu/1yFxoNqpoffiOgcYeyjVFYlQQco
Y7GyXpG77xASpAAAAAAAAA==

--Apple-Mail-4-26915825--



From owner-atom-syntax@mail.imc.org  Fri Jul 16 15:05: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 PAA24766
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 15:05: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 i6GIugRl019316;
	Fri, 16 Jul 2004 11:56:42 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6GIugQA019315;
	Fri, 16 Jul 2004 11:56:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from 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 i6GIufgg019297;
	Fri, 16 Jul 2004 11:56: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 esmtp (Exim 4.34)
	id 1BlXsu-00047S-7z; Fri, 16 Jul 2004 18:56:40 +0000
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Fri, 16 Jul 2004 14:56:47 -0400
Subject: Re: PaceReplaceLinkElement created
From: Robert Sayre <mint@franklinmint.fm>
To: Paul Hoffman / IMC <phoffman@imc.org>, Sam Ruby <rubys@intertwingly.net>,
        Graham <dtcd@mac.com>
CC: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD1D9D2F.13CD3%mint@franklinmint.fm>
In-Reply-To: <p06110450bd1dcbf80e59@[10.20.30.249]>
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: <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 7/16/04 2:17 PM, "Paul Hoffman / IMC" <phoffman@imc.org> wrote:

> 
> At 1:37 PM -0400 7/16/04, Sam Ruby wrote:
>> Meanwhile, an extensibility question.  If somebody wants to define a
>> new element, in a new namespace, are we supposed to wantonly assume
>> that any attribute spelled "href" is an indication that an atom
>> LinkConstruct is what is intended?
> 
> We can make that wanton assumption if we say in the spec something to
> the effect of "The use of attributes called 'href' mean that they are
> links to the outside world, and anyone extending Atom should only use
> 'href' in a way similar to the items in the core spec."
> 

Or we could define an "extension namespace". That way, the Atom namespace
could remain the un-prefixed default, and the @href would still be in a
namespace.

<feed xmlns="http://purl.org/atom/ns#"
      xmlns:exatom="http://example.com/atom/ex/ns#"
      xmlns:mylink="http://example.com/mylink/ns#"
      version="draft-00 do not implement">
<title>dive into mark</title>
<link href="http://diveintomark.org/" rel="alternate" type="text/html" />
<mylink:specialLink exatom:href="http://google.com"
                    exatom:rel="alternate"
                    exatom:title="Demo" />
...
</feed>

Robert Sayre



From owner-atom-syntax@mail.imc.org  Fri Jul 16 15:30: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 PAA27249
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 15:30: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 i6GJJWWo023379;
	Fri, 16 Jul 2004 12:19: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 i6GJJWM1023378;
	Fri, 16 Jul 2004 12:19: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 (mproxy.gmail.com [216.239.56.242])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6GJJVnb023368
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 12:19:31 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so2707083cwc
        for <atom-syntax@imc.org>; Fri, 16 Jul 2004 12:19:26 -0700 (PDT)
Received: by 10.11.118.39 with SMTP id q39mr107126cwc;
        Fri, 16 Jul 2004 12:19:26 -0700 (PDT)
Message-ID: <3f1451f50407161219713304e8@mail.gmail.com>
Date: Fri, 16 Jul 2004 15:19:26 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Mark Baker <distobj@acm.org>
Subject: Re: Q: Put request should return Atom entry?
Cc: atom-syntax@imc.org
In-Reply-To: <20040716182856.GX30868@markbaker.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <28C46B463CC0E9torumyax@yahoo.co.jp> <3f1451f50407161103319b3ea5@mail.gmail.com> <20040716182856.GX30868@markbaker.ca>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


On Fri, 16 Jul 2004 14:28:56 -0400, Mark Baker <distobj@acm.org> wrote:
> 
> On Fri, Jul 16, 2004 at 02:03:16PM -0400, Joe Gregorio wrote:
> > > I can't seem to find the answer in the Atom draft spec...
> > >
> > > When a client sends a PUT request, what kind of a response should
> > > the client expects?
> > >
> > > response code 301 and Atom entry?
> >
> > I expect the response to a successful PUT should be 200
> > and no Atom entry returned. That needs to be added to the spec.
> 
> Let's not be too restrictive!  I think the minimum that needs specifying
> would be to say;
> 
> - servers MUST indicate successful PUT requests with a 2xx response
> - servers MAY include additional information in the PUT response
> - clients SHOULD NOT expect any additional information in a PUT
> response

Works for me.

   Thanks,
   -joe



From owner-atom-syntax@mail.imc.org  Fri Jul 16 15:32: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 PAA27355
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 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 i6GJMR3l023861;
	Fri, 16 Jul 2004 12:22: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 i6GJMRd9023860;
	Fri, 16 Jul 2004 12:22:27 -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 i6GJMQGZ023823
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 12:22:26 -0700 (PDT)
	(envelope-from davep@dpawson.co.uk)
Received: (qmail 20550 invoked from network); 16 Jul 2004 19:42:58 -0000
Received: from dpawson.gotadsl.co.uk (HELO ?192.168.2.6?) (davep@dpawson.co.uk@81.6.251.105)
  by 0 with SMTP; 16 Jul 2004 19:42:58 -0000
Subject: Re: Non-Gregorian calendars (was: Re: Unsynchronized clocks vs.
	author calendars)
From: Dave Pawson <davep@dpawson.co.uk>
Reply-To: davep@dpawson.co.uk
To: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <4.2.0.58.J.20040716171935.053dbd70@localhost>
References: <20040715181624.90235.qmail@web41210.mail.yahoo.com>
	 <20040715181624.90235.qmail@web41210.mail.yahoo.com>
	 <4.2.0.58.J.20040716171935.053dbd70@localhost>
Content-Type: text/plain
Message-Id: <1090005721.2021.45.camel@homer>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) 
Date: Fri, 16 Jul 2004 20:22:01 +0100
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 Fri, 2004-07-16 at 09:31, Martin Duerst wrote:

> >If Atom is not going to support non-Gregorian calendars, it should be
> >clear that it doesn't, imho.
> 
> I think that:
> - Atom should concentrate on markup for machine readable dates
> - Machine readable dates should be in ISO 8601 notation, which implies
>    the Gregorian calendar
> - The spec should make clear that this is a format for exchanging
>    date/time information, and does not limit how these are being shown
>    to a user, or input by a user.
> - People who want to add anything else (such as "on a sunny Sunday
>    in July" or so) can always put that into the title/description/
>    actual item text/wherever appropriate.

+1 for simplicity | machine processing.

Question though Martin, *are* there any better i18N date formats
that meet that criteria though? m/c readable, yet also are happy with
non Western use?

regards DaveP 



From owner-atom-syntax@mail.imc.org  Fri Jul 16 15:39: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 PAA27799
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 15:39: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 i6GJRONC024829;
	Fri, 16 Jul 2004 12: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 i6GJROS7024828;
	Fri, 16 Jul 2004 12:27:24 -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 i6GJRNHj024822
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 12:27:23 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net (rdu57-27-065.nc.rr.com [66.57.27.65])
	(authenticated bits=0)
	by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i6GJSBs9007993;
	Fri, 16 Jul 2004 15:28:11 -0400
Message-ID: <40F82C16.2080909@intertwingly.net>
Date: Fri, 16 Jul 2004 15:27:18 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <dtcd@mac.com>
CC: Atom-Syntax Syntax <atom-syntax@imc.org>
Subject: Re: PaceReplaceLinkElement created
References: <7ABCBE9A-D74A-11D8-9D94-000A95DC3D90@mac.com> <40F8125C.5020206@intertwingly.net> <E6A5DA82-D751-11D8-9D94-000A95DC3D90@mac.com>
In-Reply-To: <E6A5DA82-D751-11D8-9D94-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: <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 16 Jul 2004, at 1:37 pm, Sam Ruby wrote:
> 
>> My experience is that the devil's in the details, and by not spelling 
>> out the details, it makes it hard to spot potential problem areas.
> 
> That's the best I could do. The various rel values are not properly 
> defined yet.

There is a starter set here:

http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-00.html#rfc.section.3.4.1

And a more comprehensive list here:

http://intertwingly.net/wiki/pie/LinkTagMeaning

The question that needs pondering is whether we want a format and/or 
protocol with dozens of elements in the core?  Is fewer elements (one 
perhaps with dozens of options) somehow more "approachable"?

My overall feeling (subjective, I know) is that the latter has 
considerably more "curb appeal".

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Fri Jul 16 15:57: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 PAA28790
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 15:57: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 i6GJlo98028509;
	Fri, 16 Jul 2004 12: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 i6GJlopW028508;
	Fri, 16 Jul 2004 12:47:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-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 i6GJlnra028502
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 12:47:49 -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 i6GJlsil026431
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 13:47:54 -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 <0I0Y000GTMZTDZ@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Fri, 16 Jul 2004 13:47:54 -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 <0I0Y004IJMZS0A@mail.sun.net> for atom-syntax@imc.org; Fri,
 16 Jul 2004 13:47:53 -0600 (MDT)
Date: Fri, 16 Jul 2004 12:47:57 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: PaceReplaceLinkElement: Is link-ness relevant?
To: Atom-Syntax Syntax <atom-syntax@imc.org>
Message-id: <097F1326-D761-11D8-92AF-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: <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'm sure there must be some good reason why it's considered a good 
thing to be able to spot that an element is a link to something, even 
if you have no idea what the semantics of that link are.  I assume 
there must be some essential thing you can do given that knowledge.  
But I just went and poked around the Paces and I can't find it.  Could 
someone please provide some motivation or some use cases?  Because 
unless there's a good strong motivation, I don't understand why we're 
even having this discussion. -Tim



From owner-atom-syntax@mail.imc.org  Fri Jul 16 16: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 QAA29603
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 16: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 i6GJxoKf030421;
	Fri, 16 Jul 2004 12:59:50 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6GJxoN9030420;
	Fri, 16 Jul 2004 12:59:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from w01.bloglines.com (w01.bloglines.com [216.148.212.183])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6GJxodf030400
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 12:59:50 -0700 (PDT)
	(envelope-from kwark.1511609@bloglines.com)
Received: (qmail 29299 invoked by uid 99); 16 Jul 2004 19:59:50 -0000
Message-ID: <1090007990.1602124828.29296.sendItem@bloglines.com>
Date: 16 Jul 2004 19:59:50 -0000
From: kwark.1511609@bloglines.com
To: joe.gregorio@gmail.com
CC: atom-syntax@imc.org
Subject: Re: PacePutDelete Withdrawn
MIME-Version: 1.0
Content-Type: text/plain
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


--- Joe Gregorio <joe.gregorio@gmail.com wrote:

> I would be concerned
that you could not POST arbitrary mime-types including binary content without
it being restricted to mulit-part mime.
> Is this a concern?

In my experience
this is not a problem.

I'll try to explain:

WSP encodes/decodes HTTP
requests into/from a binary format, called a PDU (protocol data unit). 
It
works by converting some "well known values" to binary tokens. Examples: the
HTTP GET method is represented as 0x40, a HTTP response code of 200 as 0x20
and mime-type text/html as 0x02. In the case of HTTP methods the list of possible
values is limited. Only GET, POST, HEAD, DELETE, OPTION, TRACE and PUT have
a binary counterpart.
In the case of content-type, "unknown values" can still
be encoded as a char sequence.
Aditionally the WapForum also defines conformance
levels [1] for client (phone) and server (gateway) implementations: only GET
and POST are required, all the others methods are optional. 

WebDav's PROPFIELD
will be guaranteed not work, while any arbitrary content-type can be transported
over WSP.

HTTP-over-WSP connectivity is the standard for mobile 2G networks
(f.e. GSM-CSD).
2.5 G (GPRS, EDGE) and 3G support native TCP/IP.

My Nokia3650
supports GSM-CSD and GPRS. I can define different access points: one using
GSM CSD and providing HTTP-over-WSP connectivity, the other using GPRS and
provide TCP/IP connectivity.

A native C++ application on my Nokia will
not be able to support WebDAV when I'm using my WAP access point.

I guess
the MIDP JSR expert group took a least common demoninator approach and somehow
came up with requiring support for only GET, HEAD and POST.

This does not
forbid MIDP licencees to implement support for additional HTTP methods, but
AFAIK this has not happened.

--
Peter



From owner-atom-syntax@mail.imc.org  Fri Jul 16 16: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 QAA29691
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 16: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 i6GJx5ax030282;
	Fri, 16 Jul 2004 12:59: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 i6GJx4P0030281;
	Fri, 16 Jul 2004 12:59:04 -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 i6GJx3CQ030266
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 12:59:04 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p06110401bd1de3378115@[10.20.30.249]>
In-Reply-To: <40F82C16.2080909@intertwingly.net>
References: <7ABCBE9A-D74A-11D8-9D94-000A95DC3D90@mac.com>
 <40F8125C.5020206@intertwingly.net>
 <E6A5DA82-D751-11D8-9D94-000A95DC3D90@mac.com>
 <40F82C16.2080909@intertwingly.net>
Date: Fri, 16 Jul 2004 12:59:18 -0700
To: Atom WG <atom-syntax@imc.org>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: PaceReplaceLinkElement created
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:27 PM -0400 7/16/04, Sam Ruby wrote:
>The question that needs pondering is whether we want a format and/or 
>protocol with dozens of elements in the core?  Is fewer elements 
>(one perhaps with dozens of options) somehow more "approachable"?
>
>My overall feeling (subjective, I know) is that the latter has 
>considerably more "curb appeal".

-.5. Folks who code in Perl often find that having one object whose 
semantics change based on the arguments is much easier to flub on 
than lots of objects whose names are syntactically different. From a 
higher level, the fact that this element is a link is not nearly as 
descriptive as the fact that this item is a cross-reference, a 
picture, and so on.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Fri Jul 16 16:27: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 QAA00569
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 16:27:49 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GKIuOA033482;
	Fri, 16 Jul 2004 13:18: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 i6GKIt4c033481;
	Fri, 16 Jul 2004 13:18: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.44])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GKIZ2k033387
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 13:18:55 -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 i6GKIeOo015996;
	Fri, 16 Jul 2004 13:18:40 -0700 (PDT)
Received: from [10.232.32.154] ([17.255.240.130])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id i6GKIbKR022656;
	Fri, 16 Jul 2004 13:18:39 -0700 (PDT)
In-Reply-To: <40F82C16.2080909@intertwingly.net>
References: <7ABCBE9A-D74A-11D8-9D94-000A95DC3D90@mac.com> <40F8125C.5020206@intertwingly.net> <E6A5DA82-D751-11D8-9D94-000A95DC3D90@mac.com> <40F82C16.2080909@intertwingly.net>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5-32764771; protocol="application/pkcs7-signature"
Message-Id: <502BD8AE-D765-11D8-9D94-000A95DC3D90@mac.com>
Cc: Atom-Syntax Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: PaceReplaceLinkElement created
Date: Fri, 16 Jul 2004 16:18:34 -0400
To: Sam Ruby <rubys@intertwingly.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-5-32764771
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed
Content-Transfer-Encoding: 7bit

On 16 Jul 2004, at 3:27 pm, Sam Ruby wrote:

> http://bitworking.org/projects/atom/draft-ietf-atompub-protocol 
> -00.html#rfc.section.3.4.1

I've done what I can with that. It's very thin material to work from  
though. No idea about cardinality rules for any of them.

> http://intertwingly.net/wiki/pie/LinkTagMeaning

Introducing those into the spec belongs in a separate thread,

> The question that needs pondering is whether we want a format and/or  
> protocol with dozens of elements in the core?  Is fewer elements (one  
> perhaps with dozens of options) somehow more "approachable"?

But they are elements! By pretending they're not, all we've done is  
introduce massively under-specified metadata into the spec. If you want  
fewer elements, you need to ditch some rel values.

(and anyway, you could achieve the same effect be tabulating the Link  
construct-based elements)

> My overall feeling (subjective, I know) is that the latter has  
> considerably more "curb appeal".

Which justifies the shoddiness?

Graham
--Apple-Mail-5-32764771
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
9w0BCQUxDxcNMDQwNzE2MjAxODM0WjAjBgkqhkiG9w0BCQQxFgQUYHZmhSGXA8IPFjbJxiSy1beH
W2oweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAy3eLbNIAM3RJB1YRNkFxXJMg
19gI2ajza3+oi1dN+2kciSdpKqmgdZed19MQXtNluP5e7JKDSu2fyQNHIcEDRRivmzHvxcE+qcJg
VMQyxdGaXy91h5cVg4TAG6Eku2t2QEN43juplxaVOf7F7eh0rlc1G0dbc9GbV+meYeeMrFG6Z6kn
NRebxEbMlTQVpj28stfYDLCyqzifciHSnEzfoJ6u2uHGjd8Gark3KSw4jz/sbx9rxOdprNgd1Rcq
ZO4yGMidm+/If5RVKh2TXtVaNJqF5a97K4IO/cd/RuM5Q6iI3SkeDOCTWjXp7I7HD69j4UCNWeq0
67bgl8M7tNAOKwAAAAAAAA==

--Apple-Mail-5-32764771--



From owner-atom-syntax@mail.imc.org  Fri Jul 16 16:30: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 QAA00842
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 16:30:54 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GKPCmN034303;
	Fri, 16 Jul 2004 13:25:12 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6GKPC8M034302;
	Fri, 16 Jul 2004 13:25:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GKPBPL034283
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 13:25:11 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from phys-bur-1 ([129.148.9.72])
	by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i6GKPB0R021377
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 13:25:11 -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 <0I0Y00201OPNKV@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com)
 for atom-syntax@imc.org; Fri, 16 Jul 2004 16:25:10 -0400 (EDT)
Received: from mercury (vpn-129-150-33-38.Central.Sun.COM [129.150.33.38])
 by bur-mail1.east.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
 with ESMTP id <0I0Y004DUOPPMM@bur-mail1.east.sun.com> for atom-syntax@imc.org;
 Fri, 16 Jul 2004 16:25:10 -0400 (EDT)
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BlZFu-00056V-00	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 16:24:30 -0400
X-URL: http://nwalsh.com/
Date: Fri, 16 Jul 2004 16:24:18 -0400
From: Norman Walsh <ndw@nwalsh.com>
Subject: Re: Low-hanging fruit: compulsory namespaces
In-reply-to: <40F7DC76.5050508@dehora.net>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <87smbrpuod.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: <6D6BAC41-D517-11D8-8C42-000A95A51C9E@sun.com>
 <40F46DAC.3030900@dehora.net> <D4AC57AE-D527-11D8-A503-000A95A51C9E@sun.com>
 <40F48A82.2020408@dehora.net> <3F81CFBF-D59D-11D8-A6EC-000A95A51C9E@sun.com>
 <40F5415E.5070100@dehora.net> <87k6x6mwef.fsf@nwalsh.com>
 <40F55860.7000800@dehora.net> <87d62w5brt.fsf@nwalsh.com>
 <40F7DC76.5050508@dehora.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-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

/ Bill de h=D3ra <bill@dehora.net> was heard to say:
| Norman Walsh wrote:
|
|> This is where we're failing to communicate. Let's take a closer look
|> at my example:
|
|    0   <outer xmlns=3D"...">
|> 1   <atom:feed xmlns:atom=3D"http://example.org/atom">
|> 2     <atom:content mode=3D"xml">
|> 3       <no-ns>Non-namespaced element</no-ns>
|> 4     </atom:content>
|> 5   </atom:feed>
|    6   </outer>
|
|> If you don't agree with my description above, please tell me how you
|> interpret the spec differently.
|
| See above.

I'm still confused. That's a different document. Are you asking me
what that document means, or are you saying that you have a tool that
produced that document from mine?

If you have an XML tool and you took my document (lines 1-5) and
dropped it into your document (between the "outer" tags) and the
result you got back is shown above, your tool is broken. Your tool was
required, by the specs, as I demonstrated in the original message, to
produce:

 0   <outer xmlns=3D"...">
 1   <atom:feed xmlns:atom=3D"http://example.org/atom">
 2     <atom:content mode=3D"xml">
 3       <no-ns xmlns=3D"">Non-namespaced element</no-ns>
 4     </atom:content>
 5   </atom:feed>
 6   </outer>

Anything else is a bug.

Does that help?

                                        Be seeing you,
                                          norm

=2D-=20
Norman Walsh <ndw@nwalsh.com> | When we are tired, we are attacked by
http://nwalsh.com/            | ideas we conquered long ago.-- Nietzsche

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA+DlzOyltUcwYWjsRAgALAJ9hglUqBnkiB6pZU1onB1I4IPtslgCffx4n
XtNZ7PEgAhHZlbLJllXvFe0=
=UwCe
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Fri Jul 16 16:31: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 QAA00864
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 16: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 i6GKMYKt033973;
	Fri, 16 Jul 2004 13:22: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 i6GKMYt9033972;
	Fri, 16 Jul 2004 13:22:34 -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 i6GKMXfL033956
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 13:22:33 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 821 messnum 6476468 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 16 Jul 2004 20:22:32 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail12.svc.cra.dublin.eircom.net (qp 821) with SMTP; 16 Jul 2004 20:22:32 -0000
Message-ID: <40F83903.3040305@dehora.net>
Date: Fri, 16 Jul 2004 21:22:27 +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: Graham <dtcd@mac.com>
CC: Antone Roundy <antone@geckotribe.com>, atom-syntax@imc.org
Subject: Re: PaceReplaceLinkElement created
References: <CC4A7A8C-D753-11D8-8968-003065EA6144@geckotribe.com> <0E87C81A-D756-11D8-9D94-000A95DC3D90@mac.com>
In-Reply-To: <0E87C81A-D756-11D8-9D94-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: <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:


> By semantically different I mean they have different @rel values, 
> nothing deeper.

I'll push on this a bit. Semantically /different/ to me as a
/concern/, here, would mean there are disjoint types for @rel - ie
there's no code sharing across them and you probably wouldn't have
much joy say hacking a superclass or an @rel visitor. That would
suggest that these things are not all links, for some definition of
link and if so, that it is likely to be the case that we do have
already a problem vis-a-vis the @rel abuse.

cheers
Bill




From owner-atom-syntax@mail.imc.org  Fri Jul 16 16:35: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 QAA01329
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 16:35: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 i6GKQnSp034543;
	Fri, 16 Jul 2004 13: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 i6GKQnvB034542;
	Fri, 16 Jul 2004 13:26:49 -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 i6GKQmvP034523
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 13:26:48 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 25585 messnum 7747567 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 16 Jul 2004 20:26:47 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail01.svc.cra.dublin.eircom.net (qp 25585) with SMTP; 16 Jul 2004 20:26:47 -0000
Message-ID: <40F83A03.3000608@dehora.net>
Date: Fri, 16 Jul 2004 21: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: Mark Baker <distobj@acm.org>
CC: atom-syntax@imc.org
Subject: Re: Q: Put request should return Atom entry?
References: <28C46B463CC0E9torumyax@yahoo.co.jp> <3f1451f50407161103319b3ea5@mail.gmail.com> <20040716182856.GX30868@markbaker.ca>
In-Reply-To: <20040716182856.GX30868@markbaker.ca>
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


Mark Baker wrote:

> - servers MUST indicate successful PUT requests with a 2xx response
> - servers MAY include additional information in the PUT response
> - clients SHOULD NOT expect any additional information in a PUT
> response

+1

cheers
Bill



From owner-atom-syntax@mail.imc.org  Fri Jul 16 16:45: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 QAA02169
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 16:45: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 i6GKe7vO036533;
	Fri, 16 Jul 2004 13: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 i6GKe7h6036532;
	Fri, 16 Jul 2004 13:40: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 i6GKe4SK036493
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 13:40:05 -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 i6GKe053019750
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 15:40:00 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6GKe0el019746;
	Fri, 16 Jul 2004 15:40:00 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom-Syntax Syntax <atom-syntax@imc.org>
Subject: Re: PaceReplaceLinkElement created
References: <7ABCBE9A-D74A-11D8-9D94-000A95DC3D90@mac.com>
	<40F8125C.5020206@intertwingly.net>
	<E6A5DA82-D751-11D8-9D94-000A95DC3D90@mac.com>
	<40F82C16.2080909@intertwingly.net>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 16 Jul 2004 15:39:59 -0500
In-Reply-To: <40F82C16.2080909@intertwingly.net>
Message-ID: <m3u0w7it40.fsf@bitsko.slc.ut.us>
Lines: 62
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: <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> writes:

> The question that needs pondering is whether we want a format and/or
> protocol with dozens of elements in the core?  Is fewer elements
> (one perhaps with dozens of options) somehow more "approachable"?
> 
> My overall feeling (subjective, I know) is that the latter has
> considerably more "curb appeal".

So much curb appeal that someone thought to introduce a "link" element
for RDF, which is by definition a linking language!

I see one of the principle driving forces for moving the "relation
name" to the element type name is to reuse the existing XML
extensibility structure of XML Namespaces.  For example, we're not
using meta/@rel for all of our other metadata elements, but are using
link/@rel for link elements.

Off-hand, I recall seeing all of the following for extensibility
suggestion for use within @rel:

 * rel="fixed"

   Fixed set of relation names, not extensible except through future
   RFCs that update the list.

 * rel="any"

   Unregistered extensions.

 * rel="registered"

   IANA registered relation names.

 * rel="registered.any"

   IANA registered prefixes, prefix-authority specs names.

 * rel="unregistered.any" or rel="unregistered-any"

   Unregistered prefixes, prefix "owner" specs names.  Used by CSS
   implementors, for example.

 * rel="qname"

   XML qnames in content.

 * rel="http://example.org/relations/any"

   Full URI.

 * rel="schema.any"

   "Link namespaces", per RFC 2731, Encoding Dublin Core Metadata in HTML.

Note that the "relation type" (hyperlink, Atom protocol, embedded) is
not part of the @rel "relation name".  Some of the Paces are
suggesting using a small few new element names to indicate "relation
type" (<link>, <service>), while still using an @rel (or equivalent)
for the relation name.

  -- Ken



From owner-atom-syntax@mail.imc.org  Fri Jul 16 17: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 RAA04584
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 17: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 i6GKvX75039412;
	Fri, 16 Jul 2004 13:57: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 i6GKvXZY039411;
	Fri, 16 Jul 2004 13:57:33 -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 i6GKvV5J039354
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 13:57:32 -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; 16 Jul 2004 20:57:13 -0000
X-Apparently-From: <torumyax@yahoo.co.jp>
From: Toru Marumoto <torumyax@yahoo.co.jp>
To: atom-syntax@imc.org
Subject: Re: Q: Put request should return Atom entry?
Date: Sat, 17 Jul 2004 05:55:41 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: TuruKame 3.55
In-Reply-To: <3f1451f50407161219713304e8@mail.gmail.com>
References: <3f1451f50407161219713304e8@mail.gmail.com>
Message-Id: <2BC46B774170C4torumyax@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




>> - servers MUST indicate successful PUT requests with a 2xx response
>> - servers MAY include additional information in the PUT response
>> - clients SHOULD NOT expect any additional information in a PUT
>> response
>
>Works for me.

same for me, as long as it(whatever) will be defined in the spec.

Thanks!


Toru Marumoto
     see you on the web!

--------------------------------

__________________________________________________
Do You Yahoo!?
http://bb.yahoo.co.jp/



From owner-atom-syntax@mail.imc.org  Fri Jul 16 17:06: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 RAA04905
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 17:06: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 i6GKwiaP039633;
	Fri, 16 Jul 2004 13:58: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 i6GKwinY039632;
	Fri, 16 Jul 2004 13:58:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail06.svc.cra.dublin.eircom.net (mail06.svc.cra.dublin.eircom.net [159.134.118.22])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6GKwhY7039613
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 13:58:44 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 70170 messnum 2895379 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 16 Jul 2004 20:58:42 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail06.svc.cra.dublin.eircom.net (qp 70170) with SMTP; 16 Jul 2004 20:58:42 -0000
Message-ID: <40F8417E.9020104@dehora.net>
Date: Fri, 16 Jul 2004 21:58:38 +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: Norman Walsh <ndw@nwalsh.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Low-hanging fruit: compulsory namespaces
References: <6D6BAC41-D517-11D8-8C42-000A95A51C9E@sun.com> <40F46DAC.3030900@dehora.net> <D4AC57AE-D527-11D8-A503-000A95A51C9E@sun.com> <40F48A82.2020408@dehora.net> <3F81CFBF-D59D-11D8-A6EC-000A95A51C9E@sun.com> <40F5415E.5070100@dehora.net> <87k6x6mwef.fsf@nwalsh.com> <40F55860.7000800@dehora.net> <87d62w5brt.fsf@nwalsh.com> <40F7DC76.5050508@dehora.net> <87smbrpuod.fsf@nwalsh.com>
In-Reply-To: <87smbrpuod.fsf@nwalsh.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


Norman Walsh wrote:


> I'm still confused. That's a different document. 

I said elsewhere that we should expect that our XML will get 
embedded. I claim that your rule 1. must *always* apply - saying it 
doesn't apply is seems only useful for the local case and is not robust.


> Are you asking me
> what that document means, or are you saying that you have a tool that
> produced that document from mine?

Neither. I'm  saying I've seen this kind of markup in the wild in 
the same way I've seen application libraries emit malformed XML in 
the wild. It tends to gravitate around "envelope-oriented" markup. I 
have my suspicions as to why but don't care to generalize.


> If you have an XML tool and you took my document (lines 1-5) and
> dropped it into your document (between the "outer" tags) and the
> result you got back is shown above, your tool is broken. Your tool was
> required, [...]

How is it required? I do not see an entailment from your 3 point 
interpretation of namespaces to this bug. I keep going back to them 
and reading them, but it just doesn't follow. And please stop saying 
"your tool". I did not raise tools as being the issue here.

> Does that help?

I guess not. People keep telling me it's a bug, but not why it's a 
bug. In any case I've already signed up "it's a bug" view. But I 
will call it a consensus view only. My point/question has always 
been whether this is something that is *specified* somewhere. 
However many days into this thread, I'm still not seeing that 
specification.

We're way off topic by now. I was looking for a few sentences in the 
spec to clear things up, sentences that I believe are deeply 
uncontroversial,  but people seem to be violently against saying 
anything direct on the matter. I'm more than happy to drop it and 
move on.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Fri Jul 16 17:09: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 RAA05262
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 17:09:33 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GL3NeO040463;
	Fri, 16 Jul 2004 14:03:23 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6GL3NTV040462;
	Fri, 16 Jul 2004 14:03: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 i6GL3MLD040441;
	Fri, 16 Jul 2004 14:03: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 i6GL4AV8012395;
	Fri, 16 Jul 2004 17:04:11 -0400
Message-ID: <40F84291.3060502@intertwingly.net>
Date: Fri, 16 Jul 2004 17:03:13 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <phoffman@imc.org>
CC: Atom WG <atom-syntax@imc.org>
Subject: Re: PaceReplaceLinkElement created
References: <7ABCBE9A-D74A-11D8-9D94-000A95DC3D90@mac.com> <40F8125C.5020206@intertwingly.net> <E6A5DA82-D751-11D8-9D94-000A95DC3D90@mac.com> <40F82C16.2080909@intertwingly.net> <p06110401bd1de3378115@[10.20.30.249]>
In-Reply-To: <p06110401bd1de3378115@[10.20.30.249]>
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


Paul Hoffman / IMC wrote:

> 
> At 3:27 PM -0400 7/16/04, Sam Ruby wrote:
> 
>> The question that needs pondering is whether we want a format and/or 
>> protocol with dozens of elements in the core?  Is fewer elements (one 
>> perhaps with dozens of options) somehow more "approachable"?
>>
>> My overall feeling (subjective, I know) is that the latter has 
>> considerably more "curb appeal".
> 
> -.5. Folks who code in Perl often find that having one object whose 
> semantics change based on the arguments is much easier to flub on than 
> lots of objects whose names are syntactically different. From a higher 
> level, the fact that this element is a link is not nearly as descriptive 
> as the fact that this item is a cross-reference, a picture, and so on.

FWIW, the motivation wasn't Perl, it was HTML:

http://www.w3.org/TR/REC-html40/struct/links.html#h-12.3
http://www.w3.org/TR/REC-html40/types.html#type-links

When one has an archive, one can imagine a start, next, and prev, 
contents, etc, exactly like HTML.

Furthermore, all blogs should have a <link rel="alternate"> to their 
feed(s), so a symmetric backlink seemed appropriate.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Fri Jul 16 17:14: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 RAA05849
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 17:14:04 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GL529S040687;
	Fri, 16 Jul 2004 14: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 i6GL52ZW040686;
	Fri, 16 Jul 2004 14:05: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 i6GL51sB040666
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 14:05:02 -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 i6GL5153020017
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 16:05:01 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6GL50xp020008;
	Fri, 16 Jul 2004 16:05:00 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom-Syntax <atom-syntax@imc.org>
Subject: LinkReferences and LinkingStyles
References: <40E16215.6070507@intertwingly.net>
	<40EC9915.4050406@intertwingly.net>
	<40F539FE.7010600@intertwingly.net>
	<40F7EFD4.1090608@intertwingly.net>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 16 Jul 2004 16:05:00 -0500
In-Reply-To: <40F7EFD4.1090608@intertwingly.net>
Message-ID: <m3llhjiryb.fsf_-_@bitsko.slc.ut.us>
Lines: 22
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: <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've created two wiki pages for aiding the discussion of links.

LinkReferences provides a list of link references, terminology, and
Atom wiki pages discussing links.

LinkingStyles gathers in one place a side-by-side visual comparison of
the linking proposals.

In discussing links, we should be clear on such things as the
"relation name" (what a link with "this" name "means", whether it's in
@rel or the element name) and "relation type" or "relation class"
(what class of links this links falls within: hyperlink, Atom
protocol, display).

For example, PaceServiceElement proposes new elements for the relation
type while maintaining the relation name in an attribute.
PaceReplaceLinkElement proposes using element names for relation
names, but does not distinguish relation types that a client can use
to know how to deal with extensions, particularly those that can or
should be displayed to the user for selection.

  -- Ken



From owner-atom-syntax@mail.imc.org  Fri Jul 16 17:18: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 RAA05971
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 17:18: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 i6GLBbAJ041820;
	Fri, 16 Jul 2004 14: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 i6GLBbJd041819;
	Fri, 16 Jul 2004 14:11:37 -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 i6GLBa0g041797
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 14:11:36 -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 i6GLCPLU012777;
	Fri, 16 Jul 2004 17:12:25 -0400
Message-ID: <40F84483.2090707@intertwingly.net>
Date: Fri, 16 Jul 2004 17:11:31 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <Tim.Bray@Sun.COM>
CC: Atom-Syntax Syntax <atom-syntax@imc.org>
Subject: Re: PaceReplaceLinkElement: Is link-ness relevant?
References: <097F1326-D761-11D8-92AF-000A95A51C9E@sun.com>
In-Reply-To: <097F1326-D761-11D8-92AF-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:
> 
> I'm sure there must be some good reason why it's considered a good thing 
> to be able to spot that an element is a link to something, even if you 
> have no idea what the semantics of that link are.  I assume there must 
> be some essential thing you can do given that knowledge.  But I just 
> went and poked around the Paces and I can't find it.  Could someone 
> please provide some motivation or some use cases?  Because unless 
> there's a good strong motivation, I don't understand why we're even 
> having this discussion. -Tim

It took me a while to dig this up:

http://www.intertwingly.net/wiki/pie/ExtensibilityFramework

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Fri Jul 16 17:22: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 RAA06185
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 17:22: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 i6GLFkco042520;
	Fri, 16 Jul 2004 14:15: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 i6GLFkv2042519;
	Fri, 16 Jul 2004 14:15: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 i6GLFiSK042512
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 14:15:44 -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 i6GLDe53029593
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 15:13:40 -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 <0I0Y000HMR2CDZ@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Fri, 16 Jul 2004 15:15:49 -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 <0I0Y00L00R2BXL@mail.sun.net> for atom-syntax@imc.org; Fri,
 16 Jul 2004 15:15:48 -0600 (MDT)
Date: Fri, 16 Jul 2004 14:15:52 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Q: Put request should return Atom entry?
In-reply-to: <2BC46B774170C4torumyax@yahoo.co.jp>
To: Joe Gregorio <joe@bitworking.org>, Robert Sayre <mint@franklinmint.fm>,
        Atom-Syntax Syntax <atom-syntax@imc.org>
Message-id: <517B15C7-D76D-11D8-92AF-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: <3f1451f50407161219713304e8@mail.gmail.com>
 <2BC46B774170C4torumyax@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


>>> - servers MUST indicate successful PUT requests with a 2xx response
>>> - servers MAY include additional information in the PUT response
>>> - clients SHOULD NOT expect any additional information in a PUT
>>> response

I see lots of +1's... quick Joe/Rob, grab it and put it in the spec.  
Thanks to whoever originally  asked this useful question. -Tim



From owner-atom-syntax@mail.imc.org  Fri Jul 16 17:35:50 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08258
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 17:35: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 i6GLPJWh044220;
	Fri, 16 Jul 2004 14:25: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 i6GLPJVh044219;
	Fri, 16 Jul 2004 14:25: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 i6GLPIZi044202
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 14:25: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 i6GLPH53020259
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 16:25:17 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6GLPHmM020255;
	Fri, 16 Jul 2004 16:25:17 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceIntrospection: New Examples for Feed-Based Introspection
References: <40F52038.4050101@spoonybards.net>
	<m3u0walm7v.fsf@bitsko.slc.ut.us>
	<3f1451f50407140749f045eb@mail.gmail.com> <40F6A7DB.4000908@aol.net>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 16 Jul 2004 16:25:17 -0500
In-Reply-To: <40F6A7DB.4000908@aol.net>
Message-ID: <m3brifir0i.fsf@bitsko.slc.ut.us>
Lines: 49
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


jpanzer@aol.net (John Panzer) writes:

> <?xml version='1.0'encoding="utf-8"?>
> <feed version='0.3' xmlns='http://purl.org/atom/ns#' xmlns:ps='http://www.pubsub.com/xmlns'>
>    <link rel='alternate' type='text/html' href='http://example.com/bugsbunny'/>
>    <modified>2004-07-07T18:36:11-04:00</modified>
>    <author>
>       <name>Bugs Bunny</name>
>    </author>
> <title><![CDATA[Bugs Bunny's Blogs]]></title>
> 
> <entry>
>   <ps:source-feed>
>     <title><![CDATA[Title of my First Blog]]></title>
>     <link rel='alternate' type='text/html' href='http://example.com/bugsbunny/MyFirstBlog'/>
>     <link rel='???' type='application/atom+xml' href='http://example.com/bugsbunny/MyFirstBlog.atom'/>
>     <link rel="service.post" type="application/atom+xml"
>       href="http:/example.com/bugsbunny/MyFirstBlog/atompost.cgi">
>   </ps:source-feed>
>   <issued>2004-07-07T19:34:10-04:00</issued>
>   <content>...</content>
> </entry>
> 
> It's unambiguous which data is associated with the feed.  Synthetic
> feeds are also something that aggregators will have to deal with in
> any case.  Can these same mechanisms be used for introspection?  (My
> position is that introspection-like-things will happen using
> synthetic feeds in any case, because they're generally useful.)

The above clearly distinguishes the site information in the entry
using the element type name ps:source-feed, the aggregator should use
that to say "original from feed Title of my First Blog" or the like,
but the feed does not indicate in any way that "this feed is not just
a bunch of entries from different blogs, it's a feed of blogs that you
should use to report new blogs to the user".  It still needs another
bit of information for that, maybe,

<?xml version='1.0'encoding="utf-8"?>
<feed version='0.3' xmlns='http://purl.org/atom/ns#' xmlns:ps='http://www.pubsub.com/xmlns'>
   <link rel='alternate' type='text/html' href='http://example.com/bugsbunny'/>
   <modified>2004-07-07T18:36:11-04:00</modified>
   <author>
      <name>Bugs Bunny</name>
   </author>
   <title><![CDATA[Bugs Bunny's Blogs]]></title>
   <resource-type>feedlist</resource-type>


  -- Ken



From owner-atom-syntax@mail.imc.org  Fri Jul 16 17:37: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 RAA08590
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 17:37: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 i6GLS6oJ044615;
	Fri, 16 Jul 2004 14:28: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 i6GLS6bC044613;
	Fri, 16 Jul 2004 14:28: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.de [213.165.64.20])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6GLS5SE044582
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 14:28:05 -0700 (PDT)
	(envelope-from julian.reschke@gmx.de)
Received: (qmail 23468 invoked by uid 65534); 16 Jul 2004 21:27:59 -0000
Received: from pD95350F7.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.80.247)
  by mail.gmx.net (mp014) with SMTP; 16 Jul 2004 23:27:59 +0200
X-Authenticated: #1915285
Message-ID: <40F8485E.5000604@gmx.de>
Date: Fri, 16 Jul 2004 23:27:58 +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: Low-hanging fruit: compulsory namespaces
References: <6D6BAC41-D517-11D8-8C42-000A95A51C9E@sun.com> <40F46DAC.3030900@dehora.net> <D4AC57AE-D527-11D8-A503-000A95A51C9E@sun.com> <40F48A82.2020408@dehora.net> <3F81CFBF-D59D-11D8-A6EC-000A95A51C9E@sun.com> <40F5415E.5070100@dehora.net> <87k6x6mwef.fsf@nwalsh.com> <40F55860.7000800@dehora.net> <87d62w5brt.fsf@nwalsh.com> <40F7DC76.5050508@dehora.net> <87smbrpuod.fsf@nwalsh.com> <40F8417E.9020104@dehora.net>
In-Reply-To: <40F8417E.9020104@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 guess not. People keep telling me it's a bug, but not why it's a bug. 
> In any case I've already signed up "it's a bug" view. But I will call it 
> a consensus view only. My point/question has always been whether this is 
> something that is *specified* somewhere. However many days into this 
> thread, I'm still not seeing that specification.
> ...

I think it's the basic nature of a namespace-aware tool that when you 
embed XML from a document X into a document Y, namespace names and local 
names of the embedded document will not change (maybe unless you 
specifically ask for it). Does this really need to spelled out expliticly?

Anyway, for DOM L2, this seems to follow from 
<http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html#Namespaces-Considerations>:

"As far as the DOM is concerned, special attributes used for declaring 
XML namespaces are still exposed and can be manipulated just like any 
other attribute. However, nodes are permanently bound to namespace URIs 
as they get created. Consequently, moving a node within a document, 
using the DOM, in no case results in a change of its namespace prefix or 
namespace URI. Similarly, creating a node with a namespace prefix and 
namespace URI, or changing the namespace prefix of a node, does not 
result in any addition, removal, or modification of any special 
attributes for declaring the appropriate XML namespaces. Namespace 
validation is not enforced; the DOM application is responsible. In 
particular, since the mapping between prefixes and namespace URIs is not 
enforced, in general, the resulting document cannot be serialized 
naively. For example, applications may have to declare every namespace 
in use when serializing a document."

(note the 2nd sentence).

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From owner-atom-syntax@mail.imc.org  Fri Jul 16 18: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 SAA13331
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 18:06: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 i6GLtmrf049420;
	Fri, 16 Jul 2004 14: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 i6GLtmiC049419;
	Fri, 16 Jul 2004 14:55:48 -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 i6GLtlsm049386
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 14:55:47 -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 i6GLtk53020550
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 16:55:46 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6GLtk4k020546;
	Fri, 16 Jul 2004 16:55:46 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PacePutDelete Withdrawn
References: <3f1451f504071218365f8ebf05@mail.gmail.com>
	<6315ADDE-D623-11D8-A6EC-000A95A51C9E@sun.com>
	<77058460BAC368B3D824DD7E@diva.verity.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 16 Jul 2004 16:55:46 -0500
In-Reply-To: <77058460BAC368B3D824DD7E@diva.verity.com>
Message-ID: <m3658niplp.fsf@bitsko.slc.ut.us>
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


Another perspective to note about the SOAP fallback and binary
resources: it is my understanding that there are client implementors
who are implementing to the SOAP binding exclusively, for the purpose
of using SOAP stacks to talk to servers, not merely as a fallback if
PUT/DELETE are not available to them.

These developers are affected by using a binary POST/PUT upload that
does not have a SOAP wrapper, at least in the degree that "this" one
tiny bit of Atom protocol must make them revert to using naked HTTP.

I put this in the "if it hurts, don't do that" category, but it is a
use-case nonetheless.

  -- Ken



From owner-atom-syntax@mail.imc.org  Fri Jul 16 19:07:32 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17373
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 19:07: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 i6GMusHH058852;
	Fri, 16 Jul 2004 15:56:54 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6GMus1O058851;
	Fri, 16 Jul 2004 15:56:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GMuro7058844
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 15:56: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 esmtp (Exim 4.34)
	id 1BlbdO-0006zi-Vx; Fri, 16 Jul 2004 22:56:55 +0000
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Fri, 16 Jul 2004 18:57:03 -0400
Subject: Re: Q: Put request should return Atom entry?
From: Robert Sayre <mint@franklinmint.fm>
To: Tim Bray <Tim.Bray@Sun.COM>, Joe Gregorio <joe@bitworking.org>,
        Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD1DD57F.13D52%mint@franklinmint.fm>
In-Reply-To: <517B15C7-D76D-11D8-92AF-000A95A51C9E@sun.com>
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: <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 7/16/04 5:15 PM, "Tim Bray" <Tim.Bray@Sun.COM> wrote:

> 
>>>> - servers MUST indicate successful PUT requests with a 2xx response
>>>> - servers MAY include additional information in the PUT response
>>>> - clients SHOULD NOT expect any additional information in a PUT
>>>> response
> 
> I see lots of +1's... quick Joe/Rob, grab it and put it in the spec.
> Thanks to whoever originally  asked this useful question. -Tim
> 

And so it was done. One question, though. Is the third sentence redundant?
Clients shouldn't expect anything in the response body because servers don't
have to send it. Couldn't hurt, I guess.

Robert Sayre



From owner-atom-syntax@mail.imc.org  Fri Jul 16 19:30: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 TAA19562
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 19:30:06 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GNMZip063716;
	Fri, 16 Jul 2004 16:22: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 i6GNMZ7e063715;
	Fri, 16 Jul 2004 16:22: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 i6GNMYxZ063708
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 16:22:34 -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 esmtp (Exim 4.34)
	id 1Blc2G-0007oO-Gc; Fri, 16 Jul 2004 23:22:36 +0000
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Fri, 16 Jul 2004 19:22:45 -0400
Subject: Summary of Put/Delete problems (PacePutDelete Withdrawn)
From: Robert Sayre <mint@franklinmint.fm>
To: <kwark.1511609@bloglines.com>, <joe.gregorio@gmail.com>
CC: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD1DDB85.13D53%mint@franklinmint.fm>
In-Reply-To: <1090007990.1602124828.29296.sendItem@bloglines.com>
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: <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 7/16/04 3:59 PM, "kwark.1511609@bloglines.com"
<kwark.1511609@bloglines.com> wrote:

> 
> I guess
> the MIDP JSR expert group took a least common demoninator approach and somehow
> came up with requiring support for only GET, HEAD and POST.

According to PutDeleteSupport on the wiki, the following platforms have
problems:

- PHP prior to 4.3
- ColdFusion prior to 6.1
- Ruby Net::HTTP 
I don't have anything to say about these three.


- Python urllib2
Doesn't matter. httplib is easy and standard. Batteries included.


- Mac OS X - NSURLConnection
PUT requests omit the request body. I gather this bug is already fixed for a
future release. At any rate, OS X developers have plenty of other options
for HTTP connectivity.


- Java J2ME MIDP 1.0/2.0
I decided to ignore Peter and try writing something with PUT/DELETE.
Unsurprisingly, Peter was right. The upside is that I found that writing
text-based J2ME apps to be rather more convenient than I expected. So
convenient that we should make sure it's easy. It's pretty cool. I'm sure it
gets exponentially more difficult as you attempt to support more phone
models, but everything worked as expected on my Nokia 3650, the Sun
reference emulator, and a couple different Nokia emulators.

Unless your phone/network supports the "socket://" URI scheme, there's no
way you're going get at that OutputStream to set the HTTP method to PUT or
DELETE, unless you resort to monkey business that we should never recommend.

It would appear that the most convenient approach for J2ME applications
would be a request header in combination with POST. SOAP would be workable
as well, but updates of binary resources would be a problem.


- Flash
Flash MX 2004 / FlashPlayer 7 has SOAP support, and I'm pretty sure there's
nothing interesting you could send as binary with Flash. Headers are also
out, I think. The wiki mentions the XMLSocket object, which does let you
send anything over a socket (not just XML). It's restricted to the same host
and ports above 1024. Other Flash objects allow transmission of XML to port
80 on the same host. The LoadMovie() function allows loading of SWFs and
JPGs (JPGs in Flash6) from other hosts.

SOAP would appear to be the best bet here.

Note: I have written tons of ActionScript, but most of it was targeted at
Flash 5.


- Existing SOAP infrastructure
I'm guessing SOAP would be most convenient here ;)


Robert Sayre



From owner-atom-syntax@mail.imc.org  Fri Jul 16 19:35:22 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19803
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 19:35: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 i6GNSUUt064586;
	Fri, 16 Jul 2004 16:28:30 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6GNSU7m064585;
	Fri, 16 Jul 2004 16:28:30 -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 i6GNSUcs064569
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 16:28: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 (rwcrmhc13) with SMTP
          id <20040716232830015003flb4e>; Fri, 16 Jul 2004 23:28:30 +0000
Date: Fri, 16 Jul 2004 17:28:29 -0600
Subject: Re: PaceReplaceLinkElement: Is link-ness relevant?
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: <097F1326-D761-11D8-92AF-000A95A51C9E@sun.com>
Message-Id: <D80692E3-D77F-11D8-8968-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 Friday, July 16, 2004, at 01:47  PM, Tim Bray wrote:
> I'm sure there must be some good reason why it's considered a good 
> thing to be able to spot that an element is a link to something, even 
> if you have no idea what the semantics of that link are.  I assume 
> there must be some essential thing you can do given that knowledge.  
> But I just went and poked around the Paces and I can't find it.  Could 
> someone please provide some motivation or some use cases?  Because 
> unless there's a good strong motivation, I don't understand why we're 
> even having this discussion. -Tim
>
A non-Atom example: If you put the following into the head of an HTML 
document and load it in Mozilla with the Site Navigation Bar active 
(look under View >> Show/Hide >> Site Navigation Bar), a "More" menu 
will show up with the link in it.

<link rel="MyLinkType" title="This links to something" 
href="http://www.example.org/">

Any @rel value that Mozilla doesn't understand will get its own submenu 
with any links of that type showing up in it.



From owner-atom-syntax@mail.imc.org  Fri Jul 16 20:03:36 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21155
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 20:03:35 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6GNrbDZ068205;
	Fri, 16 Jul 2004 16:53: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 i6GNrbHC068204;
	Fri, 16 Jul 2004 16:53: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 i6GNraTB068184
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 16:53:36 -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 i6GNra53021677
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 18:53:36 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6GNraEN021673;
	Fri, 16 Jul 2004 18:53:36 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: atom-syntax@imc.org
Subject: Re: PaceReduceMustMay: new editorial proposal
References: <m3zn60j1jc.fsf@bitsko.slc.ut.us>
	<9DEF070C-D6E8-11D8-97B1-000A95BD86C0@mnot.net>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 16 Jul 2004 18:53:36 -0500
In-Reply-To: <9DEF070C-D6E8-11D8-97B1-000A95BD86C0@mnot.net>
Message-ID: <m3zn5zh5kv.fsf@bitsko.slc.ut.us>
Lines: 74
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: <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> writes:

> I think it's fine to replace the normative requirements in prose
> with some sort of schema language -- if one can be agreed upon --
> but I'd like to have the replacement in place before we rip these
> out. Would your proposal extend to that?

The suggestion isn't specifically to replace the imperatives with
schema/BNF, but to remove the strong imperatives from what is basic
specification.  Example:

4.8  "atom:id" Element

   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.  atom:feed elements MAY contain an atom:id
   element, but MUST NOT contain more than one.  The content of this
   element, when present, MUST be a URI.

   xml:base [W3C.REC-xmlbase-20010627] processing MUST be applied to the
   atom:id element's content.

becomes:

4.8  "atom:id" Element

   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.  atom:id is optional and is not
   repeatable.  The content of this element is a URI.  xml:base
   processing is applied to the atom:id URI.


As a separate concern, having schema/BNF notation would be a good
thing.  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).

> Also, I'm a little uncomfortable with editorial work by Pace; it
> smacks of word-smithing by committee, something that IME doesn't
> work out well. I'm happy to take suggestions on board, but having
> people propose editorial changes word-for-word to be incorporated
> wholesale removes the ability of the editors to make a judgement
> call.

My offer is to do the legwork on finding current common practice and
providing those to the editors to implement, not the word-by-word
editing.  Proposing a notation for content models would be in scope
for this pace.

> That said, could you expand upon what you mean by reducing the
> formality of the specs? I would grant that the prose is a bit turgid
> now -- something that I planned to address in an upcoming edit --
> but on the whole, I prefer to err on the side of formality.

> In my experience, more formal specs, while requiring a bit more
> effort on the part of the reader, usually result in much tighter,
> interoperable, and more correct specs; OTOH the looser, more
> conversational specs that I've been involved with have always been
> the ones that different people interpret in different ways.

The above example isn't really conversational, it still has one
specification statement per sentence, but by removing the need to work
in a "MUST", "MUST NOT", etc., it can be more readable without being
less rigorous.

If you've already planned on doing something like this, then I'll go
ahead and stop here.  The discovery of using a schema as a notation
rather than a normative schema is good information, though, I think
I'll work up a suggestion/comparison there.

  -- Ken



From owner-atom-syntax@mail.imc.org  Fri Jul 16 20:08: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 UAA21546
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 20:08: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 i6GNwPsg068794;
	Fri, 16 Jul 2004 16:58: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 i6GNwPcq068793;
	Fri, 16 Jul 2004 16:58:25 -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 i6GNwDsr068771;
	Fri, 16 Jul 2004 16:58:14 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p0611040dbd1e1be6f1be@[10.20.30.249]>
In-Reply-To: <BD1DDB85.13D53%mint@franklinmint.fm>
References: <BD1DDB85.13D53%mint@franklinmint.fm>
Date: Fri, 16 Jul 2004 16:58:47 -0700
To: Robert Sayre <mint@franklinmint.fm>, <kwark.1511609@bloglines.com>,
        <joe.gregorio@gmail.com>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
Cc: Atom Syntax <atom-syntax@imc.org>
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>


Another data point, from a Brew person at Qualcomm:

>It looks like Brew supports PUT & DELETE. You can use the Brew HTTP 
>implementation for what ever HTTP method you want. Don't know if 
>there's some extra stuff required for PUT & DELETE though. If so, 
>then it is probably not there (didn't see it in the source), but you 
>could probably make it work in some form. The HTTP engine is pretty 
>flexible. You can find some details on it in the Brew SDK API 
>Reference manual. The correct section is IWeb and the option is 
>WEBOPT_METHOD.  Am pretty sure you have to download the SDK to get 
>the documentation. You can get it at 
>https://brewx.qualcomm.com/brew/sdk/download.jsp.
>
>For Brew in general you can write most any program you want, so even 
>if Brew didn't support it you could write your own HTTP engine with 
>it. Brew makes an equivalent of sockets available. Phones are moving 
>from the ARM7 processor to the ARM9 processor now and that gives you 
>lots and lots of cycles. They also have a lot more memory than they 
>used to. Brew does SSL without any special hardware and it performs 
>OK on the ARM7 and well on the ARM9. I doubt your protocol is more 
>complex than SSL so in principle it is no problem. Mostly a matter 
>of access to sockets if the HTTP engine doesn't do PUT/DELETE.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Fri Jul 16 20:26: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 UAA22671
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 20:26:54 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6H0EO4H070874;
	Fri, 16 Jul 2004 17:14: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 i6H0EOF6070873;
	Fri, 16 Jul 2004 17:14:24 -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 i6H0ENmq070855
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 17:14:23 -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 i6H0EN53021891
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 19:14:23 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6H0ENVP021887;
	Fri, 16 Jul 2004 19:14:23 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom WG <atom-syntax@imc.org>
Subject: Re: PaceReplaceLinkElement created
References: <7ABCBE9A-D74A-11D8-9D94-000A95DC3D90@mac.com>
	<40F8125C.5020206@intertwingly.net>
	<E6A5DA82-D751-11D8-9D94-000A95DC3D90@mac.com>
	<40F82C16.2080909@intertwingly.net>
	<p06110401bd1de3378115@[10.20.30.249]>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 16 Jul 2004 19:14:23 -0500
In-Reply-To: <p06110401bd1de3378115@[10.20.30.249]>
Message-ID: <m3vfgnh4m8.fsf@bitsko.slc.ut.us>
Lines: 28
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: <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> writes:

> At 3:27 PM -0400 7/16/04, Sam Ruby wrote:
> > The question that needs pondering is whether we want a format
> > and/or protocol with dozens of elements in the core?  Is fewer
> > elements (one perhaps with dozens of options) somehow more
> > "approachable"?
> >
> > My overall feeling (subjective, I know) is that the latter has
> > considerably more "curb appeal".
> 
> -.5. Folks who code in Perl often find that having one object whose
> semantics change based on the arguments is much easier to flub on
> than lots of objects whose names are syntactically different. From a
> higher level, the fact that this element is a link is not nearly as
> descriptive as the fact that this item is a cross-reference, a
> picture, and so on.

If I read this right, you're thinking that each link would be a
different class (module) because it's name is different?  I don't
think that's the case, child elements of "entity constructs" like
atom:feed and atom:entry are typically mapped to object attribute
names, not object types.  $entry->{alternate} has all the 'alternate'
links of that entry, of which each is an instance of the Atom::Link
class (because elsewhere in the spec we've said how to know an element
is a link).

  -- Ken



From owner-atom-syntax@mail.imc.org  Fri Jul 16 20:33: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 UAA23085
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 20:33: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 i6H0LX7g071857;
	Fri, 16 Jul 2004 17: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 i6H0LXld071856;
	Fri, 16 Jul 2004 17:21:33 -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 i6H0LW6q071850
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 17:21:32 -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 i6H0JT53026806
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 18:19:29 -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 <0I0Y0096TZO161@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Fri, 16 Jul 2004 18:21:38 -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 <0I0Y0047DZO00A@mail.sun.net> for atom-syntax@imc.org; Fri,
 16 Jul 2004 18:21:37 -0600 (MDT)
Date: Fri, 16 Jul 2004 17:21:41 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: A reminder we should think about congestion control at some point
To: Atom-Syntax Syntax <atom-syntax@imc.org>
Message-id: <46D88C9C-D787-11D8-92AF-000A95A51C9E@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.618)
Content-type: text/plain; charset=US-ASCII; delsp=yes; 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


http://www.infoworld.com/article/04/07/16/29OPconnection_1.html? 
source=rss&url=http://www.infoworld.com/article/04/07/16/ 
29OPconnection_1.html

I'm not sure this is *really* a problem, in that we might decide that  
existing HTTP caching & traffic management techniques will suffice for  
Atom.  But we should be conscious of it. -Tim



From owner-atom-syntax@mail.imc.org  Fri Jul 16 20:48: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 UAA23984
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 20:48: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 i6H0aiWx073909;
	Fri, 16 Jul 2004 17:36:44 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6H0aiBc073908;
	Fri, 16 Jul 2004 17:36: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.47])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6H0aic9073901
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 17:36:44 -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 i6H0anGQ025731;
	Fri, 16 Jul 2004 17:36:49 -0700 (PDT)
Received: from [192.168.1.107] (66-65-118-184.nyc.rr.com [66.65.118.184])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin01/MantshX 4.0) with ESMTP id i6H0aVLB004423;
	Fri, 16 Jul 2004 17:36:46 -0700 (PDT)
In-Reply-To: <D80692E3-D77F-11D8-8968-003065EA6144@geckotribe.com>
References: <D80692E3-D77F-11D8-8968-003065EA6144@geckotribe.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1-48238014; protocol="application/pkcs7-signature"
Message-Id: <56F15E2E-D789-11D8-9095-000A95DC3D90@mac.com>
Cc: atom-syntax@imc.org
From: Graham <dtcd@mac.com>
Subject: Re: PaceReplaceLinkElement: Is link-ness relevant?
Date: Fri, 16 Jul 2004 20:36:27 -0400
To: Antone Roundy <antone@geckotribe.com>
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-48238014
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 16 Jul 2004, at 7:28 pm, Antone Roundy wrote:

> A non-Atom example: If you put the following into the head of an HTML 
> document and load it in Mozilla with the Site Navigation Bar active 
> (look under View >> Show/Hide >> Site Navigation Bar), a "More" menu 
> will show up with the link in it.
>
> <link rel="MyLinkType" title="This links to something" 
> href="http://www.example.org/">
>
> Any @rel value that Mozilla doesn't understand will get its own 
> submenu with any links of that type showing up in it.

As an aggregator developer, I'd like to declare I have no plans (or 
desires) to do anything at all with unrecognised Link constructs, and 
thus no desire to be able to pick them out easily.

Graham
--Apple-Mail-1-48238014
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
9w0BCQUxDxcNMDQwNzE3MDAzNjI3WjAjBgkqhkiG9w0BCQQxFgQUzw2XFCtKcf7mla7fIxrM6Pat
d60weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAUm5tQPwC+vCiJPxjGU7KO50j
rMrkoBBoBnmrUpFg2c7jc1PoEcHE8A0YNy5AJ/lWcgZopab8uMn5wvg8koItH8hHUlekszTGxiSb
bYK2GDT7a0miDLFCXk77F0PvDAGw69NggtWqiMd1mYt4KSJvOPYScCfJd3l7VZAbklwstks/6wmd
Hex46YNqEGvmTxkSdITuKakTzXdoGD9bXxjLZIFjgezI8Bsts8B5oLTY1jeipG54cgQ66Nt9wfqF
t1d2b17wc5XKyjRnBgy8ExKVgItE3BoPgUCXrASRL//s/frf2xhsDiJl2K/8AKv7inWYeo9FtlOJ
WtPDmdXVNGk1xQAAAAAAAA==

--Apple-Mail-1-48238014--



From owner-atom-syntax@mail.imc.org  Fri Jul 16 20:58: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 UAA24321
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 20:58: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 i6H0ksFO075333;
	Fri, 16 Jul 2004 17:46: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 i6H0ks8W075332;
	Fri, 16 Jul 2004 17:46: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.207])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6H0krgJ075317
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 17:46:53 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d78so525478rnf
        for <atom-syntax@imc.org>; Fri, 16 Jul 2004 17:46:55 -0700 (PDT)
Received: by 10.38.59.67 with SMTP id h67mr131052rna;
        Fri, 16 Jul 2004 17:46:55 -0700 (PDT)
Message-ID: <14be96d3040716174668c86fbf@mail.gmail.com>
Date: Fri, 16 Jul 2004 20:46:55 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Tim Bray <tim.bray@sun.com>
Subject: Re: A reminder we should think about congestion control at some point
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <46D88C9C-D787-11D8-92AF-000A95A51C9E@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <46D88C9C-D787-11D8-92AF-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 Fri, 16 Jul 2004 17:21:41 -0700, Tim Bray <tim.bray@sun.com> wrote:
> 
> http://www.infoworld.com/article/04/07/16/29OPconnection_1.html?
> source=rss&url=http://www.infoworld.com/article/04/07/16/
> 29OPconnection_1.html
> 
> I'm not sure this is *really* a problem, in that we might decide that
> existing HTTP caching & traffic management techniques will suffice for
> Atom.  But we should be conscious of it. -Tim

They could start by using HTTP properly.  There server does not
support Etags, Last-Modified headers, or gzip compression.  No wonder
they have bandwidth problems.  (They're also serving their feeds as
text/html, but never mind that.)

haven:~ mark$ curl -sI http://www.infoworld.com/rss/news.xml
HTTP/1.1 200 OK
Date: Sat, 17 Jul 2004 00:45:10 GMT
Server: Apache
Accept-Ranges: bytes
Content-Type: text/html; charset=UTF-8

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Fri Jul 16 21:08: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 VAA24806
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 21:08: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 i6H0uNUi076685;
	Fri, 16 Jul 2004 17: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 i6H0uNU9076684;
	Fri, 16 Jul 2004 17:56:23 -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 i6H0uMgI076667
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 17:56:23 -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 i6H0uM53022363
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 19:56:23 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6H0uMjY022359;
	Fri, 16 Jul 2004 19:56:22 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom-Syntax Syntax <atom-syntax@imc.org>
Subject: Re: PaceReplaceLinkElement: Is link-ness relevant?
References: <097F1326-D761-11D8-92AF-000A95A51C9E@sun.com>
	<40F84483.2090707@intertwingly.net>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 16 Jul 2004 19:56:22 -0500
In-Reply-To: <40F84483.2090707@intertwingly.net>
Message-ID: <m3r7rbh2o9.fsf@bitsko.slc.ut.us>
Lines: 70
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: <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> writes:

> Tim Bray wrote:
> > I'm sure there must be some good reason why it's considered a good
> > thing to be able to spot that an element is a link to something,
> > even if you have no idea what the semantics of that link are.  I
> > assume there must be some essential thing you can do given that
> > knowledge.  But I just went and poked around the Paces and I can't
> > find it.  Could someone please provide some motivation or some use
> > cases?  Because unless there's a good strong motivation, I don't
> > understand why we're even having this discussion. -Tim
> 
> It took me a while to dig this up:
> 
> http://www.intertwingly.net/wiki/pie/ExtensibilityFramework

ExtensibilityFramework uses @ref as a foreign key reference.

Another example was in,

   http://imc.org/atom-syntax/mail-archive/msg06720.html

where @ref (coincidentally) was used to mean a link to an element that
needs to be copied to downstream feeds.

Implementations know the processing behavior of the link by the
attribute used to reference the link, the "relation type" in
LinkReferences.

Being able to scan for links of a certain relation type gives an
implementation an ability to process them as a group.

@href in SkunkLink[1] is like <link> in HTML, and browsers and Atom
clients know to make those available in a menu for the user.

One of the key differences in the proposed link markup styles is
whether to make the element name the relation name or the relation
type.

  * If the element name is the relation type, then the relation name
    goes in an @rel attribute and we have do spec extensibility for
    the value of that attribute, and the URI goes in @href.

  * If the element name is the relation name, then the relation type
    is given as the attribute name, and the value of that attribute is
    the link.

An interesting issue to consider with links is where entries and feeds
link to other entries and feeds.  It makes the most sense for these
links to be made to the <id> URI, which we've strongly emphasized
should not have a (or be the) primary access mechanism for the
entry/feed.  "parent" and "in-reply-to", for example.  This means that
these links should have two URI properties, one linking the ID and one
linking a last-well-known URI location for the Atom version of the
entry:

  <in-reply-to uri="tag:example.com,2004:001"
               location="http://example.com/001.atom"/>

or, from PaceServiceElement,

  <service name="in-reply-to"
           href="tag:example.com,2004:001"
           location="http://example.com/001.atom"/>



  -- Ken

[1] http://dubinko.info/writing/skunklink/



From owner-atom-syntax@mail.imc.org  Fri Jul 16 21:10:00 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24911
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 21:10:00 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6H0w1i4076935;
	Fri, 16 Jul 2004 17:58:01 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6H0w1Ef076934;
	Fri, 16 Jul 2004 17:58: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 i6H0w0XV076914
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 17:58:00 -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 i6H0wjeD023183;
	Fri, 16 Jul 2004 20:58:45 -0400
Message-ID: <40F87990.1080909@intertwingly.net>
Date: Fri, 16 Jul 2004 20:57:52 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Robert Sayre <mint@franklinmint.fm>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD1DDB85.13D53%mint@franklinmint.fm>
In-Reply-To: <BD1DDB85.13D53%mint@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:
> 
> - Python urllib2
> Doesn't matter. httplib is easy and standard. Batteries included.

httplib is easy, standard, and less functional than urllib2:

http://www.intertwingly.net/blog/2003/09/02/AtomDigest-via-urllib2

Net: with Python out of the box, you get a choice.  Most relevant to 
Atom is that you get to chose a library which supports PUT or you can 
chose a library which supports HTTP Digest.  VERY annoying.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Fri Jul 16 21: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 VAA25153
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 21: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 i6H11Wu8077570;
	Fri, 16 Jul 2004 18:01: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 i6H11Wxa077569;
	Fri, 16 Jul 2004 18:01: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 i6H11V60077562
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 18:01:31 -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 i6H12LS7023401
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 21:02:21 -0400
Message-ID: <40F87A68.2000007@intertwingly.net>
Date: Fri, 16 Jul 2004 21:01:28 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 Syntax <atom-syntax@imc.org>
Subject: Re: A reminder we should think about congestion control at some point
References: <46D88C9C-D787-11D8-92AF-000A95A51C9E@sun.com>
In-Reply-To: <46D88C9C-D787-11D8-92AF-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:
> 
> http://www.infoworld.com/article/04/07/16/29OPconnection_1.html? 
> source=rss&url=http://www.infoworld.com/article/04/07/16/ 
> 29OPconnection_1.html

http://tinyurl.com/6mdvo

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Fri Jul 16 21:18:45 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25381
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 21:18: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 i6H1AkK0079035;
	Fri, 16 Jul 2004 18:10: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 i6H1Ak51079034;
	Fri, 16 Jul 2004 18:10: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 i6H1Ajou079022
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 18:10:46 -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 i6H1Ba3L023800;
	Fri, 16 Jul 2004 21:11:36 -0400
Message-ID: <40F87C92.1050209@intertwingly.net>
Date: Fri, 16 Jul 2004 21:10:42 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 Pilgrim <pilgrim@gmail.com>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: A reminder we should think about congestion control at some point
References: <46D88C9C-D787-11D8-92AF-000A95A51C9E@sun.com> <14be96d3040716174668c86fbf@mail.gmail.com>
In-Reply-To: <14be96d3040716174668c86fbf@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


Mark Pilgrim wrote:

> On Fri, 16 Jul 2004 17:21:41 -0700, Tim Bray <tim.bray@sun.com> wrote:
> 
>>http://www.infoworld.com/article/04/07/16/29OPconnection_1.html?
>>source=rss&url=http://www.infoworld.com/article/04/07/16/
>>29OPconnection_1.html
>>
>>I'm not sure this is *really* a problem, in that we might decide that
>>existing HTTP caching & traffic management techniques will suffice for
>>Atom.  But we should be conscious of it. -Tim
> 
> They could start by using HTTP properly.  There server does not
> support Etags, Last-Modified headers, or gzip compression.  No wonder
> they have bandwidth problems.

Agreed that using HTTP more completely is a requirement before 
attempting to solve any larger problems.  Our job is to make sure that 
someone implementing Atom is aware of everything that they need in order 
to do it right.  A few months ago, I started to take a stab at this:

http://intertwingly.net/stories/2004/04/08/atomguide.html

It is amazing how quickly things get complicated when you add together a 
few "simple" protocols, each with their own options.  The next thing I 
started to tackle was I18N.  From there, I intended to go to URIs...

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Fri Jul 16 21:46:27 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26540
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 21:46: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 i6H1axUs083704;
	Fri, 16 Jul 2004 18:36: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 i6H1ax8A083703;
	Fri, 16 Jul 2004 18:36:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from garland.duramedia.net (garland.duramdedia.net [209.51.131.138] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6H1axDl083683
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 18:36:59 -0700 (PDT)
	(envelope-from jg@jonasgalvez.com)
Received: from 200-206-135-201.dsl.telesp.net.br ([200.206.135.201])
	by garland.duramedia.net with esmtp (Exim 4.34)
	id 1Ble8P-0000Zf-Q8
	for atom-syntax@imc.org; Fri, 16 Jul 2004 21:37:06 -0400
Message-ID: <40F8824E.1080103@jonasgalvez.com>
Date: Fri, 16 Jul 2004 22:35:10 -0300
From: Jonas Galvez <jg@jonasgalvez.com>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: AtomSyntax <atom-syntax@imc.org>
Subject: Re: A reminder we should think about congestion control at some point
References: <46D88C9C-D787-11D8-92AF-000A95A51C9E@sun.com>
In-Reply-To: <46D88C9C-D787-11D8-92AF-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 - garland.duramedia.net
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - jonasgalvez.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


Tim Bray wrote:
> http://www.infoworld.com/article/04/07/16/29OPconnection_1.html? 
> source=rss&url=http://www.infoworld.com/article/04/07/16/ 
> 29OPconnection_1.html
> 
> I'm not sure this is *really* a problem, in that we might decide that
> existing HTTP caching & traffic management techniques will suffice
> for Atom.  But we should be conscious of it. -Tim

I've been studying the HTTP caching mechanism and I'm really amazed by
the performance improvement. I guess gzip compression is something that
too few people are using. I host about a dozen of scrapped feeds for
personal use (but I share them with various friends), and recently I
noticed they were eating about 300mb of my bandwidth. I've since then
started using cgi_buffer (a Python library that encapsulates all HTTP
caching techniques plus gzip compression) to generate those feeds, and
the bandwidth use reduced drastically.

So I think the solution already exists. But not everyone is aware of it.
Perhaps it would be ideal to have a separate document, some sort of
guidelines, with detailed documentation (and preferrably friendly,
easy-to-read documentation) on how to implement these methods.

Since I've been already dedicating a considerable amount of my time to
that subject (it's important to my current work), I'd gladly volunteer
to write a draft about it with the best of my non-native English. But I
have the feeling that that document (a friendly, easy-to-read,
syndication-specific, HTTP caching tutorial) already exists somewhere...



\\ jonas galvez
// jonasgalvez.com



From owner-atom-syntax@mail.imc.org  Fri Jul 16 22: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 WAA27805
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 22:07: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 i6H1xZdQ087348;
	Fri, 16 Jul 2004 18:59: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 i6H1xZf7087347;
	Fri, 16 Jul 2004 18:59:35 -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 i6H1wwHY087274
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 18:59:34 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040717015855.93645.qmail@web41201.mail.yahoo.com>
Received: from [24.18.143.189] by web41201.mail.yahoo.com via HTTP; Fri, 16 Jul 2004 18:58:55 PDT
Date: Fri, 16 Jul 2004 18:58:55 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Bandwidth consumtion and syndication feeds
To: Tim Bray <Tim.Bray@Sun.COM>, Atom-Syntax Syntax <atom-syntax@imc.org>
In-Reply-To: <46D88C9C-D787-11D8-92AF-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:
> 
>
http://www.infoworld.com/article/04/07/16/29OPconnection_1.html?
> 
>
source=rss&url=http://www.infoworld.com/article/04/07/16/
> 
> 29OPconnection_1.html
> 
> I'm not sure this is *really* a problem, in that we
> might decide that  
> existing HTTP caching & traffic management
> techniques will suffice for  
> Atom.  But we should be conscious of it. -Tim

Testing their feed with
http://www.rexswain.com/cgi-bin/httpview.cgi I see
that Infoworld neither supports GZip encoding nor HTTP
conditional GET. No wonder their bandwidth usage is so
high. Using both techniques should reduce their
bandwidth usage by at *least* a factor of 10. 

Almost every time I see someone complain about how RSS
wastes bandwidth, I check their RSS feed and find they
aren't using basic HTTP techniques for saving
bandwidth which are supported by ALL the major RSS
aggregators. Until we find that existing solutions are
inadequate it seems like premature optimization to
start talking about even more sophisticated bandwidth
management techniques specific to syndication feeds. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/



From owner-atom-syntax@mail.imc.org  Fri Jul 16 22: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 WAA28160
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 22: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 i6H286Z2088466;
	Fri, 16 Jul 2004 19:08:06 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6H2860t088465;
	Fri, 16 Jul 2004 19:08:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from homer.w3.org (homer.w3.org [18.29.0.30])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6H286uL088458
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 19:08:06 -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 B24214F103;
	Fri, 16 Jul 2004 22:08:10 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040716182722.05704e98@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Fri, 16 Jul 2004 18:29:44 +0900
To: Tim Bray <Tim.Bray@Sun.COM>, Greg Stein <gstein@google.com>
From: Martin Duerst <duerst@w3.org>
Subject: Re: Apache mime.types (was: Thought experiment)
Cc: atom-syntax@imc.org
In-Reply-To: <5A2A046A-D69A-11D8-A6EC-000A95A51C9E@sun.com>
References: <20040715195128.GA5149@google.com>
 <5E91DE20-D61C-11D8-A6EC-000A95A51C9E@sun.com>
 <20040715105633.GB17690@google.com>
 <20040715195128.GA5149@google.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 13:05 04/07/15 -0700, Tim Bray wrote:

>On Jul 15, 2004, at 12:51 PM, Greg Stein wrote:
>
>>The W3C types were done ad-hoc since the W3C folks were not good about
>>registering their types with the IANA. They also don't have any kind
>>of single registry, so Roy just did a bunch of searches. Apparently,
>>the W3C has revamped their registration process to lose their internal
>>roadblocks, but that doesn't really matter here.
>
>Heh, and in the halls at the W3C you hear griping at how incredibly slow, 
>painful, and non-deterministic it is to register a type.  Last time Roy 
>was in the room he got mad and said "no, you're just not trying."

I have to agree with Roy here.


>I have no idea who's right but you're correct that registration of 
>W3C-generated data types has been *very* sluggish.

I keep a page at http://www.w3.org/2002/06/registering-mediatype.html,
with detailled instructions, and a list of types and their status in
the registration process as far as I know it.

Regards,    Martin.


>>I've gone ahead and done this: the application/atom+xml (for .atom)
>>type will appear in our next releases (Apache 1.3.32 and Apache
>>2.0.51), whenever those come out.
>
>Thanks on behalf of the community -Tim



From owner-atom-syntax@mail.imc.org  Fri Jul 16 22:16:17 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28178
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 22:16:16 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6H281Lj088439;
	Fri, 16 Jul 2004 19:08: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 i6H281ka088438;
	Fri, 16 Jul 2004 19:08:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from homer.w3.org (homer.w3.org [18.29.0.30])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6H2802I088432
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 19:08:01 -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 28D3E4F0FB;
	Fri, 16 Jul 2004 22:08:04 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040716175746.056c9948@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Fri, 16 Jul 2004 18:01:39 +0900
To: Julian Reschke <julian.reschke@gmx.de>, Sam Ruby <rubys@intertwingly.net>
From: Martin Duerst <duerst@w3.org>
Subject: Re: PaceMustBeWellFormed
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <40F66E0B.2000206@gmx.de>
References: <40F66628.4010004@intertwingly.net>
 <14be96d30407061142441f70ee@mail.gmail.com>
 <40F56B2A.8050500@intertwingly.net>
 <14be96d304071411092c2c44f4@mail.gmail.com>
 <p06110426bd1b3deea52a@10.20.30.249>
 <14be96d30407141427187f294d@mail.gmail.com>
 <p0611042bbd1b66fa15ef@[10.20.30.249]>
 <40F5C1F4.5080709@intertwingly.net>
 <40F62105.6080600@gmx.de>
 <40F66628.4010004@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: <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 13:44 04/07/15 +0200, Julian Reschke wrote:

>Sam Ruby wrote:
> > ...
>>My recommendation is that the presence of conflicting charset/encoding 
>>information in documents served as application/xml be treated as a 
>>well-formedness error.
>>...
>
>Thanks for the clarification, Sam. I absolutely agree here; a conflict 
>indicates that something (transcoding?) has gone wrong; and it makes a lot 
>of sense to throw the result away...

Julian - Why do you say transcoding has gone wrong? Because transcoding
from iso-8859-1 to iso-8859-7 isn't a very probable scenario anyway?
Maybe we should use a more probable example, e.g. koi8-R and iso-8859-5?

Regards,    Martin.



From owner-atom-syntax@mail.imc.org  Fri Jul 16 22: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 WAA28196
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 22: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 i6H284b2088448;
	Fri, 16 Jul 2004 19: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 i6H284FM088447;
	Fri, 16 Jul 2004 19:08:04 -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 i6H283pY088441
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 19:08:03 -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 E20D64F0FD;
	Fri, 16 Jul 2004 22:08:07 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040716180234.056ca378@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Fri, 16 Jul 2004 18:25:04 +0900
To: Sam Ruby <rubys@intertwingly.net>, Julian Reschke <julian.reschke@gmx.de>
From: Martin Duerst <duerst@w3.org>
Subject: Re: PaceMustBeWellFormed
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <40F66628.4010004@intertwingly.net>
References: <40F62105.6080600@gmx.de>
 <14be96d30407061142441f70ee@mail.gmail.com>
 <40F56B2A.8050500@intertwingly.net>
 <14be96d304071411092c2c44f4@mail.gmail.com>
 <p06110426bd1b3deea52a@10.20.30.249>
 <14be96d30407141427187f294d@mail.gmail.com>
 <p0611042bbd1b66fa15ef@[10.20.30.249]>
 <40F5C1F4.5080709@intertwingly.net>
 <40F62105.6080600@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: <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 07:10 04/07/15 -0400, Sam Ruby wrote:

>Until now, the discussion appears to have been framed in terms of 
>precedence rules: which charset/encoding "wins"?  The tradition is to say 
>that the above document is well-formed (and possibly even valid) and that 
>no error or even warning is proscribed.
>
>First tangent: the tradition is also to defer to HTTP as being the most 
>authoritative meta-data in this situation.  The reason appears to be based 
>on the promise given to folks that enabled them to write transcoders 
>dealing with content-types of "text/*".  As people appear to have deployed 
>solutions based on this promise, it is a promise that is rather difficult 
>to retract.  I fully understand and appreciate that.
>
>Back to application/xml.  As near as I can tell, no such promise has been 
>made for application/xml.  In fact, RFC 3023 [1] is rather clear: when the 
>charset parameter is not present, "An XML-unaware MIME processor SHOULD 
>make no assumptions about the charset of the XML MIME entity.";

I don't see the difference to text/* here. How are you going to transcode
a text/* document if you don't have any 'charset' information? You simply
can't. RFC 3023 just spells that out.


>Back to the example above.  While the current specs may say it is 
>well-formed, and even proscribe how it should be interpreted, I see a 
>document that is seriously confused.

Most probably. The two encodings you have choosen aren't very probable
ones for transcoding. But such a judgement should not be made by an
XML parser.


>And I see the relevant draconian provisions of the XML specification 
>tossing other documents which have committed significantly lesser 
>infractions involving so-called smart quotes out on their ear.
>
>So, given that documents such as the above do not tend to appear in 
>practice (can you give an example?), and have no reason to appear in 
>practice (any transcoders that understand application/xml had better 
>understand xml prologs),

Transcoders usually don't look inside documents.


>and that the likelihood that the current precedence rules will produce the 
>intended result is low (given the way that modern web servers are 
>configured, if the above data were served statically, I would tend to 
>trust the document prolog more than the HTTP headers in this particular 
>circumstance)...

Well, as a human user, you can always look at the results, and
see whether the text makes sense or not.


>given all this, what is my recommendation?
>
>My recommendation is that the presence of conflicting charset/encoding 
>information in documents served as application/xml be treated as a 
>well-formedness error.

Do you want to redefine application/xml in the Atom spec? Or were
you speaking about application/atom+xml? In the later case, would
you want application/xml and application/atom+xml to behave differently?
And how would you implement the above proposal in a off-the-shelf
parser?


>Second tangent: such a recommendation does not affect documents served 
>simply as "Content-type: application/xml", i.e., without a charset 
>explicitly specified on the HTTP header.  RFC 3023[1] sections 8.9 through 
>8.12 defer to the rules defined in the XML specification for determining 
>the encoding in such circumstances, so inconsistency is not possible in 
>this situation.
>
>What does the above recommendation mean to users of formats such as 
>application/atom+xml?  Simply that applications such as the feedvalidator 
>should flag such situations (it currently does, albeit with a warning),

Giving a warning in such cases is a good idea. The W3C Markup Validator
does so, too.


>and that libraries such as the feedparser should set bozo bits or 
>equivalent in such situations (it doesn't currently as the above is 
>currently completely legal), and that applications built on such libraries 
>should not attempt to resolve such inconsistencies without the consent of 
>the user[2].

What about the situation (very probable with scripts) where there
is charset information in the header (and that's not UTF-8 or
UTF-16), but no 'encoding' pseudo-attribute in the xml declaration?
According to your definitions above, this would also be an error.


Regards,    Martin.



From owner-atom-syntax@mail.imc.org  Fri Jul 16 22:36: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 WAA29075
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 22:36: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 i6H2STob091109;
	Fri, 16 Jul 2004 19:28: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 i6H2STkw091108;
	Fri, 16 Jul 2004 19:28:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6H2SPR4091042
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 19:28:26 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 17 Jul 2004 12:33:10 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sat, 17 Jul 2004 11:30:16 +1000
Subject: Re: PaceLinkConstruct central?
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD1EBE48.203CC%eric.scheid@ironclad.net.au>
In-Reply-To: <37675036-D745-11D8-92AF-000A95A51C9E@sun.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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 17/7/04 2:28 AM, "Tim Bray" <Tim.Bray@Sun.COM> wrote:

> So, here's a strawman, part 1: First of all, we address the basic
> question of whether
> (a) we try to use <link rel="this" href="">, <link rel="that" href="">,
> etc for all our link-flavoured constructs, or
> (b) we break 'em out and make a bunch of <this href="">, <that href="">
> (Graham's NukeTheLinkTag)

strawman indeed ;-)

you left out:
(c) break some links out to their own elements (<this href="">) but leave
the generalised case of <<there is a resource you may be interested in
retrieving, it's relationship to me is 'blah'>> as <link rel="blah">

e.



From owner-atom-syntax@mail.imc.org  Fri Jul 16 22: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 WAA29202
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 22:39: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 i6H2Vhwu091503;
	Fri, 16 Jul 2004 19:31: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 i6H2Vh56091502;
	Fri, 16 Jul 2004 19:31:43 -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 i6H2VgUZ091482
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 19:31:42 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040717023144.94723.qmail@web41212.mail.yahoo.com>
Received: from [24.18.143.189] by web41212.mail.yahoo.com via HTTP; Fri, 16 Jul 2004 19:31:44 PDT
Date: Fri, 16 Jul 2004 19:31:44 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: PaceReplaceLinkElement: Is link-ness relevant?
To: Graham <dtcd@mac.com>, Antone Roundy <antone@geckotribe.com>
Cc: atom-syntax@imc.org
In-Reply-To: <56F15E2E-D789-11D8-9095-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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


--- Graham <dtcd@mac.com> wrote:
> 
> As an aggregator developer, I'd like to declare I
> have no plans (or 
> desires) to do anything at all with unrecognised
> Link constructs, and 
> thus no desire to be able to pick them out easily.

+1 

Same here. Currently the link construct is a hack. If
the link element has a fixed list of rel values then
it is just a hack around having elements with distinct
names and make Atom appear simpler than it is to
newbies 'viewing source' on a feed. This hack leads to
a style of naming elements that is un-idiomatic for
XML vocabularies. 

If link has an open list of @rel values, it is pretty
useless for aggregators to do anything with it. Just
in the various Atom Paces and spec drafts there are
links that mean (i) this is a link to a human readable
document (ii) this is a link to code for processing
the content of a sibling element of this link element
(iii) this is a link to an image file which is the
logo for the producer of this feed (iv)here is an
image file that is an icon that can be used to
represent this feed in applications that display feeds
in a tree view (v) here is a URI that one can POST
Atom entries as a response to the content of one the
siblings of this link element (vi) here is a link to a
syndication feed containing comments in response to
the content of one of the siblings of the link element



Each one of the above scenarios will require a unique
code path if implemented in RSS Bandit. Besides the
initial code that grabs all elements named <link>
there will be no similarity to the how these elements
will be processed or how they will be presented to the
end user. 

Thus there is no generic code for processing links.
Link tag extensibility in Atom is an oxymoron. 



=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/



From owner-atom-syntax@mail.imc.org  Fri Jul 16 22:43: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 WAA29423
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 22:43: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 i6H2agg3092140;
	Fri, 16 Jul 2004 19:36:42 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6H2agQf092139;
	Fri, 16 Jul 2004 19:36: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 i6H2afF4092131
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 19:36: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 i6H2bW6a028265;
	Fri, 16 Jul 2004 22:37:32 -0400
Message-ID: <40F890B6.5090901@intertwingly.net>
Date: Fri, 16 Jul 2004 22:36:38 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Martin Duerst <duerst@w3.org>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceMustBeWellFormed
References: <40F62105.6080600@gmx.de> <14be96d30407061142441f70ee@mail.gmail.com> <40F56B2A.8050500@intertwingly.net> <14be96d304071411092c2c44f4@mail.gmail.com> <p06110426bd1b3deea52a@10.20.30.249> <14be96d30407141427187f294d@mail.gmail.com> <p0611042bbd1b66fa15ef@[10.20.30.249]> <40F5C1F4.5080709@intertwingly.net> <40F62105.6080600@gmx.de> <4.2.0.58.J.20040716180234.056ca378@localhost>
In-Reply-To: <4.2.0.58.J.20040716180234.056ca378@localhost>
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


Martin Duerst wrote:
> 
  > I don't see the difference to text/* here. How are you going to 
transcode
> a text/* document if you don't have any 'charset' information? You simply
> can't. RFC 3023 just spells that out.

With text/*, the default is US-ASCII.  With application/*, there is no 
default.

> What about the situation (very probable with scripts) where there
> is charset information in the header (and that's not UTF-8 or
> UTF-16), but no 'encoding' pseudo-attribute in the xml declaration?
> According to your definitions above, this would also be an error.

iso-8859-1 text in xml documents without a BOM and without an XML prolog 
(and for that matter without a charset in the header) is probably the 
single most common encoding error I see in feeds today.

Such an error are flagged by all conforming XML parsers.

The example I picked (iso-8859-7 vs -1), while not typical, can not be 
detected by an XML parser.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Fri Jul 16 22:57: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 WAA29943
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 22:57:26 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6H2kD8f093662;
	Fri, 16 Jul 2004 19: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 i6H2kDe7093661;
	Fri, 16 Jul 2004 19:46:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from scandium.sabren.com (scandium.sabren.com [209.61.155.99])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6H2kCLm093646
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 19:46:13 -0700 (PDT)
	(envelope-from joe@bitworking.org)
Received: from bitworking.org (adsl-221-6-61.rmo.bellsouth.net [68.221.6.61])
	(authenticated bits=0)
	by scandium.sabren.com (8.12.11/8.12.10) with ESMTP id i6H2n4UU004058;
	Fri, 16 Jul 2004 22:49:04 -0400
Message-ID: <40F892F1.5040105@bitworking.org>
Date: Fri, 16 Jul 2004 22:46:09 -0400
From: Joe Gregorio <joe@bitworking.org>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Robert Sayre <mint@franklinmint.fm>
CC: Tim Bray <Tim.Bray@Sun.COM>, Atom Syntax <atom-syntax@imc.org>
Subject: Re: Q: Put request should return Atom entry?
References: <BD1DD57F.13D52%mint@franklinmint.fm>
In-Reply-To: <BD1DD57F.13D52%mint@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:
> On 7/16/04 5:15 PM, "Tim Bray" <Tim.Bray@Sun.COM> wrote:
> 
> 
>>>>>- servers MUST indicate successful PUT requests with a 2xx response
>>>>>- servers MAY include additional information in the PUT response
>>>>>- clients SHOULD NOT expect any additional information in a PUT
>>>>>response
>>
>>I see lots of +1's... quick Joe/Rob, grab it and put it in the spec.
>>Thanks to whoever originally  asked this useful question. -Tim
>>
> 
> 
> And so it was done. One question, though. Is the third sentence redundant?
> Clients shouldn't expect anything in the response body because servers don't
> have to send it. Couldn't hurt, I guess.

Actually, from RFC2119:

    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)  For
    example, they must not be used to try to impose a particular method
    on implementors where the method is not required for
    interoperability.

Given that I'd say the third sentence was
redundant and should be dropped.

	-joe



From owner-atom-syntax@mail.imc.org  Fri Jul 16 22:57:30 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29960
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 22:57:30 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6H2n10L094588;
	Fri, 16 Jul 2004 19:49:01 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6H2n16M094587;
	Fri, 16 Jul 2004 19:49: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 i6H2n0BV094562
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 19:49:00 -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 i6H2nptD029023;
	Fri, 16 Jul 2004 22:49:51 -0400
Message-ID: <40F8939A.60009@intertwingly.net>
Date: Fri, 16 Jul 2004 22:48:58 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Dare Obasanjo <kpako@yahoo.com>
CC: atom-syntax@imc.org
Subject: Re: PaceReplaceLinkElement: Is link-ness relevant?
References: <20040717023144.94723.qmail@web41212.mail.yahoo.com>
In-Reply-To: <20040717023144.94723.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:

> --- Graham <dtcd@mac.com> wrote:
> 
>>As an aggregator developer, I'd like to declare I
>>have no plans (or 
>>desires) to do anything at all with unrecognised
>>Link constructs, and 
>>thus no desire to be able to pick them out easily.
> 
> 
> +1 
> 
> Same here. Currently the link construct is a hack. If
> the link element has a fixed list of rel values then
> it is just a hack around having elements with distinct
> names and make Atom appear simpler than it is to
> newbies 'viewing source' on a feed. This hack leads to
> a style of naming elements that is un-idiomatic for
> XML vocabularies. 
> 
> If link has an open list of @rel values, it is pretty
> useless for aggregators to do anything with it. Just
> in the various Atom Paces and spec drafts there are
> links that mean (i) this is a link to a human readable
> document (ii) this is a link to code for processing
> the content of a sibling element of this link element
> (iii) this is a link to an image file which is the
> logo for the producer of this feed (iv)here is an
> image file that is an icon that can be used to
> represent this feed in applications that display feeds
> in a tree view (v) here is a URI that one can POST
> Atom entries as a response to the content of one the
> siblings of this link element (vi) here is a link to a
> syndication feed containing comments in response to
> the content of one of the siblings of the link element
> 
> Each one of the above scenarios will require a unique
> code path if implemented in RSS Bandit. Besides the
> initial code that grabs all elements named <link>
> there will be no similarity to the how these elements
> will be processed or how they will be presented to the
> end user. 
> 
> Thus there is no generic code for processing links.
> Link tag extensibility in Atom is an oxymoron. 

A real life example:

   http://intertwingly.net/slides/2003/xmlconf/45.html

For the benefit of others: this slide was added to my presentation based 
on a question from Dare the day before I did my presentation.

Much of the current discussion is focusing on "rel" as if it is the most 
important attribute, but at times simply having a recognized media type, 
a title, and an href is all you need to present a relevant choice to a user.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Fri Jul 16 23:05: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 XAA00292
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 23:05: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 i6H2wamc096150;
	Fri, 16 Jul 2004 19:58: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 i6H2wan5096149;
	Fri, 16 Jul 2004 19:58:36 -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 i6H2wZg8096136
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 19:58:36 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040717025837.19874.qmail@web41213.mail.yahoo.com>
Received: from [24.18.143.189] by web41213.mail.yahoo.com via HTTP; Fri, 16 Jul 2004 19:58:37 PDT
Date: Fri, 16 Jul 2004 19:58:37 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: PaceReplaceLinkElement: Is link-ness relevant?
To: Sam Ruby <rubys@intertwingly.net>
Cc: atom-syntax@imc.org
In-Reply-To: <40F8939A.60009@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:
>  
> > Thus there is no generic code for processing
> links.
> > Link tag extensibility in Atom is an oxymoron. 
> 
> A real life example:
> 
>   
> http://intertwingly.net/slides/2003/xmlconf/45.html
> 
> For the benefit of others: this slide was added to
> my presentation based 
> on a question from Dare the day before I did my
> presentation.
> 
> Much of the current discussion is focusing on "rel"
> as if it is the most 
> important attribute, but at times simply having a
> recognized media type, 
> a title, and an href is all you need to present a
> relevant choice to a user.

It isn't. Your argument is that you can show all the
links as hyperlinks to a user. My point is that even
looking at the list of link elements in Atom today,
less than half of them would be useful if they were
just shown to the user as hyperlinks. You can always
come up with one example that proves your point. I can
always come up with a counter example (e.g.
service.post).  

How about countering my statement and those of Graham
that there is simply no consistent way to process the
various link elements that exist in Atom today let
alone processing arbitrary link elements that could be
produced by any third party. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/



From owner-atom-syntax@mail.imc.org  Fri Jul 16 23:11:50 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00690
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 23:11: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 i6H34EFh096924;
	Fri, 16 Jul 2004 20:04: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 i6H34Erf096923;
	Fri, 16 Jul 2004 20:04:14 -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 i6H34DiE096899
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 20:04:13 -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 i6H34E53023857
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 22:04:14 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6H34E1T023853;
	Fri, 16 Jul 2004 22:04:14 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: atom-syntax@imc.org
Subject: Re: PaceReplaceLinkElement: Is link-ness relevant?
References: <D80692E3-D77F-11D8-8968-003065EA6144@geckotribe.com>
	<56F15E2E-D789-11D8-9095-000A95DC3D90@mac.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 16 Jul 2004 22:04:13 -0500
In-Reply-To: <56F15E2E-D789-11D8-9095-000A95DC3D90@mac.com>
Message-ID: <m3n01zgwr6.fsf@bitsko.slc.ut.us>
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


Graham <dtcd@mac.com> writes:

> As an aggregator developer, I'd like to declare I have no plans (or
> desires) to do anything at all with unrecognised Link constructs,
> and thus no desire to be able to pick them out easily.

One suggestion for links is classifying links that are "intended
primarily for presentation to a human user", distinct from other types
of links and irrespective of the link relation name (@rel or element
name).

Does that make a difference?

  -- Ken



From owner-atom-syntax@mail.imc.org  Fri Jul 16 23:17: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 XAA00928
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 23:17: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 i6H3AYQC097753;
	Fri, 16 Jul 2004 20:10: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 i6H3AYgp097752;
	Fri, 16 Jul 2004 20:10:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6H3ASaW097729
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 20:10:30 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 17 Jul 2004 13:15:54 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sat, 17 Jul 2004 13:10:30 +1000
Subject: Re: PaceReplaceLinkElement: Is link-ness relevant?
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD1ED5C6.20418%eric.scheid@ironclad.net.au>
In-Reply-To: <D80692E3-D77F-11D8-8968-003065EA6144@geckotribe.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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 17/7/04 9:28 AM, "Antone Roundy" <antone@geckotribe.com> wrote:

> A non-Atom example: If you put the following into the head of an HTML
> document and load it in Mozilla with the Site Navigation Bar active
> (look under View >> Show/Hide >> Site Navigation Bar), a "More" menu
> will show up with the link in it.
> 
> <link rel="MyLinkType" title="This links to something"
> href="http://www.example.org/">

to come full circle, an atom-related example ... if you put this into HTML
you get something quite handy. you don't need to lobby w3c to include a new
tag in the next version of html, you don't need to use name spaces, you just
use the existing functionality ...

    <link @rel="alternate" type="application/atom+xml" href="...">

e.



From owner-atom-syntax@mail.imc.org  Fri Jul 16 23:18: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 XAA01064
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 23:18: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 i6H3AQ0b097724;
	Fri, 16 Jul 2004 20:10: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 i6H3AQdk097722;
	Fri, 16 Jul 2004 20:10:26 -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 i6H3AMi5097710
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 20:10:25 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 17 Jul 2004 13:15:43 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sat, 17 Jul 2004 13:10:20 +1000
Subject: Re: PaceReplaceLinkElement created
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD1ED5BC.20418%eric.scheid@ironclad.net.au>
In-Reply-To: <p06110450bd1dcbf80e59@[10.20.30.249]>
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 17/7/04 4:17 AM, "Paul Hoffman / IMC" <phoffman@imc.org> wrote:

> At 1:37 PM -0400 7/16/04, Sam Ruby wrote:
>> Meanwhile, an extensibility question.  If somebody wants to define a
>> new element, in a new namespace, are we supposed to wantonly assume
>> that any attribute spelled "href" is an indication that an atom
>> LinkConstruct is what is intended?
> 
> We can make that wanton assumption if we say in the spec something to
> the effect of "The use of attributes called 'href' mean that they are
> links to the outside world, and anyone extending Atom should only use
> 'href' in a way similar to the items in the core spec."

-1 to this meme.

Some other xml vocab could say something different (eg. href is used for
transclusion), and thus someone writing a context-agnostic extension (eg.
<geo>) would be screwed. (examples are not normative!)

I wouldn't be surprised if there isn't some extension module already written
which would now be incompatible with atom. That would be our loss, imho.

e.



From owner-atom-syntax@mail.imc.org  Fri Jul 16 23:19: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 XAA01108
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 23:19: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 i6H3CQ5a098303;
	Fri, 16 Jul 2004 20: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 i6H3CQfT098302;
	Fri, 16 Jul 2004 20:12: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 i6H3CPBH098296
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 20:12: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 i6H3DGFk030197;
	Fri, 16 Jul 2004 23:13:17 -0400
Message-ID: <40F89917.3030605@intertwingly.net>
Date: Fri, 16 Jul 2004 23:12:23 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Dare Obasanjo <kpako@yahoo.com>
CC: atom-syntax@imc.org
Subject: Re: PaceReplaceLinkElement: Is link-ness relevant?
References: <20040717025837.19874.qmail@web41213.mail.yahoo.com>
In-Reply-To: <20040717025837.19874.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: <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:
> 
>> 
>>
>>>Thus there is no generic code for processing
>>
>>links.
>>
>>>Link tag extensibility in Atom is an oxymoron. 
>>
>>A real life example:
>>
>>  
>>http://intertwingly.net/slides/2003/xmlconf/45.html
>>
>>For the benefit of others: this slide was added to
>>my presentation based 
>>on a question from Dare the day before I did my
>>presentation.
>>
>>Much of the current discussion is focusing on "rel"
>>as if it is the most 
>>important attribute, but at times simply having a
>>recognized media type, 
>>a title, and an href is all you need to present a
>>relevant choice to a user.
> 
> It isn't. Your argument is that you can show all the
> links as hyperlinks to a user. My point is that even
> looking at the list of link elements in Atom today,
> less than half of them would be useful if they were
> just shown to the user as hyperlinks. You can always
> come up with one example that proves your point. I can
> always come up with a counter example (e.g.
> service.post).  

That was not my argument.  My argument was that an aggregator could 
chose to filter links based on media type instead of rel.

> How about countering my statement and those of Graham
> that there is simply no consistent way to process the
> various link elements that exist in Atom today let
> alone processing arbitrary link elements that could be
> produced by any third party. 

On one hand, there is a pace to separate out service elements.

On the other hand, the service elements are designed to exactly match 
the syntax used to place this exact same information inside your HTML 
pages for service discovery.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Fri Jul 16 23: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 XAA02032
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 23:33: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 i6H3RAfH001387;
	Fri, 16 Jul 2004 20:27: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 i6H3RA1O001386;
	Fri, 16 Jul 2004 20:27:10 -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 i6H3R3OS001367;
	Fri, 16 Jul 2004 20:27:04 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p06110415bd1e4c1ed10a@[10.20.30.249]>
In-Reply-To: <40F892F1.5040105@bitworking.org>
References: <BD1DD57F.13D52%mint@franklinmint.fm>
 <40F892F1.5040105@bitworking.org>
Date: Fri, 16 Jul 2004 20:27:40 -0700
To: Joe Gregorio <joe@bitworking.org>, Robert Sayre <mint@franklinmint.fm>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: Q: Put request should return Atom entry?
Cc: Tim Bray <Tim.Bray@Sun.COM>, Atom Syntax <atom-syntax@imc.org>
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 10:46 PM -0400 7/16/04, Joe Gregorio wrote:
>Robert Sayre wrote:
>>On 7/16/04 5:15 PM, "Tim Bray" <Tim.Bray@Sun.COM> wrote:
>>
>>>>>>- servers MUST indicate successful PUT requests with a 2xx response
>>>>>>- servers MAY include additional information in the PUT response
>>>>>>- clients SHOULD NOT expect any additional information in a PUT
>>>>>>response
>>>
>>>I see lots of +1's... quick Joe/Rob, grab it and put it in the spec.
>>>Thanks to whoever originally  asked this useful question. -Tim
>>>
>>
>>
>>And so it was done. One question, though. Is the third sentence redundant?
>>Clients shouldn't expect anything in the response body because servers don't
>>have to send it. Couldn't hurt, I guess.
>
>Actually, from RFC2119:
>
>    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)  For
>    example, they must not be used to try to impose a particular method
>    on implementors where the method is not required for
>    interoperability.
>
>Given that I'd say the third sentence was
>redundant and should be dropped.

Not quite. Because "servers MAY include", clients "MUST NOT expect". 
This is a direct interoperability interpretation. If I'm creating a 
client that expects additional info, it will not interoperate with 
some conformant servers.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Fri Jul 16 23:39: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 XAA02288
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 23:39: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 i6H3W0Tx001976;
	Fri, 16 Jul 2004 20:32: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 i6H3W03V001975;
	Fri, 16 Jul 2004 20:32:00 -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 i6H3W0SB001946
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 20:32:00 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040717033201.3707.qmail@web41212.mail.yahoo.com>
Received: from [24.18.143.189] by web41212.mail.yahoo.com via HTTP; Fri, 16 Jul 2004 20:32:01 PDT
Date: Fri, 16 Jul 2004 20:32:01 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: PaceReplaceLinkElement: Is link-ness relevant?
To: Sam Ruby <rubys@intertwingly.net>
Cc: atom-syntax@imc.org
In-Reply-To: <40F89917.3030605@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:
>  
> That was not my argument.  My argument was that an
> aggregator could 
> chose to filter links based on media type instead of
> rel.

http://intertwingly.net/wiki/pie/LinkTagMeaning

That is a list of Atom link tags and media types. I
notice that even when you group link tags by media
types, you still can't treat them consistently. 

If the link tag is going to be an extensibility point
then formally defined link types should be created so
links that share similar semantics can be processed
consistently by aggregators. 

Right now all I've seen suggested are a bunch of hacks
that are infeasible for aggregator authors to program
against with any  kind of consistency. 


> On one hand, there is a pace to separate out service
> elements.
> 
> On the other hand, the service elements are designed
> to exactly match 
> the syntax used to place this exact same information
> inside your HTML 
> pages for service discovery.

Ah, yes. The false goal rears its ugly head. Why is it
important that elements in an Atom feed mimic the look
of HTML elements? Is there an expectation that
fragments of Atom feeds will appear in HTML pages? 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
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 Jul 16 23:40: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 XAA02339
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 23:39: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 i6H3WNju002042;
	Fri, 16 Jul 2004 20:32: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 i6H3WNVF002041;
	Fri, 16 Jul 2004 20:32: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 (mproxy.gmail.com [216.239.56.246])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6H3WNJZ002021
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 20:32:23 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so3137263cwc
        for <atom-syntax@imc.org>; Fri, 16 Jul 2004 20:32:25 -0700 (PDT)
Received: by 10.11.116.22 with SMTP id o22mr113253cwc;
        Fri, 16 Jul 2004 20:32:25 -0700 (PDT)
Message-ID: <3f1451f50407162032374318ea@mail.gmail.com>
Date: Fri, 16 Jul 2004 23:32:25 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Sam Ruby <rubys@intertwingly.net>
Subject: Re: PaceReplaceLinkElement created
Cc: Graham <dtcd@mac.com>, Atom-Syntax Syntax <atom-syntax@imc.org>
In-Reply-To: <40F8125C.5020206@intertwingly.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <7ABCBE9A-D74A-11D8-9D94-000A95DC3D90@mac.com> <40F8125C.5020206@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 Fri, 16 Jul 2004 13:37:32 -0400, Sam Ruby <rubys@intertwingly.net> wrote:
> 
> Graham wrote:
> > (it might be helpful to add this to today's issues list)
> >
> > http://www.intertwingly.net/wiki/pie/PaceReplaceLinkElement
> 
> Added.
> 
> >  Replace 4.4 "atom:link" Element with sections detailing rel values
> > defined in atom-protocol-00 3.4.1. For example:
> 
> >  Replace 4.13.2 "atom:link" Element with a similar list, eg:
> 
> My experience is that the devil's in the details, and by not spelling
> out the details, it makes it hard to spot potential problem areas.
> 
> Meanwhile, an extensibility question.  If somebody wants to define a new
> element, in a new namespace, are we supposed to wantonly assume that any
> attribute spelled "href" is an indication that an atom LinkConstruct is
> what is intended?

For this reason I would prefer this attribute be atom:href.

    -joe



From owner-atom-syntax@mail.imc.org  Fri Jul 16 23:45: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 XAA02646
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 23:45: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 i6H3c25i002812;
	Fri, 16 Jul 2004 20:38: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 i6H3c2HE002811;
	Fri, 16 Jul 2004 20:38: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.89])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6H3c2qK002804
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 20:38:02 -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 i6H3c92G016867;
	Fri, 16 Jul 2004 20:38:09 -0700 (PDT)
Received: from [192.168.1.107] (66-65-118-184.nyc.rr.com [66.65.118.184])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id i6H3bvaA000787;
	Fri, 16 Jul 2004 20:37:57 -0700 (PDT)
In-Reply-To: <40F8939A.60009@intertwingly.net>
References: <20040717023144.94723.qmail@web41212.mail.yahoo.com> <40F8939A.60009@intertwingly.net>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-59125022; protocol="application/pkcs7-signature"
Message-Id: <B01AEC25-D7A2-11D8-9095-000A95DC3D90@mac.com>
Cc: Atom-Syntax Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: PaceReplaceLinkElement: Is link-ness relevant?
Date: Fri, 16 Jul 2004 23:37:54 -0400
To: Sam Ruby <rubys@intertwingly.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-2-59125022
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit


On 16 Jul 2004, at 10:48 pm, Sam Ruby wrote:

>   http://intertwingly.net/slides/2003/xmlconf/45.html
>
> For the benefit of others: this slide was added to my presentation 
> based on a question from Dare the day before I did my presentation.
>
> Much of the current discussion is focusing on "rel" as if it is the 
> most important attribute, but at times simply having a recognized 
> media type, a title, and an href is all you need to present a relevant 
> choice to a user.

But what *is* the relationship here? alternate? related? via? What? I 
cannot present this usefully without knowing what it's for.

On 16 Jul 2004, at 11:04 pm, Ken MacLeod wrote:

> One suggestion for links is classifying links that are "intended
> primarily for presentation to a human user", distinct from other types
> of links and irrespective of the link relation name (@rel or element
> name).

It doesn't do anything for me, sorry. Like I said, even if I know a 
link is "clickable", I still want to make sure I'm doing the right 
thing with it. I'd still only bother with known Link constructs. The 
syndication world is small enough that any extension that comes up I 
can figure out what the best thing to do with it is myself, rather than 
have copies of Shrook in the wild presenting nonsense.

Graham
--Apple-Mail-2-59125022
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
9w0BCQUxDxcNMDQwNzE3MDMzNzU0WjAjBgkqhkiG9w0BCQQxFgQUo2jWLEXJy7El0a17AFXtntVi
towweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAzSZAxL1iHCtJNg0QsSyK3mq5
TXnfqN+E22+CXWulh4eSbdIjF1mx9hAq8fubnFKquO2FBmmi+JNu5BDSBjSliKnfGuXG61DOnbfX
SLxSWwWesXCrDEURwX5Se3p0UqPdQEjaw1KhO3JR4FHeUOPqEB4jKDxeJP+hXxKWzOga6Kew3qr/
bjTuuCep8zyhx3KfI/dgBkLDT7k8LprZGezcr8YovM07s+YshUH/3H08FfQWqtXBx7xVyoyZEBCD
ZQnUVsqiJdmTlPgie0zGF4pjZ6mHLjNfvibMSGiA9+Tpkip+AiSd7VfxIEIdNIYUwe2QHSst5+dM
2VyATS7bN236bgAAAAAAAA==

--Apple-Mail-2-59125022--



From owner-atom-syntax@mail.imc.org  Fri Jul 16 23: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 XAA02799
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 23: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 i6H3hSNh003568;
	Fri, 16 Jul 2004 20:43: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 i6H3hSxQ003567;
	Fri, 16 Jul 2004 20:43:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6H3hR1r003561
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 20:43:27 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6H3hYil021265
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 21:43:34 -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 <0I0Z00BAH90LT1@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Fri, 16 Jul 2004 21:43:34 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.45])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0Z00KTO90L3N@mail.sun.net> for atom-syntax@imc.org; Fri,
 16 Jul 2004 21:43:33 -0600 (MDT)
Date: Fri, 16 Jul 2004 20:43:38 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
In-reply-to: <BD1DDB85.13D53%mint@franklinmint.fm>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <7CEEF686-D7A3-11D8-92AF-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: <BD1DDB85.13D53%mint@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 Jul 16, 2004, at 4:22 PM, Robert Sayre wrote:

> It would appear that the most convenient approach for J2ME applications
> would be a request header in combination with POST.

Here's another simple way:

1. Create an entry:
POST the <atom:entry> to the feed EditURI

2. Update an entry:
POST the <atom:entry> to the feed EditURI
with one extra attribute update="URI of entry"

3. Delete an entry
POST to the feed editURI
<atom:delete entry="URI of entry" />

  -Tim



From owner-atom-syntax@mail.imc.org  Fri Jul 16 23:58:32 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03053
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 23:58:31 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6H3oRSt004492;
	Fri, 16 Jul 2004 20:50: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 i6H3oRUK004491;
	Fri, 16 Jul 2004 20:50: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 i6H3oQXv004469
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 20:50: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 i6H3oR53024408
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 22:50:27 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6H3oR90024404;
	Fri, 16 Jul 2004 22:50:27 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD1DDB85.13D53%mint@franklinmint.fm>
	<7CEEF686-D7A3-11D8-92AF-000A95A51C9E@sun.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 16 Jul 2004 22:50:27 -0500
In-Reply-To: <7CEEF686-D7A3-11D8-92AF-000A95A51C9E@sun.com>
Message-ID: <m3iscngum4.fsf@bitsko.slc.ut.us>
Lines: 25
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: <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> writes:

> On Jul 16, 2004, at 4:22 PM, Robert Sayre wrote:
> 
> > It would appear that the most convenient approach for J2ME
> > applications would be a request header in combination with POST.
> 
> Here's another simple way:
> 
> 1. Create an entry:
> POST the <atom:entry> to the feed EditURI
> 
> 2. Update an entry:
> POST the <atom:entry> to the feed EditURI
> with one extra attribute update="URI of entry"
> 
> 3. Delete an entry
> POST to the feed editURI
> <atom:delete entry="URI of entry" />

I don't think (2) would work for non-Atom-entry resource
representations, like image/jpeg, without using an XML wrapper and
base64.

  -- Ken



From owner-atom-syntax@mail.imc.org  Sat Jul 17 00:00: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 AAA03144
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 00:00: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 i6H3pAap004593;
	Fri, 16 Jul 2004 20:51: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 i6H3pAov004592;
	Fri, 16 Jul 2004 20:51:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from scandium.sabren.com (scandium.sabren.com [209.61.155.99])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6H3p9T5004579;
	Fri, 16 Jul 2004 20:51:09 -0700 (PDT)
	(envelope-from joe@bitworking.org)
Received: from bitworking.org (adsl-221-6-61.rmo.bellsouth.net [68.221.6.61])
	(authenticated bits=0)
	by scandium.sabren.com (8.12.11/8.12.10) with ESMTP id i6H3s35A010518;
	Fri, 16 Jul 2004 23:54:03 -0400
Message-ID: <40F8A22C.3070904@bitworking.org>
Date: Fri, 16 Jul 2004 23:51:08 -0400
From: Joe Gregorio <joe@bitworking.org>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Hoffman / IMC <phoffman@imc.org>
CC: Robert Sayre <mint@franklinmint.fm>, Tim Bray <Tim.Bray@Sun.COM>,
        Atom Syntax <atom-syntax@imc.org>
Subject: Re: Q: Put request should return Atom entry?
References: <BD1DD57F.13D52%mint@franklinmint.fm> <40F892F1.5040105@bitworking.org> <p06110415bd1e4c1ed10a@[10.20.30.249]>
In-Reply-To: <p06110415bd1e4c1ed10a@[10.20.30.249]>
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


Paul Hoffman / IMC wrote:

> Not quite. Because "servers MAY include", clients "MUST NOT expect". 
> This is a direct interoperability interpretation. If I'm creating a 
> client that expects additional info, it will not interoperate with some 
> conformant servers.

I think I'm missing something. Are you saying that

"servers MAY include" implies "clients MUST NOT expect"

and if so doesn't that mean that the second
part is redundant if added to the spec?

	-joe

P.S. I'm not going to argue about every instance
of MUST and MAY in the spec, but I am asking
a lot of questions in this instance to learn
the correct ways to apply RFC 2119.



From owner-atom-syntax@mail.imc.org  Sat Jul 17 00: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 XAA00932
	for <atompub-archive@lists.ietf.org>; Fri, 16 Jul 2004 23:17: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 i6H3A8ud097674;
	Fri, 16 Jul 2004 20:10: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 i6H3A8MI097673;
	Fri, 16 Jul 2004 20:10:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6H3A6i8097651
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 20:10:07 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 17 Jul 2004 13:15:32 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sat, 17 Jul 2004 13:10:09 +1000
Subject: Re: PaceReplaceLinkElement: Is link-ness relevant?
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD1ED5B1.20418%eric.scheid@ironclad.net.au>
In-Reply-To: <20040717025837.19874.qmail@web41213.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 17/7/04 12:58 PM, "Dare Obasanjo" <kpako@yahoo.com> wrote:

> How about countering my statement and those of Graham
> that there is simply no consistent way to process the
> various link elements that exist in Atom today let
> alone processing arbitrary link elements that could be
> produced by any third party.

what is your position regarding PaceLinkPurpose, which addresses this
specific issue of semantics of use?

e.



From owner-atom-syntax@mail.imc.org  Sat Jul 17 00: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 AAA03617
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 00:12:23 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6H43Ir0006159;
	Fri, 16 Jul 2004 21:03:18 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6H43IKB006158;
	Fri, 16 Jul 2004 21:03:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.244])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6H43Hxx006152
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 21:03:17 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so3162309cwc
        for <atom-syntax@imc.org>; Fri, 16 Jul 2004 21:03:24 -0700 (PDT)
Received: by 10.11.99.74 with SMTP id w74mr113777cwb;
        Fri, 16 Jul 2004 21:03:24 -0700 (PDT)
Message-ID: <3f1451f504071621037d50b72c@mail.gmail.com>
Date: Sat, 17 Jul 2004 00:03:24 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Tim Bray <tim.bray@sun.com>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <7CEEF686-D7A3-11D8-92AF-000A95A51C9E@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <BD1DDB85.13D53%mint@franklinmint.fm> <7CEEF686-D7A3-11D8-92AF-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 Fri, 16 Jul 2004 20:43:38 -0700, Tim Bray <tim.bray@sun.com> wrote:
> 
> On Jul 16, 2004, at 4:22 PM, Robert Sayre wrote:
> 
> > It would appear that the most convenient approach for J2ME applications
> > would be a request header in combination with POST.
> 
> Here's another simple way:
> 
> 1. Create an entry:
> POST the <atom:entry> to the feed EditURI
> 
> 2. Update an entry:
> POST the <atom:entry> to the feed EditURI
> with one extra attribute update="URI of entry"
> 
> 3. Delete an entry
> POST to the feed editURI
> <atom:delete entry="URI of entry" />

Just a point of clarification, and not to suggest
that I support this idea, which I don't,  but in the current 
spec there is a seperate EditURI for each
entry that could be edited, thus the 
attributes for "URI of entry" are not needed.

   -joe



From owner-atom-syntax@mail.imc.org  Sat Jul 17 00:16: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 AAA03925
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 00:16:26 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6H4ALPI007366;
	Fri, 16 Jul 2004 21:10:21 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6H4ALBO007365;
	Fri, 16 Jul 2004 21:10:21 -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 i6H4AK5J007350
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 21:10:20 -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 i6H4AL53024604
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 23:10:22 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6H4ALfc024600;
	Fri, 16 Jul 2004 23:10:21 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceReplaceLinkElement: Is link-ness relevant?
References: <BD1ED5C6.20418%eric.scheid@ironclad.net.au>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 16 Jul 2004 23:10:21 -0500
In-Reply-To: <BD1ED5C6.20418%eric.scheid@ironclad.net.au>
Message-ID: <m3eknbgtoy.fsf@bitsko.slc.ut.us>
Lines: 42
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


Eric Scheid <eric.scheid@ironclad.net.au> writes:

> On 17/7/04 9:28 AM, "Antone Roundy" <antone@geckotribe.com> wrote:
> 
> > A non-Atom example: If you put the following into the head of an
> > HTML document and load it in Mozilla with the Site Navigation Bar
> > active (look under View >> Show/Hide >> Site Navigation Bar), a
> > "More" menu will show up with the link in it.
> > 
> > <link rel="MyLinkType" title="This links to something"
> > href="http://www.example.org/">
> 
> to come full circle, an atom-related example ... if you put this
> into HTML you get something quite handy. you don't need to lobby w3c
> to include a new tag in the next version of html, you don't need to
> use name spaces, you just use the existing functionality ...
> 
>     <link @rel="alternate" type="application/atom+xml" href="...">

The problem with this is @rel name collision, the values are a flat
namespace.  HTML document authors don't make much use of <link>, but
micro-content authors (like Atom authors) are really getting into
links in a serious way.  Name collision is inevitable.

There is no difference of difficulty or specification between making
up your own fully-qualified @rel value or making a new element, you're
still using XML Namespaces.

I think we can sum up the debate by saying whether we're going to
allow qnames in content or not.

QNames in content have "curb appeal" because it reuses elements for
common relation types, but elements have "implementation appeal"
because the implementor doesn't have to reimplement a function of the
XML parser.

I believe the "curb appeal", however, is waning.  Just as users have
come to expect new elements for new metadata fields, they are coming
to expect new elements for new link fields.  Our own <id> and <url>
are examples of that.

  -- Ken



From owner-atom-syntax@mail.imc.org  Sat Jul 17 00:25: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 AAA04406
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 00:25: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 i6H4HsGm008476;
	Fri, 16 Jul 2004 21:17: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 i6H4Hs9J008475;
	Fri, 16 Jul 2004 21:17:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6H4HrIh008468
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 21:17:53 -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 i6H4Fp53021774
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 22:15:51 -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 <0I0Z00BOCALZCS@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Fri, 16 Jul 2004 22:18:00 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.45])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I0Z00KUGALZ3N@mail.sun.net> for atom-syntax@imc.org; Fri,
 16 Jul 2004 22:17:59 -0600 (MDT)
Date: Fri, 16 Jul 2004 21:18:03 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
In-reply-to: <3f1451f504071621037d50b72c@mail.gmail.com>
To: Joe Gregorio <joe.gregorio@gmail.com>
Cc: Atom Syntax <atom-syntax@imc.org>
Message-id: <4C1C1211-D7A8-11D8-92AF-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: <BD1DDB85.13D53%mint@franklinmint.fm>
 <7CEEF686-D7A3-11D8-92AF-000A95A51C9E@sun.com>
 <3f1451f504071621037d50b72c@mail.gmail.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 Jul 16, 2004, at 9:03 PM, Joe Gregorio wrote:

>> 1. Create an entry:
>> POST the <atom:entry> to the feed EditURI
>>
>> 2. Update an entry:
>> POST the <atom:entry> to the feed EditURI
>> with one extra attribute update="URI of entry"
>>
>> 3. Delete an entry
>> POST to the feed editURI
>> <atom:delete entry="URI of entry" />
>
> Just a point of clarification, and not to suggest
> that I support this idea, which I don't,  but in the current
> spec there is a seperate EditURI for each
> entry that could be edited, thus the
> attributes for "URI of entry" are not needed.

That neatly solves the problem that Ken McLeod pointed out:

2. Update an entry:
POST the new content to the entry's EditURI

  -Tim



From owner-atom-syntax@mail.imc.org  Sat Jul 17 00:26: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 AAA04435
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 00:26: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 i6H4IILt008527;
	Fri, 16 Jul 2004 21:18: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 i6H4IIPQ008526;
	Fri, 16 Jul 2004 21:18:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.242])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6H4IHtV008511
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 21:18:18 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so3171944cwc
        for <atom-syntax@imc.org>; Fri, 16 Jul 2004 21:18:20 -0700 (PDT)
Received: by 10.11.116.34 with SMTP id o34mr101292cwc;
        Fri, 16 Jul 2004 21:18:19 -0700 (PDT)
Message-ID: <3f1451f5040716211863a34de7@mail.gmail.com>
Date: Sat, 17 Jul 2004 00:18:19 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Antone Roundy <antone@geckotribe.com>
Subject: Re: PaceServiceElement created
Cc: atom-syntax@imc.org
In-Reply-To: <DD1905F6-CC3C-11D8-B0A4-003065EA6144@geckotribe.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <DD1905F6-CC3C-11D8-B0A4-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 Fri, 2 Jul 2004 09:31:18 -0600, Antone Roundy <antone@geckotribe.com> wrote:
> 
> I've posted PaceServiceElement on the wiki.  Since it's not scheduled
> for discussion yet, I'll just post the first little bit so that you'll
> know what it's about when it gets to the Proceed list.  (Note however
> that it is related to PaceIntrospection, which is currently under
> discussion).
> 
> Abstract
> 
>         This proposal defines a new element to be used in place of
> link[@rel="service.*"].
> 
> Related and Conflicting Proposals
> 
>      * PaceLinkPurpose
>      * PaceLinkConstruct
>      * PaceIntrospection
> 
> Rationale
> 
>         If PaceLinkPurpose is adopted, then link[@rel="service.post"] and
> link[@rel="service.edit"] will be clearly outside of the boundaries set
> for the link element (neither is an appropriate value for a clickable
> link), and thus will need a new element. Even if PaceLinkPurpose is not
> adopted, moving this logical group of @rel values to their own element
> would help to avoid excessive overloading of the link element.

I've looked at this again and instead of:

<atom:service name="edit" href="http://example.org/blah"/>

I would much prefer:

<atom:edit>http://example.org/blah</atom:/edit>

   -joe



From owner-atom-syntax@mail.imc.org  Sat Jul 17 00:29: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 AAA04565
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 00:29: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 i6H4Mc1C009106;
	Fri, 16 Jul 2004 21: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 i6H4MctD009104;
	Fri, 16 Jul 2004 21:22: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 (mproxy.gmail.com [216.239.56.249])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6H4Mbid009085
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 21:22:37 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so3174572cwc
        for <atom-syntax@imc.org>; Fri, 16 Jul 2004 21:22:40 -0700 (PDT)
Received: by 10.11.99.11 with SMTP id w11mr114273cwb;
        Fri, 16 Jul 2004 21:22:39 -0700 (PDT)
Message-ID: <3f1451f504071621226b06ea51@mail.gmail.com>
Date: Sat, 17 Jul 2004 00:22:39 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Tim Bray <tim.bray@sun.com>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <4C1C1211-D7A8-11D8-92AF-000A95A51C9E@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <BD1DDB85.13D53%mint@franklinmint.fm>
 <7CEEF686-D7A3-11D8-92AF-000A95A51C9E@sun.com>
 <3f1451f504071621037d50b72c@mail.gmail.com> <4C1C1211-D7A8-11D8-92AF-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 Fri, 16 Jul 2004 21:18:03 -0700, Tim Bray <tim.bray@sun.com> wrote:
> On Jul 16, 2004, at 9:03 PM, Joe Gregorio wrote:
> 
> >> 1. Create an entry:
> >> POST the <atom:entry> to the feed EditURI
> >>
> >> 2. Update an entry:
> >> POST the <atom:entry> to the feed EditURI
> >> with one extra attribute update="URI of entry"
> >>
> >> 3. Delete an entry
> >> POST to the feed editURI
> >> <atom:delete entry="URI of entry" />
> >
> > Just a point of clarification, and not to suggest
> > that I support this idea, which I don't,  but in the current
> > spec there is a seperate EditURI for each
> > entry that could be edited, thus the
> > attributes for "URI of entry" are not needed.
> 
> That neatly solves the problem that Ken McLeod pointed out:
> 
> 2. Update an entry:
> POST the new content to the entry's EditURI

Oh. In my implementation I was going to make 
the EditURI for an entry the 
PostURI for comments on that entry.

   -joe



From owner-atom-syntax@mail.imc.org  Sat Jul 17 00: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 AAA06118
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 00: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 i6H4fAvd011382;
	Fri, 16 Jul 2004 21:41: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 i6H4fAhv011381;
	Fri, 16 Jul 2004 21:41: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 i6H4f967011363
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 21: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 i6H4fB53024969
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 23:41:11 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6H4fBba024965;
	Fri, 16 Jul 2004 23:41:11 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceLinkConstruct central?
References: <BD1EBE48.203CC%eric.scheid@ironclad.net.au>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 16 Jul 2004 23:41:11 -0500
In-Reply-To: <BD1EBE48.203CC%eric.scheid@ironclad.net.au>
Message-ID: <m3acxzgs9k.fsf@bitsko.slc.ut.us>
Lines: 12
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


Eric Scheid <eric.scheid@ironclad.net.au> writes:

> (c) break some links out to their own elements (<this href="">) but
> leave the generalised case of <<there is a resource you may be
> interested in retrieving, it's relationship to me is 'blah'>> as
> <link rel="blah">

Are the values in @rel fixed or extensible?  If you address the
extensibility issue in @rel, we don't need <this .../>.  If the values
in @rel are fixed, then it makes all extended links second-class.

  -- Ken



From owner-atom-syntax@mail.imc.org  Sat Jul 17 00: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 AAA06283
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 00:49: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 i6H4g0qD011494;
	Fri, 16 Jul 2004 21:42: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 i6H4g0LA011493;
	Fri, 16 Jul 2004 21:42:00 -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 i6H4fxmm011479
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 21:41: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 (sccrmhc11) with SMTP
          id <2004071704420101100t1a0te>; Sat, 17 Jul 2004 04:42:01 +0000
Date: Fri, 16 Jul 2004 22:42:00 -0600
Subject: Re: PaceReplaceLinkElement: Is link-ness relevant?
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: <m3eknbgtoy.fsf@bitsko.slc.ut.us>
Message-Id: <A450F773-D7AB-11D8-8968-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 Friday, July 16, 2004, at 10:10  PM, Ken MacLeod wrote:
>>> <link rel="MyLinkType" title="This links to something"
>>> href="http://www.example.org/">
>
> The problem with this is @rel name collision, the values are a flat
> namespace.  HTML document authors don't make much use of <link>, but
> micro-content authors (like Atom authors) are really getting into
> links in a serious way.  Name collision is inevitable.
>
> There is no difference of difficulty or specification between making
> up your own fully-qualified @rel value or making a new element, you're
> still using XML Namespaces.
>
> I think we can sum up the debate by saying whether we're going to
> allow qnames in content or not.
>
Yeah, we'd definitely have to come up with some way to avoid name 
collisions, but there are various ways we might do that: having qnames 
in @rel; specifying that anything with @href MUST be a Link Construct; 
specifying that anything whose name begins with "link-" MUST be a Link 
Construct (eg. <foo:link-bar title="This links to something" href="..." 
/>); making an extension namespace to identify Link Constructs 
(<foo:bar ex:href="..." ... />); etc.



From owner-atom-syntax@mail.imc.org  Sat Jul 17 01: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 BAA07540
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 01:33: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 i6H5PuaV025332;
	Fri, 16 Jul 2004 22:25: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 i6H5Pusa025331;
	Fri, 16 Jul 2004 22:25:56 -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 i6H5PtG4025278
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 22:25:56 -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 i6H5Pv53025484
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 00:25:57 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6H5PvlO025480;
	Sat, 17 Jul 2004 00:25:57 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: atom-syntax@imc.org
Subject: Re: PaceReplaceLinkElement: Is link-ness relevant?
References: <A450F773-D7AB-11D8-8968-003065EA6144@geckotribe.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 17 Jul 2004 00:25:57 -0500
In-Reply-To: <A450F773-D7AB-11D8-8968-003065EA6144@geckotribe.com>
Message-ID: <m3zn5zfbmi.fsf@bitsko.slc.ut.us>
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: <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> writes:

> Yeah, we'd definitely have to come up with some way to avoid name
> collisions, but there are various ways we might do that: having
> qnames in @rel; specifying that anything with @href MUST be a Link
> Construct; specifying that anything whose name begins with "link-"
> MUST be a Link Construct (eg. <foo:link-bar title="This links to
> something" href="..." />); making an extension namespace to identify
> Link Constructs (<foo:bar ex:href="..." ... />); etc.

Between a localname pattern (link-*) and link relation type attributes
(@href, @ex:href), I'd choose link relation type attributes.

Two issues with link-* localnames:

Most importantly, it doesn't solve the naming issue, only reduces it.
There'd be some non-Atom vocabulary out there defining elements with
link-* in their localnames, then somebody else would want to embed
that content into an Atom document.

Less importantly, I don't think it's common for libraries to support
searching for elements based on a localname name pattern.

  -- Ken



From owner-atom-syntax@mail.imc.org  Sat Jul 17 01:51: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 BAA08175
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 01:51: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 i6H5hRrG035639;
	Fri, 16 Jul 2004 22:43:27 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6H5hRcl035638;
	Fri, 16 Jul 2004 22:43:27 -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 i6H5hO4f035235
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 22:43:25 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 17 Jul 2004 15:48:16 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sat, 17 Jul 2004 15:42:52 +1000
Subject: Re: PaceReplaceLinkElement: Is link-ness relevant?
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD1EF97C.204D5%eric.scheid@ironclad.net.au>
In-Reply-To: <56F15E2E-D789-11D8-9095-000A95DC3D90@mac.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


On 17/7/04 10:36 AM, "Graham" <dtcd@mac.com> wrote:

> As an aggregator developer, I'd like to declare I have no plans (or
> desires) to do anything at all with unrecognised Link constructs, and
> thus no desire to be able to pick them out easily.

but do you have plans or desires to do anything with link constructs you
*do* recognise?

If you are going to ignore all links, unrecognised or no, then your
objection is moot. If you are going to do something with certain kinds of
links, then what's stopping you from just ignoring the ones you don't
recognise?

e.



From owner-atom-syntax@mail.imc.org  Sat Jul 17 02:01: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 CAA09453
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 02:01: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 i6H5rSSs041180;
	Fri, 16 Jul 2004 22: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 i6H5rSeA041179;
	Fri, 16 Jul 2004 22:53: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 i6H5rKc0041116
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 22:53:26 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 17 Jul 2004 15:58:40 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sat, 17 Jul 2004 15:53:12 +1000
Subject: Re: PaceLinkConstruct central?
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD1EFBE8.20518%eric.scheid@ironclad.net.au>
In-Reply-To: <m3acxzgs9k.fsf@bitsko.slc.ut.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


On 17/7/04 2:41 PM, "Ken MacLeod" <ken@bitsko.slc.ut.us> wrote:

>> (c) break some links out to their own elements (<this href="">) but
>> leave the generalised case of <<there is a resource you may be
>> interested in retrieving, it's relationship to me is 'blah'>> as
>> <link rel="blah">
> 
> Are the values in @rel fixed or extensible?  If you address the
> extensibility issue in @rel, we don't need <this .../>.  If the values
> in @rel are fixed, then it makes all extended links second-class.

For (c), I say @rel would be extensible, but I am also saying that <link> be
restricted to just those links which are 'hyperlinks', not service entry
points, not references to resources for transclusion or performing
transformations with. That is, consider <link> to be for the same generic
purpose which <url> in <person> and <generator> serves. It's simply a URL to
some retrievable resource related in some ambiguous way to the parent
element. 

For the case of <link> standing in for <url> in <person> and <generator>,
I'd be happy to have @rel be optional. It's just a generic link. The
provision of @rel serves to refine the relationship, but can be ignored if
necessary.

Assuming PaceLinkPurpose is implemented, and thus all the URIs in <link>
elements are traversable, we could even allow @rel to be optional there too.
It would serve the bland purpose of saying "here is some other resource you
might care to retrieve". Throw in @title and users would know if it's sane
to go traverse that link. Throw in @type and users would know if their
browser will handle it, or if it is a PDF, or a quicktime movie.

e.



From owner-atom-syntax@mail.imc.org  Sat Jul 17 02:02:50 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10826
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 02:02:50 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6H5rBtW041044;
	Fri, 16 Jul 2004 22:53: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 i6H5rBsm041043;
	Fri, 16 Jul 2004 22:53:11 -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 i6H5quk8040953
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 22:53:06 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 17 Jul 2004 15:58:22 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sat, 17 Jul 2004 15:52:59 +1000
Subject: Re: PaceReplaceLinkElement: Is link-ness relevant?
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD1EFBDB.20518%eric.scheid@ironclad.net.au>
In-Reply-To: <m3zn5zfbmi.fsf@bitsko.slc.ut.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


On 17/7/04 3:25 PM, "Ken MacLeod" <ken@bitsko.slc.ut.us> wrote:

> Most importantly, it doesn't solve the naming issue, only reduces it.
> There'd be some non-Atom vocabulary out there defining elements with
> link-* in their localnames, then somebody else would want to embed
> that content into an Atom document.

well noted.

the same goes for atom:href

e.



From owner-atom-syntax@mail.imc.org  Sat Jul 17 02:31: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 CAA24473
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 02:31: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 i6H6NkBK056416;
	Fri, 16 Jul 2004 23: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 i6H6NkuD056414;
	Fri, 16 Jul 2004 23:23: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 i6H6NfmP056368
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 23:23:45 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 17 Jul 2004 16:28:57 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sat, 17 Jul 2004 16:23:33 +1000
Subject: Re: PaceReplaceLinkElement: Is link-ness relevant?
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD1F0305.20529%eric.scheid@ironclad.net.au>
In-Reply-To: <BD1EFBDB.20518%eric.scheid@ironclad.net.au>
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 17/7/04 3:52 PM, "Eric Scheid" <eric.scheid@ironclad.net.au> wrote:

> On 17/7/04 3:25 PM, "Ken MacLeod" <ken@bitsko.slc.ut.us> wrote:
> 
>> Most importantly, it doesn't solve the naming issue, only reduces it.
>> There'd be some non-Atom vocabulary out there defining elements with
>> link-* in their localnames, then somebody else would want to embed
>> that content into an Atom document.
> 
> well noted.
> 
> the same goes for atom:href

doh!

which would be written as 'href' because of default namespace contortions.

e.



From owner-atom-syntax@mail.imc.org  Sat Jul 17 02:40: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 CAA24957
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 02:40: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 i6H6WOfs060549;
	Fri, 16 Jul 2004 23: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 i6H6WOIF060548;
	Fri, 16 Jul 2004 23:32:24 -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 i6H6WNY2060505
	for <atom-syntax@imc.org>; Fri, 16 Jul 2004 23:32:24 -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 i6H6WI53026136
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 01:32:18 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6H6WHhG026132;
	Sat, 17 Jul 2004 01:32:17 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom-Syntax Syntax <atom-syntax@imc.org>
Subject: Re: PaceReplaceLinkElement: Is link-ness relevant?
References: <20040717023144.94723.qmail@web41212.mail.yahoo.com>
	<40F8939A.60009@intertwingly.net>
	<B01AEC25-D7A2-11D8-9095-000A95DC3D90@mac.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 17 Jul 2004 01:32:17 -0500
In-Reply-To: <B01AEC25-D7A2-11D8-9095-000A95DC3D90@mac.com>
Message-ID: <m3r7rbf8jy.fsf@bitsko.slc.ut.us>
Lines: 23
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


Graham <dtcd@mac.com> writes:

> [...] even if I know a link is "clickable", I still want to make
> sure I'm doing the right thing with it. I'd still only bother with
> known Link constructs. The syndication world is small enough that
> any extension that comes up I can figure out what the best thing to
> do with it is myself, rather than have copies of Shrook in the wild
> presenting nonsense.

If I read this right, you're not against having more refined[1] or
more precise link relation names (@rel or in element name) or whether
those relation names are grouped into relation types (clickable,
service), you're only going to present the relations you know of
to-date, correct?

I don't see any problems with that approach.

  -- Ken

[1] "Refined" is used in Dublin Core to mean terms that are more
precise than the terms they are derived from.  It's also used from a
"schema" or "subclassing" perspective, where you're allowed to use a
more precise term in situations where you'd use the less precise term.



From owner-atom-syntax@mail.imc.org  Sat Jul 17 03: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 DAA29312
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 03: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 i6H7kdD3093329;
	Sat, 17 Jul 2004 00: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 i6H7kdKG093328;
	Sat, 17 Jul 2004 00:46:39 -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 i6H7kcmc093312
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 00:46:39 -0700 (PDT)
	(envelope-from davep@dpawson.co.uk)
Received: (qmail 14866 invoked from network); 17 Jul 2004 08:07:16 -0000
Received: from dpawson.gotadsl.co.uk (HELO ?192.168.2.6?) (davep@dpawson.co.uk@81.6.251.105)
  by 0 with SMTP; 17 Jul 2004 08:07:16 -0000
Subject: Re: PaceReplaceLinkElement created
From: Dave Pawson <davep@dpawson.co.uk>
Reply-To: davep@dpawson.co.uk
To: Atom-Syntax Syntax <atom-syntax@imc.org>
In-Reply-To: <3f1451f50407162032374318ea@mail.gmail.com>
References: <7ABCBE9A-D74A-11D8-9D94-000A95DC3D90@mac.com>
	 <40F8125C.5020206@intertwingly.net>
	 <3f1451f50407162032374318ea@mail.gmail.com>
Content-Type: text/plain
Message-Id: <1090050375.2019.11.camel@homer>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) 
Date: Sat, 17 Jul 2004 08:46:15 +0100
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 Sat, 2004-07-17 at 04:32, Joe Gregorio wrote:
> > Meanwhile, an extensibility question.  If somebody wants to define a new
> > element, in a new namespace, are we supposed to wantonly assume that any
> > attribute spelled "href" is an indication that an atom LinkConstruct is
> > what is intended?
> 
> For this reason I would prefer this attribute be atom:href.

-1 to 'assuming semantics' from an attribute name.
It just doesn't make sense to me.

Define a link in the spec, syntax and semantics, if the
element+attribute combination doesn't meet the spec 
then its something else, not a link. 


-- 
Regards DaveP.
XSLT&Docbook  FAQ
http://www.dpawson.co.uk/xsl




From owner-atom-syntax@mail.imc.org  Sat Jul 17 04:24: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 EAA01147
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 04:24: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 i6H81NQf099810;
	Sat, 17 Jul 2004 01:01: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 i6H81NPI099809;
	Sat, 17 Jul 2004 01:01: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 i6H81LoZ099780
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 01:01:22 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 17 Jul 2004 18:06:42 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sat, 17 Jul 2004 18:01:18 +1000
Subject: PacePersonLinks created
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD1F19EE.20591%eric.scheid@ironclad.net.au>
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


http://intertwingly.net/wiki/pie/PacePersonLinks

----------------------------------------------------------

Abstract:

Replace <url> in <author> and <contributor> with <link>. Allow multiple.
Allow generic relationship.

Rationale:

Generally speaking, URIs are preferred to be in attributes.

While remaining optional, it might prove useful to allow some
machine-readable processing of resources related to person constructs. For
example: large feed aggregator sites like pubsub or bloglines or syndic8
could extract all the feeds which have foaf resources linked to their
authors and then at least make that list available for other foaf-eating
services to do as they wont.

<author>
    <name>...</name>
    <link href="..." rel="resume" type="application/pdf" title="hire me!" />
    <link href="http://friendster..."
                rel="profile" type="text/html" title="date me!" />
    <link href="..." rel="blog" type="text/html" title="read me!" />
    <link href="..." rel="foaf" type="application/foaf+xml" title="foaf!" />
</author>


The 'allow generic relationship' is to provide the same generic linking
functionality of the existing <url> construct, and could be done by simply
omitting the 'rel' attribute. Thus this:

    <author>
        <name>...</name>
        <url>....</url>
    </author>

would be written as:

    <author>
        <name>...</name>
        <link href="..." />
    </author>

It still provides the same meaning - it "conveys a URI associated with the
author". Implementations would process it the same as they would have
processed <url>. For the occasions where @rel is specified then an
implemention could either ignore @rel (treating it the same as the generic
<url>), pass it to the user to process (eg. provide a tool-tip that says
"[resume]" on the link), or do something special pertaining to that
particular @rel value.

----------------------------------------------------------

e.



From owner-atom-syntax@mail.imc.org  Sat Jul 17 05:15: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 FAA03402
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 05:15: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 i6H8uTTp026248;
	Sat, 17 Jul 2004 01: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 i6H8uTMZ026245;
	Sat, 17 Jul 2004 01:56: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 (pop.gmx.net [213.165.64.20])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6H8uRWX026162
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 01:56:28 -0700 (PDT)
	(envelope-from julian.reschke@gmx.de)
Received: (qmail 11448 invoked by uid 65534); 17 Jul 2004 08:56:22 -0000
Received: from pD9E51873.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.24.115)
  by mail.gmx.net (mp027) with SMTP; 17 Jul 2004 10:56:22 +0200
X-Authenticated: #1915285
Message-ID: <40F8E9B4.9090508@gmx.de>
Date: Sat, 17 Jul 2004 10:56: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: Martin Duerst <duerst@w3.org>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceMustBeWellFormed
References: <40F66628.4010004@intertwingly.net> <14be96d30407061142441f70ee@mail.gmail.com> <40F56B2A.8050500@intertwingly.net> <14be96d304071411092c2c44f4@mail.gmail.com> <p06110426bd1b3deea52a@10.20.30.249> <14be96d30407141427187f294d@mail.gmail.com> <p0611042bbd1b66fa15ef@[10.20.30.249]> <40F5C1F4.5080709@intertwingly.net> <40F62105.6080600@gmx.de> <40F66628.4010004@intertwingly.net> <4.2.0.58.J.20040716175746.056c9948@localhost>
In-Reply-To: <4.2.0.58.J.20040716175746.056c9948@localhost>
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


Martin Duerst wrote:

> Julian - Why do you say transcoding has gone wrong? Because transcoding
> from iso-8859-1 to iso-8859-7 isn't a very probable scenario anyway?
> Maybe we should use a more probable example, e.g. koi8-R and iso-8859-5?

Correct, that would be a good idea.

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From owner-atom-syntax@mail.imc.org  Sat Jul 17 06:27: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 GAA06956
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 06:27: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 i6HAHxgg066201;
	Sat, 17 Jul 2004 03: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 i6HAHxTp066200;
	Sat, 17 Jul 2004 03:17:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from garland.duramedia.net (garland.duramdedia.net [209.51.131.138] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6HAHwpI066177
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 03:17:59 -0700 (PDT)
	(envelope-from jg@jonasgalvez.com)
Received: from 200-206-135-201.dsl.telesp.net.br ([200.206.135.201] ident=jgalvez)
	by garland.duramedia.net with esmtp (Exim 4.34)
	id 1BlmGT-0001uB-Qo
	for atom-syntax@imc.org; Sat, 17 Jul 2004 06:17:58 -0400
Message-ID: <40F8FC66.9070307@jonasgalvez.com>
Date: Sat, 17 Jul 2004 07:16:06 -0300
From: Jonas Galvez <jg@jonasgalvez.com>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: AtomSyntax <atom-syntax@imc.org>
Subject: #atom feed
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 - garland.duramedia.net
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - jonasgalvez.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


This may look silly (the HTML formatted log is great), but I like
concentrating my daily dosage of info on my feed reader... so... just
thought some folks might also find it useful :-)

http://jonasgalvez.com/feeds/atomlogs.php
http://jonasgalvez.com/feeds/atomlogs.txt



\\ jonas galvez
// jonasgalvez.com



From owner-atom-syntax@mail.imc.org  Sat Jul 17 07:58:35 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10728
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 07:58: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 i6HBnNTE093837;
	Sat, 17 Jul 2004 04:49: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 i6HBnNef093833;
	Sat, 17 Jul 2004 04:49: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 i6HBnLgT093805
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 04:49:22 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 30423 messnum 9204971 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 17 Jul 2004 11:49:17 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail10.svc.cra.dublin.eircom.net (qp 30423) with SMTP; 17 Jul 2004 11:49:17 -0000
Message-ID: <40F91239.4050807@dehora.net>
Date: Sat, 17 Jul 2004 12:49:13 +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: Eric Scheid <eric.scheid@ironclad.net.au>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceReplaceLinkElement created
References: <BD1ED5BC.20418%eric.scheid@ironclad.net.au>
In-Reply-To: <BD1ED5BC.20418%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:

> On 17/7/04 4:17 AM, "Paul Hoffman / IMC" <phoffman@imc.org> wrote:
> 
> 
>>At 1:37 PM -0400 7/16/04, Sam Ruby wrote:
>>
>>>Meanwhile, an extensibility question.  If somebody wants to define a
>>>new element, in a new namespace, are we supposed to wantonly assume
>>>that any attribute spelled "href" is an indication that an atom
>>>LinkConstruct is what is intended?
>>
>>We can make that wanton assumption if we say in the spec something to
>>the effect of "The use of attributes called 'href' mean that they are
>>links to the outside world, and anyone extending Atom should only use
>>'href' in a way similar to the items in the core spec."

I must be missing something. If we want to allow folks to put the 
href with our semantics on their elements, why aren't we specifying 
@atom:href?

cheers
Bill



From owner-atom-syntax@mail.imc.org  Sat Jul 17 08:09: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 IAA11619
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 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 i6HC1XH9096569;
	Sat, 17 Jul 2004 05:01: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 i6HC1X5N096568;
	Sat, 17 Jul 2004 05:01:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail06.svc.cra.dublin.eircom.net (mail06.svc.cra.dublin.eircom.net [159.134.118.22])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6HC1WDd096540
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 05:01:32 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 82996 messnum 2823085 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 17 Jul 2004 12:01:28 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail06.svc.cra.dublin.eircom.net (qp 82996) with SMTP; 17 Jul 2004 12:01:28 -0000
Message-ID: <40F91514.9060100@dehora.net>
Date: Sat, 17 Jul 2004 13: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: Sam Ruby <rubys@intertwingly.net>
CC: Dare Obasanjo <kpako@yahoo.com>, atom-syntax@imc.org
Subject: Re: PaceReplaceLinkElement: Is link-ness relevant?
References: <20040717023144.94723.qmail@web41212.mail.yahoo.com> <40F8939A.60009@intertwingly.net>
In-Reply-To: <40F8939A.60009@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:

> 
> Much of the current discussion is focusing on "rel" as if it is the most 
> important attribute, but at times simply having a recognized media type, 
> a title, and an href is all you need to present a relevant choice to a 
> user.

But not all the time. And @rel /is/ the most important attribute in 
this case, as it is least well defined, most open to abuse, most 
likely to hurt interopration in a free for all scenario. Even in a 
closed scenario feedback on the list we have suggests no-one is 
going to want or be able to process them uniformly - they're clearly 
disjoint. And no, the filter by media type argument isn't sufficient 
to partition out a clean subset of links. I suugest introducing 
co-occurence constraints like this is not addressing the problem.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Sat Jul 17 08:20: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 IAA12472
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 08:20: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 i6HCAV4w098225;
	Sat, 17 Jul 2004 05: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 i6HCAVX7098224;
	Sat, 17 Jul 2004 05:10: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 i6HCAUWT098218
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 05:10: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 i6HCBHjY024763;
	Sat, 17 Jul 2004 08:11:17 -0400
Message-ID: <40F9172F.8010002@intertwingly.net>
Date: Sat, 17 Jul 2004 08:10:23 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Eric Scheid <eric.scheid@ironclad.net.au>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceReplaceLinkElement: Is link-ness relevant?
References: <BD1F0305.20529%eric.scheid@ironclad.net.au>
In-Reply-To: <BD1F0305.20529%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:

>>the same goes for atom:href
> 
> doh!
> 
> which would be written as 'href' because of default namespace contortions.

Just a point of clarification, from an XML point of view, "atom:href" 
and "href" are always considered distinct attributes, independent of the 
value of the default namespace in effect on this element.

 From http://www.w3.org/TR/REC-xml-names/#defaulting:

     Note that default namespaces do not apply directly to attributes.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Sat Jul 17 08: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 IAA12636
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 08:23: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 i6HCFcpT099108;
	Sat, 17 Jul 2004 05:15: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 i6HCFc9Y099107;
	Sat, 17 Jul 2004 05:15:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail06.svc.cra.dublin.eircom.net (mail06.svc.cra.dublin.eircom.net [159.134.118.22])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6HCFb6T099080
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 05:15:37 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 29754 messnum 2830848 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 17 Jul 2004 12:15:33 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail06.svc.cra.dublin.eircom.net (qp 29754) with SMTP; 17 Jul 2004 12:15:33 -0000
Message-ID: <40F91861.1070409@dehora.net>
Date: Sat, 17 Jul 2004 13:15:29 +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: Joe Gregorio <joe.gregorio@gmail.com>
CC: Antone Roundy <antone@geckotribe.com>, atom-syntax@imc.org
Subject: Re: PaceServiceElement created
References: <DD1905F6-CC3C-11D8-B0A4-003065EA6144@geckotribe.com> <3f1451f5040716211863a34de7@mail.gmail.com>
In-Reply-To: <3f1451f5040716211863a34de7@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


Joe Gregorio wrote:

> I've looked at this again and instead of:
> 
> <atom:service name="edit" href="http://example.org/blah"/>
> 
> I would much prefer:
> 
> <atom:edit>http://example.org/blah</atom:/edit>

My preference would be:

   <atom:edit rdf:resource="http://example.org/blah" />

but the chances of that happening are approaching zero :)

+1 to Joe in the meantime.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Sat Jul 17 08:29: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 IAA12845
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 08:29: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 i6HCMXDs000549;
	Sat, 17 Jul 2004 05:22: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 i6HCMXUb000548;
	Sat, 17 Jul 2004 05:22: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 i6HCMWWi000526
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 05:22:32 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 40345 messnum 9196018 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 17 Jul 2004 12:22:28 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail10.svc.cra.dublin.eircom.net (qp 40345) with SMTP; 17 Jul 2004 12:22:28 -0000
Message-ID: <40F91A00.9060004@dehora.net>
Date: Sat, 17 Jul 2004 13:22: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: Joe Gregorio <joe@bitworking.org>
CC: Paul Hoffman / IMC <phoffman@imc.org>, Robert Sayre <mint@franklinmint.fm>,
        Tim Bray <Tim.Bray@Sun.COM>, Atom Syntax <atom-syntax@imc.org>
Subject: Re: Q: Put request should return Atom entry?
References: <BD1DD57F.13D52%mint@franklinmint.fm> <40F892F1.5040105@bitworking.org> <p06110415bd1e4c1ed10a@[10.20.30.249]> <40F8A22C.3070904@bitworking.org>
In-Reply-To: <40F8A22C.3070904@bitworking.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


Joe Gregorio wrote:

> 
> Paul Hoffman / IMC wrote:
> 
>> Not quite. Because "servers MAY include", clients "MUST NOT expect". 
>> This is a direct interoperability interpretation. If I'm creating a 
>> client that expects additional info, it will not interoperate with 
>> some conformant servers.
> 
> 
> I think I'm missing something. Are you saying that
> 
> "servers MAY include" implies "clients MUST NOT expect"
> 
> and if so doesn't that mean that the second
> part is redundant if added to the spec?

Joe,

I think Paul is right; do not drop 3.

The reason is that the implication you've just said *doesn't* 
logically follow so we need to spec it to stop people abducting to 
other possible conclusions. Imagine bizarro-hacker reading  1 and 2 
and concluding "clients MAY expect content" or even better "clients 
SHOULD expect content".

cheers
Bill



From owner-atom-syntax@mail.imc.org  Sat Jul 17 08:37:37 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13066
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 08: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 i6HCSWJE001631;
	Sat, 17 Jul 2004 05: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 i6HCSWKv001630;
	Sat, 17 Jul 2004 05:28:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6HCSVXW001545
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 05:28:31 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 17 Jul 2004 22:33:22 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sat, 17 Jul 2004 22:17:32 +1000
Subject: Re: PaceServiceElement created
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD1F55FC.20632%eric.scheid@ironclad.net.au>
In-Reply-To: <3f1451f5040716211863a34de7@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: <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 17/7/04 2:18 PM, "Joe Gregorio" <joe.gregorio@gmail.com> wrote:

> I've looked at this again and instead of:
> 
> <atom:service name="edit" href="http://example.org/blah"/>
> 
> I would much prefer:
> 
> <atom:edit>http://example.org/blah</atom:/edit>

we don't want to put machine-readable data in element content instead of
attributes, do we?

so how about ...

    <atom:feed uri="..." />
    <atom:post uri="..." />
    <atom:edit uri="..." />
    <atom:delete uri="..." />

or would it be better to group them into a logical class, like this...

    <atom:service name='feed' uri="..." />
    <atom:service name='post' uri="..." />
    <atom:service name='edit' uri="..." />
    <atom:service name='delete' uri="..." />

?

e.



From owner-atom-syntax@mail.imc.org  Sat Jul 17 08:48:44 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13432
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 08:48:44 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6HCdVmM003577;
	Sat, 17 Jul 2004 05: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 i6HCdVhY003576;
	Sat, 17 Jul 2004 05:39:31 -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 i6HCdUN0003559
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 05:39:30 -0700 (PDT)
	(envelope-from davep@dpawson.co.uk)
Received: (qmail 14320 invoked from network); 17 Jul 2004 13:00:11 -0000
Received: from dpawson.gotadsl.co.uk (HELO ?192.168.2.6?) (davep@dpawson.co.uk@81.6.251.105)
  by 0 with SMTP; 17 Jul 2004 13:00:11 -0000
Subject: Re: PaceServiceElement created
From: Dave Pawson <davep@dpawson.co.uk>
Reply-To: davep@dpawson.co.uk
To: Eric Scheid <eric.scheid@ironclad.net.au>
Cc: "xmozillanickname: Atom syntax" <atom-syntax@imc.org>
In-Reply-To: <BD1F55FC.20632%eric.scheid@ironclad.net.au>
References: <BD1F55FC.20632%eric.scheid@ironclad.net.au>
Content-Type: text/plain
Message-Id: <1090067950.2019.41.camel@homer>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) 
Date: Sat, 17 Jul 2004 13:39:10 +0100
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 Sat, 2004-07-17 at 13:17, Eric Scheid wrote:

> > I would much prefer:
> > 
> > <atom:edit>http://example.org/blah</atom:/edit>
> 
> we don't want to put machine-readable data in element content instead of
> attributes, do we?
> 
> so how about ...
> 
>     <atom:feed uri="..." />
>     <atom:post uri="..." />
>     <atom:edit uri="..." />
>     <atom:delete uri="..." />
> 
> or would it be better to group them into a logical class, like this...
> 
>     <atom:service name='feed' uri="..." />
>     <atom:service name='post' uri="..." />
>     <atom:service name='edit' uri="..." />
>     <atom:service name='delete' uri="..." />
> 
> ?

Much clearer semantics. 

I prefer the former, again for clarity of interpretation.
I also prefer the uri attribute agains href.
I really can't see any advantage in leveraging the href name;
its not been done for the majority of other atom elements, why pick on
this one?



Regards DaveP.
XSLT&Docbook  FAQ
http://www.dpawson.co.uk/xsl




From owner-atom-syntax@mail.imc.org  Sat Jul 17 10:47: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 KAA19796
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 10: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 i6HEaWQ2025280;
	Sat, 17 Jul 2004 07: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 i6HEaWh2025279;
	Sat, 17 Jul 2004 07:36:32 -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 i6HEaVlX025256
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 07:36:31 -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 i6HEYN53008796
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 08:34:23 -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 <0I10009ZI38X61@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sat, 17 Jul 2004 08:36:34 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.45])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I1000C8S38XPO@mail.sun.net> for atom-syntax@imc.org; Sat,
 17 Jul 2004 08:36:33 -0600 (MDT)
Date: Sat, 17 Jul 2004 07:36:37 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceServiceElement created
In-reply-to: <BD1F55FC.20632%eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <B5B4ECFE-D7FE-11D8-92AF-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: <BD1F55FC.20632%eric.scheid@ironclad.net.au>
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 Jul 17, 2004, at 5:17 AM, Eric Scheid wrote:

> we don't want to put machine-readable data in element content instead 
> of
> attributes, do we?

Uh, why not? -Tim



From owner-atom-syntax@mail.imc.org  Sat Jul 17 10:53: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 KAA20072
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 10:53: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 i6HEi0Wp026623;
	Sat, 17 Jul 2004 07:44: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 i6HEi0IR026621;
	Sat, 17 Jul 2004 07:44:00 -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 i6HEhwO6026526
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 07:43:59 -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 i6HEhu53031885
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 09:43:56 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6HEht7R031881;
	Sat, 17 Jul 2004 09:43:55 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: <atom-syntax@imc.org>
Subject: Re: PaceServiceElement created
References: <BD1F55FC.20632%eric.scheid@ironclad.net.au>
	<1090067950.2019.41.camel@homer>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 17 Jul 2004 09:43:55 -0500
In-Reply-To: <1090067950.2019.41.camel@homer>
Message-ID: <m3eknag0d0.fsf@bitsko.slc.ut.us>
Lines: 93
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


Dave Pawson <davep@dpawson.co.uk> writes:

> On Sat, 2004-07-17 at 13:17, Eric Scheid wrote:
> 
> > so how about ...
> > 
> >     <atom:feed uri="..." />
> >     <atom:post uri="..." />
> >     <atom:edit uri="..." />
> >     <atom:delete uri="..." />
> > 
> > or would it be better to group them into a logical class, like
> > this...
> > 
> >     <atom:service name='feed' uri="..." />
> >     <atom:service name='post' uri="..." />
> >     <atom:service name='edit' uri="..." />
> >     <atom:service name='delete' uri="..." />
> > 
> > ?
> 
> Much clearer semantics. 
> 
> I prefer the former, again for clarity of interpretation.  I also
> prefer the uri attribute agains href.  I really can't see any
> advantage in leveraging the href name; its not been done for the
> majority of other atom elements, why pick on this one?

The semantics are fuzzy on one point: what class of link is this?

The element name tells you the specific link relation name, but alone
doesn't tell you its link class.  Is it a human clickable link or an
Atom service link?

  <feed atom:id="tag:example.com,2004:main-feed"
        atom:location="http://example.com/main-feed.atom">
    <site atom:id="tag:example.com,2004:site"
          atom:location="http://example.com/site.atom">
      <title>Example Site</title>
      <alternate atom:clickable="http://example.com/"
                 type="text/html"/>
    </site>
    <entry atom:id="tag:example.com,2004:002"
           atom:location="http://example.com/002.atom">
      <author>
        <name>John Q Public</name>
        <link atom:clickable="generic:link"/>
        <ex:homepage atom:clickable="..."/>
        <ex:weblog atom:clickable="..."/>
        <feed atom:service="..."/>
      </author>
      <responds-to atom:uri="tag:example.com,2004:001"
                   atom:location="http://example.com/001.atom"/>
      <origin atom:ref="tag:example.com,2004:site"
              atom:location="http://example.com/site.atom"/>
      <alternate atom:clickable="http://example.com/002.html"
                 type="text/html"/>
      <edit atom:service="http://example.com/002.atom"/>
      <post atom:service="http://example.com/002.atom"/>

"Link classes" ("relation types" in LinkReferences) aren't an
"end-all" solution, as certain link classes are *not* suitable for
generic processing.  Some are however, like clickable links for
humans.

Link classes used here:

  atom:service -- Atom service endpoints
  atom:clickable -- user clickable links, clients recommended to
                    display all
  atom:id -- Atom resource identifier
  atom:ref -- Atom resource identifier reference that means "copy to
              downstream feeds" (synthetic feed info caching)
  atom:uri -- Atom resource identifier reference (non caching)
  atom:location -- Atom resource URI that contains a "last well known"
                   primary access mechanism for the resource, used
                   with atom:ref and atom:uri.

This is patterned after SkunkLink[1].  atom:clickable appears to have
the exact same meaning as SkunkLink's xml:href, if that's useful, but
I chose to only mention that here.

This is still thought-experiment territory.  There are issues with
links that the above addresses, but at the same time it makes them
more complex.  There are also other potential solutions, such as
clustering similar class links under one element, or providing an
"introspection" element to indicate specifically what links clients
should consider "clickable" (the primary class that can be used in a
generic fashion).

  -- Ken

[1] http://dubinko.info/writing/skunklink/



From owner-atom-syntax@mail.imc.org  Sat Jul 17 10:56: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 KAA20230
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 10: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 i6HElprS027270;
	Sat, 17 Jul 2004 07:47: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 i6HElpIE027269;
	Sat, 17 Jul 2004 07:47:51 -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 i6HElois027262
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 07:47: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 i6HEmbVs031593;
	Sat, 17 Jul 2004 10:48:38 -0400
Message-ID: <40F93C0A.5000306@intertwingly.net>
Date: Sat, 17 Jul 2004 10:47:38 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Eric Scheid <eric.scheid@ironclad.net.au>
CC: Atom Syntax <atom-syntax@imc.org>, joe.gregorio@gmail.com
Subject: Re: PaceServiceElement created
References: <BD1F55FC.20632%eric.scheid@ironclad.net.au>
In-Reply-To: <BD1F55FC.20632%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:

> On 17/7/04 2:18 PM, "Joe Gregorio" <joe.gregorio@gmail.com> wrote:
> 
>>I've looked at this again and instead of:
>>
>><atom:service name="edit" href="http://example.org/blah"/>
>>
>>I would much prefer:
>>
>><atom:edit>http://example.org/blah</atom:/edit>
> 
> we don't want to put machine-readable data in element content instead of
> attributes, do we?
> 
> so how about ...
> 
>     <atom:feed uri="..." />
>     <atom:post uri="..." />
>     <atom:edit uri="..." />
>     <atom:delete uri="..." />
> 
> or would it be better to group them into a logical class, like this...
> 
>     <atom:service name='feed' uri="..." />
>     <atom:service name='post' uri="..." />
>     <atom:service name='edit' uri="..." />
>     <atom:service name='delete' uri="..." />
> 
> ?

An <atom:feed> element directly inside of an <atom:feed> element doesn't 
feel right to me.  So, let's take a look at this in context. 
Immediately inside a feed, there is likely to be one or more of these 
elements, and immediately inside of an entry, there is likely to be a 
possibly different set.

Let's focus for a moment on an entry.  Likely to be contained within an 
entry are post, edit, and delete.  I will note that in many cases, the 
same uri is likely to be shared across these services.

This suggests an optimization:

   <atom:service name='post edit delete' uri="..." />

Two variations come to mind.  One is that the name post and delete 
correspond to the HTTP method, but that edit does not... this 
association could be strengthened by changing the name of the attribute, 
and in this one particular case, the value, thus:

   <atom:service method='post put delete' uri="..." />

Furthermore, it might even make sense to consider having a default for 
the method attribute - both to recognize and to encourage the common 
practice whereby multiple methods share a common endpoint.  This is 
without loss of generality or penalty for the general case where the 
endpoints are distinct: in such cases one simply inserts as many service 
elements as are required.

For simplicity, it may make sense to impose the rule that you may have 
exactly one service element with a default set of methods, OR you may 
have any number of service elements that each explicitly define a non 
overlapping set of methods.

  . . .

A similar set of considerations can be made for atom:service elements 
immediately inside of a feed, but let's take a look at the problematic 
case of a "feed" service, in the context of an actual feed:

   <atom:feed>
     <atom:service method="get" uri="..."/>
     <atom:entry/>
     <atom:entry/>
     <atom:entry/>
   </atom:feed>

The way this atom:service element is to be read is as follows: "while 
you may have retrieved this feed at a given URI, the service interface 
to GET a (possibly authenticated) feed intended to contain all the data 
needed for Atom protocol clients is at the following URI".

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Sat Jul 17 11:09: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 LAA20834
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 11:09: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 i6HExY63030114;
	Sat, 17 Jul 2004 07:59: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 i6HExYja030113;
	Sat, 17 Jul 2004 07:59:34 -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 i6HExXDQ030087
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 07:59:33 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040717145931.10530.qmail@web41206.mail.yahoo.com>
Received: from [24.18.143.189] by web41206.mail.yahoo.com via HTTP; Sat, 17 Jul 2004 07:59:31 PDT
Date: Sat, 17 Jul 2004 07:59:31 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: PaceReplaceLinkElement: Is link-ness relevant?
To: Eric Scheid <eric.scheid@ironclad.net.au>
Cc: atom-syntax@imc.org
In-Reply-To: <BD1ED3AE.20416%eric.scheid@ironclad.net.au>
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>


--- Eric Scheid <eric.scheid@ironclad.net.au> wrote:
> On 17/7/04 12:31 PM, "Dare Obasanjo"
> <kpako@yahoo.com> wrote:
> 
> > (iii) this is a link to an image file which is the
> > logo for the producer of this feed (iv)here is an
> > image file that is an icon that can be used to
> > represent this feed in applications that display
> feeds
> > in a tree view
> 
> both of these also fit your (i) link to human
> readable document ... those
> image files can be loaded into a browser for viewing
> purposes. No different
> to loading the image file "picture of my cat".
> 
> if you want to do something extra with it (eg.
> display the logo in a banner
> space, display the icon in a tree view), then that
> is, um, extra.

That is not how they are primarily meant to be used.
If an aggregator presented me a link to the logo and
icon for a site as opposed to using them in a sensible
way like what Bloglines does I'd assume the aggregator
designer was extremely lazy or drunk when he wrote the
code for that "feature". 



=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/



From owner-atom-syntax@mail.imc.org  Sat Jul 17 11:18: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 LAA21054
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 11:18: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 i6HF9ei0031984;
	Sat, 17 Jul 2004 08: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 i6HF9elN031983;
	Sat, 17 Jul 2004 08:09:40 -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 i6HF9dGe031960
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 08:09:39 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 38779 messnum 2583857 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 17 Jul 2004 15:09:36 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail08.svc.cra.dublin.eircom.net (qp 38779) with SMTP; 17 Jul 2004 15:09:36 -0000
Message-ID: <40F9412B.2080802@dehora.net>
Date: Sat, 17 Jul 2004 16:09:31 +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: Eric Scheid <eric.scheid@ironclad.net.au>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceServiceElement created
References: <BD1F55FC.20632%eric.scheid@ironclad.net.au>
In-Reply-To: <BD1F55FC.20632%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:

> so how about ...
> 
>     <atom:feed uri="..." />

As far as namespaces are concerned, this is the same name as 
/atom:feed, which may not be something you want/intend to happen.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Sat Jul 17 11:30: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 LAA21482
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 11:30: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 i6HFHfUu033611;
	Sat, 17 Jul 2004 08:17: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 i6HFHfHv033610;
	Sat, 17 Jul 2004 08:17:41 -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 i6HFHe6J033592
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 08:17:40 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 8082 messnum 259176 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 17 Jul 2004 15:17:37 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail09.svc.cra.dublin.eircom.net (qp 8082) with SMTP; 17 Jul 2004 15:17:37 -0000
Message-ID: <40F9430C.9060501@dehora.net>
Date: Sat, 17 Jul 2004 16:17: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: Sam Ruby <rubys@intertwingly.net>
CC: Eric Scheid <eric.scheid@ironclad.net.au>,
        Atom Syntax <atom-syntax@imc.org>, joe.gregorio@gmail.com
Subject: Re: PaceServiceElement created
References: <BD1F55FC.20632%eric.scheid@ironclad.net.au> <40F93C0A.5000306@intertwingly.net>
In-Reply-To: <40F93C0A.5000306@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:

> This suggests an optimization:
> 
>   <atom:service name='post edit delete' uri="..." />

Is that meant to be an enumeration of the possible values for the 
name attribute, or a whitespace delimited list of methods in the 
name attribute?


> A similar set of considerations can be made for atom:service elements 
> immediately inside of a feed, but let's take a look at the problematic 
> case of a "feed" service, in the context of an actual feed:
> 
>   <atom:feed>
>     <atom:service method="get" uri="..."/>
>     <atom:entry/>
>     <atom:entry/>
>     <atom:entry/>
>   </atom:feed>

I don't see yet what the atom:service abstraction is offering direct 
element names.

Incidently, the act of eumerating the allowed methods/operations 
over a URI is what the link discussion should be focusing on.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Sat Jul 17 11:35: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 LAA21639
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 11:35: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 i6HFQhmZ035391;
	Sat, 17 Jul 2004 08:26:43 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6HFQhtV035390;
	Sat, 17 Jul 2004 08:26: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 i6HFQb44035363;
	Sat, 17 Jul 2004 08:26:38 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p06110402bd1ef336f9e9@[10.20.30.249]>
In-Reply-To: <40F8A22C.3070904@bitworking.org>
References: <BD1DD57F.13D52%mint@franklinmint.fm>
 <40F892F1.5040105@bitworking.org> <p06110415bd1e4c1ed10a@[10.20.30.249]>
 <40F8A22C.3070904@bitworking.org>
Date: Sat, 17 Jul 2004 08:26:51 -0700
To: Joe Gregorio <joe@bitworking.org>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: Q: Put request should return Atom entry?
Cc: Robert Sayre <mint@franklinmint.fm>, Tim Bray <Tim.Bray@Sun.COM>,
        Atom Syntax <atom-syntax@imc.org>
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 11:51 PM -0400 7/16/04, Joe Gregorio wrote:
>Paul Hoffman / IMC wrote:
>
>>Not quite. Because "servers MAY include", clients "MUST NOT 
>>expect". This is a direct interoperability interpretation. If I'm 
>>creating a client that expects additional info, it will not 
>>interoperate with some conformant servers.
>
>I think I'm missing something. Are you saying that
>
>"servers MAY include" implies "clients MUST NOT expect"

Yes.

>and if so doesn't that mean that the second
>part is redundant if added to the spec?

Yes. But what you may be missing is that putting redundant things in 
the spec sometimes has value. Assume that we only included "servers 
MAY include" in the spec. A client writer is reading the spec to see 
what he/she needs to do to interoperate. They see nothing about 
clients in this section, so they assume it doesn't apply to them.

Seen another way, we could say only "clients MUST NOT expect" and 
force server writers to infer from it that "servers MAY include". I 
think most people here would chafe at that, even though it is 
equivalent.

That's why I am advocating for including both "servers MAY include" 
and "clients MUST NOT expect". One of them is redundant, but 
including both helps the two important parts of our readership. We 
don't need to do this in every place, just where we are talking to 
different audiences.

>P.S. I'm not going to argue about every instance
>of MUST and MAY in the spec, but I am asking
>a lot of questions in this instance to learn
>the correct ways to apply RFC 2119.

Understood. It's not as easy as one would think. I have written specs 
that on round -04 someone has a question about the MUST/SHOULD that I 
should have seen in the -00. A general rule is to assume that 
implementers five years from now will know *much* less about the 
subject than the people writing the specs today, yet we want them to 
interoperate as well as we hope to when the spec is finished. The 
goal is to write a spec that helps them as much as it helps us.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Sat Jul 17 11: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 LAA21738
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 11:37: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 i6HFS6dQ035640;
	Sat, 17 Jul 2004 08:28: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 i6HFS6i8035639;
	Sat, 17 Jul 2004 08:28: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 i6HFS60T035623
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 08:28:06 -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 esmtp (Exim 4.34)
	id 1Blr6Y-0005F2-EZ; Sat, 17 Jul 2004 15:28:02 +0000
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Sat, 17 Jul 2004 11:28:11 -0400
Subject: Re: PaceReplaceLinkElement: Is link-ness relevant?
From: Robert Sayre <mint@franklinmint.fm>
To: Dare Obasanjo <kpako@yahoo.com>, Graham <dtcd@mac.com>,
        Antone Roundy <antone@geckotribe.com>
CC: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD1EBDCB.13E05%mint@franklinmint.fm>
In-Reply-To: <20040717023144.94723.qmail@web41212.mail.yahoo.com>
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: <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 7/16/04 10:31 PM, "Dare Obasanjo" <kpako@yahoo.com> wrote:

> 
> --- Graham <dtcd@mac.com> wrote:
>> 
>> As an aggregator developer, I'd like to declare I
>> have no plans (or
>> desires) to do anything at all with unrecognised
>> Link constructs, and
>> thus no desire to be able to pick them out easily.
> 
> +1 
> 
> Same here. Currently the link construct is a hack.

I'm not going to argue with you guys if you disagree, but wouldn't taking
all types of link elements into account help for PageRank-type algorithms? I
use RSS Bandit to see what it's like subscribing to lots of feeds; way more
than I can reasonably read. It would be nice for aggregators to present me
with "URIs that everyone is talking about".

For example, I subscribe to Slashdot, The Register, CNET, etc. I rarely read
them, but it'd be nice to know if they were all talking about the same
thing.

Perhaps Feedster, Technorati, PubSub, etc could make of use it as well.

Robert Sayre



From owner-atom-syntax@mail.imc.org  Sat Jul 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 LAA21902
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 11: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 i6HFWZ5k036439;
	Sat, 17 Jul 2004 08:32: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 i6HFWZCX036438;
	Sat, 17 Jul 2004 08:32:35 -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 i6HFWZjZ036432
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 08:32:35 -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 i6HFWc2G018098;
	Sat, 17 Jul 2004 08:32:38 -0700 (PDT)
Received: from [192.168.1.107] (66-65-118-184.nyc.rr.com [66.65.118.184])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin01/MantshX 4.0) with ESMTP id i6HFWPLB006682;
	Sat, 17 Jul 2004 08:32:37 -0700 (PDT)
In-Reply-To: <BD1EF97C.204D5%eric.scheid@ironclad.net.au>
References: <BD1EF97C.204D5%eric.scheid@ironclad.net.au>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3-101993230; protocol="application/pkcs7-signature"
Message-Id: <7F8C5C76-D806-11D8-9095-000A95DC3D90@mac.com>
Cc: Atom Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: PaceReplaceLinkElement: Is link-ness relevant?
Date: Sat, 17 Jul 2004 11:32:21 -0400
To: Eric Scheid <eric.scheid@ironclad.net.au>
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-101993230
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 17 Jul 2004, at 1:42 am, Eric Scheid wrote:

> On 17/7/04 10:36 AM, "Graham" <dtcd@mac.com> wrote:
>
>> As an aggregator developer, I'd like to declare I have no plans (or
>> desires) to do anything at all with unrecognised Link constructs, and
>> thus no desire to be able to pick them out easily.
>
> but do you have plans or desires to do anything with link constructs 
> you
> *do* recognise?

Yes. I already do.

> If you are going to ignore all links, unrecognised or no, then your
> objection is moot. If you are going to do something with certain kinds 
> of
> links, then what's stopping you from just ignoring the ones you don't
> recognise?

Nothing. But if I ignore them, and everyone else does, the there's no 
need to be able to know an unrecognised one is a link construct, and no 
reason to have such a useless hack as link@rel.

Graham
--Apple-Mail-3-101993230
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
9w0BCQUxDxcNMDQwNzE3MTUzMjIyWjAjBgkqhkiG9w0BCQQxFgQUIAk6gTvJjckfWhva/9JYKDHn
yd0weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAiyQohA8iurcH6M4vpzMErkcr
S9x2ZO01dSONZlO5ihlmvxg6uLS0b1VZnFkHZXSfETWRNj1kI01B569cBPoYglOPtYKAnHZ/DzUv
tYWI5GekfuMuIsLaZoqVxyVuCltjnzQFEPR25TSYBa2krBvOl0+Yt5wes2Rbsc1QbfJIuVrLMK6e
KxNe8ckhjv2mjHdQiiCaE5ukvkwvjw2Vyvr3r+Q7HRXGF9XQv5chihS7A9T/vTmUP8Hp5smuhke+
qIwiV4Ke1zLVTDnYcqx7xyNVc1ya3I38NgJtLer8rkJ2rarYbKtn6591iNKfWYkcF/bFG7ONKYS7
/7V2kForUn2UBgAAAAAAAA==

--Apple-Mail-3-101993230--



From owner-atom-syntax@mail.imc.org  Sat Jul 17 11: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 LAA22070
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 11:45: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 i6HFaeEl037195;
	Sat, 17 Jul 2004 08:36: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 i6HFae1b037194;
	Sat, 17 Jul 2004 08:36:40 -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 i6HFaehR037187
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 08:36:40 -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 i6HFaf2G019835;
	Sat, 17 Jul 2004 08:36:41 -0700 (PDT)
Received: from [192.168.1.107] (66-65-118-184.nyc.rr.com [66.65.118.184])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id i6HFaYaA009342;
	Sat, 17 Jul 2004 08:36:35 -0700 (PDT)
In-Reply-To: <m3r7rbf8jy.fsf@bitsko.slc.ut.us>
References: <20040717023144.94723.qmail@web41212.mail.yahoo.com> <40F8939A.60009@intertwingly.net> <B01AEC25-D7A2-11D8-9095-000A95DC3D90@mac.com> <m3r7rbf8jy.fsf@bitsko.slc.ut.us>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4-102242286; protocol="application/pkcs7-signature"
Message-Id: <13FF46B3-D807-11D8-9095-000A95DC3D90@mac.com>
Cc: Atom-Syntax Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: PaceReplaceLinkElement: Is link-ness relevant?
Date: Sat, 17 Jul 2004 11:36:30 -0400
To: Ken MacLeod <ken@bitsko.slc.ut.us>
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-4-102242286
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 17 Jul 2004, at 2:32 am, Ken MacLeod wrote:

> Graham <dtcd@mac.com> writes:
>
>> [...] even if I know a link is "clickable", I still want to make
>> sure I'm doing the right thing with it. I'd still only bother with
>> known Link constructs. The syndication world is small enough that
>> any extension that comes up I can figure out what the best thing to
>> do with it is myself, rather than have copies of Shrook in the wild
>> presenting nonsense.
>
> If I read this right, you're not against having more refined[1] or
> more precise link relation names (@rel or in element name)

Well I did write a proposal encouraging the latter.

> or whether
> those relation names are grouped into relation types (clickable,
> service), you're only going to present the relations you know of
> to-date, correct?

I'm completely against grouping them. There's no reason to and it 
creates an extensibility nightmare.


--Apple-Mail-4-102242286
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
9w0BCQUxDxcNMDQwNzE3MTUzNjMxWjAjBgkqhkiG9w0BCQQxFgQUf22Z1Z2ePgSJQQcQZBX9fvOU
FUgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAkGGVvfHQd4qXBdNhj5nodASd
VLd9vYjdhfsOhlCo8gc3IlnganLyElPfWNDIfE7vxAC95MIe8zZac5XpfcO6PvAQs+QWkkCcY1rS
Ne/na6MV/0l3/KpwhRr6Ldz9iMKL2150JxUdvgH/BinUX+AiN7ST8HKveG8lqr50F1kGZ7iSVFMd
8OfknavkDfyXbAIFpo9fWfUY1X9LFxN60SQRTmzTn0JRXYuxnVFPJm7O8ty5lHXR4cWgnDBTETQk
2HBaq815N1xdOfFKE+/J4sW19jUzaGbWwUVtSlnhEqCLTPjVASrxp9kBMQ7T1m1fpE5U7MiJgu4r
OPJjQIVUrdgHBwAAAAAAAA==

--Apple-Mail-4-102242286--



From owner-atom-syntax@mail.imc.org  Sat Jul 17 11:47: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 LAA22173
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 11:47: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 i6HFdIeN037667;
	Sat, 17 Jul 2004 08: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 i6HFdIDF037666;
	Sat, 17 Jul 2004 08:39:18 -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 i6HFdG8P037649
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 08:39:17 -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 i6HFdE53032578
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 10:39:14 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6HFdEOd032574;
	Sat, 17 Jul 2004 10:39:14 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceServiceElement created
References: <BD1F55FC.20632%eric.scheid@ironclad.net.au>
	<40F93C0A.5000306@intertwingly.net>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 17 Jul 2004 10:39:14 -0500
In-Reply-To: <40F93C0A.5000306@intertwingly.net>
Message-ID: <m38ydifxst.fsf@bitsko.slc.ut.us>
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: <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> writes:

> An <atom:feed> element directly inside of an <atom:feed> element
> doesn't feel right to me.

D'oh!  I unintentionally did that in my example too.

Note that there are cases where the referencing element uses a
URI-reference to the referenced element, and both elements have the
same name.  This is used in ExtensibilityFramework and the <site> and
<author> synthesized feed examples I posted earlier.  In those cases
it's intentional, though.

  -- Ken



From owner-atom-syntax@mail.imc.org  Sat Jul 17 11:52: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 LAA22355
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 11:52: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 i6HFkHxm038905;
	Sat, 17 Jul 2004 08:46: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 i6HFkHTn038904;
	Sat, 17 Jul 2004 08:46:17 -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 i6HFkHYO038885
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 08:46:17 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040717154615.8944.qmail@web41201.mail.yahoo.com>
Received: from [24.18.143.189] by web41201.mail.yahoo.com via HTTP; Sat, 17 Jul 2004 08:46:15 PDT
Date: Sat, 17 Jul 2004 08:46:15 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: PaceReplaceLinkElement: Is link-ness relevant?
To: Robert Sayre <mint@franklinmint.fm>, Graham <dtcd@mac.com>,
        Antone Roundy <antone@geckotribe.com>
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <BD1EBDCB.13E05%mint@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:
>
> I'm not going to argue with you guys if you
> disagree, but wouldn't taking
> all types of link elements into account help for
> PageRank-type algorithms? 

I don't think so. 

> I use RSS Bandit to see what it's like subscribing
to
> lots of feeds; way more
> than I can reasonably read. It would be nice for
> aggregators to present me
> with "URIs that everyone is talking about".

I don't see how having the currently overloaded link
element makes this feature any more possible.
SharpReader already provides something close this
feature by tracking how items that link to a
particular URL although it doesn't let you sort by
'most popular links' which should be a trivial
addition. The only reason I don't have this feature in
RSS Bandit is because I haven't had time to figure out
how to implement such a feature efficiently (and I
need to reduce our memory usage and responsiveness
already). 

If you just want to read the most popular links on the
Web then all you need is an RSS feed of Blogdex or
Daypop's daily lists. Most popular links on the Web,
that are showing up in your aggregator is much harder
since you'd have to ping an external service like
Technorati but I'm sure they'd consider it a DoS
attempt if thousands of RSS Bandit instances were
hitting their servers asking for the link cosmos of
hundreds of links a day. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/



From owner-atom-syntax@mail.imc.org  Sat Jul 17 11:53: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 LAA22438
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 11:53: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 i6HFlAK3039209;
	Sat, 17 Jul 2004 08:47: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 i6HFlA30039208;
	Sat, 17 Jul 2004 08:47:10 -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 i6HFl9pG039186
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 08:47:09 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 17304 messnum 7757129 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 17 Jul 2004 15:47:07 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail01.svc.cra.dublin.eircom.net (qp 17304) with SMTP; 17 Jul 2004 15:47:07 -0000
Message-ID: <40F949F6.3080108@dehora.net>
Date: Sat, 17 Jul 2004 16:47:02 +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: Paul Hoffman / IMC <phoffman@imc.org>
CC: Joe Gregorio <joe@bitworking.org>, Robert Sayre <mint@franklinmint.fm>,
        Tim Bray <Tim.Bray@Sun.COM>, Atom Syntax <atom-syntax@imc.org>
Subject: Re: Q: Put request should return Atom entry?
References: <BD1DD57F.13D52%mint@franklinmint.fm> <40F892F1.5040105@bitworking.org> <p06110415bd1e4c1ed10a@[10.20.30.249]> <40F8A22C.3070904@bitworking.org> <p06110402bd1ef336f9e9@[10.20.30.249]>
In-Reply-To: <p06110402bd1ef336f9e9@[10.20.30.249]>
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


Paul Hoffman / IMC wrote:

> Yes. But what you may be missing is that putting redundant things in the 
> spec sometimes has value. 

I don't think it's redundant in this case. "clients MAY expect 
content" doesn't seem to be disallowed by 1 and 2.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Sat Jul 17 11:55: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 LAA22499
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 11:55: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 i6HFjZs8038777;
	Sat, 17 Jul 2004 08:45: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 i6HFjZuB038776;
	Sat, 17 Jul 2004 08:45:35 -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 i6HFjYZb038749
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 08:45:35 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 81695 messnum 15266469 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 17 Jul 2004 15:45:32 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail11.svc.cra.dublin.eircom.net (qp 81695) with SMTP; 17 Jul 2004 15:45:32 -0000
Message-ID: <40F94997.8070507@dehora.net>
Date: Sat, 17 Jul 2004 16:45:27 +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: Ken MacLeod <ken@bitsko.slc.ut.us>
CC: atom-syntax@imc.org
Subject: Re: PaceServiceElement created
References: <BD1F55FC.20632%eric.scheid@ironclad.net.au>	<1090067950.2019.41.camel@homer> <m3eknag0d0.fsf@bitsko.slc.ut.us>
In-Reply-To: <m3eknag0d0.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: <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


Ken MacLeod wrote:

> Dave Pawson <davep@dpawson.co.uk> writes:
> 
> 
>>On Sat, 2004-07-17 at 13:17, Eric Scheid wrote:
>>
>>
>>>so how about ...
>>>
>>>    <atom:feed uri="..." />
>>>    <atom:post uri="..." />
>>>    <atom:edit uri="..." />
>>>    <atom:delete uri="..." />
>>>
>>>or would it be better to group them into a logical class, like
>>>this...
>>>
>>>    <atom:service name='feed' uri="..." />
>>>    <atom:service name='post' uri="..." />
>>>    <atom:service name='edit' uri="..." />
>>>    <atom:service name='delete' uri="..." />
>>>
>>>?
>>
>>Much clearer semantics. 

Seriously - what semantics?


> The semantics are fuzzy on one point: what class of link is this?

This is always going to be an issue with a generic element like 
atom:service whose meaning is to be determined by looking at one or 
more of its attribute values and not at the element name itself.


> The element name tells you the specific link relation name, but alone
> doesn't tell you its link class.  Is it a human clickable link or an
> Atom service link?

I would argue that all the atom:service element tells you is that 
you need to look at its attributes.


If we keep going done this road we are going end up defining an 
ad-hoc type system for Atom's use of URIs. In my humble opinion 
that's a tarpit we want to stay well away from.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Sat Jul 17 11: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 LAA22651
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 11:59:17 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6HFqLQ5040134;
	Sat, 17 Jul 2004 08:52:21 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6HFqL6c040133;
	Sat, 17 Jul 2004 08:52:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6HFqHUZ040117;
	Sat, 17 Jul 2004 08:52:18 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p06110406bd1efbb5f78f@[10.20.30.249]>
In-Reply-To: <BD1F19EE.20591%eric.scheid@ironclad.net.au>
References: <BD1F19EE.20591%eric.scheid@ironclad.net.au>
Date: Sat, 17 Jul 2004 08:52:51 -0700
To: Eric Scheid <eric.scheid@ironclad.net.au>,
        Atom Syntax <atom-syntax@imc.org>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: PacePersonLinks created
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>


Sounds reasonable. It lets folks define extension relationships while 
making the generic relationship trivial to implement.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Sat Jul 17 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 MAA22824
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 12:03: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 i6HFumxi040973;
	Sat, 17 Jul 2004 08: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 i6HFumUK040972;
	Sat, 17 Jul 2004 08: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 i6HFumxh040966
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 08:56:48 -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 esmtp (Exim 4.34)
	id 1BlrYN-0006Jp-E5; Sat, 17 Jul 2004 15:56:47 +0000
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Sat, 17 Jul 2004 11:56:56 -0400
Subject: Re: PaceReplaceLinkElement: Is link-ness relevant?
From: Robert Sayre <mint@franklinmint.fm>
To: Dare Obasanjo <kpako@yahoo.com>, Graham <dtcd@mac.com>,
        Antone Roundy <antone@geckotribe.com>
CC: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD1EC488.13E21%mint@franklinmint.fm>
In-Reply-To: <20040717154615.8944.qmail@web41201.mail.yahoo.com>
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: <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 7/17/04 11:46 AM, "Dare Obasanjo" <kpako@yahoo.com> wrote:

> --- Robert Sayre <mint@franklinmint.fm> wrote:
>> 
>> I'm not going to argue with you guys if you
>> disagree, but wouldn't taking
>> all types of link elements into account help for
>> PageRank-type algorithms?
> 
> I don't think so.

OK.

> 
>> I use RSS Bandit to see what it's like subscribing to
>> lots of feeds; way more
>> than I can reasonably read. It would be nice for
>> aggregators to present me
>> with "URIs that everyone is talking about".
> 
> I don't see how having the currently overloaded link
> element makes this feature any more possible.

I was referring to extension link types in general, not advocating the
current syntax. The beginning of this thread:

>>On 7/16/04 3:47 PM, "Tim Bray" <Tim.Bray@Sun.COM> wrote:
>>> I'm sure there must be some good reason why it's considered a good
>>> thing to be able to spot that an element is a link to something, even
>>> if you have no idea what the semantics of that link are.  I assume
>>> there must be some essential thing you can do given that knowledge.



> If you just want to read the most popular links on the
> Web then all you need is an RSS feed of Blogdex or
> Daypop's daily lists. Most popular links on the Web,
> that are showing up in your aggregator is much harder...

I just want the most popular links among feeds that I subscribe to, since
those are the sources that I trust. If the aggregator can't recognize
extension link types, it's losing some data points, that's all.

Robert Sayre



From owner-atom-syntax@mail.imc.org  Sat Jul 17 12:07: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 MAA23024
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 12: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 i6HG1ZAV041863;
	Sat, 17 Jul 2004 09:01: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 i6HG1ZwW041862;
	Sat, 17 Jul 2004 09:01: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 i6HG1ZSF041838
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 09:01:35 -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 <2004071716013201200fnfi5e>; Sat, 17 Jul 2004 16:01:32 +0000
Date: Sat, 17 Jul 2004 10:01:31 -0600
Subject: Re: PaceServiceElement created
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: <40F93C0A.5000306@intertwingly.net>
Message-Id: <91948D7A-D80A-11D8-8E8A-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, July 17, 2004, at 08:47  AM, Sam Ruby wrote:
> I will note that in many cases, the same uri is likely to be shared 
> across these services.
>
> This suggests an optimization:
>
>   <atom:service name='post edit delete' uri="..." />
>
> Two variations come to mind.  One is that the name post and delete 
> correspond to the HTTP method, but that edit does not... this 
> association could be strengthened by changing the name of the 
> attribute, and in this one particular case, the value, thus:
>
>   <atom:service method='post put delete' uri="..." />
One question: assuming the API is going to provide a fallback method 
for servers that don't support PUT and DELETE, how does such a server 
expose it's endpoints?  (Of course, the same question will need to be 
answered however we specify the service elements, unless we were to 
drop PUT and DELETE completely.)  Perhaps the following:

    <atom:service name="delete" method="post" uri="..." />

Perhaps "method" could be "http-method" for clarity.  A server that 
DOES support DELETE could omit @method thusly:

    <atom:service name="delete" uri="..." />

In the case of the editing endpoint, 'name="put"' would be less clear 
than 'name="edit"', so the default method would not equal the endpoint 
name in that case.

I'm not sure I see any reason to require this:

    <atom:service name="get" uri="..." />
    <atom:service name="post" uri="..." />
    <atom:service name="delete" method="post" uri="..." />
    <atom:service name="edit" method="post" uri="..." />

as opposed to this:

    <atom:service name="get" uri="..." />
    <atom:service name="post delete edit" method="post" uri="..." />

One problem with all of this would be that people might think they 
could do this:

    <atom:service name="post delete edit" method="get" uri="..." />

I don't imagine we want to enable that.  So one more option might be 
something along the lines of:

    <atom:service name="post delete edit" rest="0" uri="..." />

with rest="1" being the default.



From owner-atom-syntax@mail.imc.org  Sat Jul 17 12: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 MAA23252
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 12: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 i6HG6qsp042881;
	Sat, 17 Jul 2004 09:06:52 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6HG6qRp042880;
	Sat, 17 Jul 2004 09:06:52 -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 i6HG6q63042872
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 09:06:52 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6HG6til009533
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 10:06:55 -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 <0I10009017FI61@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sat, 17 Jul 2004 10:06:55 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.45])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I1000C757FIE4@mail.sun.net> for atom-syntax@imc.org; Sat,
 17 Jul 2004 10:06:54 -0600 (MDT)
Date: Sat, 17 Jul 2004 09:06:59 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: PaceServiceElement - what Bill said
In-reply-to: <40F94997.8070507@dehora.net>
To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>
Cc: atom-syntax@imc.org, Ken MacLeod <ken@bitsko.slc.ut.us>
Message-id: <558EC476-D80B-11D8-92AF-000A95A51C9E@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.618)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
References: <BD1F55FC.20632%eric.scheid@ironclad.net.au>
 <1090067950.2019.41.camel@homer> <m3eknag0d0.fsf@bitsko.slc.ut.us>
 <40F94997.8070507@dehora.net>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6HG6q63042873
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 Jul 17, 2004, at 8:45 AM, Bill de hÓra wrote:

> If we keep going done this road we are going end up defining an ad-hoc 
> type system for Atom's use of URIs. In my humble opinion that's a 
> tarpit we want to stay well away from.

+1

Furthermore, on the evidence we significantly lack expertise in 
building type systems.

-Tim




From owner-atom-syntax@mail.imc.org  Sat Jul 17 12: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 MAA24855
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 12:52: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 i6HGh1vU049523;
	Sat, 17 Jul 2004 09: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 i6HGh1q8049522;
	Sat, 17 Jul 2004 09:43:01 -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 i6HGh0Vk049494
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 09:43: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 (sccrmhc12) with SMTP
          id <2004071716425801200fplpme>; Sat, 17 Jul 2004 16:42:58 +0000
Date: Sat, 17 Jul 2004 10:42:56 -0600
Subject: Re: PaceLinkPurpose
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v553)
From: Antone Roundy <antone@geckotribe.com>
To: atom-syntax@imc.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <9CCBA856-D743-11D8-8968-003065EA6144@geckotribe.com>
Message-Id: <5B23B8DA-D810-11D8-8E8A-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 Friday, July 16, 2004, at 10:17  AM, Antone Roundy wrote:
> Well, here we go.  This is either going to be fun or painful.  I for 
> one am optimistic that it will be fun--that we'll finally resolve the 
> link/@rel vs. various link constructs issue.
My optimism has waned slightly, but let's keep going.

A question for those who don't see a useful extensibility path in this 
discussion, just to be sure I understand your POV: do you believe that 
useful extensibility using link/@rel is not possible; that useful 
extensibility is not possible using Link Constructs; that useful 
extensibility is not possible with link-like things, whether Link 
Constructs or otherwise; that useful extensibility is simply not 
possible at all; or something else?

I guess I should say something about what I mean by useful 
extensibility--the ability to make useful decisions about how to handle 
elements that one doesn't fully understand.



From owner-atom-syntax@mail.imc.org  Sat Jul 17 12: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 MAA25122
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 12: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 i6HGopd4050862;
	Sat, 17 Jul 2004 09:50: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 i6HGopwr050861;
	Sat, 17 Jul 2004 09:50:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from beattie.info (Debian-exim@26.69-93-195.reverse.theplanet.com [69.93.195.26] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6HGooca050854
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 09:50:51 -0700 (PDT)
	(envelope-from russ@russellbeattie.com)
Received: from adsl-68-124-78-90.dsl.pltn13.pacbell.net ([68.124.78.90] helo=[172.16.1.33])
	by beattie.info with asmtp (Exim 4.33)
	id 1BlsRY-0003N5-U8
	for atom-syntax@imc.org; Sat, 17 Jul 2004 09:53:50 -0700
Message-ID: <40F958E8.4030808@russellbeattie.com>
Date: Sat, 17 Jul 2004 09:50:48 -0700
From: Russell Beattie <russ@russellbeattie.com>
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22smp i686; en-US; m18) Gecko/20010110 Netscape6/6.5
X-Accept-Language: en-us, ja, es-es
MIME-Version: 1.0
To: atom-syntax@imc.org
Subject: Re: PacePutDelete Withdrawn
References: <BD1C9B03.13C0C%mint@franklinmint.fm> <0646779E-D6D0-11D8-A6EC-000A95A51C9E@sun.com> <17ref0hsek1v46oj3rupmlfolffae9t0un@4ax.com> <40F7CB03.8090009@intertwingly.net>
In-Reply-To: <40F7CB03.8090009@intertwingly.net>
Content-Type: text/plain; charset=windows-1252; 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



Peter Mortier wrote:

> I see MIDP enabled Atom clients as possibly the largest
> Atom user base. So, I do see value in this group trying to cater to MIDPs
> needs. 

+1

I'm so happy that Peter is now here posting as he seems to be able to 
better communicate what I've been trying to say for months (year?) now.  
Thanks!

Another thing that's important to note for J2ME applications is that 
there's no concept of libraries. There's just no room for general 
purpose jars, etc. Everything has to be custom written to make things as 
small and efficient as possible. So it's not enough to find some 
workaround or assume that one SOAP expert will solve a problem and then 
it'll be put in a library and used by all. It doesn't work that way. The 
API needs to be straight forward enough to be implemented by hand.

So far the responses to this issue have been

1) Implement the HTTP protocol by hand (Why not? It's simple! Or are you 
a bad programmer?)
2) Parse SOAP by hand  (Why not? It's all in the spec! Or are you a bad 
programmer?)

and no response to the SHA1 encryption issues. Does anyone know of a 
place I can find this besides the Bouncy Castle 500k jar? (This is about 
438k bigger than a phone like the Sony Ericsson T610 can even handle).


Sam Ruby wrote:

> I bring this up as I believe that running code is a much more 
> effective argument than any amount of prose.

Okay. Here's 25 lines of J2ME-compatible Java code that post to Blogger 
using XML-RPC. No libraries needed. Someone please show me the 
equivalent Atom code. Just posting, nothing else.

    String url = "http://blogger.com/api";
    String blogId = "12345";
    String username = "username";
    String password = "password";
    String content = "&lt;title&gt;New Title!&lt;/title&gt; &lt;p&gt; 
This is a test &lt;/p&gt;";
   
    HttpConnection conn = (HttpConnection)Connector.open(url);
    conn.setRequestMethod(HttpConnection.POST);

    OutputStream os = conn.openOutputStream();;
   
    StringBuffer xml = new StringBuffer("<?xml version=\"1.0\"?>");
    xml.append("<methodCall>");
    xml.append("<methodName>blogger.newPost</methodName>");
    xml.append(" <params>");
    xml.append(" 
<param><value><string>C6CE3FFB3174106584CBB250C0B0519BF4E294</string></value></param>");
    xml.append(" <param><value><string>" + blogId + 
"</string></value></param>");
    xml.append(" <param><value><string>" + username + 
"</string></value></param>");
    xml.append(" <param><value><string>" + password + 
"</string></value></param>");
    xml.append(" <param><value><string>" + content + 
"</string></value></param>");
    xml.append(" <param><value><boolean>1</boolean></value></param>");
    xml.append(" </params>");
    xml.append("</methodCall>");

    os.write(xml.toString().getBytes());
    os.flush();

-Russ




From owner-atom-syntax@mail.imc.org  Sat Jul 17 13:13: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 NAA25635
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 13:13: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 i6HH3UjF054348;
	Sat, 17 Jul 2004 10:03: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 i6HH3UMI054347;
	Sat, 17 Jul 2004 10:03: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.97])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6HH3U3M054341
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 10:03:30 -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 i6HH3YJd015564
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 10:03:34 -0700 (PDT)
Received: from [12.40.110.194] (wireless-12-40-110-194.bryantpark.org [12.40.110.194] (may be forged))
	(authenticated bits=0)
	by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id i6HH3NaA024892
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 10:03:33 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v618)
In-Reply-To: <5B23B8DA-D810-11D8-8E8A-003065EA6144@geckotribe.com>
References: <5B23B8DA-D810-11D8-8E8A-003065EA6144@geckotribe.com>
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5-107453100; protocol="application/pkcs7-signature"
Message-Id: <35E25202-D813-11D8-9095-000A95DC3D90@mac.com>
From: Graham <dtcd@mac.com>
Subject: Re: PaceLinkPurpose
Date: Sat, 17 Jul 2004 13:03:22 -0400
To: Atom-Syntax Syntax <atom-syntax@imc.org>
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-5-107453100
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 17 Jul 2004, at 12:42 pm, Antone Roundy wrote:

> do you believe that useful extensibility using link/@rel is not 
> possible;

Yes. There are no practical proposals on the table. By which I mean, 
inventing our own namespace system for attribute values is a 
non-starter, especially when we should be using XML's own namespace 
system.

> that useful extensibility is not possible with link-like things, 
> whether Link Constructs or otherwise; that useful extensibility is 
> simply not possible at all; or something else?

I wouldn't say it's impossible, just not a worthwhile goal given the 
tradeoffs.

Graham
--Apple-Mail-5-107453100
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
9w0BCQUxDxcNMDQwNzE3MTcwMzIyWjAjBgkqhkiG9w0BCQQxFgQUUqxM/T9mtGEO5S0FpyxdixtU
cA4weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAW8+4bk/V6+NxrAYd+URwUJXl
7Hq3iG2uj/ma/HpACcjlSPjLrJS7ek5+nvGrC5KPk5v2CMGkKivC8Nwkx/GpTlIA0xN6hMasSmQK
lqBL3p+roWOD+xS47PPs7xdu751fYsDplVIH1kXOj5VPjmBD72ZnCnq5+f+GI9t65VL7XmvU6rP6
kaHggvr4841962ne+jjqMQp6FBwGtMQqMcqfKK9BiNKDHOCexRWypxAdcxcz2BAZ9cKtO1WjIgcv
cA8Fzx0akQqhs5HrSwX3Fes+4OZxdqeNIPrhc8KrR/s0LUxL5IbXxvFl3xzW8WsRVUmRO4glEzCX
C4G5fJy6jMu81AAAAAAAAA==

--Apple-Mail-5-107453100--



From owner-atom-syntax@mail.imc.org  Sat Jul 17 13:22: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 NAA25964
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 13:22: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 i6HHD4Nq056191;
	Sat, 17 Jul 2004 10:13:04 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6HHD4xX056190;
	Sat, 17 Jul 2004 10:13: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 i6HHD3Ss056166
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 10:13:03 -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 i6HHDoDd028195;
	Sat, 17 Jul 2004 13:13:52 -0400
Message-ID: <40F95E11.4060208@intertwingly.net>
Date: Sat, 17 Jul 2004 13:12:49 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Russell Beattie <russ@russellbeattie.com>
CC: atom-syntax@imc.org
Subject: Re: PacePutDelete Withdrawn
References: <BD1C9B03.13C0C%mint@franklinmint.fm> <0646779E-D6D0-11D8-A6EC-000A95A51C9E@sun.com> <17ref0hsek1v46oj3rupmlfolffae9t0un@4ax.com> <40F7CB03.8090009@intertwingly.net> <40F958E8.4030808@russellbeattie.com>
In-Reply-To: <40F958E8.4030808@russellbeattie.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


Russell Beattie wrote:
> 
> So far the responses to this issue have been
> 
> 1) Implement the HTTP protocol by hand (Why not? It's simple! Or are you 
> a bad programmer?)
> 2) Parse SOAP by hand  (Why not? It's all in the spec! Or are you a bad 
> programmer?)

Can we come back to this part later?  I don't mean to dismiss it, but 
lets take this one step at a time...

> and no response to the SHA1 encryption issues. Does anyone know of a 
> place I can find this besides the Bouncy Castle 500k jar? (This is about 
> 438k bigger than a phone like the Sony Ericsson T610 can even handle).

Here[1] is an implementation of sha1 in a language very close to Java. 
Can you do me a favor and evaluate what the implications are to putting 
such logic on a Sony Ericsson T610 would be?

- Sam Ruby

[1] http://www.ldodds.com/foaf/js/sha1.js



From owner-atom-syntax@mail.imc.org  Sat Jul 17 13:30: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 NAA26376
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 13: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 i6HHKogp057602;
	Sat, 17 Jul 2004 10:20:50 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6HHKo5w057601;
	Sat, 17 Jul 2004 10:20:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from 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 i6HHKnHI057576
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 10:20:49 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040717172047.8054.qmail@web41208.mail.yahoo.com>
Received: from [24.18.143.189] by web41208.mail.yahoo.com via HTTP; Sat, 17 Jul 2004 10:20:47 PDT
Date: Sat, 17 Jul 2004 10:20:47 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: PaceLinkPurpose
To: Antone Roundy <antone@geckotribe.com>, atom-syntax@imc.org
In-Reply-To: <5B23B8DA-D810-11D8-8E8A-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:
> 
>  
> A question for those who don't see a useful
> extensibility path in this 
> discussion, just to be sure I understand your POV:
> do you believe that 
> useful extensibility using link/@rel is not
> possible; that useful 
> extensibility is not possible using Link Constructs;
> that useful 
> extensibility is not possible with link-like things,
> whether Link 
> Constructs or otherwise; that useful extensibility
> is simply not 
> possible at all; or something else?
> 
> I guess I should say something about what I mean by
> useful 
> extensibility--the ability to make useful decisions
> about how to handle 
> elements that one doesn't fully understand.

I haven't seen a proposal yet that defines a feasible
extensibility mechanism. I don't think using link/@rel
by themselves are feasible as an extensibility
mechanism unless their scope is narrowed and usage is
strictly defined.

I agree with Tim Bray that defining this properly
would be akin to defining a type system of sorts if
multiple classes of link types are to be supported. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/



From owner-atom-syntax@mail.imc.org  Sat Jul 17 14:11: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 OAA28088
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 14: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 i6HI0paq065315;
	Sat, 17 Jul 2004 11:00: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 i6HI0pUI065314;
	Sat, 17 Jul 2004 11:00:51 -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 i6HI0n3R065307
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 11:00:50 -0700 (PDT)
	(envelope-from davep@dpawson.co.uk)
Received: (qmail 6562 invoked from network); 17 Jul 2004 18:21:34 -0000
Received: from dpawson.gotadsl.co.uk (HELO ?192.168.2.6?) (davep@dpawson.co.uk@81.6.251.105)
  by 0 with SMTP; 17 Jul 2004 18:21:34 -0000
Subject: Re: PaceServiceElement created
From: Dave Pawson <davep@dpawson.co.uk>
Reply-To: davep@dpawson.co.uk
To: Bill de =?ISO-8859-1?Q?h=D3ra?= <bill@dehora.net>
Cc: "xmozillanickname: Atom syntax" <atom-syntax@imc.org>
In-Reply-To: <40F94997.8070507@dehora.net>
References: <BD1F55FC.20632%eric.scheid@ironclad.net.au>
	 <1090067950.2019.41.camel@homer> <m3eknag0d0.fsf@bitsko.slc.ut.us>
	 <40F94997.8070507@dehora.net>
Content-Type: text/plain; charset=
Message-Id: <1090087234.2019.154.camel@homer>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) 
Date: Sat, 17 Jul 2004 19:00:34 +0100
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


On Sat, 2004-07-17 at 16:45, Bill de hÓra wrote:
> Seriously - what semantics?

Semantic markup Bill. 
I understand what a link is, I know what a uri is, I could even
guess what to put into a uri attribute.


> 
> 
> > The semantics are fuzzy on one point: what class of link is this?

See my other post. This thread so far hasn't addressed (that I saw)
any requirement | use case for classes.


> 
> This is always going to be an issue with a generic element like 
> atom:service whose meaning is to be determined by looking at one or 
> more of its attribute values and not at the element name itself.

I'd rather read the spec than guess what it means? Wouldn't you?


> If we keep going done this road we are going end up defining an 
> ad-hoc type system for Atom's use of URIs. In my humble opinion 
> that's a tarpit we want to stay well away from.

I'm guessing there are some motives behind all the issues?



-- 
Regards DaveP.
XSLT&Docbook  FAQ
http://www.dpawson.co.uk/xsl




From owner-atom-syntax@mail.imc.org  Sat Jul 17 14:37: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 OAA29767
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 14:37:10 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6HITTAI071439;
	Sat, 17 Jul 2004 11:29: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 i6HITTLG071438;
	Sat, 17 Jul 2004 11:29:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail06.svc.cra.dublin.eircom.net (mail06.svc.cra.dublin.eircom.net [159.134.118.22])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6HITShV071414
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 11:29:29 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 23786 messnum 2835817 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 17 Jul 2004 18:29:27 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail06.svc.cra.dublin.eircom.net (qp 23786) with SMTP; 17 Jul 2004 18:29:27 -0000
Message-ID: <40F97002.3000509@dehora.net>
Date: Sat, 17 Jul 2004 19:29:22 +0100
From: =?windows-1252?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: davep@dpawson.co.uk
CC: xmozillanickname: Atom syntax <atom-syntax@imc.org>
Subject: Re: PaceServiceElement created
References: <BD1F55FC.20632%eric.scheid@ironclad.net.au>	 <1090067950.2019.41.camel@homer> <m3eknag0d0.fsf@bitsko.slc.ut.us>	 <40F94997.8070507@dehora.net> <1090087234.2019.154.camel@homer>
In-Reply-To: <1090087234.2019.154.camel@homer>
Content-Type: text/plain; charset=windows-1252; 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


Dave Pawson wrote:

> On Sat, 2004-07-17 at 16:45, Bill de hÓra wrote:
> 
>>Seriously - what semantics?
> 
> 
> Semantic markup Bill. 
> I understand what a link is, I know what a uri is, I could even
> guess what to put into a uri attribute.

I still don't get it.


>>>The semantics are fuzzy on one point: what class of link is this?
> 
> See my other post. This thread so far hasn't addressed (that I saw)
> any requirement | use case for classes.

I didn't write that bit.


> I'm guessing there are some motives behind all the issues?

None I'm aware of.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Sat Jul 17 16: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 QAA04645
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 16: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 i6HJtABS087451;
	Sat, 17 Jul 2004 12: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 i6HJt903087450;
	Sat, 17 Jul 2004 12:55: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 i6HJt8UZ087443
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 12: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 i6HJts6l015496;
	Sat, 17 Jul 2004 15:55:57 -0400
Message-ID: <40F98408.4080807@intertwingly.net>
Date: Sat, 17 Jul 2004 15:54:48 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: steve jenson <stevej@google.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Low-hanging fruit: compulsory namespaces
References: <6D6BAC41-D517-11D8-8C42-000A95A51C9E@sun.com> <40F46DAC.3030900@dehora.net> <D4AC57AE-D527-11D8-A503-000A95A51C9E@sun.com> <40F48A82.2020408@dehora.net> <3F81CFBF-D59D-11D8-A6EC-000A95A51C9E@sun.com> <40F5415E.5070100@dehora.net> <87k6x6mwef.fsf@nwalsh.com> <40F55860.7000800@dehora.net> <CC364146-D5B5-11D8-A6EC-000A95A51C9E@sun.com> <A90FCC42-D5F2-11D8-9B45-000A95B09B46@google.com> <40F5CF1E.1000503@intertwingly.net> <10ED1F59-D5F6-11D8-9B45-000A95B09B46@google.com>
In-Reply-To: <10ED1F59-D5F6-11D8-9B45-000A95B09B46@google.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


steve jenson wrote:
> 
> On Jul 14, 2004, at 5:26 PM, Sam Ruby wrote:
> 
>> steve jenson wrote:
>>
>>> Blogger feeds won't wrap your content in a <div 
>>> xmlns="http://www.w3.org/1999/xhtml"> if your fragment is well 
>>> formed. Sometimes this means that you'll end up with html tags in the 
>>> atom namespace. I didn't notice this was a problem until users of 
>>> Mozilla-based newsreaders pointed it out. A note like this would have 
>>> persuaded me to unset the default namespace before the problem arose.
>>
>> Ouch.  I'll go fix the feedvalidator to check fot this.
> 
> That would have persuaded me, too!

Committed and deployed.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Sat Jul 17 17:44: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 RAA08937
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 17:44: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 i6HLXmW4001830;
	Sat, 17 Jul 2004 14:33: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 i6HLXmXo001829;
	Sat, 17 Jul 2004 14:33:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf19.cluster1.charter.net (mxsf19.cluster1.charter.net [209.225.28.219])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6HLXlTK001803
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 14:33:48 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip10.cluster1.charter.net (mxip10a.cluster1.charter.net [209.225.28.140])
	by mxsf19.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6HLbx2r029799
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 17:37:59 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip10.cluster1.charter.net with ESMTP; 17 Jul 2004 17:33:44 -0400
X-Ironport-AV: i="3.81R,176,1083556800"; 
   d="scan'208"; a="123727845:sNHT18152172"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BlwnT-0000xx-00
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 17:32:43 -0400
To: Atom Syntax <atom-syntax@imc.org>
Subject: On LinkTagMeaning...
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Sat, 17 Jul 2004 17:32:40 -0400
Message-ID: <87k6x2l3pj.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: <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-Type: text/plain

My initial impression of all those @rel values is to run screaming.
We're designing an XML format, we have a widely deployed,
well-established extensibility mechanism at our fingertips, why aren't
we using it? I know why HTML didn't use it, but we don't have the same
constraints.

In the -00 draft, we have seven @rel values:

   attribute rel {
      "alternate"
    | "start"
    | "next"
    | "prev"
    | "service.edit"
    | "service.post"
    | "service.feed" },

It seems to me that those fall neatly into three categories: alternate
formats, threading, and Atom protocol services.

Looking at LinkTagMeaning I see (very broadly) three more categories:
comments, processing, and icons.

My two cents:

1. We need alternate formats, let's have a tag for that.

2. We'll never get consensus on threading, let's not try. Let the
   folks who are interested develop a few extension vocabularies for
   it, let's take them around the block a few times, kick the tires,
   see what we like and standardize something in 18 months.

3. We need protocol services, let's have a tag for that.

4. Let's lump coments in with threading and let a thousand flowers
   bloom.

5. We'll never get consensus on a processing model that allows Atom
   feeds to be transformed arbitrarily by producers and consumers at
   arbitray points in the life cycle of an entry. It just ain't going
   to happen. Let the folks who are interested develop a few extension
   vocabularies for it, let's take them around the block a few times,
   kick the tires, see what we like and standardize something in 36
   months (or 120 maybe).

6. I think feed producers would like the ability to associate an image
   with their feeds, maybe an icon and another larger image. Let's
   have a tag for that.

I have a hard time imagining any real value that would come from being
able to tell that a random extension element contains a link. Here:

   <ndw:whizbang @rel="tatters" href="http://example.org/ralphie"/>

Good luck doing anything useful with that. Given the diversity of link
relationships that we're considering, it wouldn't even make a lot of
sense to put that up as a link for the reader to click on.

There will be extension vocabularies. Some of them will include links.
Some of them will be popular. Some of them will gain critical mass. Some
of them will be supported by tools. Some of them will only ever be used
by four random friends. That's ok.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | It is good to have an end to journey
http://nwalsh.com/            | toward; but it is the journey that
                              | matters, in the end.--Ursula K. LeGuin

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA+Zr7OyltUcwYWjsRAgy6AJ9hnGb3hAVLL4cExB1UBDMOVIY1/gCbBpUr
ShblSmcqs99dUtkdciqUcZ0=
=GlFz
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Sat Jul 17 18:10: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 SAA10677
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 18:10: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 i6HM3X0I005708;
	Sat, 17 Jul 2004 15:03: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 i6HM3X5n005707;
	Sat, 17 Jul 2004 15:03:33 -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 i6HM3VX2005649
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 15:03:32 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 18 Jul 2004 08:08:25 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sun, 18 Jul 2004 08:02:51 +1000
Subject: Re: PaceServiceElement created
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD1FDF2B.207B6%eric.scheid@ironclad.net.au>
In-Reply-To: <91948D7A-D80A-11D8-8E8A-003065EA6144@geckotribe.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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 18/7/04 2:01 AM, "Antone Roundy" <antone@geckotribe.com> wrote:

> Perhaps "method" could be "http-method" for clarity.  A server that
> DOES support DELETE could omit @method thusly:
> 
>   <atom:service name="delete" uri="..." />

Y'all realise that service.delete doesn't exist, right? I threw that in
there with the thought in the back of my head that an atom content server
could provide service.delete if it couldn't support http-method=DELETE, or
wanted to cater to atom-clients that were unable to send http-method=DELETE.
You'd probably use GET with some authentication on the URI.

    <entry>
        <id>/1233.atom</id>
        <atom:service name="delete" uri="/1233.atom?action=delete" />
        ...
    </entry>

e.



From owner-atom-syntax@mail.imc.org  Sat Jul 17 18:38: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 SAA12683
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 18: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 i6HMV3Yt009542;
	Sat, 17 Jul 2004 15:31: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 i6HMV30x009541;
	Sat, 17 Jul 2004 15:31:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail48-s.fg.online.no (mail48-s.fg.online.no [148.122.161.48])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6HMV26h009497
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 15:31:03 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Received: from mail.online.no (ti132110a080-3373.bb.online.no [80.212.221.45])
	by mail48.fg.online.no (8.12.11/8.12.11) with ESMTP id i6HMV0QT017152;
	Sun, 18 Jul 2004 00:31:01 +0200 (CEST)
Date: Sun, 18 Jul 2004 00:30:52 +0200
To: "Norman Walsh" <ndw@nwalsh.com>, Atom-syntax <atom-syntax@imc.org>
Subject: Re: On LinkTagMeaning...
References: <87k6x2l3pj.fsf@nwalsh.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: <opsbazhqq76dxgxk@mail.online.no>
In-Reply-To: <87k6x2l3pj.fsf@nwalsh.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, 17 Jul 2004 17:32:40 -0400, Norman Walsh <ndw@nwalsh.com> wrote:

> It seems to me that those fall neatly into three categories: alternate
> formats, threading, and Atom protocol services.

Small note, unless you read something different into threading than me,  
"start", "next" and "prev" does not describe threading.  They do, however  
describe relationships between atom entries.

> 2. We'll never get consensus on threading, let's not try. Let the
>    folks who are interested develop a few extension vocabularies for
>    it, let's take them around the block a few times, kick the tires,
>    see what we like and standardize something in 18 months.

I believe leaving this issue, just because "getting consensus" is hard, is  
a mistake. My suggestion would be to revisit one  of the approaches that  
have been mentioned, either here or in #atom - sum up, and decide on one  
model (possibly even a subset of these models).

If we put this into an extension vocabulary, I'm afraid threading, or any  
other relation mechanisms, such as supersedes/replaces or even  
prev/next/start are going to be plagued by competing mechanisms.


-- 
Arve Bersvendsen

http://www.virtuelvis.com
http://www.bersvendsen.com



From owner-atom-syntax@mail.imc.org  Sat Jul 17 19:02:57 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13796
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 19:02: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 i6HMrnUZ012205;
	Sat, 17 Jul 2004 15:53:49 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6HMrn3Q012204;
	Sat, 17 Jul 2004 15:53: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-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 i6HMrmkK012196
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 15:53:48 -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 i6HMrril028416
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 16:53: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 <0I100030MQ9TDM@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sat, 17 Jul 2004 16:53:53 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.45])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I10003U1Q9SL2@mail.sun.net> for atom-syntax@imc.org; Sat,
 17 Jul 2004 16:53:53 -0600 (MDT)
Date: Sat, 17 Jul 2004 15:53:58 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: On LinkTagMeaning...
In-reply-to: <opsbazhqq76dxgxk@mail.online.no>
To: Arve Bersvendsen <arve@virtuelvis.com>
Cc: Atom-syntax <atom-syntax@imc.org>, Norman Walsh <ndw@nwalsh.com>
Message-id: <3026FE15-D844-11D8-92AF-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: <87k6x2l3pj.fsf@nwalsh.com> <opsbazhqq76dxgxk@mail.online.no>
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 Jul 17, 2004, at 3:30 PM, Arve Bersvendsen wrote:

>> It seems to me that those fall neatly into three categories: alternate
>> formats, threading, and Atom protocol services.
>
> Small note, unless you read something different into threading than 
> me, "start", "next" and "prev" does not describe threading.  They do, 
> however describe relationships between atom entries.

The distinction between this and threading is so fuzzy as to be not 
separable.

>> 2. We'll never get consensus on threading, let's not try. Let the
>>    folks who are interested develop a few extension vocabularies for
>>    it, let's take them around the block a few times, kick the tires,
>>    see what we like and standardize something in 18 months.
>
> I believe leaving this issue, just because "getting consensus" is 
> hard, is a mistake. My suggestion would be to revisit one  of the 
> approaches that have been mentioned, either here or in #atom - sum up, 
> and decide on one model (possibly even a subset of these models).

On the contrary.  There is no body of practice that proves we know how 
to solve the problem, and this group should not be in the business of 
speculative invention of new technologies.

> If we put this into an extension vocabulary, I'm afraid threading, or 
> any other relation mechanisms, such as supersedes/replaces or even 
> prev/next/start are going to be plagued by competing mechanisms.

This is good, because the problem is very far from being solved, and 
thus we need competing candidates if we're going to make progress. -Tim



From owner-atom-syntax@mail.imc.org  Sat Jul 17 20: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 UAA16288
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 20:11: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 i6I01jvo020936;
	Sat, 17 Jul 2004 17: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 i6I01j4I020935;
	Sat, 17 Jul 2004 17:01:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6I01hZM020919
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 17:01:43 -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 esmtp (Exim 4.34)
	id 1Blz7c-0000QK-12; Sun, 18 Jul 2004 00:01:40 +0000
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Sat, 17 Jul 2004 20:01:46 -0400
Subject: Re: On LinkTagMeaning...
From: Robert Sayre <mint@franklinmint.fm>
To: Tim Bray <Tim.Bray@Sun.COM>, Arve Bersvendsen <arve@virtuelvis.com>
CC: Atom Syntax <atom-syntax@imc.org>, Norman Walsh <ndw@nwalsh.com>
Message-ID: <BD1F362A.13EEE%mint@franklinmint.fm>
In-Reply-To: <3026FE15-D844-11D8-92AF-000A95A51C9E@sun.com>
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: <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 7/17/04 6:53 PM, "Tim Bray" <Tim.Bray@Sun.COM> wrote:

> 
>> If we put this into an extension vocabulary, I'm afraid threading, or
>> any other relation mechanisms, such as supersedes/replaces or even
>> prev/next/start are going to be plagued by competing mechanisms.
> 
> This is good, because the problem is very far from being solved, and
> thus we need competing candidates if we're going to make progress.

Unfortunately, prev/next/start are currently cornerstones of the protocol.
This is _not obvious_ [1] from the current draft. It's a problem we do have
to partially solve, I think. A Link Construct may not be the best way to do
it, however.

Robert Sayre

[1] 
http://www.ilrt.bris.ac.uk/discovery/chatlogs/atom/2004-06-29.html#T02-57-50



From owner-atom-syntax@mail.imc.org  Sat Jul 17 20: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 UAA17978
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 20: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 i6I0i3vP026497;
	Sat, 17 Jul 2004 17: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 i6I0i3oQ026496;
	Sat, 17 Jul 2004 17:44:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-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 i6I0i38U026487
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 17:44:03 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6I0i8il017760
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 18:44:08 -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 <0I10006MRVDK6S@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sat, 17 Jul 2004 18:44:08 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.45])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I1000CKNVDJE4@mail.sun.net> for atom-syntax@imc.org; Sat,
 17 Jul 2004 18:44:08 -0600 (MDT)
Date: Sat, 17 Jul 2004 17:44:12 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: On LinkTagMeaning...
In-reply-to: <BD1F362A.13EEE%mint@franklinmint.fm>
To: Robert Sayre <mint@franklinmint.fm>
Cc: Arve Bersvendsen <arve@virtuelvis.com>, Atom Syntax <atom-syntax@imc.org>,
        Norman Walsh <ndw@nwalsh.com>
Message-id: <968F80B8-D853-11D8-92AF-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: <BD1F362A.13EEE%mint@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 Jul 17, 2004, at 5:01 PM, Robert Sayre wrote:

> Unfortunately, prev/next/start are currently cornerstones of the 
> protocol.
> This is _not obvious_ [1] from the current draft. It's a problem we do 
> have
> to partially solve, I think. A Link Construct may not be the best way 
> to do
> it, however.

I didn't know that, and didn't find the IRC log to be very transparent. 
  Perhaps someone could enlarge on next/prev being "cornerstones of the 
protocol"? -Tim



From owner-atom-syntax@mail.imc.org  Sat Jul 17 21:11: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 VAA20522
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 21:11:26 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6I10Zta028840;
	Sat, 17 Jul 2004 18:00: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 i6I10ZuW028839;
	Sat, 17 Jul 2004 18:00: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 i6I10Zfo028830
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 18:00:35 -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 esmtp (Exim 4.34)
	id 1Bm02i-0002kl-L5; Sun, 18 Jul 2004 01:00:40 +0000
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Sat, 17 Jul 2004 21:00:44 -0400
Subject: Re: On LinkTagMeaning...
From: Robert Sayre <mint@franklinmint.fm>
To: Tim Bray <Tim.Bray@Sun.COM>
CC: Arve Bersvendsen <arve@virtuelvis.com>, Atom Syntax <atom-syntax@imc.org>,
        Norman Walsh <ndw@nwalsh.com>
Message-ID: <BD1F43FC.13EFA%mint@franklinmint.fm>
In-Reply-To: <968F80B8-D853-11D8-92AF-000A95A51C9E@sun.com>
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: <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 7/17/04 8:44 PM, "Tim Bray" <Tim.Bray@Sun.COM> wrote:

> 
> On Jul 17, 2004, at 5:01 PM, Robert Sayre wrote:
> 
>> Unfortunately, prev/next/start are currently cornerstones of the
>> protocol.
>> This is _not obvious_ [1] from the current draft. It's a problem we do
>> have
>> to partially solve, I think. A Link Construct may not be the best way
>> to do
>> it, however.
> 
> I didn't know that, and didn't find the IRC log to be very transparent.
> Perhaps someone could enlarge on next/prev being "cornerstones of the
> protocol"? -Tim

Let me try again. The smell of dinner encouraged me to make that email very
brief.

Check this out for an implementation of the FeedURI:
http://www.xml.com/pub/a/2004/04/14/atomwiki.html?page=2

Basically, the FeedURI[2] is similar in appearance to the main feed of a
site. The difference would be that it's expected to be a dynamic resource.
It uses next/prev to send paging parameters (most likely to itself). As the
editor's note says:

"the [FeedURI representation also] replaces the search facet by having
'link' tags that point to other feeds using  well knows 'rel' attribute
values such as 'next' and 'prev' "

I'm not so hot on paging as a discovery mechanism for editing clients, but
it is one approach.

Robert Sayre

[1] 
http://www.ilrt.bris.ac.uk/discovery/chatlogs/atom/2004-06-29.html#T02-57-50

[2] 
http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-00.html#Feed
URI



From owner-atom-syntax@mail.imc.org  Sat Jul 17 21:33: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 VAA21589
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 21:33:25 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6I1NPQL033013;
	Sat, 17 Jul 2004 18:23:25 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6I1NPW0033011;
	Sat, 17 Jul 2004 18:23: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 (mproxy.gmail.com [216.239.56.242])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6I1NPf0032998
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 18:23:25 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so3972966cwc
        for <atom-syntax@imc.org>; Sat, 17 Jul 2004 18:23:29 -0700 (PDT)
Received: by 10.11.116.34 with SMTP id o34mr111634cwc;
        Sat, 17 Jul 2004 18:23:29 -0700 (PDT)
Message-ID: <3f1451f504071718231dd08561@mail.gmail.com>
Date: Sat, 17 Jul 2004 21:23:29 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Tim Bray <tim.bray@sun.com>
Subject: Re: On LinkTagMeaning...
Cc: Robert Sayre <mint@franklinmint.fm>,
        Arve Bersvendsen <arve@virtuelvis.com>,
        Atom Syntax <atom-syntax@imc.org>, Norman Walsh <ndw@nwalsh.com>
In-Reply-To: <968F80B8-D853-11D8-92AF-000A95A51C9E@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <BD1F362A.13EEE%mint@franklinmint.fm> <968F80B8-D853-11D8-92AF-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 Sat, 17 Jul 2004 17:44:12 -0700, Tim Bray <tim.bray@sun.com> wrote:
> On Jul 17, 2004, at 5:01 PM, Robert Sayre wrote:
> 
> > Unfortunately, prev/next/start are currently cornerstones of the
> > protocol.
> > This is _not obvious_ [1] from the current draft. It's a problem we do
> > have
> > to partially solve, I think. A Link Construct may not be the best way
> > to do
> > it, however.
> 
> I didn't know that, and didn't find the IRC log to be very transparent.
>   Perhaps someone could enlarge on next/prev being "cornerstones of the
> protocol"? -Tim

Each entry has an EditURI used for editing. GET on this
URI to fetch it, PUT an entry back to update it. 
The question is, how do you find out the EditURI of
the entry you want to edit in the first place?

The solution, as it stands today, is to use the FeedURI
which contains a list of N recent entries and in 
each entry is a pointer to the EditURI. Now this works
fine if you want to edit a recent entry, but what if you wanted
to go back further in time? That is what the 'prev' and 'next'
links are for, follow the 'next' URI and you get another atom
feed, in the same format as the FeedURI, but populated with
the next batch of N entries. It also contains yet another
'next' link.  You keep following 'next' links back in time 
until you get to the entry you want to edit. 

In the chatlog I make reference to a [2]
which is something that was a part of RESTLog,
and despite the poor usage of the term 'archive',
I would like to see brought into the Atom Publishing
Protocol. 

The problem with the 'next' and 'prev' links
is that the navigation is only linear. The format
I talk about in [2] allows for a more richly structured
browing of the archives where the depth and complexity
of the types of navigation is determined by the 
server.

A more detailed explaination of the 'next' and 
'prev' navigation as found in the -00 I-D is here[1]:

[1] http://webservices.xml.com/pub/a/ws/2004/02/03/atom8.html
[2] http://bitworking.org/news/Atom_Archive_Format


    Thanks,
    -joe

-- 
Joe Gregorio        http://bitworking.org



From owner-atom-syntax@mail.imc.org  Sat Jul 17 23:13:50 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25849
	for <atompub-archive@lists.ietf.org>; Sat, 17 Jul 2004 23:13:49 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6I32tGJ047814;
	Sat, 17 Jul 2004 20: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 i6I32t1g047813;
	Sat, 17 Jul 2004 20:02:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6I32ktL047716
	for <atom-syntax@imc.org>; Sat, 17 Jul 2004 20:02:50 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 18 Jul 2004 13:07:34 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sun, 18 Jul 2004 13:02:03 +1000
Subject: Re: On LinkTagMeaning...
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD20254B.20800%eric.scheid@ironclad.net.au>
In-Reply-To: <BD1F43FC.13EFA%mint@franklinmint.fm>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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 18/7/04 11:00 AM, "Robert Sayre" <mint@franklinmint.fm> wrote:

> Basically, the FeedURI[2] is similar in appearance to the main feed of a
> site. The difference would be that it's expected to be a dynamic resource.
> It uses next/prev to send paging parameters (most likely to itself). As the
> editor's note says:
> 
> "the [FeedURI representation also] replaces the search facet by having
> 'link' tags that point to other feeds using  well known 'rel' attribute
> values such as 'next' and 'prev' "
> 
> I'm not so hot on paging as a discovery mechanism for editing clients, but
> it is one approach.

perhaps these should be "service.next" and "service.prev" then?

would "service.index" be another mechanism ... a single SSFF feed with
"service.edit" links?

e.



From owner-atom-syntax@mail.imc.org  Sun Jul 18 03:18: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 DAA20848
	for <atompub-archive@lists.ietf.org>; Sun, 18 Jul 2004 03:18: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 i6I73EIg022543;
	Sun, 18 Jul 2004 00:03:15 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6I73E0t022542;
	Sun, 18 Jul 2004 00:03:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from homer.w3.org (homer.w3.org [18.29.0.30])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6I73DcD022520
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 00:03:14 -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 0F9E94F061;
	Sun, 18 Jul 2004 03:03:10 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040717113049.056ea330@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Sat, 17 Jul 2004 11:40:21 +0900
To: Bill de =?ISO-2022-JP?B?aBskQiViGyhCcmE=?= <bill@dehora.net>,
        Norman Walsh <ndw@nwalsh.com>
From: Martin Duerst <duerst@w3.org>
Subject: Re: Low-hanging fruit: compulsory namespaces
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <40F8417E.9020104@dehora.net>
References: <87smbrpuod.fsf@nwalsh.com>
 <6D6BAC41-D517-11D8-8C42-000A95A51C9E@sun.com>
 <40F46DAC.3030900@dehora.net>
 <D4AC57AE-D527-11D8-A503-000A95A51C9E@sun.com>
 <40F48A82.2020408@dehora.net>
 <3F81CFBF-D59D-11D8-A6EC-000A95A51C9E@sun.com>
 <40F5415E.5070100@dehora.net>
 <87k6x6mwef.fsf@nwalsh.com>
 <40F55860.7000800@dehora.net>
 <87d62w5brt.fsf@nwalsh.com>
 <40F7DC76.5050508@dehora.net>
 <87smbrpuod.fsf@nwalsh.com>
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: <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


Hello Bill,

I think what you are saying is that there is no place in the namespace
REC that explicitly says that no-ns in line 3 is in no namespace, and
that therefore, you can put it in any namespace. But then the question
would be: but in which one? For example, both

  0   <outer xmlns="http://foo.example.org/">
  1   <atom:feed xmlns:atom="http://example.org/atom">
  2     <atom:content mode="xml">
  3       <no-ns xmlns="">Non-namespaced element</no-ns>
  4     </atom:content>
  5   </atom:feed>
  6   </outer>

and

  0   <outer xmlns="http://bar.example.org/">
  1   <atom:feed xmlns:atom="http://example.org/atom">
  2     <atom:content mode="xml">
  3       <no-ns xmlns="">Non-namespaced element</no-ns>
  4     </atom:content>
  5   </atom:feed>
  6   </outer>

would be legal according to that interpretation of the namespace REC.
But this would clearly lead to a contradiction, so transformations
of the above type can't possibly be legal according to the
namespace REC.

I think that you are probably right that it's rather difficult to
understand that from the namespace REC itself. It may be worth
looking at adding something like (just a draft):

"Note: elements without prefixes and not within the scope of a default
namespace declaration are in no namespace. Elements in no namespace
are different from elements with the same local name in any existing
namespace."

Norm, can I ask you as the co-chair of the XML Core WG to forward
this issue to the XML Core WG? Thanks!

Regards,    Martin.

At 21:58 04/07/16 +0100, Bill de h$B%b(Bra wrote:

>Norman Walsh wrote:
>
>
>>I'm still confused. That's a different document.
>
>I said elsewhere that we should expect that our XML will get embedded. I 
>claim that your rule 1. must *always* apply - saying it doesn't apply is 
>seems only useful for the local case and is not robust.
>
>
>>Are you asking me
>>what that document means, or are you saying that you have a tool that
>>produced that document from mine?
>
>Neither. I'm  saying I've seen this kind of markup in the wild in the same 
>way I've seen application libraries emit malformed XML in the wild. It 
>tends to gravitate around "envelope-oriented" markup. I have my suspicions 
>as to why but don't care to generalize.
>
>
>>If you have an XML tool and you took my document (lines 1-5) and
>>dropped it into your document (between the "outer" tags) and the
>>result you got back is shown above, your tool is broken. Your tool was
>>required, [...]
>
>How is it required? I do not see an entailment from your 3 point 
>interpretation of namespaces to this bug. I keep going back to them and 
>reading them, but it just doesn't follow. And please stop saying "your 
>tool". I did not raise tools as being the issue here.
>
>>Does that help?
>
>I guess not. People keep telling me it's a bug, but not why it's a bug. In 
>any case I've already signed up "it's a bug" view. But I will call it a 
>consensus view only. My point/question has always been whether this is 
>something that is *specified* somewhere. However many days into this 
>thread, I'm still not seeing that specification.
>
>We're way off topic by now. I was looking for a few sentences in the spec 
>to clear things up, sentences that I believe are deeply 
>uncontroversial,  but people seem to be violently against saying anything 
>direct on the matter. I'm more than happy to drop it and move on.
>
>cheers
>Bill



From owner-atom-syntax@mail.imc.org  Sun Jul 18 04:13: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 EAA23702
	for <atompub-archive@lists.ietf.org>; Sun, 18 Jul 2004 04:13: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 i6I80P8d046795;
	Sun, 18 Jul 2004 01:00: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 i6I80PYW046793;
	Sun, 18 Jul 2004 01:00:25 -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 i6I80NN2046757
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 01:00:24 -0700 (PDT)
	(envelope-from davep@dpawson.co.uk)
Received: (qmail 15375 invoked from network); 18 Jul 2004 08:21: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; 18 Jul 2004 08:21:06 -0000
Subject: Re: On LinkTagMeaning...
From: Dave Pawson <davep@dpawson.co.uk>
Reply-To: davep@dpawson.co.uk
To: atom-syntax@imc.org
In-Reply-To: <3f1451f504071718231dd08561@mail.gmail.com>
References: <BD1F362A.13EEE%mint@franklinmint.fm>
	 <968F80B8-D853-11D8-92AF-000A95A51C9E@sun.com>
	 <3f1451f504071718231dd08561@mail.gmail.com>
Content-Type: text/plain
Message-Id: <1090137602.2018.28.camel@homer>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) 
Date: Sun, 18 Jul 2004 09:00:02 +0100
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 Sun, 2004-07-18 at 02:23, Joe Gregorio wrote:

> The solution, as it stands today, is to use the FeedURI
> which contains a list of N recent entries and in 
> each entry is a pointer to the EditURI. Now this works
> fine if you want to edit a recent entry, but what if you wanted
> to go back further in time? That is what the 'prev' and 'next'
> links are for, follow the 'next' URI and you get another atom
> feed, in the same format as the FeedURI, but populated with
> the next batch of N entries. It also contains yet another
> 'next' link.  You keep following 'next' links back in time 
> until you get to the entry you want to edit. 
<snip/>

> 
> The problem with the 'next' and 'prev' links
> is that the navigation is only linear. The format
> I talk about in [2] allows for a more richly structured
> browing of the archives where the depth and complexity
> of the types of navigation is determined by the 
> server.

I can see the issue you are working at Joe, I'm less sure its 
open to a standard approach. For the chatty publisher the structure
could be long and deep. For the occasional publisher it could be
simply linear. Do you think it right that atom force you into
structuring your documents in a fixed way?
  Seems wrong to me.
The previous next idea meets the need, if somewhat laborious.

Can you propose something to improve on Norms idea without
introducing additional complexity?
  The edit approach seems to me like an application domain issue,
with the publishing side needing to support it, but I'd hope that
it won't start to constrain it too much.

Norms approach seems to capture the needs I've heard so far?

-- 
Regards DaveP.
XSLT&Docbook  FAQ
http://www.dpawson.co.uk/xsl




From owner-atom-syntax@mail.imc.org  Sun Jul 18 05:59: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 FAA29223
	for <atompub-archive@lists.ietf.org>; Sun, 18 Jul 2004 05: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 i6I9iXCT087823;
	Sun, 18 Jul 2004 02:44: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 i6I9iWcv087822;
	Sun, 18 Jul 2004 02:44: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 i6I9iW8M087812
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 02:44:32 -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 7B7644F000;
	Sun, 18 Jul 2004 05:44:31 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040718184256.05707008@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Sun, 18 Jul 2004 18:44:24 +0900
To: kwark.1511609@bloglines.com, joe.gregorio@gmail.com
From: Martin Duerst <duerst@w3.org>
Subject: Re: PacePutDelete Withdrawn
Cc: atom-syntax@imc.org
In-Reply-To: <1090007990.1602124828.29296.sendItem@bloglines.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 19:59 04/07/16 +0000, kwark.1511609@bloglines.com wrote:

>HTTP-over-WSP connectivity is the standard for mobile 2G networks
>(f.e. GSM-CSD).

This is an overstatement. I'm not at all an expert in this area,
but I know for sure that most Japanese phones (2G or otherwise)
don't use WAP at all. And there are lots of mobile phones with
HTTP and HTML support in Japan.

Regards,     Martin.


>2.5 G (GPRS, EDGE) and 3G support native TCP/IP.



From owner-atom-syntax@mail.imc.org  Sun Jul 18 06: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 GAA01722
	for <atompub-archive@lists.ietf.org>; Sun, 18 Jul 2004 06:34: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 i6IAMuAP004612;
	Sun, 18 Jul 2004 03:22: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 i6IAMu4R004611;
	Sun, 18 Jul 2004 03:22:56 -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 i6IAMtrX004589
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 03:22:55 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Received: from mail.online.no (ti132110a080-3373.bb.online.no [80.212.221.45])
	by mail58.fg.online.no (8.12.11/8.12.11) with ESMTP id i6IAMrHc022341;
	Sun, 18 Jul 2004 12:22:54 +0200 (MEST)
To: "Tim Bray" <Tim.Bray@sun.com>, Atom-syntax <atom-syntax@imc.org>
Subject: Re: On LinkTagMeaning...
References: <87k6x2l3pj.fsf@nwalsh.com> <opsbazhqq76dxgxk@mail.online.no> <3026FE15-D844-11D8-92AF-000A95A51C9E@sun.com>
Message-ID: <opsbbwf7vj6dxgxk@mail.online.no>
Date: Sun, 18 Jul 2004 12:22:45 +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: <3026FE15-D844-11D8-92AF-000A95A51C9E@sun.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, 17 Jul 2004 15:53:58 -0700, Tim Bray <Tim.Bray@Sun.COM> wrote:

> On the contrary.  There is no body of practice that proves we know how  
> to solve the problem, and this group should not be in the business of  
> speculative invention of new technologies.

What about use of existing technologies?

Threading is a problem that has been discussed extensively elsewhere.

<URL: http://www.threadsml.org/ >
<URL: http://www.eyrie.org/~zednenem/2002/web-threads/tdl3.html >
<URL:  
http://dublincore.org/documents/2000/07/11/dcmes-qualifiers/#relation >

All of these resources would seem to cover most of what is needed from  
'threading' (sans some of the html @rel/@rev values).Dublin Core relation  
also seems to cover a simple revisioning mechanism

-- 
Arve Bersvendsen

http://www.virtuelvis.com
http://www.bersvendsen.com



From owner-atom-syntax@mail.imc.org  Sun Jul 18 07:55: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 HAA04471
	for <atompub-archive@lists.ietf.org>; Sun, 18 Jul 2004 07: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 i6IBlpwU019047;
	Sun, 18 Jul 2004 04:47: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 i6IBlpXS019046;
	Sun, 18 Jul 2004 04:47: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 (mproxy.gmail.com [216.239.56.240])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6IBloOL019029
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 04:47:50 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so4395690cwc
        for <atom-syntax@imc.org>; Sun, 18 Jul 2004 04:47:47 -0700 (PDT)
Received: by 10.11.99.40 with SMTP id w40mr286712cwb;
        Sun, 18 Jul 2004 04:47:47 -0700 (PDT)
Message-ID: <3f1451f5040718044768a3f02a@mail.gmail.com>
Date: Sun, 18 Jul 2004 07:47:47 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: davep@dpawson.co.uk
Subject: Re: On LinkTagMeaning...
Cc: atom-syntax@imc.org
In-Reply-To: <1090137602.2018.28.camel@homer>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <BD1F362A.13EEE%mint@franklinmint.fm>
	 <968F80B8-D853-11D8-92AF-000A95A51C9E@sun.com>
	 <3f1451f504071718231dd08561@mail.gmail.com> <1090137602.2018.28.camel@homer>
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, 18 Jul 2004 09:00:02 +0100, Dave Pawson <davep@dpawson.co.uk> wrote: 
> I can see the issue you are working at Joe, I'm less sure its
> open to a standard approach. For the chatty publisher the structure
> could be long and deep. For the occasional publisher it could be
> simply linear. Do you think it right that atom force you into
> structuring your documents in a fixed way?

Not quite sure what you mean by that. If publishers
only want to support a 'prev-next' type of navigation
they can do that in my proposal. Here is some more 
detail on how the format can be used:

http://www.imc.org/atom-syntax/mail-archive/msg00763.html

>   Seems wrong to me.
> The previous next idea meets the need, if somewhat laborious.
> 
> Can you propose something to improve on Norms idea without
> introducing additional complexity?

Norm is only proposing changes in the names of
the elements/attributes, which is orthogonal
to what I am talking about here. If you go back
an re-read the thread you can see how we drifted. 

    Thanks,
    -joe

-- 
Joe Gregorio        http://bitworking.org



From owner-atom-syntax@mail.imc.org  Sun Jul 18 07:55: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 HAA04505
	for <atompub-archive@lists.ietf.org>; Sun, 18 Jul 2004 07:55: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 i6IBjADp018776;
	Sun, 18 Jul 2004 04: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 i6IBjAgq018775;
	Sun, 18 Jul 2004 04:45:10 -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 i6IBj9O8018761
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 04:45:09 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 55846 messnum 254487 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 18 Jul 2004 11:45:04 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail09.svc.cra.dublin.eircom.net (qp 55846) with SMTP; 18 Jul 2004 11:45:04 -0000
Message-ID: <40FA62BB.7070107@dehora.net>
Date: Sun, 18 Jul 2004 12:44:59 +0100
From: =?UTF-8?B?QmlsbCBkZSBow5NyYQ==?= <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: Martin Duerst <duerst@w3.org>
CC: Norman Walsh <ndw@nwalsh.com>, Atom Syntax <atom-syntax@imc.org>
Subject: Re: Low-hanging fruit: compulsory namespaces
References: <87smbrpuod.fsf@nwalsh.com> <6D6BAC41-D517-11D8-8C42-000A95A51C9E@sun.com> <40F46DAC.3030900@dehora.net> <D4AC57AE-D527-11D8-A503-000A95A51C9E@sun.com> <40F48A82.2020408@dehora.net> <3F81CFBF-D59D-11D8-A6EC-000A95A51C9E@sun.com> <40F5415E.5070100@dehora.net> <87k6x6mwef.fsf@nwalsh.com> <40F55860.7000800@dehora.net> <87d62w5brt.fsf@nwalsh.com> <40F7DC76.5050508@dehora.net> <87smbrpuod.fsf@nwalsh.com> <4.2.0.58.J.20040717113049.056ea330@localhost>
In-Reply-To: <4.2.0.58.J.20040717113049.056ea330@localhost>
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


Martin Duerst wrote:
> Hello Bill,
> 
> I think what you are saying is that there is no place in the namespace
> REC that explicitly says that no-ns in line 3 is in no namespace, and
> that therefore, you can put it in any namespace. But then the question
> would be: but in which one? For example, both
> 
>  0   <outer xmlns="http://foo.example.org/">
>  1   <atom:feed xmlns:atom="http://example.org/atom">
>  2     <atom:content mode="xml">
>  3       <no-ns xmlns="">Non-namespaced element</no-ns>
>  4     </atom:content>
>  5   </atom:feed>
>  6   </outer>
> 
> and
> 
>  0   <outer xmlns="http://bar.example.org/">
>  1   <atom:feed xmlns:atom="http://example.org/atom">
>  2     <atom:content mode="xml">
>  3       <no-ns xmlns="">Non-namespaced element</no-ns>
>  4     </atom:content>
>  5   </atom:feed>
>  6   </outer>

Martin.

Those look the same... was one of the <no-ns xmlns=""> lines meant 
to be different or not there?


> would be legal according to that interpretation of the namespace REC.
> But this would clearly lead to a contradiction, so transformations
> of the above type can't possibly be legal according to the
> namespace REC.
 >
> I think that you are probably right that it's rather difficult to
> understand that from the namespace REC itself. It may be worth
> looking at adding something like (just a draft):

You see, I think they can be legal. The fact that you/I/we think 
something  leads to a contradiction or doing so would just be silly 
doesn't imply it can't be possibly be legal. I claim the 
contradiction is the case and that it should be addressed with 
normative text; ie the bug is that the spec's 'axioms' are 
inconsistent/incomplete. To get around it I have to add extra 
information (a sense of silliness in one case, xmlns="" shrouding by 
default in another, or some other extra-interpretation) My position 
was to do that in the Atom spec, because it is something I might 
have sway over.


> "Note: elements without prefixes and not within the scope of a default
> namespace declaration are in no namespace. Elements in no namespace
> are different from elements with the same local name in any existing
> namespace."

And yet - more interpretation is needed to make sense of how that 
should apply, so imo we haven't gotten anywhere. The problem occurs 
when an element that is not in a namespace is embedded in markup 
that has a default namespace. The scoping rules are incomplete for 
this case and the text above doesn't change that - how shall we 
*make* them different?

cheers
Bill



From owner-atom-syntax@mail.imc.org  Sun Jul 18 11:52: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 LAA16090
	for <atompub-archive@lists.ietf.org>; Sun, 18 Jul 2004 11:52: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 i6IFddwq050574;
	Sun, 18 Jul 2004 08:39: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 i6IFddts050573;
	Sun, 18 Jul 2004 08:39:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from w02.bloglines.com (w02.bloglines.com [216.148.212.184])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6IFdcZW050564
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 08:39:38 -0700 (PDT)
	(envelope-from kwark.1511609@bloglines.com)
Received: (qmail 17780 invoked by uid 99); 18 Jul 2004 15:39:37 -0000
Message-ID: <1090165177.2738485554.17777.sendItem@bloglines.com>
Date: 18 Jul 2004 15:39:37 -0000
From: kwark.1511609@bloglines.com
To: duerst@w3.org
CC: atom-syntax@imc.org
Subject: Re: PacePutDelete Withdrawn
MIME-Version: 1.0
Content-Type: text/plain
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


--- Martin Duerst <duerst@w3.org wrote:

> >HTTP-over-WSP connectivity is
the standard for mobile 2G networks
> >(f.e. GSM-CSD).
> 
> This is an
overstatement. I'm not at all an expert in this area,

You are right, it
is an overstatement.

> but I know for sure that most Japanese phones (2G
or otherwise) don't use WAP at all. 

You're right. In Japan NTT Docomo
uses iMode, a packet oriented network, which also uses a gateway.
Since I
really am not an iMode expert, I asked Google for some advice. 
It looks
like Japan's largest operator NTT Docomo uses a gateway developed by Nec [1].

An older article describes iMode's technical architecture [2]. I find the
following section on HTTP interesting:

"The microbrowser sits on top of
a protocol named Application Layer Protocol (ALP), developed by DoCoMo as
the mobile client-side version of standard HTTP. The conversion between HTTP
and ALP is transparent to the subscriber and to the sending Web server. It
reduces client burden by removing HTTP header data (which is not needed by
the Mobile Station), instituting a termination notification signal and converting
SMTP mail text to cHTML format."

Unfortunately it does not say which HTTP
methods are required and/or supported. Any iMode expert present willing to
elaborate/investigate?

> And there are lots of mobile phones with
> HTTP
and HTML support in Japan.

Yep, and in other parts of the world too. Mobile
networks and application environments are heterogenous. Most network operators
introduce a gateway between their mobile network and the Internet and these
gateways possibly have limitations for full REST support.

Eventually, mobile
applications will have full REST support. Efforts like Atom could even accelerate
REST adoption in the mobile space.

I would personally love to have the
Nokia people on this list to pressure their MIDP departement, to change their
MIDP implementation to support full REST when possible. I would love it even
more, if this would be available as a firmware upgrade for my Nokia 3650.
I would be in heaven if Nokia provided a way for me to upgrade my firmware
via the Internet and a PC connection or even directly from my mobile. Currently
I have to go to my local Nokia service center to get my phone flashed for
firmware upgrades.

I'm realistic enough to realize that I don't have any
influence on Nokia's business decisions and that this probably won't happen
anytime soon.

I'm willing to do some leg work to examine Atom's feasability
for my geographical area (Europe) and preferred client platform (MIDP). 
It's definately not a niche market for Atom and this WG should be aware of
its limitations to make informed decisions.

Regards,

Peter
 
[1] http://www.3g.co.uk/PR/May2003/5334.htm

[2] http://www.awprofessional.com/articles/article.asp?p=27009



From owner-atom-syntax@mail.imc.org  Sun Jul 18 12:17:13 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17493
	for <atompub-archive@lists.ietf.org>; Sun, 18 Jul 2004 12:17: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 i6IGADfm055971;
	Sun, 18 Jul 2004 09:10: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 i6IGAD4Q055970;
	Sun, 18 Jul 2004 09:10:13 -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 i6IGAChl055930
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 09:10:12 -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 i6IGA753022861
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 11:10:07 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6IGA6L7022856;
	Sun, 18 Jul 2004 11:10:06 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: atom-syntax@imc.org
Subject: Re: PaceServiceElement - what Bill said
References: <BD1F55FC.20632%eric.scheid@ironclad.net.au>
	<1090067950.2019.41.camel@homer> <m3eknag0d0.fsf@bitsko.slc.ut.us>
	<40F94997.8070507@dehora.net>
	<558EC476-D80B-11D8-92AF-000A95A51C9E@sun.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 18 Jul 2004 11:10:06 -0500
In-Reply-To: <558EC476-D80B-11D8-92AF-000A95A51C9E@sun.com>
Message-ID: <m33c3pfg9t.fsf@bitsko.slc.ut.us>
Lines: 32
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 i6IGAChl055957
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 <Tim.Bray@Sun.COM> writes:

> On Jul 17, 2004, at 8:45 AM, Bill de hÓra wrote:
> 
> > If we keep going done this road we are going end up defining an
> > ad-hoc type system for Atom's use of URIs. In my humble opinion
> > that's a tarpit we want to stay well away from.
> 
> +1
> 
> Furthermore, on the evidence we significantly lack expertise in
> building type systems.

I'm ok with ditching link type markup in the general case and relying
on the link name to be defined concretely in terms of both meaning and
usage pattern (class/type).

  <qname uri="URI"/>  or <qname>URI</qname>

Regarding the one link type that people seem most interested in being
both extensible and discoverable ("a link that is intended primarily
for presentation to a human user"[1]), maybe we can get some more
examples of extension link names where that discoverability would be
useful.  Mark Pilgrim's foray into b-link markup would be one example,
if those link names were in extensions and not the core.

Graham and Dare have indicated, if I read correctly, that they would
not implement such a feature in their aggregators, however.

  -- Ken

[1] http://dubinko.info/writing/skunklink/



From owner-atom-syntax@mail.imc.org  Sun Jul 18 12:17: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 MAA17534
	for <atompub-archive@lists.ietf.org>; Sun, 18 Jul 2004 12:17: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 i6IG9WX4055791;
	Sun, 18 Jul 2004 09:09:32 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6IG9W6I055790;
	Sun, 18 Jul 2004 09:09:32 -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 i6IG9VFr055762
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 09:09:31 -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 i6IG7N53006937
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 10:07:23 -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 <0I120069T27X6S@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sun, 18 Jul 2004 10:09:34 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.45])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I1200CJE27XE1@mail.sun.net> for atom-syntax@imc.org; Sun,
 18 Jul 2004 10:09:33 -0600 (MDT)
Date: Sun, 18 Jul 2004 09:09:40 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PacePutDelete Withdrawn
In-reply-to: <1090165177.2738485554.17777.sendItem@bloglines.com>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <DFBF4C9F-D8D4-11D8-92AF-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: <1090165177.2738485554.17777.sendItem@bloglines.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


It dawns on me that there is another popular application platform with 
support for GET and POST but not PUT nor DELETE.  That would be a Web 
Browser.  Thus, if the full capabilities of Atom were available using 
only GET and POST I would be able to do a full client implementation as 
a set of HTML pages with no reliance on server-side scripts, right?  
Given that the browser is becoming a locus of innovation again (see 
Apache, WHAT-WG) this seems potentially quite significant. -Tim



From owner-atom-syntax@mail.imc.org  Sun Jul 18 12:31: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 MAA17906
	for <atompub-archive@lists.ietf.org>; Sun, 18 Jul 2004 12: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 i6IGMkuQ058235;
	Sun, 18 Jul 2004 09: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 i6IGMkDp058234;
	Sun, 18 Jul 2004 09:22:46 -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 i6IGMkNw058204
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 09:22:46 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040718162244.91491.qmail@web41208.mail.yahoo.com>
Received: from [24.19.154.247] by web41208.mail.yahoo.com via HTTP; Sun, 18 Jul 2004 09:22:44 PDT
Date: Sun, 18 Jul 2004 09:22:44 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: On LinkTagMeaning...
To: Arve Bersvendsen <arve@virtuelvis.com>, Tim Bray <Tim.Bray@sun.com>,
        Atom-syntax <atom-syntax@imc.org>
In-Reply-To: <opsbbwf7vj6dxgxk@mail.online.no>
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>


--- Arve Bersvendsen <arve@virtuelvis.com> wrote:
> 
> Threading is a problem that has been discussed
> extensively elsewhere.
> 
> <URL: http://www.threadsml.org/ >
> <URL:
>
http://www.eyrie.org/~zednenem/2002/web-threads/tdl3.html
> >
> <URL:  
>
http://dublincore.org/documents/2000/07/11/dcmes-qualifiers/#relation
> >

I am unaware of any sites or aggregators that support
any of the aforementioned threading specs. Can anyone
point to any aggregators that support any of these
specs? Or point to more than one site that uses them? 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
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  Sun Jul 18 12:45: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 MAA18630
	for <atompub-archive@lists.ietf.org>; Sun, 18 Jul 2004 12:45: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 i6IGbicY060718;
	Sun, 18 Jul 2004 09:37: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 i6IGbiq1060717;
	Sun, 18 Jul 2004 09:37:44 -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 i6IGbiQp060628
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 09:37:44 -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 i6IGbZ409546
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 09:37:40 -0700 (PDT)
Received: from aol.net ([10.169.192.58]) by judge.mcom.com
          (Netscape Messaging Server 4.15) with ESMTP id I123IM03.20P;
          Sun, 18 Jul 2004 09:37:34 -0700 
Message-ID: <40FAA6D3.30701@aol.net>
Date: Sun, 18 Jul 2004 09:35:31 -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: Robert Sayre <mint@franklinmint.fm>
CC: kwark.1511609@bloglines.com, joe.gregorio@gmail.com,
        Atom Syntax <atom-syntax@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD1DDB85.13D53%mint@franklinmint.fm>
In-Reply-To: <BD1DDB85.13D53%mint@franklinmint.fm>
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


Robert Sayre wrote:

>On 7/16/04 3:59 PM, "kwark.1511609@bloglines.com"
><kwark.1511609@bloglines.com> wrote:
>  
>
> ...
>
>It would appear that the most convenient approach for J2ME applications
>would be a request header in combination with POST. SOAP would be workable
>as well, but updates of binary resources would be a problem.
>
>  
>
Is an X-ATOM-xxx HTTP request header a reasonable 90% solution?  This 
would work for both Atom XML and binary resources, is implementable even 
by CGI scripts on the server side, and I'm guessing has a nice simple 
specification (if present, overrides the HTTP method used in the 
original request).

>- Flash
>Flash MX 2004 / FlashPlayer 7 has SOAP support, and I'm pretty sure there's
>nothing interesting you could send as binary with Flash. Headers are also
>out, I think. The wiki mentions the XMLSocket object, which does let you
>send anything over a socket (not just XML). It's restricted to the same host
>and ports above 1024. Other Flash objects allow transmission of XML to port
>80 on the same host. The LoadMovie() function allows loading of SWFs and
>JPGs (JPGs in Flash6) from other hosts.
>
>SOAP would appear to be the best bet here.
>
>Note: I have written tons of ActionScript, but most of it was targeted at
>Flash 5.
>  
>
We've used XML documents (non-SOAP) with Flash fairly successfully in a 
number of applications, for both reading and for posting (just GET and 
POST, though).  Not sure what underlying objects/libraries are being 
used, though I could find out if there is interest. 

It is possible to get around the same-host security restrictions via 
"crossdomain.xml" files placed at the root of the Atom server.  If a 
domain is listed in this file, Flash .swf files originally loaded from 
that domain are allowed to at least GET/POST to/from the Atom server.

Most of the time, Flash .swfs are served up from either the same host or 
well-known partner hosts, so a static crossdomain.xml file works.  There 
are some annoying differences between Flash 5/ Flash 6 w.r.t. security 
but I can't remember what they are at the moment.

-John Panzer

Example /crossdomain.xml:

<cross-domain-policy>
<allow-access-from domain="*.aol.com"/>
<allow-access-from domain="channelevents.aol.com"/>
<allow-access-from domain="*.channel.aol.com"/>
</cross-domain-policy>



From owner-atom-syntax@mail.imc.org  Sun Jul 18 12:46: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 MAA18721
	for <atompub-archive@lists.ietf.org>; Sun, 18 Jul 2004 12: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 i6IGcFjG061192;
	Sun, 18 Jul 2004 09: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 i6IGcFfi061190;
	Sun, 18 Jul 2004 09:38:15 -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 i6IGcELL061156
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 09:38: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 i6IGcC53023224
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 11:38:12 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6IGcC6L023220;
	Sun, 18 Jul 2004 11:38:12 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceServiceElement created
References: <BD1F55FC.20632%eric.scheid@ironclad.net.au>
	<40F93C0A.5000306@intertwingly.net>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 18 Jul 2004 11:38:12 -0500
In-Reply-To: <40F93C0A.5000306@intertwingly.net>
Message-ID: <m3smbpe0ej.fsf@bitsko.slc.ut.us>
Lines: 40
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 i6IGcFLL061185
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


Sam Ruby <rubys@intertwingly.net> writes:

> Let's focus for a moment on an entry.  Likely to be contained within
> an entry are [links for] post, edit, and delete.  I will note that
> in many cases, the same uri is likely to be shared across these
> services.
> 
> This suggests an optimization:
> 
>    <atom:service name='post edit delete' uri="..." />

Note here that 'edit' has a meaning whose implementation uses HTTP's
GET, PUT, and DELETE.  'edit' really means "this URI is actionable for
editing entries in the way an Atom implementation should expect", it's
not merely an alias for multiple HTTP methods.

> Two variations come to mind.  One is that the name post and delete
> correspond to the HTTP method, but that edit does not... this
> association could be strengthened by changing the name of the
> attribute, and in this one particular case, the value, thus:
> 
>    <atom:service method='post put delete' uri="..." />

HTTP's POST method has a different meaning from Atom's 'post' service,
Atom's definition of 'post' is a lot more narrow than HTTP's.  It is
possible, for example, that new Atom service links will be defined
that may also use HTTP's POST but not be used for creating new
entries.

Conclusion: HTTP method names are not sufficient to derive "meaning"
or "usage" as a replacement of specific link names.

Bill de hÓra writes:
> Incidently, the act of eumerating the allowed methods/operations
> over a URI is what the link discussion should be focusing on.

Agreed.  The allowed methods/operations over a URI are part of the
definition of the link name.

  -- Ken



From owner-atom-syntax@mail.imc.org  Sun Jul 18 12:48:34 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18923
	for <atompub-archive@lists.ietf.org>; Sun, 18 Jul 2004 12: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 i6IGdVpj061488;
	Sun, 18 Jul 2004 09: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 i6IGdVfm061487;
	Sun, 18 Jul 2004 09:39: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 (mproxy.gmail.com [216.239.56.252])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6IGdVrB061473
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 09:39:31 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so4513183cwc
        for <atom-syntax@imc.org>; Sun, 18 Jul 2004 09:39:31 -0700 (PDT)
Received: by 10.11.99.11 with SMTP id w11mr133395cwb;
        Sun, 18 Jul 2004 09:39:31 -0700 (PDT)
Message-ID: <3f1451f504071809394e1476fe@mail.gmail.com>
Date: Sun, 18 Jul 2004 12:39:31 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Tim Bray <tim.bray@sun.com>
Subject: Re: PacePutDelete Withdrawn
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <DFBF4C9F-D8D4-11D8-92AF-000A95A51C9E@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <1090165177.2738485554.17777.sendItem@bloglines.com> <DFBF4C9F-D8D4-11D8-92AF-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 Sun, 18 Jul 2004 09:09:40 -0700, Tim Bray <tim.bray@sun.com> wrote:
> 
> It dawns on me that there is another popular application platform with
> support for GET and POST but not PUT nor DELETE.  That would be a Web
> Browser.  Thus, if the full capabilities of Atom were available using
> only GET and POST I would be able to do a full client implementation as
> a set of HTML pages with no reliance on server-side scripts, right?
> Given that the browser is becoming a locus of innovation again (see
> Apache, WHAT-WG) this seems potentially quite significant. -Tim

How, exactly, would you POST XML via a web page?

HTTP web pages only support GET and POST of content of the form
x-www-form-urlencoded. 

XForms supports XML and PUT but not DELETE, though there
might be vendor extensions for all HTTP methods. Also,  
at this point XForms has a tiny market share.

If you are going to use JavaScript then both IE and Mozilla
based browsers have extensions that support full
HTTP including all the methods.

    -joe

-- 
Joe Gregorio        http://bitworking.org



From owner-atom-syntax@mail.imc.org  Sun Jul 18 12:51: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 MAA19529
	for <atompub-archive@lists.ietf.org>; Sun, 18 Jul 2004 12:51: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 i6IGiFpL062103;
	Sun, 18 Jul 2004 09:44:15 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6IGiF4u062102;
	Sun, 18 Jul 2004 09:44:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6IGiFK3062087
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 09:44:15 -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 esmtp (Exim 4.34)
	id 1BmElp-0008Cs-Mk; Sun, 18 Jul 2004 16:44:14 +0000
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Sun, 18 Jul 2004 12:44:19 -0400
Subject: Re: PacePutDelete Withdrawn
From: Robert Sayre <mint@franklinmint.fm>
To: Tim Bray <Tim.Bray@Sun.COM>, Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD202123.13F3F%mint@franklinmint.fm>
In-Reply-To: <DFBF4C9F-D8D4-11D8-92AF-000A95A51C9E@sun.com>
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: <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 7/18/04 12:09 PM, "Tim Bray" <Tim.Bray@Sun.COM> wrote:

> 
> It dawns on me that there is another popular application platform with
> support for GET and POST but not PUT nor DELETE.  That would be a Web
> Browser.  Thus, if the full capabilities of Atom were available using
> only GET and POST I would be able to do a full client implementation as
> a set of HTML pages with no reliance on server-side scripts, right?

The data would be sent as "application/x-www-form-urlencoded". In the
archives, you can find an email from Jason Diamond catching me forgetting
this. So I think this would be a separate gateway, one that most blogging
software already has.

 
> Given that the browser is becoming a locus of innovation again (see
> Apache, WHAT-WG) this seems potentially quite significant. -Tim

WHAT-WG is going to have PUT/DELETE capability for forms.

Also, you could build a ReST Atom client in javascript, using the XMLHTTP
object. This code would work in IE6 and recent versions of Mozilla. Safari
also has XMLHTTP support scheduled. It's one of those de-facto IE standards
that is actually pretty good.

Robert Sayre



From owner-atom-syntax@mail.imc.org  Sun Jul 18 12: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 MAA19920
	for <atompub-archive@lists.ietf.org>; Sun, 18 Jul 2004 12: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 i6IGhScA062022;
	Sun, 18 Jul 2004 09:43: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 i6IGhSn5062021;
	Sun, 18 Jul 2004 09:43:28 -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 i6IGhR4n062003
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 09:43:28 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Received: from mail.online.no (ti132110a080-3373.bb.online.no [80.212.221.45])
	by mail58.fg.online.no (8.12.11/8.12.11) with ESMTP id i6IGhPLZ020972;
	Sun, 18 Jul 2004 18:43:25 +0200 (MEST)
To: "Dare Obasanjo" <kpako@yahoo.com>, Atom-syntax <atom-syntax@imc.org>
Subject: Re: On LinkTagMeaning...
References: <20040718162244.91491.qmail@web41208.mail.yahoo.com>
Message-ID: <opsbcd2jnb6dxgxk@mail.online.no>
Date: Sun, 18 Jul 2004 18:43:21 +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: <20040718162244.91491.qmail@web41208.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 Sun, 18 Jul 2004 09:22:44 -0700 (PDT), Dare Obasanjo <kpako@yahoo.com>  
wrote:

> I am unaware of any sites or aggregators that support
> any of the aforementioned threading specs. Can anyone
> point to any aggregators that support any of these
> specs? Or point to more than one site that uses them?

This is a chicken-and-egg problem: No feeds use these mechanisms because  
no aggregator supports them, and no aggregator supports them because no  
feeds use them.

There are however newsfeeds that would benefit from this. Examples that  
come to mind:

- Phil Ringnaldas blog does threaded comments;  
http://www.philringnalda.com/
- A threading plugin exists for Movable Type.  
http://mt-plugins.org/archives/entry/threadedcomments.php
- Postnuke/PHPNuke does threading. Probably a bunch of other CMSes as well.
- The new Google Groups 2 beta has atom feeds. See  
http://groups-beta.google.com/group/comp.lang.python/feeds for an example.

So, _people_ and _software_ do threading, but Atom has no way of  
expressing this.

-- 
Arve Bersvendsen

http://www.virtuelvis.com
http://www.bersvendsen.com



From owner-atom-syntax@mail.imc.org  Sun Jul 18 13:07:25 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20647
	for <atompub-archive@lists.ietf.org>; Sun, 18 Jul 2004 13:07: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 i6IGwSpj065030;
	Sun, 18 Jul 2004 09:58:28 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6IGwSHr065029;
	Sun, 18 Jul 2004 09:58:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from 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 i6IGwQ0u065009
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 09:58:27 -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 i6IGwO53023478
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 11:58:25 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6IGwOkK023474;
	Sun, 18 Jul 2004 11:58:24 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PacePutDelete Withdrawn
References: <1090165177.2738485554.17777.sendItem@bloglines.com>
	<DFBF4C9F-D8D4-11D8-92AF-000A95A51C9E@sun.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 18 Jul 2004 11:58:24 -0500
In-Reply-To: <DFBF4C9F-D8D4-11D8-92AF-000A95A51C9E@sun.com>
Message-ID: <m3llhhdzgv.fsf@bitsko.slc.ut.us>
Lines: 38
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 i6IGwR0u065024
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 <Tim.Bray@Sun.COM> writes:

> It dawns on me that there is another popular application platform
> with support for GET and POST but not PUT nor DELETE.  That would be
> a Web Browser.  Thus, if the full capabilities of Atom were
> available using only GET and POST I would be able to do a full
> client implementation as a set of HTML pages with no reliance on
> server-side scripts, right?  Given that the browser is becoming a
> locus of innovation again (see Apache, WHAT-WG) this seems
> potentially quite significant. -Tim

The current browsers don't support forms that use <atom:entry>
elements, either, so I think that would be a bigger problem in using a
browser as an Atom protocol client.

On the other hand, with regards to the WHAT-WG's support of Atom,
Asbjørn (quarkie) writes in chat[1]:

  <quarkie> something that might interest veryone; I've queried WHAT
  WG on the Web Forms 2.0 proposal on the case where a web browser can
  act as an Atom API client

  <quarkie> Ian Hickson made a swift reply, where he explains that Web
  Forms 2.0 is going to support PUT and DELETE as '@method's on <form>
  as well as an unlimited amount of values for '@enctype'

  <bitsko> you'd have to rewrite the Atom specs to support form input,
  no?

  <quarkie> yup. as he writes: "If the Atom spec specifies how to
  convert a Web Forms 2.0 form data set into an 'application/atom+xml'
  encoded form data set, then UAs can implement it."

'bitsko' is my IRC nick.

  -- Ken

[1] http://www.ilrt.bris.ac.uk/discovery/chatlogs/atom/2004-07-04.html#T16-21-27



From owner-atom-syntax@mail.imc.org  Sun Jul 18 13:09: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 NAA20800
	for <atompub-archive@lists.ietf.org>; Sun, 18 Jul 2004 13:09: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 i6IH1eKZ065764;
	Sun, 18 Jul 2004 10:01:40 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6IH1eqT065763;
	Sun, 18 Jul 2004 10:01:40 -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 i6IH1d6u065746
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 10:01:39 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040718170133.71711.qmail@web41209.mail.yahoo.com>
Received: from [24.19.154.247] by web41209.mail.yahoo.com via HTTP; Sun, 18 Jul 2004 10:01:33 PDT
Date: Sun, 18 Jul 2004 10:01:33 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: On LinkTagMeaning...
To: Arve Bersvendsen <arve@virtuelvis.com>, Atom-syntax <atom-syntax@imc.org>
In-Reply-To: <opsbcd2jnb6dxgxk@mail.online.no>
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>


--- Arve Bersvendsen <arve@virtuelvis.com> wrote:
> 
> There are however newsfeeds that would benefit from
> this. Examples that  
> come to mind:

Any site that supports comments would benefit from the
ability to expose comments in their news feeds. 

 
> So, _people_ and _software_ do threading, but Atom
> has no way of  
> expressing this.

The threading mechanism I've seen in prominent use in
the wild is wfw:commentRss which is supported by a
handful of blogs (Sam Ruby's, Phil Ringnalda's) and
the major blogging tools written on ASP.NET (dasBlog &
RSS Bandit). Similarly the aggregators I've seen
supporting threading using this mechanism are the .NET
based ones (RSS Bandit & SharpReader as well as
Newzcrawler). Actually it seems Newzcrawler also
supports the blogcomments module. 

I don't see why Atom feeds can't use that extension or
any of the other 3 you mention. I don't think there's
much experience with implementing threading mechanisms
in the wild to start putting in the core Atom spec. 


=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/



From owner-atom-syntax@mail.imc.org  Sun Jul 18 13:10: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 NAA20861
	for <atompub-archive@lists.ietf.org>; Sun, 18 Jul 2004 13:10: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 i6IH09Df065452;
	Sun, 18 Jul 2004 10: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 i6IH09R5065451;
	Sun, 18 Jul 2004 10:00:09 -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 i6IH08VF065445
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 10:00:09 -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 esmtp (Exim 4.34)
	id 1BmF1F-0000Jq-Fe; Sun, 18 Jul 2004 17:00:09 +0000
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Sun, 18 Jul 2004 13:00:16 -0400
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
From: Robert Sayre <mint@franklinmint.fm>
To: John Panzer <jpanzer@aol.net>
CC: <kwark.1511609@bloglines.com>, <joe.gregorio@gmail.com>,
        Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD2024E0.13F48%mint@franklinmint.fm>
In-Reply-To: <40FAA6D3.30701@aol.net>
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: <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 7/18/04 12:35 PM, "John Panzer" <jpanzer@aol.net> wrote:

> 
> Robert Sayre wrote:
> 
>> It would appear that the most convenient approach for J2ME applications
>> would be a request header in combination with POST. SOAP would be workable
>> as well, but updates of binary resources would be a problem.
>> 
>>  
>> 
> Is an X-ATOM-xxx HTTP request header a reasonable 90% solution?  This
> would work for both Atom XML and binary resources, is implementable even
> by CGI scripts on the server side, and I'm guessing has a nice simple
> specification (if present, overrides the HTTP method used in the
> original request).
> 

I think the Header and/or SOAP/XML are reasonable 90% solutions. Both of
them make me squeamish, but that's life. The binary requirement is for a
proposal we haven't accepted yet. I think we should keep our options open
for now. 


>> - Flash
>> Flash MX 2004 / FlashPlayer 7 has SOAP support, and I'm pretty sure there's
>> nothing interesting you could send as binary with Flash. Headers are also
>> out, I think. The wiki mentions the XMLSocket object, which does let you
>> send anything over a socket (not just XML). It's restricted to the same host
>> and ports above 1024. Other Flash objects allow transmission of XML to port
>> 80 on the same host. The LoadMovie() function allows loading of SWFs and
>> JPGs (JPGs in Flash6) from other hosts.
>> 
>> SOAP would appear to be the best bet here.
>> 
>> Note: I have written tons of ActionScript, but most of it was targeted at
>> Flash 5.
>>  
>> 
> We've used XML documents (non-SOAP) with Flash fairly successfully in a
> number of applications, for both reading and for posting (just GET and
> POST, though).  Not sure what underlying objects/libraries are being
> used, though I could find out if there is interest.

Yep, it works pretty well. It's called the "XML Object" [1]. You can use GET
(XML.load()) or POST (XML.sendAndLoad()) with it.

You assign a callback function to the object before you send the request.
When it's all loaded, you get a DOM-style interface to the data.


> It is possible to get around the same-host security restrictions via
> "crossdomain.xml" files placed at the root of the Atom server.  If a
> domain is listed in this file, Flash .swf files originally loaded from
> that domain are allowed to at least GET/POST to/from the Atom server.
> 

I was surprised to see this. I'd never heard of it. It seems to be a feature
of FlashPlayer 7 only [1]. Is that right?

Robert Sayre

[1] 
http://www.macromedia.com/support/flash/action_scripts/actionscript_dictiona
ry/actionscript_dictionary827.html

[2] http://www.macromedia.com/devnet/mx/flash/articles/fplayer_security.html



From owner-atom-syntax@mail.imc.org  Sun Jul 18 13:20: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 NAA21628
	for <atompub-archive@lists.ietf.org>; Sun, 18 Jul 2004 13:20: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 i6IHAFxO067309;
	Sun, 18 Jul 2004 10:10: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 i6IHAFs4067308;
	Sun, 18 Jul 2004 10:10: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.197])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6IHAE02067302
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 10:10:14 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d15so645178rng
        for <atom-syntax@imc.org>; Sun, 18 Jul 2004 10:10:12 -0700 (PDT)
Received: by 10.38.207.51 with SMTP id e51mr637053rng;
        Sun, 18 Jul 2004 10:10:12 -0700 (PDT)
Message-ID: <14be96d30407181010533eb035@mail.gmail.com>
Date: Sun, 18 Jul 2004 13:10:12 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Robert Sayre <mint@franklinmint.fm>
Subject: Re: PacePutDelete Withdrawn
Cc: Tim Bray <tim.bray@sun.com>, Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <BD202123.13F3F%mint@franklinmint.fm>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <BD202123.13F3F%mint@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 Sun, 18 Jul 2004 12:44:19 -0400, Robert Sayre <mint@franklinmint.fm> wrote:
> Also, you could build a ReST Atom client in javascript, using the XMLHTTP
> object. This code would work in IE6 and recent versions of Mozilla. Safari
> also has XMLHTTP support scheduled. It's one of those de-facto IE standards
> that is actually pretty good.

http://www.isolani.co.uk/blog/atom/JavascriptAtomApiClientUsingXmlHttpRequest

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Sun Jul 18 13: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 NAA22095
	for <atompub-archive@lists.ietf.org>; Sun, 18 Jul 2004 13: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 i6IHPGFg069481;
	Sun, 18 Jul 2004 10:25: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 i6IHPGSt069480;
	Sun, 18 Jul 2004 10:25:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail48-s.fg.online.no (mail48-s.fg.online.no [148.122.161.48])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6IHPFJb069459
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 10:25:16 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Received: from mail.online.no (ti132110a080-3373.bb.online.no [80.212.221.45])
	by mail48.fg.online.no (8.12.11/8.12.11) with ESMTP id i6IHPDNl001428;
	Sun, 18 Jul 2004 19:25:13 +0200 (CEST)
Date: Sun, 18 Jul 2004 19:25:12 +0200
To: "Dare Obasanjo" <kpako@yahoo.com>, Atom-syntax <atom-syntax@imc.org>
Subject: Re: On LinkTagMeaning...
References: <20040718170133.71711.qmail@web41209.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: <opsbcf0a1n6dxgxk@mail.online.no>
In-Reply-To: <20040718170133.71711.qmail@web41209.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 Sun, 18 Jul 2004 10:01:33 -0700 (PDT), Dare Obasanjo <kpako@yahoo.com>  
wrote:

> The threading mechanism I've seen in prominent use in
> the wild is wfw:commentRss

Looking around, I was only able to determine that wfw:commentRss is only a  
discovery/exposure mechanism for comments, and not a threading mechanism  
as such.

> I don't see why Atom feeds can't use that extension or
> any of the other 3 you mention. I don't think there's
> much experience with implementing threading mechanisms
> in the wild to start putting in the core Atom spec.

Having threading in the core promotes usage.

Also: Don't forget that there is considerable experience with threading  
outside the feed/aggregator world. If you want a hands-on-tutorial on how  
to perform threading when in-reply-to and references is present, take a  
look at Jamie Zawinskis threading algorithm for Netscape 3, <URL:  
http://www.jwz.org/doc/threading.html >

-- 
Arve Bersvendsen

http://www.virtuelvis.com
http://www.bersvendsen.com



From owner-atom-syntax@mail.imc.org  Sun Jul 18 13:44: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 NAA22808
	for <atompub-archive@lists.ietf.org>; Sun, 18 Jul 2004 13:44:35 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6IHaDcn070780;
	Sun, 18 Jul 2004 10: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 i6IHaDOc070779;
	Sun, 18 Jul 2004 10:36:13 -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 i6IHaCFS070763
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 10:36:12 -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 i6IHaA53023988
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 12:36:10 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6IHaAso023984;
	Sun, 18 Jul 2004 12:36:10 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom-syntax <atom-syntax@imc.org>
Subject: Re: On LinkTagMeaning...
References: <20040718170133.71711.qmail@web41209.mail.yahoo.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 18 Jul 2004 12:36:10 -0500
In-Reply-To: <20040718170133.71711.qmail@web41209.mail.yahoo.com>
Message-ID: <m3hds5dxpx.fsf@bitsko.slc.ut.us>
Lines: 46
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: <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> writes:

> --- Arve Bersvendsen <arve@virtuelvis.com> wrote:
> > So, _people_ and _software_ do threading, but Atom has no way of
> > expressing this.
> 
> The threading mechanism I've seen in prominent use in the wild is
> wfw:commentRss which is supported by a handful of blogs (Sam Ruby's,
> Phil Ringnalda's) and the major blogging tools written on ASP.NET
> (dasBlog & RSS Bandit). Similarly the aggregators I've seen
> supporting threading using this mechanism are the .NET based ones
> (RSS Bandit & SharpReader as well as Newzcrawler). Actually it seems
> Newzcrawler also supports the blogcomments module.
> 
> I don't see why Atom feeds can't use that extension or any of the
> other 3 you mention. I don't think there's much experience with
> implementing threading mechanisms in the wild to start putting in
> the core Atom spec.

I think we're using different scopes for the word "threading".  Both
scopes are implemented exactly the same as in wfw:commentRss and in
Atom with the "service.feed" link on an atom:entry resource.

Current RSS threads are "flat".  The examples Arve linked to, and the
threading support being requested, are "nested".

The current proposal (PaceLinkParent) is for those entries in the
service.feed/wfw:commentRss feed to have a "parent" link to the entry
they reply to, so that clients that support that feature can show the
nesting level.  Clients that don't support that feature would properly
default to flat display.

Earlier you had suggested[1] that each nested comment should have its
own wfw:commentRss link, and Roger Benningfield described the "Yikes!"
scenario[2] with that approach.  This proposal keeps all the entries
in the same feed and also supports nested and flat comments.

  -- Ken

PS. My main objection to PaceLinkParent is that it is intentionally
overloading the term "parent".  I'll be creating a new proposal
shortly that is confined to just replies as used in the examples Arve
linked to.

[1] http://imc.org/atom-syntax/mail-archive/msg05611.html
[2] http://imc.org/atom-syntax/mail-archive/msg05639.html



From owner-atom-syntax@mail.imc.org  Sun Jul 18 14:29: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 OAA24717
	for <atompub-archive@lists.ietf.org>; Sun, 18 Jul 2004 14:29: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 i6IIITH3076418;
	Sun, 18 Jul 2004 11:18: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 i6IIIT68076416;
	Sun, 18 Jul 2004 11:18:29 -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 i6IIIThL076389
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 11:18:29 -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 i6IIINt17220
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 11:18:23 -0700 (PDT)
Received: from aol.net ([10.169.192.58]) by judge.mcom.com
          (Netscape Messaging Server 4.15) with ESMTP id I1286M01.60S;
          Sun, 18 Jul 2004 11:18:22 -0700 
Message-ID: <40FABE73.8010507@aol.net>
Date: Sun, 18 Jul 2004 11:16:19 -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: Robert Sayre <mint@franklinmint.fm>
CC: kwark.1511609@bloglines.com, joe.gregorio@gmail.com,
        Atom Syntax <atom-syntax@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD2024E0.13F48%mint@franklinmint.fm>
In-Reply-To: <BD2024E0.13F48%mint@franklinmint.fm>
Content-Type: multipart/alternative;
 boundary="------------010009080502010700020703"
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>


This is a multi-part message in MIME format.
--------------010009080502010700020703
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Robert Sayre wrote:

>On 7/18/04 12:35 PM, "John Panzer" <jpanzer@aol.net> wrote:
>  
>
> ...
>
>>It is possible to get around the same-host security restrictions via
>>"crossdomain.xml" files placed at the root of the Atom server.  If a
>>domain is listed in this file, Flash .swf files originally loaded from
>>that domain are allowed to at least GET/POST to/from the Atom server.
>>
>>    
>>
>
>I was surprised to see this. I'd never heard of it. It seems to be a feature
>of FlashPlayer 7 only [1]. Is that right?
>
>Robert Sayre
>
>[1] 
>http://www.macromedia.com/support/flash/action_scripts/actionscript_dictiona
>ry/actionscript_dictionary827.html
>
>[2] http://www.macromedia.com/devnet/mx/flash/articles/fplayer_security.html
>
>  
>
I do dimly recall that we had to do something different for Flash 6 and 
7, with F7 being much easier to deal with.  I've identified the internal 
guru on this and I hope to have details on Monday.

John


--------------010009080502010700020703
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Robert Sayre wrote:<br>
<blockquote cite="midBD2024E0.13F48%25mint@franklinmint.fm" type="cite">
  <pre wrap="">On 7/18/04 12:35 PM, "John Panzer" <a class="moz-txt-link-rfc2396E" href="mailto:jpanzer@aol.net">&lt;jpanzer@aol.net&gt;</a> wrote:
  </pre>
...
  <blockquote type="cite">
    <pre wrap="">It is possible to get around the same-host security restrictions via
"crossdomain.xml" files placed at the root of the Atom server.  If a
domain is listed in this file, Flash .swf files originally loaded from
that domain are allowed to at least GET/POST to/from the Atom server.

    </pre>
  </blockquote>
  <pre wrap=""><!---->
I was surprised to see this. I'd never heard of it. It seems to be a feature
of FlashPlayer 7 only [1]. Is that right?

Robert Sayre

[1] 
<a class="moz-txt-link-freetext" href="http://www.macromedia.com/support/flash/action_scripts/actionscript_dictiona">http://www.macromedia.com/support/flash/action_scripts/actionscript_dictiona</a>
ry/actionscript_dictionary827.html

[2] <a class="moz-txt-link-freetext" href="http://www.macromedia.com/devnet/mx/flash/articles/fplayer_security.html">http://www.macromedia.com/devnet/mx/flash/articles/fplayer_security.html</a>

  </pre>
</blockquote>
I do dimly recall that we had to do something different for Flash 6 and
7, with F7 being much easier to deal with.&nbsp; I've identified the
internal guru on this and I hope to have details on Monday.<br>
<br>
John<br>
<br>
</body>
</html>

--------------010009080502010700020703--



From owner-atom-syntax@mail.imc.org  Sun Jul 18 14:42: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 OAA25464
	for <atompub-archive@lists.ietf.org>; Sun, 18 Jul 2004 14:42: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 i6IIZPkd078676;
	Sun, 18 Jul 2004 11: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 i6IIZPfV078675;
	Sun, 18 Jul 2004 11:35:25 -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 i6IIZPFX078659
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 11:35:25 -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 i6IIZNt17833
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 11:35:23 -0700 (PDT)
Received: from aol.net ([10.169.192.58]) by judge.mcom.com
          (Netscape Messaging Server 4.15) with ESMTP id I128YY00.90K;
          Sun, 18 Jul 2004 11:35:22 -0700 
Message-ID: <40FAC26F.2070807@aol.net>
Date: Sun, 18 Jul 2004 11:33:19 -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: Robert Sayre <mint@franklinmint.fm>
CC: kwark.1511609@bloglines.com, joe.gregorio@gmail.com,
        Atom Syntax <atom-syntax@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD2024E0.13F48%mint@franklinmint.fm>
In-Reply-To: <BD2024E0.13F48%mint@franklinmint.fm>
Content-Type: multipart/alternative;
 boundary="------------010307040804040209030607"
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>


This is a multi-part message in MIME format.
--------------010307040804040209030607
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Robert Sayre wrote:

>On 7/18/04 12:35 PM, "John Panzer" <jpanzer@aol.net> wrote:
>
>  
>
>>Is an X-ATOM-xxx HTTP request header a reasonable 90% solution?  This
>>would work for both Atom XML and binary resources, is implementable even
>>by CGI scripts on the server side, and I'm guessing has a nice simple
>>specification (if present, overrides the HTTP method used in the
>>original request).
>>
>>    
>>
>
>I think the Header and/or SOAP/XML are reasonable 90% solutions. Both of
>them make me squeamish, but that's life. 
>
Yes, me too.

>The binary requirement is for a
>proposal we haven't accepted yet. I think we should keep our options open
>for now. 
>  
>
I agree in principle.  (But does this mean that we should refrain from 
adopting something incompatible with possible future binary HTTP requests?)

-John

--------------010307040804040209030607
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Robert Sayre wrote:<br>
<blockquote cite="midBD2024E0.13F48%25mint@franklinmint.fm" type="cite">
  <pre wrap="">On 7/18/04 12:35 PM, "John Panzer" <a class="moz-txt-link-rfc2396E" href="mailto:jpanzer@aol.net">&lt;jpanzer@aol.net&gt;</a> wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">Is an X-ATOM-xxx HTTP request header a reasonable 90% solution?  This
would work for both Atom XML and binary resources, is implementable even
by CGI scripts on the server side, and I'm guessing has a nice simple
specification (if present, overrides the HTTP method used in the
original request).

    </pre>
  </blockquote>
  <pre wrap=""><!---->
I think the Header and/or SOAP/XML are reasonable 90% solutions. Both of
them make me squeamish, but that's life. </pre>
</blockquote>
Yes, me too.<br>
<blockquote cite="midBD2024E0.13F48%25mint@franklinmint.fm" type="cite">
  <pre wrap="">The binary requirement is for a
proposal we haven't accepted yet. I think we should keep our options open
for now. 
  </pre>
</blockquote>
I agree in principle.&nbsp; (But does this mean that we should refrain from
adopting something incompatible with possible future binary HTTP
requests?)<br>
<br>
-John<br>
</body>
</html>

--------------010307040804040209030607--



From owner-atom-syntax@mail.imc.org  Sun Jul 18 15:37: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 PAA28826
	for <atompub-archive@lists.ietf.org>; Sun, 18 Jul 2004 15:37: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 i6IJT83g086306;
	Sun, 18 Jul 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 i6IJT8Y6086304;
	Sun, 18 Jul 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 beattie.info (Debian-exim@26.69-93-195.reverse.theplanet.com [69.93.195.26] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6IJT7Gh086297
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 12:29:08 -0700 (PDT)
	(envelope-from russ@russellbeattie.com)
Received: from [64.164.31.160] (helo=[192.168.0.160])
	by beattie.info with asmtp (Exim 4.33)
	id 1BmHOK-0004rS-5T
	for atom-syntax@imc.org; Sun, 18 Jul 2004 12:32:08 -0700
Message-ID: <40FACF82.7090500@russellbeattie.com>
Date: Sun, 18 Jul 2004 12:29:06 -0700
From: Russell Beattie <russ@russellbeattie.com>
User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040708)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Atomlist <atom-syntax@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net>
In-Reply-To: <40FAA6D3.30701@aol.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: <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




John Panzer wrote:

> Is an X-ATOM-xxx HTTP request header a reasonable 90% solution?  This 
> would work for both Atom XML and binary resources, is implementable 
> even by CGI scripts on the server side, and I'm guessing has a nice 
> simple specification (if present, overrides the HTTP method used in 
> the original request).
>

I think it's great. I suggested an X-ATOMACTION header back in Februrary 
[1] and I still like the idea:

> One solution is to add another custom HTTP header. Since we have to do 
> that anyway for the WSSE security this may not a bad idea, it would 
> have the benefit of allowing the server process to not worry about XML 
> until it had to. Apache might even have a mod_rewrite rule for the 
> EditURI which looks for POSTs with an Action header which could change 
> the request's verb on the fly so the backend wouldn't even have to be 
> modified.

I think this garnered some support among some others as well.

- Russ



[1] http://www.imc.org/atom-syntax/mail-archive/msg03025.html



From owner-atom-syntax@mail.imc.org  Sun Jul 18 16: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 QAA01561
	for <atompub-archive@lists.ietf.org>; Sun, 18 Jul 2004 16:43: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 i6IKVnwu095101;
	Sun, 18 Jul 2004 13:31: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 i6IKVnRu095100;
	Sun, 18 Jul 2004 13:31:49 -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 i6IKVnlO095094
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 13:31:49 -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 i6IKVrn6023357;
	Sun, 18 Jul 2004 13:31:53 -0700 (PDT)
Received: from [160.39.246.138] (dyn-wireless-246-138.dyn.columbia.edu [160.39.246.138])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id i6IKVpKR003887;
	Sun, 18 Jul 2004 13:31:52 -0700 (PDT)
In-Reply-To: <87k6x2l3pj.fsf@nwalsh.com>
References: <87k6x2l3pj.fsf@nwalsh.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-206363355; protocol="application/pkcs7-signature"
Message-Id: <80FD9414-D8F9-11D8-81CD-000A95DC3D90@mac.com>
Cc: Atom Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: On LinkTagMeaning...
Date: Sun, 18 Jul 2004 16:31:52 -0400
To: Norman Walsh <ndw@nwalsh.com>
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-206363355
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 17 Jul 2004, at 5:32 pm, Norman Walsh wrote:

> There will be extension vocabularies. Some of them will include links.
> Some of them will be popular. Some of them will gain critical mass. 
> Some
> of them will be supported by tools. Some of them will only ever be used
> by four random friends. That's ok.

+1 to that and to the suggested link replacements (though I thing 
prev/next or something equally simple might fit in v1.0). It's becoming 
more clear that not all link elements have the same requirements for 
attributes (eg image might need size attributes), so the value of a 
Link Construct at all is questionable.

(I'd also like to reiterate that the number of extension vocabularies 
that will re-use any kind of Link Construct is likely to be manageably 
small, and I don't expect it to be a big challenge for tool-vendors to 
be aware of all of the popular ones, so needing an automated way to 
find them seems unnecessary)

Graham
--Apple-Mail-2-206363355
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
9w0BCQUxDxcNMDQwNzE4MjAzMTUzWjAjBgkqhkiG9w0BCQQxFgQUZXjJX4o+IzXkUkpon6WokNBI
SwYweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAWKSQSjZ7q8vwF6nZMSKQpXaP
/Fuk1Hv3jP8N84QfESMoyXFRWj+oRyCTazRn+9Id7lthrDXo8sfNXoVrHnSzpdcdADyM7HqIM3vZ
PLTkU81ZlnDBGsKqtYZQEUzt1+eYs/tX/NMgMYdTbDM2crvQlzKy43i/MtmkRzo2JvgEpQ7cY3jK
NlmHVzU5kD6Jfju2WTmL3vfjOdenbkHO++H2haJDaIBC+QopbZSeoLZR03j9feBGPyDH5lRnilGS
KcZY3QVj0yTD4+r5uxin8/QxAkPLrkvPIFceSvpBjFCFkyMLu8PI1yThzjcl84uXL/CaWgsbPn5x
ELUWLF9dQrPxlQAAAAAAAA==

--Apple-Mail-2-206363355--



From owner-atom-syntax@mail.imc.org  Sun Jul 18 16:46: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 QAA01684
	for <atompub-archive@lists.ietf.org>; Sun, 18 Jul 2004 16:46: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 i6IKa0F2095953;
	Sun, 18 Jul 2004 13:36: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 i6IKa0V2095952;
	Sun, 18 Jul 2004 13:36:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6IKZxce095937
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 13:36:00 -0700 (PDT)
	(envelope-from hsivonen@iki.fi)
Received: from 217-140-251-133.adsl-net.finnetcom.net ([217.140.251.133]:62139
        "EHLO [217.140.251.133]" TLS-CIPHER: <none>) by smtp2.dnainternet.net
        with ESMTP id S1229362AbUGRUf7 (ORCPT <rfc822;atom-syntax@imc.org>);
        Sun, 18 Jul 2004 23:35:59 +0300
Mime-Version: 1.0 (Apple Message framework v618)
Content-Transfer-Encoding: 7bit
Message-Id: <130AC5A4-D8FA-11D8-933E-003065B8CF0E@iki.fi>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: atom-syntax@imc.org
From: Henri Sivonen <hsivonen@iki.fi>
Subject: Re: Low-hanging fruit: compulsory namespaces
Date:   Sun, 18 Jul 2004 23:35:58 +0300
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>
Content-Transfer-Encoding: 7bit


On Wed, 14 Jul 2004 17:44:32 -0700 steve jenson wrote:

> On Jul 14, 2004, at 5:42 PM, Dare Obasanjo wrote:
>
>>     --- steve jenson <stevej@xxxxxxxxxx> wrote:
>>
>> This implies that Blogger is not using XML tools to
>> generate their feeds. No XML tools I've come across
>> would make such mistakes unless they are extremely
>> buggy. I think adding this text to the normative spec
>> is akin to adding stuff like 'best practices for
>> parsing XML with regexes' in the spec.
>
> I'm using the DOM provided with Java 1.4.2.

How? I don't see serialization features in the public API.

I use gnu.xml.pipeline.NSFilter for fixing the namespace declarations 
when serializing. (The GNU JAXP serialization code works fine with 
Crimson.)

-- 
Henri Sivonen
hsivonen@iki.fi
http://iki.fi/hsivonen/



From owner-atom-syntax@mail.imc.org  Sun Jul 18 16:55: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 QAA02082
	for <atompub-archive@lists.ietf.org>; Sun, 18 Jul 2004 16:55: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 i6IKjrg9097302;
	Sun, 18 Jul 2004 13:45:53 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6IKjrxv097301;
	Sun, 18 Jul 2004 13:45:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6IKjrrs097294
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 13:45:53 -0700 (PDT)
	(envelope-from hsivonen@iki.fi)
Received: from 217-140-251-133.adsl-net.finnetcom.net ([217.140.251.133]:62144
        "EHLO [217.140.251.133]" TLS-CIPHER: <none>) by smtp2.dnainternet.net
        with ESMTP id S1229047AbUGRUpt (ORCPT <rfc822;atom-syntax@imc.org>);
        Sun, 18 Jul 2004 23:45:49 +0300
Mime-Version: 1.0 (Apple Message framework v618)
In-Reply-To: <m3llhhdzgv.fsf@bitsko.slc.ut.us>
References: <1090165177.2738485554.17777.sendItem@bloglines.com> <DFBF4C9F-D8D4-11D8-92AF-000A95A51C9E@sun.com> <m3llhhdzgv.fsf@bitsko.slc.ut.us>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <72940BAE-D8FB-11D8-933E-003065B8CF0E@iki.fi>
Content-Transfer-Encoding: 7bit
From: Henri Sivonen <hsivonen@iki.fi>
Subject: Re: PacePutDelete Withdrawn
Date:   Sun, 18 Jul 2004 23:45:47 +0300
To: Atom Syntax <atom-syntax@imc.org>
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>
Content-Transfer-Encoding: 7bit


On Jul 18, 2004, at 19:58, Ken MacLeod wrote:

>   <quarkie> yup. as he writes: "If the Atom spec specifies how to
>   convert a Web Forms 2.0 form data set into an 'application/atom+xml'
>   encoded form data set, then UAs can implement it."

What would be the point of burdening a Web Forms 2.0 UA with Atom? If 
you are able to spec how to build an Atom entry out of a form dataset, 
surely the conversion can be done on the server instead of introducing 
yet another submission format for UAs to support.

-- 
Henri Sivonen
hsivonen@iki.fi
http://iki.fi/hsivonen/



From owner-atom-syntax@mail.imc.org  Sun Jul 18 18:20:58 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07601
	for <atompub-archive@lists.ietf.org>; Sun, 18 Jul 2004 18: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 i6IMALXp009524;
	Sun, 18 Jul 2004 15:10:22 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6IMAL8t009523;
	Sun, 18 Jul 2004 15:10:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf13.cluster1.charter.net (mxsf13.cluster1.charter.net [209.225.28.213])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6IMAKWe009499
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 15:10:21 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip01.cluster1.charter.net (mxip01a.cluster1.charter.net [209.225.28.131])
	by mxsf13.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6IMFD0J018091
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 18:15:13 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip01.cluster1.charter.net with ESMTP; 18 Jul 2004 18:10:18 -0400
X-Ironport-AV: i="3.81R,176,1083556800"; 
   d="scan'208"; a="106839081:sNHT15026252"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BmJrK-0004iz-00
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 18:10:14 -0400
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: On LinkTagMeaning...
References: <87k6x2l3pj.fsf@nwalsh.com>
	<80FD9414-D8F9-11D8-81CD-000A95DC3D90@mac.com>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Sun, 18 Jul 2004 18:10:14 -0400
In-Reply-To: <80FD9414-D8F9-11D8-81CD-000A95DC3D90@mac.com> (dtcd@mac.com's
 message of "Sun, 18 Jul 2004 16:31:52 -0400")
Message-ID: <87zn5x55mh.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: <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-Type: text/plain

/ Graham <dtcd@mac.com> was heard to say:
| On 17 Jul 2004, at 5:32 pm, Norman Walsh wrote:
|> There will be extension vocabularies. Some of them will include
|> links. Some of them will be popular. Some of them will gain
|> critical mass. Some of them will be supported by tools. Some of
|> them will only ever be used by four random friends. That's ok.
|
| +1 to that and to the suggested link replacements (though I thing
| prev/next or something equally simple might fit in v1.0). It's

How would that be used? I've always imagined that sorting on one of
the date fields gives an effective linear order. Are there any tools
that use a prev/next link? How do they use it? What do they do with
entries that are 'skipped' in the feed?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Doubt is to certainty as neurosis is to
http://nwalsh.com/            | psychosis. The neurotic is in doubt and
                              | has fears about persons and things; the
                              | psychotic has convictions and makes
                              | claims about them. In short, the
                              | neurotic has problems, the psychotic
                              | has solutions.--Thomas Szasz

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA+vVGOyltUcwYWjsRAlQLAJwJ77UUwkgpAkVyrDeipsxcFxINQgCgrH/Q
6xmIAsPkzANWGdJX5/NfvHM=
=3B9r
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Sun Jul 18 19:57: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 TAA12811
	for <atompub-archive@lists.ietf.org>; Sun, 18 Jul 2004 19:57: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 i6INlt3f026665;
	Sun, 18 Jul 2004 16: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 i6INltVY026664;
	Sun, 18 Jul 2004 16:47:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from garland.duramedia.net (garland.duramdedia.net [209.51.131.138] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6INlt3I026641
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 16:47:55 -0700 (PDT)
	(envelope-from jg@jonasgalvez.com)
Received: from 200-206-135-201.dsl.telesp.net.br ([200.206.135.201] ident=jgalvez)
	by garland.duramedia.net with esmtp (Exim 4.34)
	id 1BmLNw-00073A-Un
	for atom-syntax@imc.org; Sun, 18 Jul 2004 19:48:01 -0400
Message-ID: <40FB0BCC.7080202@jonasgalvez.com>
Date: Sun, 18 Jul 2004 20:46:20 -0300
From: Jonas Galvez <jg@jonasgalvez.com>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: AtomSyntax <atom-syntax@imc.org>
Subject: Bug in Bloglines
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 - garland.duramedia.net
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jonasgalvez.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


fyi:

Bloglines doesn't parse <content> tags with plain text correctly. Entity
encoded chars are not converted before presentation.

http://jonasgalvez.com/lab/content_test.xml
http://bloglines.com/preview?siteid=349738

Only double-escaping (entities in CDATA sections) work.

I've just reported the bug.



\\ jonas galvez
// jonasgalvez.com



From owner-atom-syntax@mail.imc.org  Sun Jul 18 20:19: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 UAA14092
	for <atompub-archive@lists.ietf.org>; Sun, 18 Jul 2004 20:19: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 i6J0AtN9029839;
	Sun, 18 Jul 2004 17:10:55 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6J0AtmB029838;
	Sun, 18 Jul 2004 17:10:55 -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 i6J0AsK0029818
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 17:10:54 -0700 (PDT)
	(envelope-from donpark@docuverse.com)
Received: from [192.168.0.100] (c-24-7-33-191.client.comcast.net[24.7.33.191])
          by comcast.net (rwcrmhc11) with ESMTP
          id <20040719001052013003j1gee>
          (Authid: dopilpark);
          Mon, 19 Jul 2004 00:10:53 +0000
Message-ID: <40FB1141.5030400@docuverse.com>
Date: Sun, 18 Jul 2004 17:09:37 -0700
From: Don Park <donpark@docuverse.com>
User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tim Bray <Tim.Bray@Sun.COM>
CC: Joe Gregorio <joe.gregorio@gmail.com>, Atom Syntax <atom-syntax@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD1DDB85.13D53%mint@franklinmint.fm> <7CEEF686-D7A3-11D8-92AF-000A95A51C9E@sun.com> <3f1451f504071621037d50b72c@mail.gmail.com> <4C1C1211-D7A8-11D8-92AF-000A95A51C9E@sun.com>
In-Reply-To: <4C1C1211-D7A8-11D8-92AF-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


3. Delete an entry
POST an entry with empty content to the entry's EditURI

Don

Tim Bray wrote:

>
> On Jul 16, 2004, at 9:03 PM, Joe Gregorio wrote:
>
>>> 1. Create an entry:
>>> POST the <atom:entry> to the feed EditURI
>>>
>>> 2. Update an entry:
>>> POST the <atom:entry> to the feed EditURI
>>> with one extra attribute update="URI of entry"
>>>
>>> 3. Delete an entry
>>> POST to the feed editURI
>>> <atom:delete entry="URI of entry" />
>>
>>
>> Just a point of clarification, and not to suggest
>> that I support this idea, which I don't,  but in the current
>> spec there is a seperate EditURI for each
>> entry that could be edited, thus the
>> attributes for "URI of entry" are not needed.
>
>
> That neatly solves the problem that Ken McLeod pointed out:
>
> 2. Update an entry:
> POST the new content to the entry's EditURI
>
>  -Tim
>
>
>



From owner-atom-syntax@mail.imc.org  Sun Jul 18 21:37:34 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17954
	for <atompub-archive@lists.ietf.org>; Sun, 18 Jul 2004 21: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 i6J1PN69041739;
	Sun, 18 Jul 2004 18:25: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 i6J1PNMW041738;
	Sun, 18 Jul 2004 18:25:23 -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 i6J1PMHf041732
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 18:25:23 -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 378A84EEDC;
	Sun, 18 Jul 2004 21:25:26 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040719094314.059586b8@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Mon, 19 Jul 2004 09:57:08 +0900
To: Bill de =?ISO-2022-JP?B?aBskQiVGRVMbKEI=?=a <bill@dehora.net>
From: Martin Duerst <duerst@w3.org>
Subject: Re: Low-hanging fruit: compulsory namespaces
Cc: Norman Walsh <ndw@nwalsh.com>, Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <40FA62BB.7070107@dehora.net>
References: <4.2.0.58.J.20040717113049.056ea330@localhost>
 <87smbrpuod.fsf@nwalsh.com>
 <6D6BAC41-D517-11D8-8C42-000A95A51C9E@sun.com>
 <40F46DAC.3030900@dehora.net>
 <D4AC57AE-D527-11D8-A503-000A95A51C9E@sun.com>
 <40F48A82.2020408@dehora.net>
 <3F81CFBF-D59D-11D8-A6EC-000A95A51C9E@sun.com>
 <40F5415E.5070100@dehora.net>
 <87k6x6mwef.fsf@nwalsh.com>
 <40F55860.7000800@dehora.net>
 <87d62w5brt.fsf@nwalsh.com>
 <40F7DC76.5050508@dehora.net>
 <87smbrpuod.fsf@nwalsh.com>
 <4.2.0.58.J.20040717113049.056ea330@localhost>
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: <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


At 12:44 04/07/18 +0100, Bill de h$B%FES(Ba wrote:

>Martin.
>
>Those look the same... was one of the <no-ns xmlns=""> lines meant to be 
>different or not there?

Sorry, both xmlns="" are supposed to not be there. So it should have been

  0   <outer xmlns="http://foo.example.org/">
  1   <atom:feed xmlns:atom="http://example.org/atom">
  2     <atom:content mode="xml">
  3       <no-ns>Non-namespaced element</no-ns>
  4     </atom:content>
  5   </atom:feed>
  6   </outer>

and

  0   <outer xmlns="http://bar.example.org/">
  1   <atom:feed xmlns:atom="http://example.org/atom">
  2     <atom:content mode="xml">
  3       <no-ns>Non-namespaced element</no-ns>
  4     </atom:content>
  5   </atom:feed>
  6   </outer>


>Martin Duerst wrote:

>>would be legal according to that interpretation of the namespace REC.
>>But this would clearly lead to a contradiction, so transformations
>>of the above type can't possibly be legal according to the
>>namespace REC.
> >
>>I think that you are probably right that it's rather difficult to
>>understand that from the namespace REC itself. It may be worth
>>looking at adding something like (just a draft):
>
>You see, I think they can be legal. The fact that you/I/we think 
>something  leads to a contradiction or doing so would just be silly 
>doesn't imply it can't be possibly be legal. I claim the contradiction is 
>the case and that it should be addressed with normative text; ie the bug 
>is that the spec's 'axioms' are inconsistent/incomplete. To get around it 
>I have to add extra information (a sense of silliness in one case, 
>xmlns="" shrouding by default in another, or some other 
>extra-interpretation) My position was to do that in the Atom spec, because 
>it is something I might have sway over.

The Atom spec clearly should not try to fix the namespace spec,
or interpret it in any way that may risk to be different from what
the spec says. I have already asked Norm to take this back to the
XML Core WG and make sure it's clear, with whatever means the XML
Core WG deems necessary.


>>"Note: elements without prefixes and not within the scope of a default
>>namespace declaration are in no namespace. Elements in no namespace
>>are different from elements with the same local name in any existing
>>namespace."
>
>And yet - more interpretation is needed to make sense of how that should 
>apply, so imo we haven't gotten anywhere. The problem occurs when an 
>element that is not in a namespace is embedded in markup that has a 
>default namespace. The scoping rules are incomplete for this case and the 
>text above doesn't change that - how shall we *make* them different?

I would claim that the scoping rules are complete. An element without
any namespace prefix but within the scope of a default namespace
declaration is in this default namespace.

Simply wrapping some XML that contains elements that are not in any
namespace with something that defines a default namespace therefore
changes the namespace of these elements from 'no namespace' to that
specific namespace, which means that it changes the nature of these
elements. So this operation, even if it looks less dangerous, is just
the same as going in and changing the URI in any arbitrary xmlns:foo
element: you change elements from one namespace to another. If you
don't want to do that, and it's pretty clear that you don't want to
do that except in very special cases, then it's clear that simply
wrapping some XML that contains elements that are not in any
namespace with something that defines a default namespace is
bad/dangerous.


Regards,    Martin.



From owner-atom-syntax@mail.imc.org  Sun Jul 18 22:22: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 VAA17945
	for <atompub-archive@lists.ietf.org>; Sun, 18 Jul 2004 21:37: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 i6J1SH3I042066;
	Sun, 18 Jul 2004 18:28: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 i6J1SHx1042065;
	Sun, 18 Jul 2004 18:28:17 -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 i6J1SGAX042058
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 18:28:16 -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 63EB94EF51;
	Sun, 18 Jul 2004 21:28:21 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040719102550.059bc858@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Mon, 19 Jul 2004 10:28:26 +0900
To: kwark.1511609@bloglines.com
From: Martin Duerst <duerst@w3.org>
Subject: Re: PacePutDelete Withdrawn
Cc: atom-syntax@imc.org
In-Reply-To: <1090165177.2738485554.17777.sendItem@bloglines.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 15:39 04/07/18 +0000, kwark.1511609@bloglines.com wrote:

>An older article describes iMode's technical architecture [2]. I find the
>following section on HTTP interesting:
>
>"The microbrowser sits on top of
>a protocol named Application Layer Protocol (ALP), developed by DoCoMo as
>the mobile client-side version of standard HTTP. The conversion between HTTP
>and ALP is transparent to the subscriber and to the sending Web server. It
>reduces client burden by removing HTTP header data (which is not needed by
>the Mobile Station), instituting a termination notification signal and 
>converting
>SMTP mail text to cHTML format."
>
>Unfortunately it does not say which HTTP
>methods are required and/or supported. Any iMode expert present willing to
>elaborate/investigate?

I'm trying to get that information from a friend.

Regards,    Martin.



From owner-atom-syntax@mail.imc.org  Sun Jul 18 22:26: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 WAA20778
	for <atompub-archive@lists.ietf.org>; Sun, 18 Jul 2004 22:26: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 i6J2IOBV049941;
	Sun, 18 Jul 2004 19:18: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 i6J2IO4f049938;
	Sun, 18 Jul 2004 19:18: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.45])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6J2IOdG049925
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 19:18:24 -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 i6J2ITAv024624;
	Sun, 18 Jul 2004 19:18:30 -0700 (PDT)
Received: from [192.168.1.103] (66-108-153-170.nyc.rr.com [66.108.153.170])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id i6J2I8KR009279;
	Sun, 18 Jul 2004 19:18:16 -0700 (PDT)
In-Reply-To: <87zn5x55mh.fsf@nwalsh.com>
References: <87k6x2l3pj.fsf@nwalsh.com> <80FD9414-D8F9-11D8-81CD-000A95DC3D90@mac.com> <87zn5x55mh.fsf@nwalsh.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4-227139774; protocol="application/pkcs7-signature"
Message-Id: <E0B3955B-D929-11D8-81CD-000A95DC3D90@mac.com>
Cc: Atom Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: On LinkTagMeaning...
Date: Sun, 18 Jul 2004 22:18:09 -0400
To: Norman Walsh <ndw@nwalsh.com>
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-4-227139774
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 18 Jul 2004, at 6:10 pm, Norman Walsh wrote:

> How would that be used? I've always imagined that sorting on one of
> the date fields gives an effective linear order. Are there any tools
> that use a prev/next link? How do they use it? What do they do with
> entries that are 'skipped' in the feed?

Are you talking about fir relationships between entries? That doesn't 
make much sense, no. I mean for feeds - ie The main feed has a previous 
(or next - no one's sure) link to a feed of the earlier n entries, 
which has a link to the n before that, etc. It's not very robust and 
you'd have to periodically look through the whole lot for changes, but 
still, it's a lot better than not being able to get at previous entries 
at all.

Graham
--Apple-Mail-4-227139774
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
9w0BCQUxDxcNMDQwNzE5MDIxODA5WjAjBgkqhkiG9w0BCQQxFgQUIhtm80DLxska5E7pXK4LfBYh
YvEweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAiIPj4HdPRfWfbu3YIg/bANe3
q/y8XX8O0TbUhG0mKu0NhJbHk90eRqy057sllCf5xfjmf4n7rqvB/5JE5S2yZe3XHcp+oNuuVkXB
6DQv9DX3EUCS6whHg70X/Y8jcqQ6SAwMqoYL0d/1IkQIwkNxQ60EuK3HSVeWnTzq6XqV7nVy/7r3
7GNTjp55poH7FsnDjKlgZ3UfjCl435R9wdFGmyCBK65VMoQQR6xbMgxNqKraBM5OkGvAr+beC3wJ
RyJUbQ9AR5WYlD+Z/LauwZYDrx/cm7mt1Yrpy0r4VmeXnDlnU+mef2UUIA9wEFPpBE9pJtZkCZsC
KOO9K3XrPvxfBwAAAAAAAA==

--Apple-Mail-4-227139774--



From owner-atom-syntax@mail.imc.org  Mon Jul 19 00:59: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 AAA28242
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 00:59: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 i6J4nLrd074553;
	Sun, 18 Jul 2004 21:49: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 i6J4nLdg074552;
	Sun, 18 Jul 2004 21:49:21 -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 i6J4nKcl074541;
	Sun, 18 Jul 2004 21:49:21 -0700 (PDT)
	(envelope-from distobj@acm.org)
Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian))
	id 1BmQ6H-0001Jd-00; Mon, 19 Jul 2004 00:50:05 -0400
Date: Mon, 19 Jul 2004 00:50:05 -0400
To: Paul Hoffman / IMC <phoffman@imc.org>
Cc: Atom Syntax <atom-syntax@imc.org>
Subject: Private extension support (was Re: Q: Put request should return Atom entry?
Message-ID: <20040719045005.GY30868@markbaker.ca>
References: <BD1DD57F.13D52%mint@franklinmint.fm> <40F892F1.5040105@bitworking.org> <p06110415bd1e4c1ed10a@[10.20.30.249]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <p06110415bd1e4c1ed10a@[10.20.30.249]>
User-Agent: Mutt/1.3.28i
From: Mark Baker <distobj@acm.org>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


On Fri, Jul 16, 2004 at 08:27:40PM -0700, Paul Hoffman / IMC wrote:
> Not quite. Because "servers MAY include", clients "MUST NOT expect". 
> This is a direct interoperability interpretation. If I'm creating a 
> client that expects additional info, it will not interoperate with 
> some conformant servers.

Mostly, but there are different forms of interoperatation.  By using
"SHOULD NOT", I meant to support the case where private (but declared)
extensions between clients and servers were used, which provides a
degraded form of interop where agents not party to the extension can
at least determine that they don't understand the message and fail
gracefully.  For example, imagine an extension called
"ReturnBodyOnPut" which a client declares as mandatory in the PUT
message.

Discussion to date concerning Atom extensibility has suggested the need
for "must understand" support in the data format.  What I'm talking
about is doing the same thing for the protocol, at least where the
protocol supports it (e.g. SOAP).

The bigger question though, is whether or not the group is interested in
supporting private extensions.

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

  Seeking work on large scale application/data integration projects
  and/or the enabling infrastructure for same.



From owner-atom-syntax@mail.imc.org  Mon Jul 19 01: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 BAA29943
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 01:31: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 i6J5KuCs084825;
	Sun, 18 Jul 2004 22:20: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 i6J5Ku3s084824;
	Sun, 18 Jul 2004 22:20:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from dns01.mail.yahoo.co.jp (dns01.mail.yahoo.co.jp [211.14.15.204])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6J5Ks5H084713
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 22:20:54 -0700 (PDT)
	(envelope-from torumyax@yahoo.co.jp)
Received: from unknown (HELO yahoo.co.jp) (210.151.150.2 with poptime)
  by dns01.mail.yahoo.co.jp with SMTP; 19 Jul 2004 05:20:47 -0000
X-Apparently-From: <torumyax@yahoo.co.jp>
From: Toru Marumoto <torumyax@yahoo.co.jp>
To: atom-syntax@imc.org
Subject: Blogging specific Options: Extended Text,Convert Line Breaks...
Date: Mon, 19 Jul 2004 14:19:12 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: TuruKame 3.55
Message-Id: <33C46D4FED65E1torumyax@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



I joined the list a few month ago, so I might have missed important issues.
Plese forgive me if I'm posting about a old duplicated issue. 

I'm a developer of BlogWrite (a japanese Blogging client) which supports
XML-RPC APIs and the Atom. There is a need for Atom to support
"Extended Text(text_more)","Convert Line Breaks", and TrackBack just like a
XML-RPC API do now. I understand Atom is not just for Blogging, but Atom is
widely used for Blogging already. 

Now I'm wondering if I should create a new namespace and some tags for those 
Blogging specific features and extend Atom. But, of course, I don't want to
reinvent a wheel...

So, does anyone know if any of those features is already exists or planned in
the Atom? if not, why not make tags for them?


Thanks 

PS.
I don't wanna be greedy, but it would be so nice if there were options like
"allow comments","allow pings", "public/draft". Why? 'Cause I want to replace 
all XML-RPC APIs with Atom!
BTW, Categories are OK, SixApart's way works fine for me.


Toru Marumoto
     see you on the web!
--------------------------------


__________________________________________________
Do You Yahoo!?
http://bb.yahoo.co.jp/



From owner-atom-syntax@mail.imc.org  Mon Jul 19 02:17:36 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15849
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 02:17:36 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6J66J77011272;
	Sun, 18 Jul 2004 23:06:19 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6J66JuR011268;
	Sun, 18 Jul 2004 23:06:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from garland.duramedia.net (garland.duramdedia.net [209.51.131.138] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6J66JEn011243
	for <atom-syntax@imc.org>; Sun, 18 Jul 2004 23:06:19 -0700 (PDT)
	(envelope-from jg@jonasgalvez.com)
Received: from 200-206-135-201.dsl.telesp.net.br ([200.206.135.201] ident=jgalvez)
	by garland.duramedia.net with esmtp (Exim 4.34)
	id 1BmRI6-0005AR-9e
	for atom-syntax@imc.org; Mon, 19 Jul 2004 02:06:23 -0400
Message-ID: <40FB6481.30903@jonasgalvez.com>
Date: Mon, 19 Jul 2004 03:04:49 -0300
From: Jonas Galvez <jg@jonasgalvez.com>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: AtomSyntax <atom-syntax@imc.org>
Subject: Re: Blogging specific Options: Extended Text,Convert Line Breaks...
References: <33C46D4FED65E1torumyax@yahoo.co.jp>
In-Reply-To: <33C46D4FED65E1torumyax@yahoo.co.jp>
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 - garland.duramedia.net
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jonasgalvez.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


Toru Marumoto wrote:
> I'm a developer of BlogWrite (a japanese Blogging client) which 
> supports XML-RPC APIs and the Atom. There is a need for Atom to 
> support "Extended Text(text_more)","Convert Line Breaks", and 
> TrackBack just like a XML-RPC API do now. I understand Atom is not 
> just for Blogging, but Atom is widely used for Blogging already.
> 
> Now I'm wondering if I should create a new namespace and some tags  
> for those Blogging specific features and extend Atom. But, of course, 
> I don't want to reinvent a wheel...

Yes, you should look forward extending it through namespaces. Here's a 
nice primer on the Atom API which shows some useful examples:

http://www.xml.com/pub/a/2003/10/15/dive.html?page=2

     POST /myblog/atom.cgi HTTP/1.1
     Host: example.com
     Content-Type: application/x.atom+xml

     <?xml version="1.0" encoding="utf-8"?>
     <entry
       xmlns="http://purl.org/atom/ns#"
       xmlns:mt="http://www.movabletype.org/atom/ns#">

       <title>My Entry Title</title>
       <created>2003-11-17T12:29:29Z</created>
       <mt:allowComments>1</mt:allowComments>
       [...]

It's really that simple. Note that the Content-Type should now be 
application/atom+xml and not application/x.atom+xml.



\\ jonas galvez
// jonasgalvez.com



From owner-atom-syntax@mail.imc.org  Mon Jul 19 03:30: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 DAA21015
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 03:30:09 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6J7I9Ys042803;
	Mon, 19 Jul 2004 00: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 i6J7I91W042802;
	Mon, 19 Jul 2004 00:18:09 -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 i6J7I793042698
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 00:18:08 -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; 19 Jul 2004 07:17:53 -0000
X-Apparently-From: <torumyax@yahoo.co.jp>
From: Toru Marumoto <torumyax@yahoo.co.jp>
To: AtomSyntax <atom-syntax@imc.org>
Subject: Re: Blogging specific Options: Extended Text,Convert Line Breaks...
Date: Mon, 19 Jul 2004 16:16:17 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: TuruKame 3.55
In-Reply-To: <40FB6481.30903@jonasgalvez.com>
References: <40FB6481.30903@jonasgalvez.com>
Message-Id: <34C46D6048B080torumyax@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



>> Now I'm wondering if I should create a new namespace and some tags  
>> for those Blogging specific features and extend Atom. But, of course, 
>> I don't want to reinvent a wheel...
>
>Yes, you should look forward extending it through namespaces. Here's a 
>nice primer on the Atom API which shows some useful examples:
>
>http://www.xml.com/pub/a/2003/10/15/dive.html?page=2
>
...
Right...I've read this one before (and forgot).
Thanks a lot for the example.

>It's really that simple. 
Yes, but it's not easy to make it "standard" by one person..
My understanding is that the example is not yet implemented in MT.
Or maybe is?
I can't check it because MT3's Atom implementation has got a bug.

http://www.movabletype.org/support/index.php?act=ST&f=29&t=41904&s=
480ccec46c84af01c0459d7e655bda7b

And there seems to be no documentation about MT3's Atom implementation
available on the web.

Does anyone know that the Atom entry in MT is already extended using
a namespace?


Thanks


Toru Marumoto
     see you on the web!

--------------------------------


__________________________________________________
Do You Yahoo!?
http://bb.yahoo.co.jp/



From owner-atom-syntax@mail.imc.org  Mon Jul 19 04:04: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 EAA22833
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 04:04: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 i6J7rfon057139;
	Mon, 19 Jul 2004 00:53: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 i6J7rfPm057138;
	Mon, 19 Jul 2004 00:53:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from garland.duramedia.net (garland.duramdedia.net [209.51.131.138] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6J7rfOk057111
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 00:53:41 -0700 (PDT)
	(envelope-from jg@jonasgalvez.com)
Received: from 200-206-135-201.dsl.telesp.net.br ([200.206.135.201] ident=jgalvez)
	by garland.duramedia.net with esmtp (Exim 4.34)
	id 1BmSxu-0000wn-HU
	for atom-syntax@imc.org; Mon, 19 Jul 2004 03:53:39 -0400
Message-ID: <40FB7DA5.8000201@jonasgalvez.com>
Date: Mon, 19 Jul 2004 04:52:05 -0300
From: Jonas Galvez <jg@jonasgalvez.com>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: AtomSyntax <atom-syntax@imc.org>
Subject: Re: Blogging specific Options: Extended Text,Convert Line Breaks...
References: <40FB6481.30903@jonasgalvez.com> <34C46D6048B080torumyax@yahoo.co.jp>
In-Reply-To: <34C46D6048B080torumyax@yahoo.co.jp>
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 - garland.duramedia.net
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jonasgalvez.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


Toru Marumoto wrote:
> Yes, but it's not easy to make it "standard" by one person..

No matter how common some of these elements may be, I think they should
be seen as application-specific. Even if we standardize them in a manner
that would be acceptable to all implementors, we could still be adding
constraints to possible extensions.

But yes, trying to see it from the perspective of a developer who wants
to offer these features while mantaining compatibility with differently
extended implementations of the API, some sort of standardization
wouldn't hurt.

It's a tough one, at least for me. I'm sure this has already been
discussed before, and there must be a very good reason for not letting
these kinds of elements go into the spec.

I hope someone has the patience to post a brief clarification.

> Does anyone know that the Atom entry in MT is already extended using 
> a namespace?

I don't know, but there are a few MT developers on this list. I hope
they can answer it.



\\ jonas galvez
// jonasgalvez.com








From owner-atom-syntax@mail.imc.org  Mon Jul 19 05: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 FAA27473
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 05: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 i6J9Gxf2092405;
	Mon, 19 Jul 2004 02:16: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 i6J9GxC4092404;
	Mon, 19 Jul 2004 02:16: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 (pop.gmx.net [213.165.64.20])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6J9GwTN092328
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 02:16:58 -0700 (PDT)
	(envelope-from derhoermi@gmx.net)
Received: (qmail 28956 invoked by uid 65534); 19 Jul 2004 09:16:48 -0000
Received: from dsl-213-023-058-007.arcor-ip.net (EHLO localhost) (213.23.58.7)
  by mail.gmx.net (mp002) with SMTP; 19 Jul 2004 11:16:48 +0200
X-Authenticated: #723575
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Tim Bray <Tim.Bray@Sun.COM>
Cc: Atomlist Syntax <atom-syntax@imc.org>
Subject: Re: Low-hanging fruit: non-validating parser
Date: Mon, 19 Jul 2004 11:16:38 +0200
Message-ID: <40fe8ba7.186107598@smtp.bjoern.hoehrmann.de>
References: <E2DC94E5-D516-11D8-8C42-000A95A51C9E@sun.com>
In-Reply-To: <E2DC94E5-D516-11D8-8C42-000A95A51C9E@sun.com>
X-Mailer: Forte Agent 1.92/32.572
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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:
>I'm looking around seeing what we might be able to roll into -01 drafts 
>per discussion here.  I think we can update the Format Draft with Rob 
>Sayre's language: "Atom documents can be processed by non-validating 
>XML processors. An Atom document MUST NOT rely on any behaviors not 
>required of such processors."  [But I'd change "document MUST NOT" to 
>"software MUST NOT"]. -Tim

Hmm, "An Atom software MUST NOT rely on behaviors not required of such
processors"? That does not make much sense to me. Do you mean, Atom
implementations MUST NOT behave as validating XML 1.0 processors? Or
do you mean that Atom implementations MAY use a validating XML processor
to process Atom documents? It is also not clear what "rely" means, if
I have

  <!DOCTYPE feed [
    <!ENTITY foo SYSTEM "bar">
  ]><feed version="draft-ietf-atompub-format-00.txt: do not deploy"
    xmlns="http://purl.org/atom/ns#draft-ietf-atompub-format-00">
     <title>&foo;</title>
  ...

does that document rely on such behaviors? If yes, is this also true if
the reference to an external parsed entity occurs in the content of an
extension element? Exentsion elements are probably not essential to the
processing of Atom documents, so it would seem that a document using
that would not rely on such behaviors. If that is also not allowed, it
seems that the intent of the statement is, that Atom documents MUST NOT
contain references to external parsed entities and that attributes that
have a default value in the referenced external subset of the document
type declaration must be specified explicitly for the relevant elements.
I am not sure how a document could rely on Validation. So, the change
you suggest seems to yield in very different implications.



From owner-atom-syntax@mail.imc.org  Mon Jul 19 07:58: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 HAA07478
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 07:58: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 i6JBmKnI041403;
	Mon, 19 Jul 2004 04: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 i6JBmK9h041402;
	Mon, 19 Jul 2004 04:48:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from lakermmtao09.cox.net (lakermmtao09.cox.net [68.230.240.30])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JBmJQA041382
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 04:48:19 -0700 (PDT)
	(envelope-from millennium@spoonybards.net)
Received: from [10.0.1.2] (really [68.105.186.6]) by lakermmtao09.cox.net
          (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with ESMTP
          id <20040719114807.PIWW1759.lakermmtao09.cox.net@[10.0.1.2]>;
          Mon, 19 Jul 2004 07:48:07 -0400
Message-ID: <40FBB4EF.2090800@spoonybards.net>
Date: Mon, 19 Jul 2004 07:47:59 -0400
From: Beecher Greenman <millennium@spoonybards.net>
User-Agent: Mozilla Thunderbird 0.7 (Macintosh/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ken MacLeod <ken@bitsko.slc.ut.us>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceIntrospection: New Examples for Feed-Based Introspection
References: <40F52038.4050101@spoonybards.net> <m3u0walm7v.fsf@bitsko.slc.ut.us>
In-Reply-To: <m3u0walm7v.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: <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


Ken MacLeod wrote:
> Beecher Greenman <millennium@spoonybards.net> writes:
> 
> 
>>[Ken MacLeod wrote:]
>>
>>>If this resource description in the list of resource were a
>>><site> resource instead of an <entry> resource, the client would
>>>know better what to do with it.
>>
>>That data is redundant. A client which found this via autodiscovery
>>knows what types of entries to expect from the @rel attribute of the
>>autodiscovery link. If it doesn't use this link then it's violating
>>most common definitions of introspection (which need to be in the
>>context of the resource being introspected), and so we get an
>>ordinary list of links, which is really all we can hope to guess
>>about the client's intentions anyway.
> 
> 
> OK, this seems to be a very clear statement.  What this is saying is
> that one should determine the content type of a resource at a
> particular URI location:
> 
>  * not by its Internet Media Type (application/atom+xml),
>  * not by its XML namespace (http://purl.org/atom/ns#),

These last two cannot be used to determine the content type (as opposed 
to MIME type) anyway, because it has already been decided that there is 
only one of each of these for all Atom documents.

>  * not by its element type (namespace+localname), and

Namespace does not matter, as we've noted, because there is only one 
namespace for all Atom documents, unless you are willing to propose another.

>  * not by any other local means indicated within the content

Last I checked, Atom was an API, not a file format. As such, a feed 
loses most if not all of its meaning when it is references other than by 
its URI, as this is the mechanism used to call it. That is a consequence 
of the REST design we are using: without a URI or some other call point 
the document loses its meaning.

> but rather, solely by the external link property used to reference the
> resource (<link rel="service.feed">).
> 
> That doesn't work past the first time the link is copied to some other
> location, for *any* other purpose (linking, documentation, storage).
> Once the link reference "leaves its home", knowledge of what the
> resource "is" is lost.

I reiterate: this is a consequence of REST. To add this information in 
would violate that design principle, perhaps in a minor way but not an 
insignificant one. A client which needs to use this information in some 
sort of cached manner can cache the URL used to call it. Indeed, it 
already needs to do this, so that it can refresh the document as 
necessary. Given that it needs to store the URL, context need not be lost.

If there is truly a need to define what a feed is outside the context of 
its call, then that need exists whether or not we use feed-based 
introspection, because we have already "dual-purposed" <atom:feed> to 
describe both sites and contents within sites (see ContentsAreEntries). 
If such an element is already needed (<atom:resource> perhaps?) for 
"site" and "article" feeds, then it is trivial to add "introspection" to 
the list of allowable types.

- Beecher Greenman



From owner-atom-syntax@mail.imc.org  Mon Jul 19 08:23: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 IAA09769
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 08:23: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 i6JCFXLp046229;
	Mon, 19 Jul 2004 05:15: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 i6JCFXfh046228;
	Mon, 19 Jul 2004 05:15:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf17.cluster1.charter.net (mxsf17.cluster1.charter.net [209.225.28.217])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JCFW0v046206
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 05:15:33 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip16.cluster1.charter.net (mxip16a.cluster1.charter.net [209.225.28.146])
	by mxsf17.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6JCKp3k025490
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 08:20:51 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip16.cluster1.charter.net with ESMTP; 19 Jul 2004 08:15:26 -0400
X-Ironport-AV: i="3.81R,178,1083556800"; 
   d="scan'208"; a="125527233:sNHT15512576"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BmX2y-0004Q0-00
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 08:15:08 -0400
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: On LinkTagMeaning...
References: <87k6x2l3pj.fsf@nwalsh.com>
	<80FD9414-D8F9-11D8-81CD-000A95DC3D90@mac.com>
	<87zn5x55mh.fsf@nwalsh.com>
	<E0B3955B-D929-11D8-81CD-000A95DC3D90@mac.com>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Mon, 19 Jul 2004 08:15:05 -0400
In-Reply-To: <E0B3955B-D929-11D8-81CD-000A95DC3D90@mac.com> (dtcd@mac.com's
 message of "Sun, 18 Jul 2004 22:18:09 -0400")
Message-ID: <87hds45h2u.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: <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-Type: text/plain

/ Graham <dtcd@mac.com> was heard to say:
| Are you talking about fir relationships between entries? That doesn't
| make much sense, no. I mean for feeds - ie The main feed has a
| previous (or next - no one's sure) link to a feed of the earlier n
| entries, which has a link to the n before that, etc. It's not very
| robust and you'd have to periodically look through the whole lot for
| changes, but still, it's a lot better than not being able to get at
| previous entries at all.

Ah. Ok. I wasn't thinking about that. I guess that could be useful,
though I chose a different solution myself: I make a feed of the "top
30" that rotates over time and a feed of "everything". (Actually, I
make a bunch of topic-specific feeds too.)

But I can imagine that the "everything" feed might eventually be so
large that it was impractical and I'd want to break it into pieces.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | We do not know what thoughts stirred in
http://nwalsh.com/            | the mind of the last of the mastodons,
                              | but we can take it that they were
                              | nothing very remarkable. It is hardly
                              | likely that the last man will have the
                              | mind of a Goethe. He will die, and that
                              | will be the last stage of human
                              | progress.--Anatole France

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA+7tMOyltUcwYWjsRAjz9AJ4xNWPpxnVDzpWLGckppUkrQqYqigCdEfdm
DLb8HgM5vPEycmF/BMDbFRA=
=6EAO
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Mon Jul 19 08:24:36 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09958
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 08:24: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 i6JCDF7M045497;
	Mon, 19 Jul 2004 05:13: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 i6JCDFOF045496;
	Mon, 19 Jul 2004 05:13:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from lakermmtao07.cox.net (lakermmtao07.cox.net [68.230.240.32])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JCDEAC045482
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 05:13:14 -0700 (PDT)
	(envelope-from millennium@spoonybards.net)
Received: from [10.0.1.2] (really [68.105.186.6]) by lakermmtao07.cox.net
          (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with ESMTP
          id <20040719121304.ZXER16724.lakermmtao07.cox.net@[10.0.1.2]>;
          Mon, 19 Jul 2004 08:13:04 -0400
Message-ID: <40FBBAC8.1080505@spoonybards.net>
Date: Mon, 19 Jul 2004 08:12:56 -0400
From: Beecher Greenman <millennium@spoonybards.net>
User-Agent: Mozilla Thunderbird 0.7 (Macintosh/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mark Pilgrim <pilgrim@gmail.com>
CC: Ken MacLeod <ken@bitsko.slc.ut.us>, Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceIntrospection: New Examples for Feed-Based Introspection
References: <40F52038.4050101@spoonybards.net> <m3u0walm7v.fsf@bitsko.slc.ut.us> <14be96d30407140738693529e9@mail.gmail.com>
In-Reply-To: <14be96d30407140738693529e9@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


>>OK, this seems to be a very clear statement.  What this is saying is
>>that one should determine the content type of a resource at a
>>particular URI location:
>>
>> * not by its Internet Media Type (application/atom+xml),
>> * not by its XML namespace (http://purl.org/atom/ns#),
>> * not by its element type (namespace+localname), and
>> * not by any other local means indicated within the content
>>
>>but rather, solely by the external link property used to reference the
>>resource (<link rel="service.feed">).
>>
>>That doesn't work past the first time the link is copied to some other
>>location, for *any* other purpose (linking, documentation, storage).
>>Once the link reference "leaves its home", knowledge of what the
>>resource "is" is lost.
> 
> 
> More to the point, it violates every best practice detailed in
> <http://www.w3.org/2001/tag/doc/mime-respect.html>.  Participants in
> this thread who disagree with Ken would do well to read (or re-read)
> that document, in particular section 5
> <http://www.w3.org/2001/tag/doc/mime-respect.html#specs>, which
> explicitly mentions the priority of the HTML link element as compared
> to other (possibly conflicting) server-generated metadata.
> 
I would agree with you, but there is a problem with using MIME to 
determine the feed's content type: we only have one MIME type for all 
Atom documents at this point. "application/atom+xml" is useful for 
determining that a document is Atom, but by itself it cannot tell us 
anything more about it. If we want to instead use one MIME type for each 
kind of Atom call, perhaps "application/atom+xml:introspection", 
"application/atom+xml:syndication", and "application/atom+xml:edit" 
among others, then MIME types would come into play. At the present, 
however, these MIME types do not exist.

This said, since we need the URL to provide the context for what the 
file means, there are several ways of providing it if we don't want to 
rely on clients to cache it. The way which changes the spec the least 
would be to add to <atom:link>, perhaps with a new @rel value of 
"call-point" or even by adding the little-used @rev from HTML in, with a 
value of "introspection". Either suggestion is likely to get me 
crucified here, but if we're going to use REST then we may as well be 
hardcore about it.

On the other hand, perhaps there is a need for, as Ken suggested, an 
<atom:resource-type> attribute. If this would be needed for 
introspection, then we already need it for feeds anyway, as a matter of 
distinguishing when a feed lists articles and when it lists comments, so 
it cannot be considered a real barrier to using feeds for introspection.

- Beecher Greenman



From owner-atom-syntax@mail.imc.org  Mon Jul 19 08:28: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 IAA10339
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 08:28: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 i6JCI02K046592;
	Mon, 19 Jul 2004 05:18: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 i6JCI03b046591;
	Mon, 19 Jul 2004 05:18:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf20.cluster1.charter.net (mxsf20.cluster1.charter.net [209.225.28.220])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JCHxhg046563
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 05:17:59 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip18.cluster1.charter.net (mxip18a.cluster1.charter.net [209.225.28.148])
	by mxsf20.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6JCO4nD023689
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 08:24:04 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip18.cluster1.charter.net with ESMTP; 19 Jul 2004 08:17:52 -0400
X-Ironport-AV: i="3.81R,178,1083556800"; 
   d="scan'208"; a="126511253:sNHT14837152"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BmX5C-0004QJ-00
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 08:17:26 -0400
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Low-hanging fruit: non-validating parser
References: <E2DC94E5-D516-11D8-8C42-000A95A51C9E@sun.com>
	<40fe8ba7.186107598@smtp.bjoern.hoehrmann.de>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Mon, 19 Jul 2004 08:17:26 -0400
In-Reply-To: <40fe8ba7.186107598@smtp.bjoern.hoehrmann.de> (Bjoern
 Hoehrmann's message of "Mon, 19 Jul 2004 11:16:38 +0200")
Message-ID: <87d62s5gyx.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: <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-Type: text/plain

/ Bjoern Hoehrmann <derhoermi@gmx.net> was heard to say:
| * Tim Bray wrote:
|>I'm looking around seeing what we might be able to roll into -01 drafts 
|>per discussion here.  I think we can update the Format Draft with Rob 
|>Sayre's language: "Atom documents can be processed by non-validating 
|>XML processors. An Atom document MUST NOT rely on any behaviors not 
|>required of such processors."  [But I'd change "document MUST NOT" to 
|>"software MUST NOT"]. -Tim
|
| Hmm, "An Atom software MUST NOT rely on behaviors not required of such
| processors"? That does not make much sense to me. Do you mean, Atom
| implementations MUST NOT behave as validating XML 1.0 processors? Or

No, I think it just means the spec must not require implementors to
use a validating parser.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Vision is the art of seeing things
http://nwalsh.com/            | invisible.-- Swift

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA+7vWOyltUcwYWjsRAtHkAKCO2NCOPVNdCohe6z9JzUgMW2WCEgCfcIE5
UtCDQUJscG/0zzA/LJNvrJE=
=n8d2
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Mon Jul 19 09:00:34 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13253
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 09:00: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 i6JCmbXK052158;
	Mon, 19 Jul 2004 05:48:37 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6JCmbu5052157;
	Mon, 19 Jul 2004 05:48: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 i6JCma7n052149
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 05:48:36 -0700 (PDT)
	(envelope-from mint@franklinmint.fm)
Received: from user-12lcgee.cable.mindspring.com ([69.86.65.206] helo=[192.168.0.6])
	by web02.designerslab.net with asmtp (Exim 4.34)
	id 1BmXZI-0007VX-F5; Mon, 19 Jul 2004 12:48:32 +0000
Message-ID: <40FBC308.9070601@franklinmint.fm>
Date: Mon, 19 Jul 2004 08:48:08 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Bjoern Hoehrmann <derhoermi@gmx.net>
CC: Tim Bray <Tim.Bray@Sun.COM>, Atomlist Syntax <atom-syntax@imc.org>
Subject: Re: Low-hanging fruit: non-validating parser
References: <E2DC94E5-D516-11D8-8C42-000A95A51C9E@sun.com> <40fe8ba7.186107598@smtp.bjoern.hoehrmann.de>
In-Reply-To: <40fe8ba7.186107598@smtp.bjoern.hoehrmann.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: <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


Bjoern Hoehrmann wrote:

>
>Hmm, "An Atom software MUST NOT rely on behaviors not required of such
>processors"? That does not make much sense to me. Do you mean, Atom
>implementations MUST NOT behave as validating XML 1.0 processors? Or
>do you mean that Atom implementations MAY use a validating XML processor
>to process Atom documents? It is also not clear what "rely" means
>
This language is pretty much copied from the XML 1.0 spec, section 5.2:

"For maximum reliability in interoperating between different XML 
processors, applications which use non-validating processors should not 
rely on any behaviors not required of such processors."

I found it difficult to state more clearly. Feel free to suggest 
alternate wording.

Robert Sayre



From owner-atom-syntax@mail.imc.org  Mon Jul 19 09:24: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 JAA15149
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 09:24: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 i6JDFug4057529;
	Mon, 19 Jul 2004 06: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 i6JDFuQZ057528;
	Mon, 19 Jul 2004 06:15: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 (pop.gmx.de [213.165.64.20])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6JDFts2057511
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 06:15:56 -0700 (PDT)
	(envelope-from derhoermi@gmx.net)
Received: (qmail 5350 invoked by uid 65534); 19 Jul 2004 13:15:51 -0000
Received: from dsl-213-023-058-007.arcor-ip.net (EHLO localhost) (213.23.58.7)
  by mail.gmx.net (mp008) with SMTP; 19 Jul 2004 15:15:51 +0200
X-Authenticated: #723575
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: mint@franklinmint.fm
Cc: atom-syntax@imc.org
Subject: Re: Low-hanging fruit: non-validating parser
Date: Mon, 19 Jul 2004 15:15:37 +0200
Message-ID: <4101c636.201099085@smtp.bjoern.hoehrmann.de>
References: <E2DC94E5-D516-11D8-8C42-000A95A51C9E@sun.com> <40fe8ba7.186107598@smtp.bjoern.hoehrmann.de> <40FBC308.9070601@franklinmint.fm>
In-Reply-To: <40FBC308.9070601@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:
>>Hmm, "An Atom software MUST NOT rely on behaviors not required of such
>>processors"? That does not make much sense to me. Do you mean, Atom
>>implementations MUST NOT behave as validating XML 1.0 processors? Or
>>do you mean that Atom implementations MAY use a validating XML processor
>>to process Atom documents? It is also not clear what "rely" means
>>
>This language is pretty much copied from the XML 1.0 spec, section 5.2:
>
>"For maximum reliability in interoperating between different XML 
>processors, applications which use non-validating processors should not 
>rely on any behaviors not required of such processors."

You are looking at an outdated revision of the specification, the Third
Edition reads:

[...]
  For maximum reliability in interoperating between different XML
  processors, applications which use non-validating processors SHOULD
  NOT rely on any behaviors not required of such processors.
  Applications which require DTD facilities not related to validation
  (such as the declaration of default attributes and internal entities
  that are or may be specified in external entities) SHOULD use
  validating XML processors.
[...]

It is not clear to me what you have in mind here for Atom documents
and/or Atom implementations. You would copy the text and replace all
instances of "application" with "Atom implementation". I do not know
whether Atom implementations require DTD facilities not related to
validation. They would if Atom documents use DTDs or certain features
from DTDs. If Atom documents are allowed to do that, it would mean
that Atom implementations SHOULD use validating XML processors for
maximum reliability. And if they do not use one, they should not rely
on features optional for non-validating processors. Even then it is
not clear to me what "rely" would mean. So,

>I found it difficult to state more clearly. Feel free to suggest 
>alternate wording.

since I do not really understand your intent, proposing alternate
wording would be quite difficult for me...



From owner-atom-syntax@mail.imc.org  Mon Jul 19 11: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 LAA27905
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 11: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 i6JFH87b079169;
	Mon, 19 Jul 2004 08: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 i6JFH8r1079168;
	Mon, 19 Jul 2004 08:17:08 -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 i6JFH6KF079148
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 08:17: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 i6JFH353009058
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 10:17:04 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6JFH31V009054;
	Mon, 19 Jul 2004 10:17:03 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PacePutDelete Withdrawn
References: <1090165177.2738485554.17777.sendItem@bloglines.com>
	<DFBF4C9F-D8D4-11D8-92AF-000A95A51C9E@sun.com>
	<m3llhhdzgv.fsf@bitsko.slc.ut.us>
	<72940BAE-D8FB-11D8-933E-003065B8CF0E@iki.fi>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 19 Jul 2004 10:17:02 -0500
In-Reply-To: <72940BAE-D8FB-11D8-933E-003065B8CF0E@iki.fi>
Message-ID: <m3zn5wc9ht.fsf@bitsko.slc.ut.us>
Lines: 28
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


Henri Sivonen <hsivonen@iki.fi> writes:

> On Jul 18, 2004, at 19:58, Ken MacLeod wrote:
> 
> >   <quarkie> yup. as he writes: "If the Atom spec specifies how to
> >   convert a Web Forms 2.0 form data set into an
> >   'application/atom+xml' encoded form data set, then UAs can
> >   implement it."
> 
> What would be the point of burdening a Web Forms 2.0 UA with Atom?
> If you are able to spec how to build an Atom entry out of a form
> dataset, surely the conversion can be done on the server instead of
> introducing yet another submission format for UAs to support.

It's not burdening Web Forms 2.0 UA with Atom, it's Web Forms 2.0 UA
being XML and REST enabled.  The conversion between XML and Form is
done with a supplied stylesheet.

I suspect the end result will be something like Naked Objects[1] over
the web.

The point is that they're speccing PUT and DELETE for forms and for
use with formats like ours, and we'll get to see how it works out in
practice with "just a browser".

  -- Ken

[1] http://www.nakedobjects.org/



From owner-atom-syntax@mail.imc.org  Mon Jul 19 12:31: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 MAA02800
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 12:31: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 i6JGIrx5090247;
	Mon, 19 Jul 2004 09:18: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 i6JGIrM3090246;
	Mon, 19 Jul 2004 09:18:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JGIohc090236;
	Mon, 19 Jul 2004 09:18:51 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p06110439bd21a3976c9e@[10.20.30.249]>
In-Reply-To: <20040719045005.GY30868@markbaker.ca>
References: <BD1DD57F.13D52%mint@franklinmint.fm>
 <40F892F1.5040105@bitworking.org> <p06110415bd1e4c1ed10a@[10.20.30.249]>
 <20040719045005.GY30868@markbaker.ca>
Date: Mon, 19 Jul 2004 09:16:57 -0700
To: Mark Baker <distobj@acm.org>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: Private extension support (was Re: Q: Put request should
 return Atom entry?
Cc: Atom Syntax <atom-syntax@imc.org>
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 12:50 AM -0400 7/19/04, Mark Baker wrote:
>On Fri, Jul 16, 2004 at 08:27:40PM -0700, Paul Hoffman / IMC wrote:
>>  Not quite. Because "servers MAY include", clients "MUST NOT expect".
>>  This is a direct interoperability interpretation. If I'm creating a
>>  client that expects additional info, it will not interoperate with
>>  some conformant servers.
>
>Mostly, but there are different forms of interoperatation.  By using
>"SHOULD NOT", I meant to support the case where private (but declared)
>extensions between clients and servers were used, which provides a
>degraded form of interop where agents not party to the extension can
>at least determine that they don't understand the message and fail
>gracefully.  For example, imagine an extension called
>"ReturnBodyOnPut" which a client declares as mandatory in the PUT
>message.
>
>Discussion to date concerning Atom extensibility has suggested the need
>for "must understand" support in the data format.  What I'm talking
>about is doing the same thing for the protocol, at least where the
>protocol supports it (e.g. SOAP).
>
>The bigger question though, is whether or not the group is interested in
>supporting private extensions.

In a word: no. Public extensions are fine and will be fully and 
enthusiastically supported by Atom. In the case above, a public 
extension could say "this extension changes the 'MUST NOT expect' 
from the base spec to 'SHOULD expect' when this extension is 
present". But that is done explicitly in the particular extension 
spec, not in a private fashion.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Mon Jul 19 13:01:23 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06317
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 13:01:23 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JGnsnk095306;
	Mon, 19 Jul 2004 09:49: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 i6JGnsiw095302;
	Mon, 19 Jul 2004 09:49:54 -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 i6JGnsG5095292;
	Mon, 19 Jul 2004 09:49:54 -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 i6JGno4Q027892;
	Mon, 19 Jul 2004 09:49:50 -0700
Received: from ussjex01.amer.bea.com ([172.16.120.50]) by ussjfe01.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 19 Jul 2004 09:49:49 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Private extension support (was Re: Q: Put request should return Atom entry?
Date: Mon, 19 Jul 2004 09:49:49 -0700
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF08FA6DCF@ussjex01.amer.bea.com>
Thread-Topic: Private extension support (was Re: Q: Put request should return Atom entry?
Thread-Index: AcRtTE7nIwdCeLKXRIakOI/qJTBGCwAZBJ/A
From: "David Orchard" <dorchard@bea.com>
To: "Mark Baker" <distobj@acm.org>, "Paul Hoffman / IMC" <phoffman@imc.org>
Cc: "Atom Syntax" <atom-syntax@imc.org>
X-OriginalArrivalTime: 19 Jul 2004 16:49:49.0998 (UTC) FILETIME=[6803FCE0:01C46DB0]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6JGnsG5095293
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 wrote up some thoughts a while ago on applying some "standard" format extensibility rules to protocols

http://www.pacificspirit.com/blog/2004/06/14/protocol_extensibility_and_versioning

Seems like a reasonable question to ask, but it's harder to figure out what to do...

cheers,
Dave

> -----Original Message-----
> From: owner-atom-syntax@mail.imc.org
> [mailto:owner-atom-syntax@mail.imc.org]On Behalf Of Mark Baker
> Sent: Sunday, July 18, 2004 9:50 PM
> To: Paul Hoffman / IMC
> Cc: Atom Syntax
> Subject: Private extension support (was Re: Q: Put request 
> should return
> Atom entry?
> 
> 
> 
> On Fri, Jul 16, 2004 at 08:27:40PM -0700, Paul Hoffman / IMC wrote:
> > Not quite. Because "servers MAY include", clients "MUST NOT 
> expect". 
> > This is a direct interoperability interpretation. If I'm creating a 
> > client that expects additional info, it will not interoperate with 
> > some conformant servers.
> 
> Mostly, but there are different forms of interoperatation.  By using
> "SHOULD NOT", I meant to support the case where private (but declared)
> extensions between clients and servers were used, which provides a
> degraded form of interop where agents not party to the extension can
> at least determine that they don't understand the message and fail
> gracefully.  For example, imagine an extension called
> "ReturnBodyOnPut" which a client declares as mandatory in the PUT
> message.
> 
> Discussion to date concerning Atom extensibility has 
> suggested the need
> for "must understand" support in the data format.  What I'm talking
> about is doing the same thing for the protocol, at least where the
> protocol supports it (e.g. SOAP).
> 
> The bigger question though, is whether or not the group is 
> interested in
> supporting private extensions.
> 
> Mark.
> -- 
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
> 
>   Seeking work on large scale application/data integration projects
>   and/or the enabling infrastructure for same.
> 
> 



From owner-atom-syntax@mail.imc.org  Mon Jul 19 13:02: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 NAA06427
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 13: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 i6JGoC6B095359;
	Mon, 19 Jul 2004 09:50: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 i6JGoCpt095357;
	Mon, 19 Jul 2004 09:50:12 -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 i6JGoCj4095343;
	Mon, 19 Jul 2004 09:50:12 -0700 (PDT)
	(envelope-from distobj@acm.org)
Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian))
	id 1BmbLp-0002vc-00; Mon, 19 Jul 2004 12:50:53 -0400
Date: Mon, 19 Jul 2004 12:50:53 -0400
To: Paul Hoffman / IMC <phoffman@imc.org>
Cc: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Private extension support (was Re: Q: Put request should return Atom entry?
Message-ID: <20040719165053.GZ30868@markbaker.ca>
References: <BD1DD57F.13D52%mint@franklinmint.fm> <40F892F1.5040105@bitworking.org> <p06110415bd1e4c1ed10a@[10.20.30.249]> <20040719045005.GY30868@markbaker.ca> <p06110439bd21a3976c9e@[10.20.30.249]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <p06110439bd21a3976c9e@[10.20.30.249]>
User-Agent: Mutt/1.3.28i
From: Mark Baker <distobj@acm.org>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


On Mon, Jul 19, 2004 at 09:16:57AM -0700, Paul Hoffman / IMC wrote:
> >The bigger question though, is whether or not the group is interested in
> >supporting private extensions.
> 
> In a word: no. Public extensions are fine and will be fully and 
> enthusiastically supported by Atom. In the case above, a public 
> extension could say "this extension changes the 'MUST NOT expect' 
> from the base spec to 'SHOULD expect' when this extension is 
> present".  But that is done explicitly in the particular extension 
> spec, not in a private fashion.

Perhaps my use of the word "private" brings with it some unintended
semantics.  Let me explain another way ...

Atom - format and protocol - *will* be extended in ways which are not
publically specified; history shows us that this is inevitable.  What
explicit recognition for this buys us is graceful degradation when
extended agents bump up against unextended ones.

FWIW, incorporating support for mandatory extensions is fairly common
practice nowadays in protocol (and more commonly, data format) design.
SOAP has them[1], SMIL has them[2], Waka[3] will have them, and HTTP
wants them[4][5].  And as I mentioned, it seems that the Atom data
format will also support them.  I don't think it's too much to ask then,
that the Atom "API" at least consider them.

Cheers,

 [1] http://www.w3.org/TR/soap12-part1/#soapmu
 [2] http://www.w3.org/TR/smil20/smil-content.html#ContentControlNS-SkipContentAttribute
 [3] http://gbiv.com/protocols/waka/
 [4] http://www.w3.org/TR/WD-http-pep-971121
 [5] http://www.ietf.org/rfc/rfc2774.txt

Mark.



From owner-atom-syntax@mail.imc.org  Mon Jul 19 13: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 NAA09479
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 13: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 i6JHOnwd002032;
	Mon, 19 Jul 2004 10:24: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 i6JHOn67002030;
	Mon, 19 Jul 2004 10:24:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JHOlB4002014
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 10:24:48 -0700 (PDT)
	(envelope-from hsivonen@iki.fi)
Received: from 217-140-251-133.adsl-net.finnetcom.net ([217.140.251.133]:62940
        "EHLO [217.140.251.133]" TLS-CIPHER: <none>) by smtp2.dnainternet.net
        with ESMTP id S1229527AbUGSRYk (ORCPT <rfc822;atom-syntax@imc.org>);
        Mon, 19 Jul 2004 20:24:40 +0300
Mime-Version: 1.0 (Apple Message framework v618)
In-Reply-To: <m3zn5wc9ht.fsf@bitsko.slc.ut.us>
References: <1090165177.2738485554.17777.sendItem@bloglines.com> <DFBF4C9F-D8D4-11D8-92AF-000A95A51C9E@sun.com> <m3llhhdzgv.fsf@bitsko.slc.ut.us> <72940BAE-D8FB-11D8-933E-003065B8CF0E@iki.fi> <m3zn5wc9ht.fsf@bitsko.slc.ut.us>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <82B0ECD4-D9A8-11D8-933E-003065B8CF0E@iki.fi>
Content-Transfer-Encoding: 7bit
From: Henri Sivonen <hsivonen@iki.fi>
Subject: Re: PacePutDelete Withdrawn
Date:   Mon, 19 Jul 2004 20:24:37 +0300
To: Atom Syntax <atom-syntax@imc.org>
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>
Content-Transfer-Encoding: 7bit


On Jul 19, 2004, at 18:17, Ken MacLeod wrote:

> Henri Sivonen <hsivonen@iki.fi> writes:
>
>> What would be the point of burdening a Web Forms 2.0 UA with Atom?
>> If you are able to spec how to build an Atom entry out of a form
>> dataset, surely the conversion can be done on the server instead of
>> introducing yet another submission format for UAs to support.
>
> It's not burdening Web Forms 2.0 UA with Atom, it's Web Forms 2.0 UA
> being XML and REST enabled.

XML and REST don't imply Atom envelopes. In fact, one might argue that 
in order to publish HTML it would be more RESTian to PUT straight HTML 
without an envelope.

> The conversion between XML and Form is done with a supplied stylesheet.

I think you mean an XSLT transformation. I don't think solutions that 
require client-side XSLT will end up in Web Forms 2.0.

See:
http://www.hixie.ch/advocacy/xslt
http://groups.google.com/groups?selm=oprtucqzcxn2y593%40news.opera.com

(FWIW, I agree with Hixie on XSLT as far as the client side goes.)

-- 
Henri Sivonen
hsivonen@iki.fi
http://iki.fi/hsivonen/



From owner-atom-syntax@mail.imc.org  Mon Jul 19 14:01: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 OAA11635
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 14:01: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 i6JHpqwC006972;
	Mon, 19 Jul 2004 10:51: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 i6JHpqc5006971;
	Mon, 19 Jul 2004 10:51:52 -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 i6JHppec006948
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 10:51:52 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 46730 messnum 7808334 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 19 Jul 2004 17:51:49 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail01.svc.cra.dublin.eircom.net (qp 46730) with SMTP; 19 Jul 2004 17:51:49 -0000
Message-ID: <40FC0A2F.8070709@dehora.net>
Date: Mon, 19 Jul 2004 18:51: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: Mark Baker <distobj@acm.org>
CC: Paul Hoffman / IMC <phoffman@imc.org>, Atom Syntax <atom-syntax@imc.org>
Subject: Re: Private extension support (was Re: Q: Put request should return
 Atom entry?
References: <BD1DD57F.13D52%mint@franklinmint.fm> <40F892F1.5040105@bitworking.org> <p06110415bd1e4c1ed10a@[10.20.30.249]> <20040719045005.GY30868@markbaker.ca> <p06110439bd21a3976c9e@[10.20.30.249]> <20040719165053.GZ30868@markbaker.ca>
In-Reply-To: <20040719165053.GZ30868@markbaker.ca>
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


Mark Baker wrote:

> On Mon, Jul 19, 2004 at 09:16:57AM -0700, Paul Hoffman / IMC wrote:
> 
>>>The bigger question though, is whether or not the group is interested in
>>>supporting private extensions.
>>
>>In a word: no. Public extensions are fine and will be fully and 
>>enthusiastically supported by Atom. In the case above, a public 
>>extension could say "this extension changes the 'MUST NOT expect' 
>>from the base spec to 'SHOULD expect' when this extension is 
>>present".  But that is done explicitly in the particular extension 
>>spec, not in a private fashion.
> 
> 
> Perhaps my use of the word "private" brings with it some unintended
> semantics.  Let me explain another way ...

No, I think it was the word 'support',  where support could imply 
enablement, encouragement or both.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Mon Jul 19 14:02: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 OAA11753
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 14:02: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 i6JHqOQT007059;
	Mon, 19 Jul 2004 10:52: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 i6JHqO9M007058;
	Mon, 19 Jul 2004 10:52:24 -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 i6JHqNHI007051
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 10:52:23 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net (rdu57-27-065.nc.rr.com [66.57.27.65])
	(authenticated bits=0)
	by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i6JHrG2N014369
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 13:53:16 -0400
Message-ID: <40FC0A55.5090409@intertwingly.net>
Date: Mon, 19 Jul 2004 13:52:21 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: PaceLinkAttrDefaults
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


http://www.intertwingly.net/wiki/pie/PaceLinkAttrDefaults

  - - -

Preamble:

   Can you live with

     <link href="uri"/>

   ?

  - - -

Preface:

"Having an element that says, here is a pointer to some data that is 
related to this entry that is too large to fit in the feed is a good 
idea. Similarly providing a hint at what the MIME type is so the reader 
knows whether it can handle that MIME type or can display something 
specific to that media type in the user interface without making an 
additional request to the server is very useful."

Dare Obasanjo, 
http://www.25hoursaday.com/weblog/default.aspx?date=2004-05-26

  - - -

Main text

There is a lot of hyperbole floating around relating to the link tag. 
Let me start of by stating some non-goals:

1) It is a non-goal of the link element to define an extensibility model 
that enables consumers to achieve an almost AI like ability to sense and 
adapt to new constructs that may be introduced at some point in the far 
distant future.

2) It is a non-goal of the link element to make anything more than 
minor, incremental, adaptations over the existing prior art of HTML link 
tags, RSS link tags, and RSS 2.0 enclosure tags.  In particular, it is a 
non-goal to introduce "co-occurence constraints" or a type system.

3) It is a non-goal to make all producers to provide information that 
they don't have, or to make all consumers interpret all link tags 
identically.

  - - -

Now, lets explore what a link tag is in terms of an abstract "schema". 
In relational database terms, a link element when used within a the 
context of an atom entry would be a table:

The first column is id of the entry.  This is a foreign key.

There are five additional columns, rel, type, href, hreflang, and title. 
  Rel has a default of "alternate".  href has a non-null constraint. 
All the remaining elements may be null.

None of these columns are a primary key.

  - - -

Now lets explore usage scenarios.  First from a producer perspective, 
the primary usage would be to declare the permalink associated with this 
entry.  From a syntax perspective, this usage should be optimized for. 
As the type attribute is merely advisory, it should be recommended but 
not be required.  The remaining attributes should only be provided if known.

  - - -

Continuing with a consumer perspective, there are a number of use cases. 
  Identifying the permalink is obviously a key one.  In relational db terms:

   select href from link where entryid='uri' and rel='alternate'

RSSBandit may wish to identifying calendar events, thus:

   select href,title from link where entryid='uri' and type='text/calendar'

Bloglines may with to identify which blog entries reference a given one 
thus:

   select entryid from link where href='uri'

  - - -

 From a syntax perspective, the most common use case is should be able 
to be simply expressed thus:

   <link href="uri"/>

A link blog may want to acknowledge the origin of a given bit of news, thus:

   <link href="uri" rel="via"/>

An event could be indicated thus:

   <link href="uri" rel="event" type="text/calendar"/>

  - - -

Prior art includes the RSS link tag, which variously would be used to 
point to the permalink of the item itself, or to the full story that is 
summarized by the item.

Then there is the HTML link tag, which defines most of the semantics of 
this link tag.

Then there is the enclosure element in RSS 2.0 that, while perhaps 
misnamed, does a reasonably good job - with one exception, first noted 
by Dare.  Outside of the specification itself, an expectation was set 
that an enclosure was to be automatically downloaded asynchronously; 
enough so that it impeeded other use cases.

  - -

Summary:

The purpose is not to make things automagically happen.  There is no 
pixie dust.  The purpose it so enable a small bit of loose coupling. 
Producers provide what information that they have available.  Consumers 
select what they recognize, and ignore the rest.

  - - -

Impacts: existing producers may want to take advantage of the new 
defaults.  Consumers will have to deal appropriately with the new defaults.



From owner-atom-syntax@mail.imc.org  Mon Jul 19 14:09: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 OAA12218
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 14: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 i6JHvVBG007735;
	Mon, 19 Jul 2004 10:57: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 i6JHvVkF007734;
	Mon, 19 Jul 2004 10:57:31 -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 i6JHvU4t007728
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 10:57:30 -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 i6JHvZ4Q002816
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 10:57:35 -0700
Received: from ussjex01.amer.bea.com ([172.16.120.50]) by ussjfe01.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 19 Jul 2004 10:57:34 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: PaceExtensibilityAndVersioning
Date: Mon, 19 Jul 2004 10:57:34 -0700
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF08FA6F0F@ussjex01.amer.bea.com>
Thread-Topic: PaceExtensibilityAndVersioning
Thread-Index: AcRtugM2v3Ul/oQJQjOs1B2fHeQtwg==
From: "David Orchard" <dorchard@bea.com>
To: "Atom Syntax" <atom-syntax@imc.org>
X-OriginalArrivalTime: 19 Jul 2004 17:57:34.0503 (UTC) FILETIME=[DEA63B70:01C46DB9]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6JHvV4t007729
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


http://www.intertwingly.net/wiki/pie/PaceExtensibilityAndVersioning

== Abstract ==

This proposal provides for extensibility and versioning of Atom.  The format rules are roughly: re-use namespace names when possible, ie compatible change, follow the "Must Ignore unknown extensions" rule, and provide "mustUnderstand" attribute for extensibility, change namespaces when making breaking, ie incompatible, changes.

== Proposal ==

The following text is to be inserted into the format specification

New format section 3.1.3 "mustUnderstand" attribute
The "mustUnderstand" attribute indicates whether the parent element MUST be understood by Atom processors.  The default value is false.

Into each element description in 4.x ensure:
XYZ type allows attributes from any namespace.  XYZ type allows XML elements from any namespace.  

Remove section 4.1

New section 7 Extending and Versioning Atom

Atom allows any party to extend instances of Atom using a namespace other than the atom format namespace name.  Atom may make changes to it's namespace and/or qnames, and this is called versioning.  This section describes the processing model, extensibility and namespace models for extensibility and versioning.

An optional change means that existing software that doesn't know about the change should not break.  A required change means that software that doesn't know about the change must break if it doesn't understand the change.  The meaning of "understanding" is up to the change owner.  It typically means at least a human has read a specification and/or software can validate the type according to the type definition.

7.1 Processing model

All atom compliant processor MUST ignore any unknown namespace qualified XML attribute content.  All atom compliant processor MUST ignore any unknown XML element content in any namespace and all it's descendents UNLESS the atom:mustUnderstand flag on the element is set to "true".  An atom compliant processor MUST process all elements marked with mustUnderstand="true" or process none at all.  A Fault must be generated if any element marked mustUnderstand is not understood.

7.2 Atom namespace management policy

Any future version of Atom that is backwards compatible with this version will use this namespace name.  An example is adding an optional element or attribute.  

Any future version of Atom that is incompatible with this version will either use a different namespace name or will use an element name not defined in this specification.  An example is adding a required element/attribute or removing an element or attribute.

7.3 Atom 3rd party extensibility

3rd parties are allowed to extend Atom.  They MUST use namespace names they control.  The default for 3rd party extensions is that they will be ignored by processors if the processor does not know about the extension, as defined by section 7.1.  Element extensions may be marked with atom:mustUnderstand to indicate that  processor must fault if the extension is unknown.

7.4 Sample extensibility scenarios.

The following are some sample scenarios of extensibility and versioning.

7.4.1 Atom optional extension element

A subsequent version of Atom adds an optional element to entry called atom:foo.  The format specification contains the definition of foo and the allowed/disallowed locations for foo.  This may be safely ignored by all processors.  The Atom namespace is re-used.  

7.4.2 Atom required extension element

A subsequent version of Atom adds a required element to entry called atom:bar.  The format specification contains the definition of bar and the allowed/disallowed locations for bar.   This must be understood by all processors.  A new atom namespace name is used for all the existing atom names (feeed, entry, bar, etc.).

7.4.3 Atom incompatible change

A subsequent version of Atom makes an incompatible change that is not an addition.  This could be changing the semantics of existing elements or attributes, removing an attribute or element.  As per 7.4.2, a new atom namespace name is used.

7.4.4 3rd party optional addition

A 3rd party creates an extension called thirdpartyns:foo.  Atom instances may contain foo in any of the extensibility points unless the 3rd party has provided a format document that specifies otherwise.  The instance contains a mustUnderstand="false" or it is not set.

7.4.5 3rd party required extension

A 3rd party creates an extension called thirdpartyns:bar.  Atom instances may contain foo in any of the extensibility points unless the 3rd party has provided a format document that specifies otherwise. The instance contains a mustUnderstand="true".

7.4.6 3rd party extensions refered to by atom

A 3rd party creates an extension called thirdpartyns:author.  Atom instances may contain thirdpartyns:author in a specific location.  The atom format specification contains the allowed/disallowed locations for thirdpartyns:author and refers to the third party definition of author.  In the case of a mandatory extension, a new atom namespace name is minted OR the extension is marked with mustUnderstand="true".

7.4.7 enumeration extensibility

Atom or a 3rd party create an additional attribute value, such as extending the "rel" type.  If this is optional, it may be simply added in.  If mandatory to be understood then Atom has the opportunity to create a new qname for the extended attribute.  Atom and 3rd parties can create a new extension element and mark it mustUnderstood.  There is no mechanism for 3rd party to add in a mandatory enumeration value.

7.5 schema languages for extensibility

XML Schema, RelaxNG, and RDF/OWL each provide different capabilities for extensibility and versioning.  There is discussion about which languages to use to specify machine readable constraints on Atom

XML Schema has particular difficulty in allowing elements to be mixed in at the same level as existing elements in extension namespace.  A wildcard is not allowed at the same level as an optional element (in the same namespace) because of the "Unique Particle Attribution Rule".  This problem, and a solution, is described in http://www.pacificspirit.com/Authoring/Compatibility/ExaminingElementWildcardSiblings.html.

Atom must do one of the following wrt extensibility and schema languages:
 * Using XML Schema, the format must use mechanisms in addition to wildcards to enable schema creation, ie extension elements
 * Using XML Schema, the schema is not revised for backwards compatible extensions or versions.
 * Does not use XML Schema

End of inserted text

Out of scope
 * Protocol extensibility (New verbs for Feed, Edit, Post URIs, new URIs + verbs )
 * Supporting in a backwards compatible way the removal of elements/attributes.  There is no need for an XSLT style versioning model for testing for a version number and switching between instances.
 * Supporting arbitrary transformations between newer types and older types.  There is no need for shipping an XSLT with an instance to transform it to an older version.
 * different extensibility models for different linktype
 * Grouping multiple extensions and versions into a single specification aka profile


== Discussion ==


== Author ==

DaveOrchard

----

CategoryProposals

Cheers,
Dave



From owner-atom-syntax@mail.imc.org  Mon Jul 19 14:15:10 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12753
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 14:15:10 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JI2q4d009698;
	Mon, 19 Jul 2004 11:02: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 i6JI2qWn009697;
	Mon, 19 Jul 2004 11:02: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 i6JI2puQ009688
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 11:02:51 -0700 (PDT)
	(envelope-from mint@franklinmint.fm)
Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94])
	by web02.designerslab.net with asmtp (Exim 4.34)
	id 1BmcTT-0002na-QX; Mon, 19 Jul 2004 18:02:51 +0000
Message-ID: <40FC0CBE.6030504@franklinmint.fm>
Date: Mon, 19 Jul 2004 14:02:38 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Henri Sivonen <hsivonen@iki.fi>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PacePutDelete Withdrawn
References: <1090165177.2738485554.17777.sendItem@bloglines.com> <DFBF4C9F-D8D4-11D8-92AF-000A95A51C9E@sun.com> <m3llhhdzgv.fsf@bitsko.slc.ut.us> <72940BAE-D8FB-11D8-933E-003065B8CF0E@iki.fi> <m3zn5wc9ht.fsf@bitsko.slc.ut.us> <82B0ECD4-D9A8-11D8-933E-003065B8CF0E@iki.fi>
In-Reply-To: <82B0ECD4-D9A8-11D8-933E-003065B8CF0E@iki.fi>
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


Henri Sivonen wrote:

>
> On Jul 19, 2004, at 18:17, Ken MacLeod wrote:
>
>> Henri Sivonen <hsivonen@iki.fi> writes:
>>
>>> What would be the point of burdening a Web Forms 2.0 UA with Atom?
>>> If you are able to spec how to build an Atom entry out of a form
>>> dataset, surely the conversion can be done on the server instead of
>>> introducing yet another submission format for UAs to support.
>>
>>
>> It's not burdening Web Forms 2.0 UA with Atom, it's Web Forms 2.0 UA
>> being XML and REST enabled.
>
>
> XML and REST don't imply Atom envelopes. In fact, one might argue that 
> in order to publish HTML it would be more RESTian to PUT straight HTML 
> without an envelope.


That would work if websites weren't covered in "chrome". However, I do 
agree with you here. The WHAT-WG forms spec is geared towards 
serialization of arbitrary datasets[0] without requiring very specific 
HTTP interaction. Atom isn't general enough for Web Forms 2.0[1]. It's a 
better fit for Web Applications 1.0[2], another of their specs. I've 
stated this opinion their mailing list[3].

It seems the WHAT-WG is focusing on standardizing functionality that is 
commonly achieved with JavaScript (e.g. date controls, email fields). If 
AtomPP.js files become really common, they can standardize it in the future.

Robert Sayre

[0] http://www.whatwg.org/specs/web-forms/current-work/#x-www-form-xml
[1] http://www.whatwg.org/specs/web-forms/current-work/
[2] http://www.whatwg.org/specs/web-apps/current-work/
[3] 
http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2004-July/001195.html



From owner-atom-syntax@mail.imc.org  Mon Jul 19 14:56: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 OAA16064
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 14:56: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 i6JIkFnZ016531;
	Mon, 19 Jul 2004 11:46: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 i6JIkFEZ016530;
	Mon, 19 Jul 2004 11:46:15 -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 i6JIkFrs016514
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 11:46:15 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040719184614.95295.qmail@web41211.mail.yahoo.com>
Received: from [131.107.3.74] by web41211.mail.yahoo.com via HTTP; Mon, 19 Jul 2004 11:46:14 PDT
Date: Mon, 19 Jul 2004 11:46:14 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: PaceLinkAttrDefaults
To: Sam Ruby <rubys@intertwingly.net>, Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <40FC0A55.5090409@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>


The suggestions in the Pace seem fine to me. 

Personally I'd rather see a Pace that once and for all
states that the link tag isn't extensible or if it one
that provides guidelines for its usage if it is...

Oh, it looks likes there is PaceLinkPurpose which is a
decent start.  

--- Sam Ruby <rubys@intertwingly.net> wrote:
> 
>
http://www.intertwingly.net/wiki/pie/PaceLinkAttrDefaults
> 
>   - - -
> 
> Preamble:
> 
>    Can you live with
> 
>      <link href="uri"/>
> 
>    ?
> 
>   - - -
> 
> Preface:
> 
> "Having an element that says, here is a pointer to
> some data that is 
> related to this entry that is too large to fit in
> the feed is a good 
> idea. Similarly providing a hint at what the MIME
> type is so the reader 
> knows whether it can handle that MIME type or can
> display something 
> specific to that media type in the user interface
> without making an 
> additional request to the server is very useful."
> 
> Dare Obasanjo, 
>
http://www.25hoursaday.com/weblog/default.aspx?date=2004-05-26
> 
>   - - -
> 
> Main text
> 
> There is a lot of hyperbole floating around relating
> to the link tag. 
> Let me start of by stating some non-goals:
> 
> 1) It is a non-goal of the link element to define an
> extensibility model 
> that enables consumers to achieve an almost AI like
> ability to sense and 
> adapt to new constructs that may be introduced at
> some point in the far 
> distant future.
> 
> 2) It is a non-goal of the link element to make
> anything more than 
> minor, incremental, adaptations over the existing
> prior art of HTML link 
> tags, RSS link tags, and RSS 2.0 enclosure tags.  In
> particular, it is a 
> non-goal to introduce "co-occurence constraints" or
> a type system.
> 
> 3) It is a non-goal to make all producers to provide
> information that 
> they don't have, or to make all consumers interpret
> all link tags 
> identically.
> 
>   - - -
> 
> Now, lets explore what a link tag is in terms of an
> abstract "schema". 
> In relational database terms, a link element when
> used within a the 
> context of an atom entry would be a table:
> 
> The first column is id of the entry.  This is a
> foreign key.
> 
> There are five additional columns, rel, type, href,
> hreflang, and title. 
>   Rel has a default of "alternate".  href has a
> non-null constraint. 
> All the remaining elements may be null.
> 
> None of these columns are a primary key.
> 
>   - - -
> 
> Now lets explore usage scenarios.  First from a
> producer perspective, 
> the primary usage would be to declare the permalink
> associated with this 
> entry.  From a syntax perspective, this usage should
> be optimized for. 
> As the type attribute is merely advisory, it should
> be recommended but 
> not be required.  The remaining attributes should
> only be provided if known.
> 
>   - - -
> 
> Continuing with a consumer perspective, there are a
> number of use cases. 
>   Identifying the permalink is obviously a key one. 
> In relational db terms:
> 
>    select href from link where entryid='uri' and
> rel='alternate'
> 
> RSSBandit may wish to identifying calendar events,
> thus:
> 
>    select href,title from link where entryid='uri'
> and type='text/calendar'
> 
> Bloglines may with to identify which blog entries
> reference a given one 
> thus:
> 
>    select entryid from link where href='uri'
> 
>   - - -
> 
>  From a syntax perspective, the most common use case
> is should be able 
> to be simply expressed thus:
> 
>    <link href="uri"/>
> 
> A link blog may want to acknowledge the origin of a
> given bit of news, thus:
> 
>    <link href="uri" rel="via"/>
> 
> An event could be indicated thus:
> 
>    <link href="uri" rel="event"
> type="text/calendar"/>
> 
>   - - -
> 
> Prior art includes the RSS link tag, which variously
> would be used to 
> point to the permalink of the item itself, or to the
> full story that is 
> summarized by the item.
> 
> Then there is the HTML link tag, which defines most
> of the semantics of 
> this link tag.
> 
> Then there is the enclosure element in RSS 2.0 that,
> while perhaps 
> misnamed, does a reasonably good job - with one
> exception, first noted 
> by Dare.  Outside of the specification itself, an
> expectation was set 
> that an enclosure was to be automatically downloaded
> asynchronously; 
> enough so that it impeeded other use cases.
> 
>   - -
> 
> Summary:
> 
> The purpose is not to make things automagically
> happen.  There is no 
> pixie dust.  The purpose it so enable a small bit of
> loose coupling. 
> Producers provide what information that they have
> available.  Consumers 
> select what they recognize, and ignore the rest.
> 
>   - - -
> 
> Impacts: existing producers may want to take
> advantage of the new 
> defaults.  Consumers will have to deal appropriately
> with the new defaults.
> 
> 


=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/



From owner-atom-syntax@mail.imc.org  Mon Jul 19 14:58: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 OAA16118
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 14:58: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 i6JIjrk6016477;
	Mon, 19 Jul 2004 11:45:53 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6JIjr7q016476;
	Mon, 19 Jul 2004 11:45:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JIjquL016470
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 11:45:53 -0700 (PDT)
	(envelope-from hsivonen@iki.fi)
Received: from 217-140-251-133.adsl-net.finnetcom.net ([217.140.251.133]:63190
        "EHLO [217.140.251.133]" TLS-CIPHER: <none>) by smtp2.dnainternet.net
        with ESMTP id S1229127AbUGSSpp (ORCPT <rfc822;atom-syntax@imc.org>);
        Mon, 19 Jul 2004 21:45:45 +0300
Mime-Version: 1.0 (Apple Message framework v618)
In-Reply-To: <40FC0CBE.6030504@franklinmint.fm>
References: <1090165177.2738485554.17777.sendItem@bloglines.com> <DFBF4C9F-D8D4-11D8-92AF-000A95A51C9E@sun.com> <m3llhhdzgv.fsf@bitsko.slc.ut.us> <72940BAE-D8FB-11D8-933E-003065B8CF0E@iki.fi> <m3zn5wc9ht.fsf@bitsko.slc.ut.us> <82B0ECD4-D9A8-11D8-933E-003065B8CF0E@iki.fi> <40FC0CBE.6030504@franklinmint.fm>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <D7572C6C-D9B3-11D8-933E-003065B8CF0E@iki.fi>
Content-Transfer-Encoding: 7bit
From: Henri Sivonen <hsivonen@iki.fi>
Subject: Re: PacePutDelete Withdrawn
Date:   Mon, 19 Jul 2004 21:45:44 +0300
To: Atom Syntax <atom-syntax@imc.org>
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>
Content-Transfer-Encoding: 7bit


On Jul 19, 2004, at 21:02, Robert Sayre wrote:

>> XML and REST don't imply Atom envelopes. In fact, one might argue 
>> that in order to publish HTML it would be more RESTian to PUT 
>> straight HTML without an envelope.
>
> That would work if websites weren't covered in "chrome".

I don't see how taking the stuff out of an Atom envelope before 
wrapping it in the chrome helps compared to taking the stuff out of an 
HTML body and wrapping it in the chrome.

-- 
Henri Sivonen
hsivonen@iki.fi
http://iki.fi/hsivonen/



From owner-atom-syntax@mail.imc.org  Mon Jul 19 15:03: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 PAA16351
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 15:03:24 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JItHQf018499;
	Mon, 19 Jul 2004 11:55: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 i6JItHDZ018498;
	Mon, 19 Jul 2004 11:55: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.86])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JItHtm018492
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 11:55:17 -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 i6JItJRG011692;
	Mon, 19 Jul 2004 11:55:21 -0700 (PDT)
Received: from [10.232.32.85] ([17.255.240.130])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id i6JIssKR014913;
	Mon, 19 Jul 2004 11:55:17 -0700 (PDT)
In-Reply-To: <40FC0A55.5090409@intertwingly.net>
References: <40FC0A55.5090409@intertwingly.net>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7-286939515; protocol="application/pkcs7-signature"
Message-Id: <1C1FE7C6-D9B5-11D8-81CD-000A95DC3D90@mac.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: PaceLinkAttrDefaults
Date: Mon, 19 Jul 2004 14:54:48 -0400
To: Sam Ruby <rubys@intertwingly.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-7-286939515
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 19 Jul 2004, at 1:52 pm, Sam Ruby wrote:

> RSSBandit may wish to identifying calendar events, thus:
>
>   select href,title from link where entryid='uri' and 
> type='text/calendar'
>
> Bloglines may with to identify which blog entries reference a given 
> one thus:
>
>   select entryid from link where href='uri'

I can't see either of these being useful without either:
a) Assuming links only ever contain certain kinds of links - ie There's 
never going to be 
rel="This-link-is-completely-unrelated-to-the-entry-please-ignore", or 
equivalent (I assure you there will be values that mean as good as 
that).
b) Only selecting certain link types. I assure you RSSBandit would do 
well to add "and rel='related' ".

Seeing as that's the core of your proposal, a big fat -1 from me.

Graham

(PS Show us your extensibility mechanism)
--Apple-Mail-7-286939515
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
9w0BCQUxDxcNMDQwNzE5MTg1NDQ5WjAjBgkqhkiG9w0BCQQxFgQUtS8u6ILHsbvCLzlOzPzO0gGM
aFoweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEA2uLdMcC090Jx/mQWD6EPiZNC
vpXsfjarfD40a268eMQioKid5aKg+Pl7NFgzd4mz65AHnMAPKaFBuZK2qjwSmBXkdHQLvUSAvRsw
aXS2QpQmLU83bFcb1L7D/wxT6xjMtJqg3+k3emwotzfxBQmYSFxxtSeB0bTHzkc3TztRjo/Urwu0
t2fni6TBPp7AOEVphGe4UgiDpxsoloNrtKixOsa1b3apjhxUxO5XTOXKlzWuEaD2mDDE1uGobBXG
565LcGWEPUT1z2UrW3d0352kO+06SIDrNGp0URulCNl7FIH9b0z5aRUdxOjOVw8DQbeC5H1vURJE
gjTMF9l2bXynGgAAAAAAAA==

--Apple-Mail-7-286939515--



From owner-atom-syntax@mail.imc.org  Mon Jul 19 15:05: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 PAA16525
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 15: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 i6JIrXxs018072;
	Mon, 19 Jul 2004 11: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 i6JIrWn8018071;
	Mon, 19 Jul 2004 11:53: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 i6JIrWM9018064
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 11:53:32 -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 i6JIsPW8017197;
	Mon, 19 Jul 2004 14:54:26 -0400
Message-ID: <40FC18AA.50404@intertwingly.net>
Date: Mon, 19 Jul 2004 14:53:30 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Dare Obasanjo <kpako@yahoo.com>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceLinkAttrDefaults
References: <20040719184614.95295.qmail@web41211.mail.yahoo.com>
In-Reply-To: <20040719184614.95295.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: <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 suggestions in the Pace seem fine to me. 
> 
> Personally I'd rather see a Pace that once and for all
> states that the link tag isn't extensible or if it one
> that provides guidelines for its usage if it is...
> 
> Oh, it looks likes there is PaceLinkPurpose which is a
> decent start.  

I agree that PaceLinkAttrDefaults is incomplete without resolving this 
question.

I also think that some version of the prose that I submitted to the 
email list (in particular, the listing of non-goals) should be captured 
in some form - either informative text, or in a companion Usage Guide.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Mon Jul 19 15:08: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 PAA16840
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 15:08: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 i6JJ0rX6019897;
	Mon, 19 Jul 2004 12:00: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 i6JJ0rUD019896;
	Mon, 19 Jul 2004 12:00: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 i6JJ0rpK019890
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 12:00:53 -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 1BmdNd-0005YU-8X; Mon, 19 Jul 2004 19:00:53 +0000
Message-ID: <40FC1A61.8030306@franklinmint.fm>
Date: Mon, 19 Jul 2004 15:00:49 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Henri Sivonen <hsivonen@iki.fi>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PacePutDelete Withdrawn
References: <1090165177.2738485554.17777.sendItem@bloglines.com> <DFBF4C9F-D8D4-11D8-92AF-000A95A51C9E@sun.com> <m3llhhdzgv.fsf@bitsko.slc.ut.us> <72940BAE-D8FB-11D8-933E-003065B8CF0E@iki.fi> <m3zn5wc9ht.fsf@bitsko.slc.ut.us> <82B0ECD4-D9A8-11D8-933E-003065B8CF0E@iki.fi> <40FC0CBE.6030504@franklinmint.fm> <D7572C6C-D9B3-11D8-933E-003065B8CF0E@iki.fi>
In-Reply-To: <D7572C6C-D9B3-11D8-933E-003065B8CF0E@iki.fi>
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


Henri Sivonen wrote:

>
> On Jul 19, 2004, at 21:02, Robert Sayre wrote:
>
>>> XML and REST don't imply Atom envelopes. In fact, one might argue 
>>> that in order to publish HTML it would be more RESTian to PUT 
>>> straight HTML without an envelope.
>>
>>
>> That would work if websites weren't covered in "chrome".
>
>
> I don't see how taking the stuff out of an Atom envelope before 
> wrapping it in the chrome helps compared to taking the stuff out of an 
> HTML body and wrapping it in the chrome.
>

We're getting OT here, but the problem with HTML is that the websites 
put their own chrome throughout the body. People have been requesting 
<header> and <navigation> extensions for precisely this reason. There's 
always contenteditable, if that fits your needs.

Robert Sayre



From owner-atom-syntax@mail.imc.org  Mon Jul 19 15: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 PAA18412
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 15: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 i6JJJtl6022978;
	Mon, 19 Jul 2004 12:19: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 i6JJJtDX022977;
	Mon, 19 Jul 2004 12:19: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 i6JJJrth022954
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 12:19:54 -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 i6JJJp53012727
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 14:19:51 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6JJJobT012723;
	Mon, 19 Jul 2004 14:19:50 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: atom-syntax@imc.org
Subject: PaceLinkParent updated, tightened
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 19 Jul 2004 14:19:50 -0500
Message-ID: <m3vfgjdctl.fsf@bitsko.slc.ut.us>
Lines: 55
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: <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've updated PaceLinkParent with the following changes:

    * rename "parent" to "in-reply-to"

    * constrain defined behavior to "same feed", while leaving open
      future specification

    * remove description of linking to alternate media types

The proposal section now reads:

    Add the following to section to the protocol draft -00 section,
    3.4.1 rel:

    [[ note: link construct markup and location of normative
    specification (protocol or format) are currently under
    discussion. This proposal is written in the style of the -00
    drafts.]]

    [[ note to editor: the definition of this is adapted from RFC2882,
    sec 3.6.4]]

    in-reply-to

        The "in-reply-to" URI will contain the atom:id URI of the
        entry to which this one is a reply (the "parent entry"). An
        atom:entry MAY have one "in-reply-to" link, but MUST NOT have
        more than one. Clients MAY use this link to display nested
        entry threads.

        The "in-reply-to" URI can refer to an atom:entry or other
        resource that is not within the same atom:feed, however the
        mechanism for resolving these URIs is outside the scope of
        this document. An "in-reply-to" link that cannot be resolved
        SHOULD be considered as if the "in-reply-to" link were not
        present.

        For example, if this entry is a comment on a previous entry,
        the "href" attribute URI will be the atom:id URI of the
        previous entry. If this entry is a comment in reply to a
        previous comment (in a threaded comment system), the "href"
        attribute URI will be the URI of the previous comment.


This spec text constrains the defined behavior to what would work
within a minimum of a "local feed" as used in current practice
(including wfw:commentRss, atom:entry/atom:service.feed) and for
existing sites that provide nested comments, as linked from the Pace.

  -- Ken

PS.  I couldn't find who the author of this Pace was, so was not able
to coordinate this change with them following the discussion on the
list.  If the original author has a concern about how the discussion
was factored in, let me know and I'll revert it and create a new Pace.



From owner-atom-syntax@mail.imc.org  Mon Jul 19 15:30: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 PAA18509
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 15: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 i6JJM49Q023266;
	Mon, 19 Jul 2004 12: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 i6JJM4JA023265;
	Mon, 19 Jul 2004 12:22: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 i6JJM3Nd023259
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 12:22:03 -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 i6JJMv8i018406;
	Mon, 19 Jul 2004 15:22:57 -0400
Message-ID: <40FC1F59.1070909@intertwingly.net>
Date: Mon, 19 Jul 2004 15:22:01 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <dtcd@mac.com>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceLinkAttrDefaults
References: <40FC0A55.5090409@intertwingly.net> <1C1FE7C6-D9B5-11D8-81CD-000A95DC3D90@mac.com>
In-Reply-To: <1C1FE7C6-D9B5-11D8-81CD-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: <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 19 Jul 2004, at 1:52 pm, Sam Ruby wrote:
> 
>> RSSBandit may wish to identifying calendar events, thus:
>>
>>   select href,title from link where entryid='uri' and 
>> type='text/calendar'
>>
>> Bloglines may with to identify which blog entries reference a given 
>> one thus:
>>
>>   select entryid from link where href='uri'
> 
> I can't see either of these being useful without either:
> a) Assuming links only ever contain certain kinds of links - ie There's 
> never going to be 
> rel="This-link-is-completely-unrelated-to-the-entry-please-ignore", or 
> equivalent (I assure you there will be values that mean as good as that).
> b) Only selecting certain link types. I assure you RSSBandit would do 
> well to add "and rel='related' ".
> 
> Seeing as that's the core of your proposal, a big fat -1 from me.

The core of the proposal is that different consumers will chose to 
ignore different things.  It is inconceivable to me that anybody would 
put a link inside of an entry with the intent that it be completely 
unrelated to the entry and ignored by literally everyone.

The intent of the proposal is to allow for what the enclosure element 
almost - but doesn't completely - provide: namely a bit of loose 
coupling.  Bloglines, for example, would not have to understand the 
value of the rel attribute in order to identify which blog entries 
reference this one.  rel could be "related", "via", or 
"in-refutation-of" for all such an application could care.

Once we nail down the general shape of the solution, we can proceed to 
decide what the permissable values of the rel attribute are.  At the 
moment, I'm leaning towards expelling a number of the current 
definitions (e.g., service.*), nailing down a few values (alternate 
being the key one), and establishing a registration scheme for new 
values.  Hopefully the registration scheme will be hairy enough to scare 
away fivilous and unproven suggestions.  Hmmm, seems to me like IANA 
might fit that bill.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Mon Jul 19 15: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 PAA18592
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 15: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 i6JJPF07023697;
	Mon, 19 Jul 2004 12: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 i6JJPFpL023696;
	Mon, 19 Jul 2004 12:25:15 -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 i6JJPEgK023672
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 12:25:15 -0700 (PDT)
	(envelope-from mail@annevankesteren.nl)
Received: (qmail 11928 invoked by uid 10); 19 Jul 2004 19:25:11 -0000
Received: (vexira-qq 11912-88F40BD4 invoked from network) 19 Jul 2004 21:25:10 +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 < >; 19 Jul 2004 19:25:10 -0000
Message-ID: <40FC201A.509@annevankesteren.nl>
Date: Mon, 19 Jul 2004 21:25:14 +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/20040718
X-Accept-Language: nl, en
MIME-Version: 1.0
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: I-D ACTION:draft-ietf-atompub-format-01.txt
References: <200407191919.PAA17914@ietf.org>
In-Reply-To: <200407191919.PAA17914@ietf.org>
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.26.0.5; VDF: 6.26.0.36; 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


Internet-Drafts@ietf.org wrote:

> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-01.txt

Hmm... 404 anyone?


-- 
  Anne van Kesteren
  <http://annevankesteren.nl/>



From owner-atom-syntax@mail.imc.org  Mon Jul 19 15:32: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 PAA18611
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 15:32: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 i6JJJlDx022952;
	Mon, 19 Jul 2004 12:19: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 i6JJJlhj022951;
	Mon, 19 Jul 2004 12:19:47 -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 i6JJJkI7022937
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 12:19:46 -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 PAA17914;
	Mon, 19 Jul 2004 15:19:47 -0400 (EDT)
Message-Id: <200407191919.PAA17914@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: i-d-announce@ietf.org
Cc: atom-syntax@imc.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-atompub-format-01.txt
Date: Mon, 19 Jul 2004 15:19:47 -0400
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>


--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Atom Publishing Format and Protocol Working Group of the IETF.

	Title		: The Atom Syndication Format
	Author(s)	: M. Nottingham
	Filename	: draft-ietf-atompub-format-01.txt
	Pages		: 27
	Date		: 2004-7-19
	
This specification describes Atom, an XML-based Web content and
   metadata syndication format.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-01.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-atompub-format-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-atompub-format-01.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-7-19152059.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-atompub-format-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-atompub-format-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2004-7-19152059.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-atom-syntax@mail.imc.org  Mon Jul 19 15:36: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 PAA18839
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 15:36: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 i6JJR6qB023949;
	Mon, 19 Jul 2004 12:27: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 i6JJR6A3023948;
	Mon, 19 Jul 2004 12:27:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from aaryn.lunarpages.com (aaryn.lunarpages.com [216.193.217.198])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JJR5O7023939
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 12:27:05 -0700 (PDT)
	(envelope-from sah@428cobrajet.net)
Received: from h87.s239.netsol.com ([216.168.239.87] helo=dul1shollenbl1)
	by aaryn.lunarpages.com with asmtp (TLSv1:RC4-MD5:128)
	(Exim 4.34)
	id 1Bmdn4-00060Y-Js; Mon, 19 Jul 2004 12:27:10 -0700
From: "Scott Hollenbeck" <sah@428cobrajet.net>
To: "'Anne van Kesteren'" <mail@annevankesteren.nl>,
        "'Atom Syntax'" <atom-syntax@imc.org>
Subject: RE: I-D ACTION:draft-ietf-atompub-format-01.txt
Date: Mon, 19 Jul 2004 15:26:54 -0400
Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF02E0F6F5@vsvapostal8.vcorp.ad.vrsn.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <40FC201A.509@annevankesteren.nl>
Importance: Normal
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - aaryn.lunarpages.com
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - 428cobrajet.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


Sometimes the announcements get out before the archive web site is updated.
The doc should be there "soon" (in a matter of hours).

-Scott-

> -----Original Message-----
> From: Anne van Kesteren [mailto:mail@annevankesteren.nl] 
> Sent: Monday, July 19, 2004 3:25 PM
> To: Atom Syntax
> Subject: Re: I-D ACTION:draft-ietf-atompub-format-01.txt
> 
> 
> 
> Internet-Drafts@ietf.org wrote:
> 
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-01.txt
> 
> Hmm... 404 anyone?
> 
> 
> -- 
>   Anne van Kesteren
>   <http://annevankesteren.nl/>



From owner-atom-syntax@mail.imc.org  Mon Jul 19 15:58:05 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19559
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 15: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 i6JJl08o027075;
	Mon, 19 Jul 2004 12: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 i6JJl00A027074;
	Mon, 19 Jul 2004 12:47: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.89])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JJl0oK027068
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 12:47:00 -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 i6JJl42G000435;
	Mon, 19 Jul 2004 12:47:04 -0700 (PDT)
Received: from [10.232.32.85] ([17.255.240.130])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin01/MantshX 4.0) with ESMTP id i6JJkrLB012953;
	Mon, 19 Jul 2004 12:47:04 -0700 (PDT)
In-Reply-To: <40FC1F59.1070909@intertwingly.net>
References: <40FC0A55.5090409@intertwingly.net> <1C1FE7C6-D9B5-11D8-81CD-000A95DC3D90@mac.com> <40FC1F59.1070909@intertwingly.net>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8-290064007; protocol="application/pkcs7-signature"
Message-Id: <62778C5C-D9BC-11D8-81CD-000A95DC3D90@mac.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: PaceLinkAttrDefaults
Date: Mon, 19 Jul 2004 15:46:53 -0400
To: Sam Ruby <rubys@intertwingly.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-8-290064007
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 19 Jul 2004, at 3:22 pm, Sam Ruby wrote:

> The core of the proposal is that different consumers will chose to 
> ignore different things.  It is inconceivable to me that anybody would 
> put a link inside of an entry with the intent that it be completely 
> unrelated to the entry and ignored by literally everyone.

I didn't mean that literally. My point was that not paying attention to 
the rel value doesn't seem safe from a not-displaying-nonsense point of 
view.

> The intent of the proposal is to allow for what the enclosure element 
> almost - but doesn't completely - provide: namely a bit of loose 
> coupling.  Bloglines, for example, would not have to understand the 
> value of the rel attribute in order to identify which blog entries 
> reference this one.  rel could be "related", "via", or 
> "in-refutation-of" for all such an application could care.

One example from HTML I'm thinking of is rel="stylesheet". I'm not sure 
what the syndication equivalent of that would be, but if Bloglines were 
to include such things in its list of popular links, it would obviously 
run in to trouble.

> At the moment, I'm leaning towards expelling a number of the current 
> definitions (e.g., service.*), nailing down a few values (alternate 
> being the key one), and establishing a registration scheme for new 
> values.

If you can make <link> itself have a semantic meaning, and @rel just be 
further information, I might be OK with it. It'd probable make sense 
for all allowable values to be some variation on "related". "alternate" 
actually looks like it doesn't belong (I note you didn't include it in 
your Bloglines example above). As long as we stop crow-baring 
everything that's a URI (which on the internet = everything) into one 
element, I'm happy.

Graham
--Apple-Mail-8-290064007
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
9w0BCQUxDxcNMDQwNzE5MTk0NjUzWjAjBgkqhkiG9w0BCQQxFgQU2H7vvFrPpEnNAwwXuf9TcYxr
RlIweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEARhjbtJc76pGhFi8o3lKUkNJr
kXDMGyY4XvcFmuqYLOPnw2z7J5OgmPAC1biS29i9rdaA8f9Ir1a1Ifyywp0Su3+1JXYa90SPXQWr
thRlaGH4RQoaLac7k6/BUYyYMPGtlPQWTxJr4dz2vCui+C5XyGsWvYk7tluJXKKB6sP9o0h296Zn
9OnHquiGunWxjEt3Qx+BEtGGIE3JjquRIpg3JuRLeAw1o7suklABbVsjm8zdDvC9J/vdS+AMEWUk
dr4HDaA9WUtiHLqd4ZDlU3CUDoSAqPXkoK7uNeqaLY+7Oh5TMG+3S5/7jth/9ZTQXcq3Xb80iMIi
N8+eW+IhKaIGZgAAAAAAAA==

--Apple-Mail-8-290064007--



From owner-atom-syntax@mail.imc.org  Mon Jul 19 16:44: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 QAA00202
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 16: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 i6JKVQFJ034154;
	Mon, 19 Jul 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 i6JKVQBD034153;
	Mon, 19 Jul 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 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 i6JKVObq034111
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 13:31:25 -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 i6JKVN53014039
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 15:31:23 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6JKVMjV014035;
	Mon, 19 Jul 2004 15:31:22 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: "Atom Syntax" <atom-syntax@imc.org>
Subject: Re: PaceExtensibilityAndVersioning
References: <32D5845A745BFB429CBDBADA57CD41AF08FA6F0F@ussjex01.amer.bea.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 19 Jul 2004 15:31:22 -0500
In-Reply-To: <32D5845A745BFB429CBDBADA57CD41AF08FA6F0F@ussjex01.amer.bea.com>
Message-ID: <m3oembd9id.fsf@bitsko.slc.ut.us>
Lines: 43
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


"David Orchard" <dorchard@bea.com> writes:

> http://www.intertwingly.net/wiki/pie/PaceExtensibilityAndVersioning

+1

One thing I'm trying to think of is how we could model mustUnderstand
causing the faulting of individual entries, rather than an entire
feed.

Possibility #1:

    Restrict faulting to identified "top-level" elements.  If an
    extension should fault at both the feed level and at the element
    level, a mustUnderstand attribute must appear in both.  The
    corresponding feed-level mustUnderstand element may just be a
    placeholder for that purpose.

Possibility #2:

    Instead of true/false, we use feed/entry/none (default: none).

    Pass-through intermediaries could then pass-through entries marked
    with mustUnderstand="entry", but not entries marked with
    mustUnderstand="feed", since the intermediary itself must
    understand the effect on the feed from the one entry to be able to
    pass it on alone.

    Feed-level extensions would be always be feed/none.

    This possibility has the drawback in that it doesn't scale well to
    other top-level elements, that may in turn be cross-referenced to
    other top-level elements.

Possibility #3:

    Do nothing.  If the intermediary doesn't understand, it faults its
    source feed and doesn't pass on any entries.  If the intermediary
    does understand the scope of the extension element, and chooses to
    pass on an entry with mustUnderstand="true", it understands that
    downstream clients may fault the entire feed based on that entry.

  -- Ken



From owner-atom-syntax@mail.imc.org  Mon Jul 19 16:45:35 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01183
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 16:45:34 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JKXa11034476;
	Mon, 19 Jul 2004 13:33: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 i6JKXah7034474;
	Mon, 19 Jul 2004 13:33: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 i6JKXZMW034441
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 13:33: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 NAA28719
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 13:33:32 -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 NAA19231
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 13:33:32 -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, 19 Jul 2004 13:33:31 -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 <0I1400I0Q93VAF@shazam.verity.com> for atom-syntax@imc.org; Mon,
 19 Jul 2004 13:33:31 -0700 (PDT)
Date: Mon, 19 Jul 2004 13:40:48 -0700
From: Walter Underwood <wunder@verity.com>
Subject: Re: Bandwidth consumtion and syndication feeds
In-reply-to: <20040717015855.93645.qmail@web41201.mail.yahoo.com>
To: Atom-Syntax Syntax <atom-syntax@imc.org>
Message-id: <9EBD134C2C1E7D02C36D354C@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: <20040717015855.93645.qmail@web41201.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 Friday, July 16, 2004 06:58:55 PM -0700 Dare Obasanjo 
<kpako@yahoo.com> wrote:
>
> Testing their feed with
> http://www.rexswain.com/cgi-bin/httpview.cgi I see
> that Infoworld neither supports GZip encoding nor HTTP
> conditional GET. No wonder their bandwidth usage is so
> high. Using both techniques should reduce their
> bandwidth usage by at *least* a factor of 10.

For RSS, but not for the rest of the site. Public sites just
can't send cachable HTML because they need to rotate the ads
and count ad impressions. Cached pages mean lost ad revenue.

For ad-free feeds, caching is excellent. Then put in an Expires
header that shows when it would be smart to check again.

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek



From owner-atom-syntax@mail.imc.org  Mon Jul 19 17: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 RAA14047
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 17:47: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 i6JLWIAc045938;
	Mon, 19 Jul 2004 14:32: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 i6JLWICg045937;
	Mon, 19 Jul 2004 14:32:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.202])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6JLWHOb045930
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 14:32:18 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d15so721111rng
        for <atom-syntax@imc.org>; Mon, 19 Jul 2004 14:32:22 -0700 (PDT)
Received: by 10.38.181.43 with SMTP id d43mr315332rnf;
        Mon, 19 Jul 2004 14:32:22 -0700 (PDT)
Message-ID: <14be96d304071914321246d14@mail.gmail.com>
Date: Mon, 19 Jul 2004 17:32:22 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Ken MacLeod <ken@bitsko.slc.ut.us>
Subject: Re: PaceLinkParent updated, tightened
Cc: atom-syntax@imc.org
In-Reply-To: <m3vfgjdctl.fsf@bitsko.slc.ut.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <m3vfgjdctl.fsf@bitsko.slc.ut.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 19 Jul 2004 14:19:50 -0500, Ken MacLeod <ken@bitsko.slc.ut.us> wrote:
> PS.  I couldn't find who the author of this Pace was, so was not able
> to coordinate this change with them following the discussion on the
> list.  If the original author has a concern about how the discussion
> was factored in, let me know and I'll revert it and create a new Pace.

That would be me, and your changes look good.

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Mon Jul 19 17:48:34 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14311
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 17: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 i6JLbn3B047602;
	Mon, 19 Jul 2004 14: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 i6JLbnon047601;
	Mon, 19 Jul 2004 14:37:49 -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 i6JLbmTD047585
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 14:37:48 -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 i6JLb06i025444;
	Mon, 19 Jul 2004 17:37:01 -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 BJD21242 (AUTH bob@wyman.us);
	Mon, 19 Jul 2004 17:37:48 -0400 (EDT)
Message-Id: <200407192137.BJD21242@ms8.netsolmail.com>
Reply-To: <bob@wyman.us>
From: "Bob Wyman" <bob@wyman.us>
To: "'Atom-Syntax Syntax'" <atom-syntax@imc.org>
Cc: "'Walter Underwood'" <wunder@verity.com>
Subject: Non-Normative Text in RFC's? (was: RE: Bandwidth consumtion and syndication feeds)
Date: Mon, 19 Jul 2004 17:37:48 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Thread-Index: AcRt00/xzKJ4v943Rz2YV0lmQ9H1oAABCFlA
In-Reply-To: <9EBD134C2C1E7D02C36D354C@diva.verity.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


Walter Underwood wrote:
> Public sites just can't send cachable HTML because they need
> to rotate the ads and count ad impressions. Cached pages mean
> lost ad revenue.
	What is the policy on non-normative text for the Atom RFCs?
	I would like to write a  Pace for some "Best Practice" text that
recommends that people should not modify atom:id, atom:modified, or
atom:issued if they are inserting or modifying ad content embedded in atom
entries. The reason for this is to prevent aggregators from being fooled
into thinking that an entry is "new" when the only change is a modification
to an embedded ad. (Note: It is probably in the advertisers' best interest
to follow the recommended practice since doing otherwise will tend to
irritate users by exposing them to many duplicate entries.)
	Is it appropriate to include such non-normative "Best Practice"
guidance in these RFC's? Should I write a Pace on this?

		bob wyman




From owner-atom-syntax@mail.imc.org  Mon Jul 19 17:48: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 RAA14346
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 17:48: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 i6JLc0uB047638;
	Mon, 19 Jul 2004 14:38: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 i6JLc0Zx047637;
	Mon, 19 Jul 2004 14:38:00 -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 i6JLbwVo047605
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 14:37:59 -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 i6JLbs53015300
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 16:37:55 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6JLbssF015296;
	Mon, 19 Jul 2004 16:37:54 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceLinkAttrDefaults
References: <40FC0A55.5090409@intertwingly.net>
	<1C1FE7C6-D9B5-11D8-81CD-000A95DC3D90@mac.com>
	<40FC1F59.1070909@intertwingly.net>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 19 Jul 2004 16:37:54 -0500
In-Reply-To: <40FC1F59.1070909@intertwingly.net>
Message-ID: <m3llhfd6fh.fsf@bitsko.slc.ut.us>
Lines: 30
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: <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> writes:

> Hopefully the registration scheme will be hairy enough to scare away
> fivilous and unproven suggestions.  Hmmm, seems to me like IANA
> might fit that bill.

Using element names appears to be hairy enough to scare away frivious
and unproven suggestions, also.

When PaceLinkAttrDefaults describes its method of extension, we can
compare it more evenly with PaceReplaceLinkElement.

+1 in principle on the goals, non-goals, and summary.

Earlier,
> 2) It is a non-goal of the link element to make anything more than
> minor, incremental, adaptations over the existing prior art of HTML
> link tags, RSS link tags, and RSS 2.0 enclosure tags.  In
> particular, it is a non-goal to introduce "co-occurence constraints"
> or a type system.

In the notes of the Pace, it indicates that <atom:link> would be a
type that means "GET" links, and supporting PaceServiceElement for
links that are of type "service".  If that's the intent, is this truly
a non-goal?

  -- Ken

PS. In case it was missed in an earlier post, I am no longer
supporting discoverable or explicit link types.



From owner-atom-syntax@mail.imc.org  Mon Jul 19 17: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 RAA15340
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 17: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 i6JLiCV5048703;
	Mon, 19 Jul 2004 14:44:12 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6JLiC8l048702;
	Mon, 19 Jul 2004 14:44: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 i6JLiBv0048696
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 14:44:11 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from phys-bur-1 ([129.148.9.72])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i6JLfw53022340
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 15:42:03 -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 <0I1400L01C3YFO@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com)
 for atom-syntax@imc.org; Mon, 19 Jul 2004 17:44:11 -0400 (EDT)
Received: from mercury (vpn-129-150-32-212.Central.Sun.COM [129.150.32.212])
 by bur-mail1.east.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
 with ESMTP id <0I1400J21CDMI5@bur-mail1.east.sun.com> for atom-syntax@imc.org;
 Mon, 19 Jul 2004 17:44:10 -0400 (EDT)
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BmfvY-0000ay-00	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 17:44:04 -0400
X-URL: http://nwalsh.com/
Date: Mon, 19 Jul 2004 17:43:51 -0400
From: Norman Walsh <ndw@nwalsh.com>
Subject: xml:lang summary
In-reply-to: <200407191919.PAA17914@ietf.org>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <87ekn7u0yw.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: <200407191919.PAA17914@ietf.org>
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-Type: text/plain

|    Any element in an Atom Document MAY have an xml:lang attribute, whose
|    content indicates the default natural language of the element's
|    content.  Requirements regarding the content and interpretation of
|    xml:lang are specified in XML 1.0 [W3C.REC-xml-20040204] Section
|    2.12.  For convenience, the most important are summarised here:
| 
|       The content of this attribute must be a language tag [RFC3066] or
|       an empty string (e.g., xml:lang=""), which indicates that there is
|       no language information available.
|       If an element does not have an xml:lang element, the first
|       xml:lang attribute in its ancestors indicates the natural language
|       of its content.
| 
|    [[ feedback as to whether this listing is helpful or not would be
|    appreciated; re-stating the requirements of other specifications is
|    tricky.  ]]

Drop it. If it isn't dropped, I suggest making the two points into
a bulleted list:

     * The content of this attribute must be a language tag [RFC3066] or
       an empty string (e.g., xml:lang=""), which indicates that there is
       no language information available.
     * If an element does not have an xml:lang element, the first
       xml:lang attribute in its ancestors indicates the natural language
       of its content.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | [The internet is] the largest
http://nwalsh.com/            | equivalence class in the reflexive
                              | transitive symmetric closure of the
                              | relationship 'can be reached by an IP
                              | packet from.'--Seth Breidbart

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA/ECfOyltUcwYWjsRAkG6AJ9Pd6A93vNb0CpYETBjpDInm+EMeQCeLAgA
FGFPKaU8QvQb73svPp9lOOQ=
=INt5
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Mon Jul 19 17:55: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 RAA15931
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 17:55: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 i6JLgoid048408;
	Mon, 19 Jul 2004 14:42: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 i6JLgo2H048407;
	Mon, 19 Jul 2004 14:42:50 -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 i6JLgnDG048387
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 14:42:49 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040719214244.46800.qmail@web41207.mail.yahoo.com>
Received: from [207.46.238.137] by web41207.mail.yahoo.com via HTTP; Mon, 19 Jul 2004 14:42:44 PDT
Date: Mon, 19 Jul 2004 14:42:44 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: PaceLinkAttrDefaults
To: Sam Ruby <rubys@intertwingly.net>, Graham <dtcd@mac.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <40FC1F59.1070909@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:
> 
>  
> Once we nail down the general shape of the solution,
> we can proceed to 
> decide what the permissable values of the rel
> attribute are.  
> At the 
> moment, I'm leaning towards expelling a number of
> the current 
> definitions (e.g., service.*), nailing down a few
> values (alternate 
> being the key one), and establishing a registration
> scheme for new 
> values.  Hopefully the registration scheme will be
> hairy enough to scare 
> away fivilous and unproven suggestions.  Hmmm, seems
> to me like IANA 
> might fit that bill.

This implies to me that PaceLinkPurpose and its ilk
should be the focus of discussion before we bother
with related Paces like PaceLinkAttrDefaults. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/



From owner-atom-syntax@mail.imc.org  Mon Jul 19 18:00: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 SAA16842
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 18:00: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 i6JLnuUk049758;
	Mon, 19 Jul 2004 14:49:57 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6JLnuda049757;
	Mon, 19 Jul 2004 14:49:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JLnuJx049750
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 14:49:56 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from phys-bur-1 ([129.148.9.72])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i6JLlm53025107
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 15:47:48 -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 <0I1400001CLUTL@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com)
 for atom-syntax@imc.org; Mon, 19 Jul 2004 17:50:01 -0400 (EDT)
Received: from mercury (vpn-129-150-32-212.Central.Sun.COM [129.150.32.212])
 by bur-mail1.east.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
 with ESMTP id <0I1400J4BCN4I5@bur-mail1.east.sun.com> for atom-syntax@imc.org;
 Mon, 19 Jul 2004 17:50:00 -0400 (EDT)
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1Bmg0y-0000h2-00	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 17:49:40 -0400
X-URL: http://nwalsh.com/
Date: Mon, 19 Jul 2004 17:49:39 -0400
From: Norman Walsh <ndw@nwalsh.com>
Subject: Unstructured text
In-reply-to: <200407191919.PAA17914@ietf.org>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <877jszu0p8.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: <200407191919.PAA17914@ietf.org>
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-Type: text/plain

The -01 draft describes two elements as having "unstructured text" as
their content:

[...]
| 3.2.1  "atom:name" Element
| 
|    The "atom:name" element's content conveys a human-readable name for
|    the person.  Person constructs MUST contain exactly one "atom:name"
|    element, whose content is unstructured text.
[...]
| 3.4.5  "title" Attribute
| 
|    The "title" attribute conveys human-readable information about the
|    link.  Link constructs MAY have a title attribute, whose value is
|    unstructured text.

It also describes the 'version' attribute this way. What is the intent here?
Does "unstructured text" mean a string without markup? Or does it mean that
the structure is ignored? Is this allowed:

  <atom:title>I <html:em>Really</html:em> Mean It</atom:title>

I think the answer is "no". If that's the case, I suggest that the
descriptions be extended to explicitly forbid markup.

   Person constructs MUST contain exactly one "atom:name"
   element, whose content is unstructured text. The "atom:name" element
   must not contain any embedded element markup.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Taste ripens at the expense of
http://nwalsh.com/            | happiness.--Jules Renard

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA/EHzOyltUcwYWjsRAvxLAJ91sK1GeQARGfUzT5+shMqbzP8TKgCbBX3r
gbkTchNSr8h/wQOjQRAaDTs=
=Bs4e
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Mon Jul 19 18:02: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 SAA17348
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 18:02: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 i6JLqiDG050384;
	Mon, 19 Jul 2004 14:52: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 i6JLqi4u050383;
	Mon, 19 Jul 2004 14:52:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JLqi9j050368
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 14:52:44 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from phys-bur-1 ([129.148.9.72])
	by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i6JLqh0R025600
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 14:52:44 -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 <0I1400001CLUTL@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com)
 for atom-syntax@imc.org; Mon, 19 Jul 2004 17:52:43 -0400 (EDT)
Received: from mercury (vpn-129-150-32-212.Central.Sun.COM [129.150.32.212])
 by bur-mail1.east.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
 with ESMTP id <0I1400JI9CRNI5@bur-mail1.east.sun.com> for atom-syntax@imc.org;
 Mon, 19 Jul 2004 17:52:43 -0400 (EDT)
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1Bmg3a-0000ht-00	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 17:52:22 -0400
X-URL: http://nwalsh.com/
Date: Mon, 19 Jul 2004 17:52:22 -0400
From: Norman Walsh <ndw@nwalsh.com>
Subject: Text in atom:feed
In-reply-to: <200407191919.PAA17914@ietf.org>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <873c3nu0kp.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: <200407191919.PAA17914@ietf.org>
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-Type: text/plain

| 4.  The "atom:feed" Element
| 
|    The "atom:feed" element is the document (i.e., top-level) element of
|    an Atom Feed Document, acting as a container for metadata and data
|    associated with the feed.  Its first element child MUST be atom:head,
|    which MAY be followed zero or more atom:entry child elements.

I don't think this description goes far enough to forbid text content in
atom:feed, which I think should be forbidden. Do we agree it should
be forbidden?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | My fate cannot be mastered; it can only
http://nwalsh.com/            | be collaborated with and thereby, to
                              | some extent, directed. Nor am I the
                              | captain of my soul; I am only its
                              | noisiest passenger.--Aldous Huxley

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA/EKWOyltUcwYWjsRAkG8AJ9GygeC4qBbtfofcMNEXbpv4eenvACfTZJ7
SDQNykjvF5KlhM+hiQYssVY=
=cOQ4
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Mon Jul 19 18: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 SAA17817
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 18: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 i6JLu4SZ050850;
	Mon, 19 Jul 2004 14:56: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 i6JLu49l050849;
	Mon, 19 Jul 2004 14:56:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JLu3Hk050843
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 14:56:03 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from phys-bur-1 ([129.148.9.72])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6JLu7il014600
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 15:56:08 -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 <0I1400201CUO87@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com)
 for atom-syntax@imc.org; Mon, 19 Jul 2004 17:56:07 -0400 (EDT)
Received: from mercury (vpn-129-150-32-212.Central.Sun.COM [129.150.32.212])
 by bur-mail1.east.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
 with ESMTP id <0I1400J35CXGI5@bur-mail1.east.sun.com> for atom-syntax@imc.org;
 Mon, 19 Jul 2004 17:56:07 -0400 (EDT)
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1Bmg72-0000nN-00	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 17:55:56 -0400
X-URL: http://nwalsh.com/
Date: Mon, 19 Jul 2004 17:55:56 -0400
From: Norman Walsh <ndw@nwalsh.com>
Subject: atom:created same as atom:modified?
In-reply-to: <200407191919.PAA17914@ietf.org>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <87pt6rslub.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: <200407191919.PAA17914@ietf.org>
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-Type: text/plain

| 5.8  "atom:created" Element
| 
|    The "atom:created" element is a Date construct that indicates the
|    time that the entry was created.  atom:entry elements MAY contain an
|    atom:created element, but MUST NOT contain more than one.
| 
|    The content of an atom:created element MUST have a time zone whose
|    value SHOULD be "UTC".
| 
|    If atom:created is not present, its content MUST considered to be the
|    same as that of atom:modified.

I would have expected it to be the same as atom:issued. I'm not sure
either is really the obviously correct answer. Is there value in
providing a default if it isn't specified?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Extinction is an endless crime, quietly
http://nwalsh.com/            | slaughtering all the lives that would
                              | have been.--Captian Sverre (James
                              | Morrow)

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD4DBQBA/ENsOyltUcwYWjsRAioWAJj7v44EKHb712j/yIm4kY+vN3zaAKCXiFtL
gQsQWHpgWQ53LeqzKWEhcA==
=DCee
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Mon Jul 19 18:06: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 SAA18091
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 18:06: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 i6JLwbD2051205;
	Mon, 19 Jul 2004 14: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 i6JLwb3J051204;
	Mon, 19 Jul 2004 14:58: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-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 i6JLwajT051197
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 14:58:36 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from phys-bur-1 ([129.148.9.72])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i6JLuS53028615
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 15:56:28 -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 <0I1400201CUO87@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com)
 for atom-syntax@imc.org; Mon, 19 Jul 2004 17:58:41 -0400 (EDT)
Received: from mercury (vpn-129-150-32-212.Central.Sun.COM [129.150.32.212])
 by bur-mail1.east.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
 with ESMTP id <0I1400JK1D1NI5@bur-mail1.east.sun.com> for atom-syntax@imc.org;
 Mon, 19 Jul 2004 17:58:41 -0400 (EDT)
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1Bmg9K-0000nc-00	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 17:58:18 -0400
X-URL: http://nwalsh.com/
Date: Mon, 19 Jul 2004 17:58:18 -0400
From: Norman Walsh <ndw@nwalsh.com>
Subject: multipart/alternative
In-reply-to: <200407191919.PAA17914@ietf.org>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <87llhfslqd.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: <200407191919.PAA17914@ietf.org>
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-Type: text/plain

| 5.10  "atom:content" Element
| 
|    The "atom:content" element is a Content construct that conveys the
|    content of the entry.  atom:entry elements MAY contain one or more
|    atom:content elements.
| 
|    If @type="multipart/alternative", @mode MUST NOT be specified, and
|    content element MUST contain 1 or more content elements.  These
|    content elements MUST NOT specify @type="multipart/alternative" (i.e.
|    only one level of nesting is allowed).  Consumers SHOULD look at all
|    alternative content elements and determine which one is most
|    suitable, based on which @type and @mode the consumer supports, and
|    preferences specified by the end user (if any).  Consumers SHOULD NOT
|    render more than one content alternative.

I tried a little harder to understand this text this time. I think the
intent is:

  <atom:content type="multipart/alternative">
    <atom:content type="text/html">...</atom:content>
    <atom:content type="application/pdf">...</atom:content>
    ...
  </atom:content>

If that's the case, I think the phrase "MUST contain 1 or more content
elements". Perhaps it would be clearer to say "MUST contain 1 or more
atom:content elements"? Or maybe I just don't understand yet.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | And gentlemen in England now a-bed /
http://nwalsh.com/            | Shall think themselves accursed they
                              | were not here, / And hold their
                              | manhoods cheap whiles any speaks / That
                              | fought with us upon Saint Crispin's
                              | day.--William Shakespeare, Henry V

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA/EP6OyltUcwYWjsRAqyXAKCvxuhQWZIFL0L/cw2Kv8C73VJEfQCfew8J
dAE4TKLfWuOjMrnTfzIqrEU=
=ejR6
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Mon Jul 19 18: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 SAA18956
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 18:10: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 i6JLx9Oa051355;
	Mon, 19 Jul 2004 14:59: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 i6JLx9th051354;
	Mon, 19 Jul 2004 14:59: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 i6JLx8aT051348
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 14:59:08 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from phys-bur-1 ([129.148.9.72])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6JLxDil015869
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 15:59:13 -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 <0I1400201CUO87@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com)
 for atom-syntax@imc.org; Mon, 19 Jul 2004 17:59:13 -0400 (EDT)
Received: from mercury (vpn-129-150-32-212.Central.Sun.COM [129.150.32.212])
 by bur-mail1.east.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
 with ESMTP id <0I1400JNXD2OI5@bur-mail1.east.sun.com> for atom-syntax@imc.org;
 Mon, 19 Jul 2004 17:59:13 -0400 (EDT)
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BmgA0-0000nr-00	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 17:59:00 -0400
X-URL: http://nwalsh.com/
Date: Mon, 19 Jul 2004 17:58:59 -0400
From: Norman Walsh <ndw@nwalsh.com>
Subject: atom:origin?
In-reply-to: <200407191919.PAA17914@ietf.org>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <87hds3slp8.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: <200407191919.PAA17914@ietf.org>
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-Type: text/plain

| 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 same, character-for-character, as that of the
|    href attribute of the atom:link element that has a rel attribute
|    value of "alternate" in that document's atom:head section (i.e., the
|    XPath expression "/atom:feed/atom:head/atom:link[@rel='alternate']/
|    @href").

Really? Not the atom:id of the feed? That seems...odd.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | The sudden disappointment of hope
http://nwalsh.com/            | leaves a scar which the ultimate
                              | fulfillment of that hope never entirely
                              | removes.--Thomas Hardy

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA/EQkOyltUcwYWjsRAnnNAJ9WRfDyWd7eyNCkTV25wGecnWg6vwCdEle6
UQtNwIJkNtSIYSz+tBvAOmw=
=byya
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Mon Jul 19 18:21:28 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21857
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 18:21:28 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JMDUth053698;
	Mon, 19 Jul 2004 15: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 i6JMDUpC053697;
	Mon, 19 Jul 2004 15:13:30 -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 i6JMDTqw053680
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 15:13:29 -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 <20040719221328013003m5oee>; Mon, 19 Jul 2004 22:13:29 +0000
Date: Mon, 19 Jul 2004 16:13:26 -0600
Subject: Re: PaceLinkAttrDefaults
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: <m3llhfd6fh.fsf@bitsko.slc.ut.us>
Message-Id: <DB3F7E93-D9D0-11D8-B499-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 Monday, July 19, 2004, at 03:37  PM, Ken MacLeod wrote:
> When PaceLinkAttrDefaults describes its method of extension, we can
> compare it more evenly with PaceReplaceLinkElement.

I just took a look at PaceReplaceLinkElement, and it doesn't describe 
it's method of extension either.  I was going to follow that sentence 
with assumptions and ask if they were correct, but a few possibilities 
come to mind, so instead, I'll save myself the trouble of typing them 
all up and just ask, what is PaceReplaceLinkElement's method of 
extension?



From owner-atom-syntax@mail.imc.org  Mon Jul 19 18: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 SAA23150
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 18:26: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 i6JMI7LZ054365;
	Mon, 19 Jul 2004 15:18: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 i6JMI7H9054364;
	Mon, 19 Jul 2004 15:18:07 -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 i6JMI6Sc054345
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 15:18:06 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 25008 messnum 5124476 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 19 Jul 2004 22:18:06 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail13.svc.cra.dublin.eircom.net (qp 25008) with SMTP; 19 Jul 2004 22:18:06 -0000
Message-ID: <40FC489D.3010807@dehora.net>
Date: Mon, 19 Jul 2004 23:18:05 +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: Norman Walsh <ndw@nwalsh.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Text in atom:feed
References: <200407191919.PAA17914@ietf.org> <873c3nu0kp.fsf@nwalsh.com>
In-Reply-To: <873c3nu0kp.fsf@nwalsh.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


Norman Walsh wrote:

> | 4.  The "atom:feed" Element
> | 
> |    The "atom:feed" element is the document (i.e., top-level) element of
> |    an Atom Feed Document, acting as a container for metadata and data
> |    associated with the feed.  Its first element child MUST be atom:head,
> |    which MAY be followed zero or more atom:entry child elements.
> 
> I don't think this description goes far enough to forbid text content in
> atom:feed, which I think should be forbidden. Do we agree it should
> be forbidden?

+1 to forbidden and to stating so.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Mon Jul 19 18:27: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 SAA23331
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 18:27: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 i6JMJj5H054713;
	Mon, 19 Jul 2004 15:19:45 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6JMJjbc054712;
	Mon, 19 Jul 2004 15:19: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 (mproxy.gmail.com [216.239.56.243])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6JMJiEX054695
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 15:19:44 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so6224557cwc
        for <atom-syntax@imc.org>; Mon, 19 Jul 2004 15:19:46 -0700 (PDT)
Received: by 10.11.116.34 with SMTP id o34mr146617cwc;
        Mon, 19 Jul 2004 15:19:46 -0700 (PDT)
Message-ID: <3f1451f504071915197a07d06@mail.gmail.com>
Date: Mon, 19 Jul 2004 18:19:46 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Norman Walsh <ndw@nwalsh.com>
Subject: Re: Text in atom:feed
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <873c3nu0kp.fsf@nwalsh.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <200407191919.PAA17914@ietf.org> <873c3nu0kp.fsf@nwalsh.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 Mon, 19 Jul 2004 17:52:22 -0400, Norman Walsh <ndw@nwalsh.com> wrote:
> | 4.  The "atom:feed" Element
> |
> |    The "atom:feed" element is the document (i.e., top-level) element of
> |    an Atom Feed Document, acting as a container for metadata and data
> |    associated with the feed.  Its first element child MUST be atom:head,
> |    which MAY be followed zero or more atom:entry child elements.
> 
> I don't think this description goes far enough to forbid text content in
> atom:feed, which I think should be forbidden. Do we agree it should
> be forbidden?

+1

    -joe

-- 
Joe Gregorio        http://bitworking.org



From owner-atom-syntax@mail.imc.org  Mon Jul 19 18: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 SAA25259
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 18: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 i6JMOjBK056462;
	Mon, 19 Jul 2004 15:24: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 i6JMOjUa056461;
	Mon, 19 Jul 2004 15:24:45 -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 i6JMOi60056441
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 15:24:45 -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 i6JMOh53016093
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 17:24:44 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6JMOhj9016089;
	Mon, 19 Jul 2004 17:24:43 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: atom-syntax@imc.org
Subject: Re: PaceLinkAttrDefaults
References: <DB3F7E93-D9D0-11D8-B499-003065EA6144@geckotribe.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 19 Jul 2004 17:24:42 -0500
In-Reply-To: <DB3F7E93-D9D0-11D8-B499-003065EA6144@geckotribe.com>
Message-ID: <m3hds3d49h.fsf@bitsko.slc.ut.us>
Lines: 16
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: <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> writes:

> On Monday, July 19, 2004, at 03:37  PM, Ken MacLeod wrote:
> > When PaceLinkAttrDefaults describes its method of extension, we
> > can compare it more evenly with PaceReplaceLinkElement.
> 
> I just took a look at PaceReplaceLinkElement, and it doesn't
> describe it's method of extension either.  I was going to follow
> that sentence with assumptions and ask if they were correct, but a
> few possibilities come to mind, so instead, I'll save myself the
> trouble of typing them all up and just ask, what is
> PaceReplaceLinkElement's method of extension?

The same as other extensions in Atom: a new element name.

  -- Ken



From owner-atom-syntax@mail.imc.org  Mon Jul 19 18:40: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 SAA25440
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 18:40: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 i6JMSgbR057327;
	Mon, 19 Jul 2004 15: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 i6JMSgAN057326;
	Mon, 19 Jul 2004 15:28:42 -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 i6JMSfNN057306
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 15:28:42 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 40153 messnum 5051481 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 19 Jul 2004 22:28:41 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail04.svc.cra.dublin.eircom.net (qp 40153) with SMTP; 19 Jul 2004 22:28:41 -0000
Message-ID: <40FC4B18.7020400@dehora.net>
Date: Mon, 19 Jul 2004 23:28:40 +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: Norman Walsh <ndw@nwalsh.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: atom:origin?
References: <200407191919.PAA17914@ietf.org> <87hds3slp8.fsf@nwalsh.com>
In-Reply-To: <87hds3slp8.fsf@nwalsh.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


Norman Walsh wrote:

> | 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 same, character-for-character, as that of the
> |    href attribute of the atom:link element that has a rel attribute
> |    value of "alternate" in that document's atom:head section (i.e., the
> |    XPath expression "/atom:feed/atom:head/atom:link[@rel='alternate']/
> |    @href").
> 
> Really? Not the atom:id of the feed? That seems...odd.

Not that odd, since atom:id is optional. I would have used atom:id 
were that not the case.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Mon Jul 19 18:40:28 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25485
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 18:40:27 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JMU0q9057518;
	Mon, 19 Jul 2004 15:30: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 i6JMU0Ff057517;
	Mon, 19 Jul 2004 15:30:00 -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 i6JMTvTs057502;
	Mon, 19 Jul 2004 15:29:58 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p0611044dbd21fbd760ab@[10.20.30.249]>
In-Reply-To: <877jszu0p8.fsf@nwalsh.com>
References: <200407191919.PAA17914@ietf.org> <877jszu0p8.fsf@nwalsh.com>
Date: Mon, 19 Jul 2004 15:30:37 -0700
To: Norman Walsh <ndw@nwalsh.com>, Atom Syntax <atom-syntax@imc.org>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: Unstructured text
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 5:49 PM -0400 7/19/04, Norman Walsh wrote:
>The -01 draft describes two elements as having "unstructured text" as
>their content:
>
>[...]
>| 3.2.1  "atom:name" Element
>|
>|    The "atom:name" element's content conveys a human-readable name for
>|    the person.  Person constructs MUST contain exactly one "atom:name"
>|    element, whose content is unstructured text.
>[...]
>| 3.4.5  "title" Attribute
>|
>|    The "title" attribute conveys human-readable information about the
>|    link.  Link constructs MAY have a title attribute, whose value is
>|    unstructured text.
>
>It also describes the 'version' attribute this way. What is the intent here?

The intent in the version attribute is that you should not imply any 
structure to the text in the attribute. That is, you should not imply 
that "2.1" comes after "2", or that the version after "2" will be "3".

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Mon Jul 19 18:44: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 SAA26358
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 18:44: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 i6JMPJtW056562;
	Mon, 19 Jul 2004 15:25: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 i6JMPJ2q056561;
	Mon, 19 Jul 2004 15:25:19 -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 i6JMPIPh056538
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 15:25:18 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 51891 messnum 6507089 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 19 Jul 2004 22:25:17 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail12.svc.cra.dublin.eircom.net (qp 51891) with SMTP; 19 Jul 2004 22:25:17 -0000
Message-ID: <40FC4A4B.3050806@dehora.net>
Date: Mon, 19 Jul 2004 23:25:15 +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: Norman Walsh <ndw@nwalsh.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Unstructured text
References: <200407191919.PAA17914@ietf.org> <877jszu0p8.fsf@nwalsh.com>
In-Reply-To: <877jszu0p8.fsf@nwalsh.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


Norman Walsh wrote:


> It also describes the 'version' attribute this way. What is the intent here?
> Does "unstructured text" mean a string without markup? 

I assume it means #PCDATA.



>    Person constructs MUST contain exactly one "atom:name"
>    element, whose content is unstructured text. The "atom:name" element
>    must not contain any embedded element markup.


    Person constructs MUST contain exactly one
    "atom:name" element, whose content must not
    contain any embedded element markup.

Once you say no tags the "unstructured text" bit is redundant.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Mon Jul 19 18: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 SAA27713
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 18:50: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 i6JMgb1J059697;
	Mon, 19 Jul 2004 15:42:37 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6JMgbkY059695;
	Mon, 19 Jul 2004 15:42: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 i6JMgaPL059689
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 15:42: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 i6JMgfil006679
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 16:42:41 -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 <0I1400DCLF33II@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Mon, 19 Jul 2004 16:42:40 -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 <0I1400KC2F333Q@mail.sun.net> for atom-syntax@imc.org; Mon,
 19 Jul 2004 16:42:39 -0600 (MDT)
Date: Mon, 19 Jul 2004 15:42:47 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceLinkAttrDefaults
In-reply-to: <40FC0A55.5090409@intertwingly.net>
To: Atom-Syntax <atom-syntax@imc.org>
Message-id: <F52A7810-D9D4-11D8-92AF-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: <40FC0A55.5090409@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 Jul 19, 2004, at 10:52 AM, Sam Ruby wrote:

>
> http://www.intertwingly.net/wiki/pie/PaceLinkAttrDefaults

+1 to <link href=""> for the permalink.

+1 to the proposed semantics for type=""

+1 to removing rel= from current drafts until we have a coherent 
proposal on the table (if someone thinks that there's an existing Pace 
worth serious consideration, point it out)

+1 to removing the service.* machinery from <link> to its own element

  -Tim



From owner-atom-syntax@mail.imc.org  Mon Jul 19 18:50: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 SAA27721
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 18:50: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 i6JMfK5Z059499;
	Mon, 19 Jul 2004 15:41: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 i6JMfKqh059498;
	Mon, 19 Jul 2004 15:41:20 -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 i6JMfKOB059473
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 15:41:20 -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 8C18A171D27; Mon, 19 Jul 2004 18:42:20 -0400 (EDT)
Reply-To: <bobwyman@pubsub.com>
From: "Bob Wyman" <bobwyman@pubsub.com>
To: "'Norman Walsh'" <ndw@nwalsh.com>, "'Atom Syntax'" <atom-syntax@imc.org>
Subject: RE: Text in atom:feed
Date: Mon, 19 Jul 2004 18:41: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
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Thread-Index: AcRt3iVZapnsxV+XTFaFmzMlihZBWwAAzM9A
In-Reply-To: <873c3nu0kp.fsf@nwalsh.com>
Message-Id: <20040719224220.8C18A171D27@mail.pubsub.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


Norman Walsh wrote:
> text content in atom:feed, which I think should be forbidden. 
> Do we agree it should be forbidden?

	It should be forbidden. I agree.

		bob wyman



From owner-atom-syntax@mail.imc.org  Mon Jul 19 19:02: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 TAA00074
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 19:02:29 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JMsitk061762;
	Mon, 19 Jul 2004 15:54: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 i6JMsieS061761;
	Mon, 19 Jul 2004 15:54:44 -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 i6JMshOY061732
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 15:54:44 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 95544 messnum 9198582 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 19 Jul 2004 22:54:43 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail10.svc.cra.dublin.eircom.net (qp 95544) with SMTP; 19 Jul 2004 22:54:43 -0000
Message-ID: <40FC5132.3030102@dehora.net>
Date: Mon, 19 Jul 2004 23:54:42 +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: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>
CC: Paul Hoffman / IMC <phoffman@imc.org>, Norman Walsh <ndw@nwalsh.com>,
        Atom Syntax <atom-syntax@imc.org>
Subject: Re: Unstructured text
References: <200407191919.PAA17914@ietf.org> <877jszu0p8.fsf@nwalsh.com> <p0611044dbd21fbd760ab@[10.20.30.249]> <40FC50C4.5060007@dehora.net>
In-Reply-To: <40FC50C4.5060007@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:

> "atom:feed elements MUST have a "version" attribute whose content 
> indicates the version of the Atom specification that the feed conforms 
> to.  The content of this attribute element should be treated as opaque, 
> unstructured text."

s/element//

cheers
Bill



From owner-atom-syntax@mail.imc.org  Mon Jul 19 19:03: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 TAA00178
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 19:03: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 i6JMqsbm061493;
	Mon, 19 Jul 2004 15:52: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 i6JMqs1E061492;
	Mon, 19 Jul 2004 15:52:54 -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 i6JMqrjR061467
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 15:52:53 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 76336 messnum 2823334 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 19 Jul 2004 22:52:52 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail07.svc.cra.dublin.eircom.net (qp 76336) with SMTP; 19 Jul 2004 22:52:52 -0000
Message-ID: <40FC50C4.5060007@dehora.net>
Date: Mon, 19 Jul 2004 23:52:52 +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: Paul Hoffman / IMC <phoffman@imc.org>
CC: Norman Walsh <ndw@nwalsh.com>, Atom Syntax <atom-syntax@imc.org>
Subject: Re: Unstructured text
References: <200407191919.PAA17914@ietf.org> <877jszu0p8.fsf@nwalsh.com> <p0611044dbd21fbd760ab@[10.20.30.249]>
In-Reply-To: <p0611044dbd21fbd760ab@[10.20.30.249]>
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


Paul Hoffman / IMC wrote:


> The intent in the version attribute is that you should not imply any 
> structure to the text in the attribute. That is, you should not imply 
> that "2.1" comes after "2", or that the version after "2" will be "3".

If that's the intent, how about adding "opaque" and a constraint:

"atom:feed elements MUST have a "version" attribute whose content 
indicates the version of the Atom specification that the feed 
conforms to.  The content of this attribute element should be 
treated as opaque, unstructured text."

?

cheers
Bill



From owner-atom-syntax@mail.imc.org  Mon Jul 19 19:03:38 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00275
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 19:03: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 i6JMs3HE061661;
	Mon, 19 Jul 2004 15:54: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 i6JMs3Vr061660;
	Mon, 19 Jul 2004 15:54:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JMs2Yh061652
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 15:54:03 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i6JMpt53024467
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 16:51:55 -0600 (MDT)
Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0I1400E4LFM7W3@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Mon, 19 Jul 2004 16:54:08 -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 <0I1400KF6FM73Q@mail.sun.net> for atom-syntax@imc.org; Mon,
 19 Jul 2004 16:54:07 -0600 (MDT)
Date: Mon, 19 Jul 2004 15:54:16 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Unstructured text
In-reply-to: <p0611044dbd21fbd760ab@[10.20.30.249]>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <8F9CAA61-D9D6-11D8-92AF-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: <200407191919.PAA17914@ietf.org> <877jszu0p8.fsf@nwalsh.com>
 <p0611044dbd21fbd760ab@[10.20.30.249]>
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 Jul 19, 2004, at 3:30 PM, Paul Hoffman / IMC wrote:

> The intent in the version attribute is that you should not imply any 
> structure to the text in the attribute. That is, you should not imply 
> that "2.1" comes after "2", or that the version after "2" will be "3".

Which, by the way, I probably disagree with; I believe 
extensibility/versioning proposals such as Dave Orchard's recent 
submission are going to work better if there is a clear ordering on 
version stamps. -Tim



From owner-atom-syntax@mail.imc.org  Mon Jul 19 19:05: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 TAA00582
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 19:05: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 i6JMtrKc061966;
	Mon, 19 Jul 2004 15:55: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 i6JMtr8r061965;
	Mon, 19 Jul 2004 15:55:53 -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 i6JMtpmA061937
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 15:55:51 -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 i6JMtp53016532
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 17:55:51 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6JMtp4p016528;
	Mon, 19 Jul 2004 17:55:51 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceLinkAttrDefaults
References: <40FC0A55.5090409@intertwingly.net>
	<F52A7810-D9D4-11D8-92AF-000A95A51C9E@sun.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 19 Jul 2004 17:55:50 -0500
In-Reply-To: <F52A7810-D9D4-11D8-92AF-000A95A51C9E@sun.com>
Message-ID: <m37jszd2tl.fsf@bitsko.slc.ut.us>
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: <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> writes:

> On Jul 19, 2004, at 10:52 AM, Sam Ruby wrote:
> 
> >
> > http://www.intertwingly.net/wiki/pie/PaceLinkAttrDefaults
> 
> +1 to removing rel= from current drafts until we have a coherent
> proposal on the table (if someone thinks that there's an existing
> Pace worth serious consideration, point it out)

PaceReplaceLinkElement.

  -- Ken



From owner-atom-syntax@mail.imc.org  Mon Jul 19 19:14:17 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02239
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 19:14: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 i6JN5lXG063745;
	Mon, 19 Jul 2004 16: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 i6JN5l0m063744;
	Mon, 19 Jul 2004 16:05:47 -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 i6JN5kqE063738
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 16:05:46 -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 i6JN5n4Q007669;
	Mon, 19 Jul 2004 16:05:49 -0700
Received: from ussjex01.amer.bea.com ([172.16.120.50]) by ussjfe01.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 19 Jul 2004 16:05:50 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: PaceExtensibilityAndVersioning
Date: Mon, 19 Jul 2004 16:05:49 -0700
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF08FA743F@ussjex01.amer.bea.com>
Thread-Topic: PaceExtensibilityAndVersioning
Thread-Index: AcRtz7ASTFlrJXzsS9SRZIyB10FkKgAEtalw
From: "David Orchard" <dorchard@bea.com>
To: "Ken MacLeod" <ken@bitsko.slc.ut.us>, "Atom Syntax" <atom-syntax@imc.org>
X-OriginalArrivalTime: 19 Jul 2004 23:05:50.0095 (UTC) FILETIME=[EEE199F0:01C46DE4]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6JN5kqE063739
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


Ken,

Could elaborate a bit more?  I'm a little confused about who's being targetted with what extensions.  In your possibility #1, where is the extension?  

I think you are asking 2 separate questions: 
1) Do we want a mustUnderstand at the element level to be a fault of the feed or the element?  
2) Do we want to be able to target particulare nodes(intermediaries) with a mustUnderstand, ie an intermediary and the target node mustUnderstand a particular extension?

I don't know whether an intermediary should be targetable with an extension.  I've always found intermediaries very confusing.  Does this happen in Atom?

Is the particular problem you are worried about that a feed aggregator might not understand an extension but the receiving nodes might, and so an entry is marked with mU but the feed doesn't get it?  FWIW, this is exactly why SOAP has the "role" attribute, so that particular nodes can be targetted with information and mU.

I think I'm hearing that there are really 3 scenarios for end nodes:
- unknown element extension is optional and is ignored
- unknown element extension is required for entire feed and faults entire feed if extension is unknown.
- unknown element extension is required for element and faults (ignores?) element if extension is unknown.

Which seems like a question about scope of the faulting if unknown.  Perhaps unknownExtensionFaultScope="atom:element" in the element extension?  So it can pick out high up the ancestry the mU applies?

Dave


> -----Original Message-----
> From: owner-atom-syntax@mail.imc.org
> [mailto:owner-atom-syntax@mail.imc.org]On Behalf Of Ken MacLeod
> Sent: Monday, July 19, 2004 1:31 PM
> To: Atom Syntax
> Subject: Re: PaceExtensibilityAndVersioning
> 
> 
> 
> "David Orchard" <dorchard@bea.com> writes:
> 
> > http://www.intertwingly.net/wiki/pie/PaceExtensibilityAndVersioning
> 
> +1
> 
> One thing I'm trying to think of is how we could model mustUnderstand
> causing the faulting of individual entries, rather than an entire
> feed.
> 
> Possibility #1:
> 
>     Restrict faulting to identified "top-level" elements.  If an
>     extension should fault at both the feed level and at the element
>     level, a mustUnderstand attribute must appear in both.  The
>     corresponding feed-level mustUnderstand element may just be a
>     placeholder for that purpose.
> 
> Possibility #2:
> 
>     Instead of true/false, we use feed/entry/none (default: none).
> 
>     Pass-through intermediaries could then pass-through entries marked
>     with mustUnderstand="entry", but not entries marked with
>     mustUnderstand="feed", since the intermediary itself must
>     understand the effect on the feed from the one entry to be able to
>     pass it on alone.
> 
>     Feed-level extensions would be always be feed/none.
> 
>     This possibility has the drawback in that it doesn't scale well to
>     other top-level elements, that may in turn be cross-referenced to
>     other top-level elements.
> 
> Possibility #3:
> 
>     Do nothing.  If the intermediary doesn't understand, it faults its
>     source feed and doesn't pass on any entries.  If the intermediary
>     does understand the scope of the extension element, and chooses to
>     pass on an entry with mustUnderstand="true", it understands that
>     downstream clients may fault the entire feed based on that entry.
> 
>   -- Ken
> 
> 



From owner-atom-syntax@mail.imc.org  Mon Jul 19 19:31: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 TAA05463
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 19: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 i6JNOT38066942;
	Mon, 19 Jul 2004 16:24: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 i6JNOT0P066941;
	Mon, 19 Jul 2004 16:24:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxsf01.cluster1.charter.net (mxsf01.cluster1.charter.net [209.225.28.201])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JNOS51066904
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 16:24:29 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from mxip18.cluster1.charter.net (mxip18a.cluster1.charter.net [209.225.28.148])
	by mxsf01.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id i6JNT4rc030330
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 19:29:04 -0400
Received: from cpe-24-177-58-142.ma.charter.com (HELO mercury) (24.177.58.142)
  by mxip18.cluster1.charter.net with ESMTP; 19 Jul 2004 19:24:25 -0400
X-Ironport-AV: i="3.81R,180,1083556800"; 
   d="scan'208"; a="127623910:sNHT15127952"
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BmhUV-0002Us-00
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 19:24:15 -0400
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Unstructured text
References: <200407191919.PAA17914@ietf.org> <877jszu0p8.fsf@nwalsh.com>
	<p0611044dbd21fbd760ab@[10.20.30.249]> <40FC50C4.5060007@dehora.net>
From: Norman Walsh <ndw@nwalsh.com>
X-URL: http://nwalsh.com/
Date: Mon, 19 Jul 2004 19:24:15 -0400
In-Reply-To: <40FC50C4.5060007@dehora.net> (Bill de
 =?iso-8859-1?q?h=D3ra's?= message of "Mon, 19 Jul 2004 23:52:52 +0100")
Message-ID: <87pt6rr36o.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: <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-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

/ Bill de h=D3ra <bill@dehora.net> was heard to say:
| Paul Hoffman / IMC wrote:
|
|> The intent in the version attribute is that you should not imply any
|> structure to the text in the attribute. That is, you should not
|> imply that "2.1" comes after "2", or that the version after "2" will
|> be "3".
|
| If that's the intent, how about adding "opaque" and a constraint:
|
| "atom:feed elements MUST have a "version" attribute whose content
| indicates the version of the Atom specification that the feed conforms
| to.  The content of this attribute element should be treated as
| opaque, unstructured text."

How about removing "unstructured text" in that sentence. Using the same
phrase for two different purposes is confusing.

                                        Be seeing you,
                                          norm

=2D-=20
Norman Walsh <ndw@nwalsh.com> | People say law but they mean wealth.--
http://nwalsh.com/            | Emerson

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA/FgfOyltUcwYWjsRAj/sAJ9zsBAO/MCjtbsCPdeo7K9iHH77YACcC/br
CSod2oQjXc7oXPXgSFb16M0=
=ivQd
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Mon Jul 19 19: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 TAA07098
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 19:39: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 i6JNWk88068390;
	Mon, 19 Jul 2004 16:32: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 i6JNWk31068389;
	Mon, 19 Jul 2004 16:32:46 -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 i6JNWkdH068371
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 16:32:46 -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 <2004071923324601600bf0t8e>; Mon, 19 Jul 2004 23:32:46 +0000
Date: Mon, 19 Jul 2004 17:32:45 -0600
Subject: Re: PaceLinkAttrDefaults
Content-Type: text/plain; delsp=yes; 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: <m3hds3d49h.fsf@bitsko.slc.ut.us>
Message-Id: <EFC99BA0-D9DB-11D8-B499-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 Monday, July 19, 2004, at 04:24  PM, Ken MacLeod wrote:
> Antone Roundy <antone@geckotribe.com> writes:
>> On Monday, July 19, 2004, at 03:37  PM, Ken MacLeod wrote:
>>> When PaceLinkAttrDefaults describes its method of extension, we
>>> can compare it more evenly with PaceReplaceLinkElement.
>>
>> I just took a look at PaceReplaceLinkElement, and it doesn't
>> describe it's method of extension either.  I was going to follow
>> that sentence with assumptions and ask if they were correct, but a
>> few possibilities come to mind, so instead, I'll save myself the
>> trouble of typing them all up and just ask, what is
>> PaceReplaceLinkElement's method of extension?
>
> The same as other extensions in Atom: a new element name.
>
Okay, that much was obvious.  You've posted a similar comment in  
PaceLinkPurpose.  Here are a few comments and assumptions on each:

PaceReplaceLinkElement:
1) How new links are defined: Whether in the core or a new namespace,  
new Link Constructs get a new element name.
2) Name collision: Because extensions have to use their own namespace,  
there's no problem with name collision.
3) Default Link Construct processing for unknown types: Apparently none  
(not all Link Constructs can be handled the same way, so it seems  
unlikely that new Link Constructs will all follow any particular  
pattern).
4) Unknown Link Construct recognizability: Unknown, but not useful  
anyway because of the answer to #3.

PaceLinkAttrDefaults:
1) How new links are defined: add new @rel value to the core  
specification (currently enumerated in the API spec)
2) Name collision: Because extensions can't create new @rel values,  
there's no problem with name collision.
3) Default Link Construct processing for unknown types: Unless other  
proposals like PaceLinkPurpose and PaceServiceElement are adopted,  
apparently none for the same reasons as listed for  
PaceReplaceLinkElement.  (Note: Sam's comment in the Notes section  
supports something along those lines).
4) Unknown Link Construct recognizability: The link element is the only  
Link Construct, so it's immediately recognizable, but that may or may  
not be useful depending on what happens with #3.

PaceLinkPurpose:
1) How new links are defined: New @rel values are added to the core, or  
by some not-yet-specified extension method.
2) Name collision: Unknown (see #1).
3) Default Link Construct processing for unknown types: Unknown link  
types can be rendered as user-activatable links.
4) Unknown Link Construct recognizability: The link element is the only  
Link Construct, so it's immediately recognizable.

Other comments:
A) If only this section of PaceLinkPurpose is adopted:
> 3.4 Link Constructs A Link construct specifies a hyperlink primarily  
> intended to be activated through explicit user interactions such as  
> clicking, selecting a menu item, drag and drop, etc. When accessing  
> the resource pointed to by the href attribute using HTTP, the GET  
> method MUST be used. It MUST NOT have any child content. The Link  
> Construct has the following attributes:
and not this part:
> 3.4.1 "rel" Attribute The "rel" attribute indicates the type of  
> relationship that the link represents. Link constructs MUST have a rel  
> attribute, whose value MUST be a string, and MAY either be one of the  
> values enumerated (either "below:", if we move the list into this  
> specification, or "in the Atom API specification  
> <eref>http://bitworking.org/projects/atom/draft-gregorio-09.html</ 
> eref>." otherwise) or be defined by an extension.
and additions to the @rel list are only allowed in the core (not  
through extensions--as at present), then #1 and #2 for PaceLinkPurpose  
become the same as for PaceLinkAttrDefaults.

B) If section 3.4 from PaceLinkPurpose is adopted and  
PaceReplaceLinkElement is adopted (except that things like service-post  
which don't work with PaceLinkPurpose are no longer considered "Link  
Constructs"), then answers for the combination come from #1 and #2 from  
PaceReplaceLinkElement, and #3 and #4 from PaceLinkPurpose.

C) If we can decide on a way to recognize Link Constructs and adopt  
section 3.4 from PaceLinkPurpose, I would support  
PaceReplaceLinkElement to the extent that it is compatible with  
PaceLinkPurpose.  That would answer #1 and #2 for PaceLinkPurpose.  The  
difficult part is deciding how to make Link Constructs recognizable.   
Of the ideas mentioned thus far, I think the least potentially  
problematic is to have a separate namespace for Link Construct  
attributes, the use of which indicates that the element using them can  
be processed as a Link Construct.  For example:

<feed xmlns="atom's namespace"
	xmlns:ex="atom's extension namespace"
	xmlns:ox="some other extension's namespace">

<some-core-link-construct ex:href="uri" ... />

<ox:some-extension-link-construct ex:href="uri" ... />

</feed>



From owner-atom-syntax@mail.imc.org  Mon Jul 19 19:40:02 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07319
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 19:40: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 i6JNXWYC068502;
	Mon, 19 Jul 2004 16:33: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 i6JNXWCF068501;
	Mon, 19 Jul 2004 16:33:32 -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 i6JNXV7I068485
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 16:33:31 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 37602 messnum 2981370 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 19 Jul 2004 23:33:31 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail07.svc.cra.dublin.eircom.net (qp 37602) with SMTP; 19 Jul 2004 23:33:31 -0000
Message-ID: <40FC5A4A.7000503@dehora.net>
Date: Tue, 20 Jul 2004 00:33:30 +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: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>
CC: Norman Walsh <ndw@nwalsh.com>, Atom Syntax <atom-syntax@imc.org>
Subject: Re: Unstructured text
References: <200407191919.PAA17914@ietf.org> <877jszu0p8.fsf@nwalsh.com>	<p0611044dbd21fbd760ab@[10.20.30.249]> <40FC50C4.5060007@dehora.net> <87pt6rr36o.fsf@nwalsh.com> <40FC59DF.5000801@dehora.net>
In-Reply-To: <40FC59DF.5000801@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:

> Norman Walsh wrote:
> 
> 
>> How about removing "unstructured text" in that sentence. Using the same
>> phrase for two different purposes is confusing.
> 
> 
> Like this:
> 
> "atom:feed elements MUST have a "version" attribute whose content 
> indicates the version of the Atom specification that the feed conforms 
> to.  The content of this attribute element should be considered opaque." *


(aaarrgh) s/element//:

"atom:feed elements MUST have a "version" attribute whose content 
indicates the version of the Atom specification that the feed 
conforms to.  The content of this attribute should be considered 
opaque."

cheers
Bill





From owner-atom-syntax@mail.imc.org  Mon Jul 19 19:40: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 TAA07557
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 19:40: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 i6JNVj8d068202;
	Mon, 19 Jul 2004 16:31: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 i6JNVjHa068201;
	Mon, 19 Jul 2004 16:31:45 -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 i6JNVia3068146
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 16:31:44 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 34673 messnum 9352020 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 19 Jul 2004 23:31:44 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail10.svc.cra.dublin.eircom.net (qp 34673) with SMTP; 19 Jul 2004 23:31:44 -0000
Message-ID: <40FC59DF.5000801@dehora.net>
Date: Tue, 20 Jul 2004 00:31: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: Norman Walsh <ndw@nwalsh.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Unstructured text
References: <200407191919.PAA17914@ietf.org> <877jszu0p8.fsf@nwalsh.com>	<p0611044dbd21fbd760ab@[10.20.30.249]> <40FC50C4.5060007@dehora.net> <87pt6rr36o.fsf@nwalsh.com>
In-Reply-To: <87pt6rr36o.fsf@nwalsh.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


Norman Walsh wrote:


> How about removing "unstructured text" in that sentence. Using the same
> phrase for two different purposes is confusing.

Like this:

"atom:feed elements MUST have a "version" attribute whose content 
indicates the version of the Atom specification that the feed 
conforms to.  The content of this attribute element should be 
considered opaque." *

?

cheers
Bill

* "considered opaque" sounded 'better' than "treated opaquely"



From owner-atom-syntax@mail.imc.org  Mon Jul 19 19: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 TAA10858
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 19:53: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 i6JNfqUx069934;
	Mon, 19 Jul 2004 16: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 i6JNfqvC069933;
	Mon, 19 Jul 2004 16:41:52 -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 i6JNfo0d069917
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 16:41:51 -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 i6JNfo53017196
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 18:41:51 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6JNfo7U017191;
	Mon, 19 Jul 2004 18:41:50 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: "Atom Syntax" <atom-syntax@imc.org>
Subject: Re: PaceExtensibilityAndVersioning
References: <32D5845A745BFB429CBDBADA57CD41AF08FA743F@ussjex01.amer.bea.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 19 Jul 2004 18:41:50 -0500
In-Reply-To: <32D5845A745BFB429CBDBADA57CD41AF08FA743F@ussjex01.amer.bea.com>
Message-ID: <m33c3nd0ox.fsf@bitsko.slc.ut.us>
Lines: 61
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


"David Orchard" <dorchard@bea.com> writes:

> Could elaborate a bit more?  I'm a little confused about who's being
> targetted with what extensions.  In your possibility #1, where is
> the extension?

A producer publishes a feed which contains entries where some contain
elements with mustUnderstand="true".  An intermediary (like Feedster
or PubSub) reads the feed and selects entries to redistribute in a new
feed.  The client reads the feed from the intermediary.

The mU extension is in the entry and ''The meaning of
"understanding"'' is that it only applies to the entry.

> I think you are asking 2 separate questions: 
> 1) Do we want a mustUnderstand at the element level to be a fault of
> the feed or the element?

This is the more important question.  Can we optionally restrict
faulting to the atom:entry element level.

> 2) Do we want to be able to target particulare nodes(intermediaries)
> with a mustUnderstand, ie an intermediary and the target node
> mustUnderstand a particular extension?

This question can be deferred until (1) is addressed.

> I don't know whether an intermediary should be targetable with an
> extension.  I've always found intermediaries very confusing.  Does
> this happen in Atom?

Yes.  Copying of individual entries from feeds or other sources is
picking up.  Sites like Feedster and PubSub are doing this on a big
scale, and TrackBack and remote comments are be doing it on a small
scale.

> Is the particular problem you are worried about that a feed
> aggregator might not understand an extension but the receiving nodes
> might, and so an entry is marked with mU but the feed doesn't get
> it?  FWIW, this is exactly why SOAP has the "role" attribute, so
> that particular nodes can be targetted with information and mU.

No, I'm not worried so much about the role as I am worried that
atom:entry elements are considered first-class resources in their own
right, even when grouped together within a feed, so the scope question
below is what applies:

> I think I'm hearing that there are really 3 scenarios for end nodes:
> - unknown element extension is optional and is ignored
> - unknown element extension is required for entire feed and faults
>   entire feed if extension is unknown.
> - unknown element extension is required for element and faults
>   (ignores?) element if extension is unknown.
> 
> Which seems like a question about scope of the faulting if unknown.
> Perhaps unknownExtensionFaultScope="atom:element" in the element
> extension?  So it can pick out high up the ancestry the mU applies?

Yes, that'd work.

  -- Ken



From owner-atom-syntax@mail.imc.org  Mon Jul 19 19:56: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 TAA11305
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 19:56: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 i6JNlC7I070747;
	Mon, 19 Jul 2004 16:47:12 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6JNlCPh070746;
	Mon, 19 Jul 2004 16:47:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JNlCqk070726
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 16:47:12 -0700 (PDT)
	(envelope-from antone@geckotribe.com)
Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134])
          by comcast.net (rwcrmhc13) with SMTP
          id <20040719234712015003klcie>; Mon, 19 Jul 2004 23:47:12 +0000
Date: Mon, 19 Jul 2004 17:47:11 -0600
Subject: Re: PaceLinkAttrDefaults
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: <EFC99BA0-D9DB-11D8-B499-003065EA6144@geckotribe.com>
Message-Id: <F44B3D6E-D9DD-11D8-B499-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


Note a few additions to the following:

On Monday, July 19, 2004, at 05:32  PM, Antone Roundy wrote:
> <feed xmlns="atom's namespace"
> 	xmlns:ex="atom's extension namespace"
> 	xmlns:ox="some other extension's namespace">
>
> <some-core-link-construct ex:href="uri" ... />
>
> <ox:some-extension-link-construct ex:href="uri" ... />

<ox:some-core-NON-link-construct href="uri" ... />
<ox:some-core-NON-link-construct ox:href="uri" ... />

<ox:some-extension-NON-link-construct href="uri" ... />

> </feed>

Only @ex:href indicates a "Link Construct" as defined by 
PaceLinkConstruct.  @href and @ox:href do not.



From owner-atom-syntax@mail.imc.org  Mon Jul 19 19:57: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 TAA11488
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 19:57:43 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JNog68071270;
	Mon, 19 Jul 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 i6JNogd7071269;
	Mon, 19 Jul 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 chromium.sabren.com (chromium.sabren.com [69.20.61.177])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6JNofxc071261
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 16:50:41 -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 i6JNpa30031193;
	Mon, 19 Jul 2004 19:51:36 -0400
Message-ID: <40FC5E56.90505@intertwingly.net>
Date: Mon, 19 Jul 2004 19:50:46 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>
CC: Norman Walsh <ndw@nwalsh.com>, Atom Syntax <atom-syntax@imc.org>
Subject: Re: atom:origin?
References: <200407191919.PAA17914@ietf.org> <87hds3slp8.fsf@nwalsh.com> <40FC4B18.7020400@dehora.net>
In-Reply-To: <40FC4B18.7020400@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:
> 
> Norman Walsh wrote:
> 
>> | 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 same, character-for-character, as that of 
>> the
>> |    href attribute of the atom:link element that has a rel attribute
>> |    value of "alternate" in that document's atom:head section (i.e., the
>> |    XPath expression "/atom:feed/atom:head/atom:link[@rel='alternate']/
>> |    @href").
>>
>> Really? Not the atom:id of the feed? That seems...odd.
> 
> 
> Not that odd, since atom:id is optional. I would have used atom:id were 
> that not the case.

http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-01.txt

Section 5.5  "atom:id" Element :

    atom:entry MUST contain exactly one atom:id element.  The content of
    this element MUST be a URI.

- Sam Ruby

P.S.  Yes, this is a change from format-00



From owner-atom-syntax@mail.imc.org  Mon Jul 19 21:21: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 VAA19108
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 21:21: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 i6K1CMTG087373;
	Mon, 19 Jul 2004 18: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 i6K1CMQg087372;
	Mon, 19 Jul 2004 18:12:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K1CH02087216
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 18:12:21 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 20 Jul 2004 11:17:13 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Tue, 20 Jul 2004 11:11:43 +1000
Subject: Re: PaceLinkAttrDefaults
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD22AE6F.2102C%eric.scheid@ironclad.net.au>
In-Reply-To: <40FC0A55.5090409@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: <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 20/7/04 3:52 AM, "Sam Ruby" <rubys@intertwingly.net> wrote:

> There are five additional columns, rel, type, href, hreflang, and title.
> Rel has a default of "alternate".  href has a non-null constraint.
> All the remaining elements may be null.

I'm not so sure about @rel defaulting to "alternate". Does that capture the
essence of "here is a link to a resource of some relevance to this entity"?

Perhaps the default should be null, meaning no relationship is specified,
only the connection is specified.

I'm thinking particularly of <link> inside <author>.

e.



From owner-atom-syntax@mail.imc.org  Mon Jul 19 21: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 VAA19545
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 21: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 i6K1JjYU089023;
	Mon, 19 Jul 2004 18:19:45 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6K1JjtS089022;
	Mon, 19 Jul 2004 18:19:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K1Je3C089000
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 18:19:43 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 20 Jul 2004 11:25:01 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Tue, 20 Jul 2004 11:19:30 +1000
Subject: Re: Unstructured text
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD22B042.21030%eric.scheid@ironclad.net.au>
In-Reply-To: <40FC4A4B.3050806@dehora.net>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6K1Ji3C089015
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 20/7/04 8:25 AM, "Bill de hÓra" <bill@dehora.net> wrote:

>>    Person constructs MUST contain exactly one "atom:name"
>>    element, whose content is unstructured text. The "atom:name" element
>>    must not contain any embedded element markup.
> 
> 
>   Person constructs MUST contain exactly one
>   "atom:name" element, whose content must not
>   contain any embedded element markup.
> 
> Once you say no tags the "unstructured text" bit is redundant.

Not entirely. Some places might want to emit names like this:

    <name>de hÓra, Bill</name>

that is structured, but it has no embedded markup.


Similarly,<feed @version="1.2.3" /> is structured, as is

    <generator>
        <version>MozAtom/5.0 (Macintosh; U; PPC Mac OS X; en)
AppleWebKit/125.2 (KHTML, like Gecko) FooBar/125.8</version>
    </generator>

e.




From owner-atom-syntax@mail.imc.org  Mon Jul 19 22:26: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 WAA23209
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 22:26: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 i6K2D3AP000331;
	Mon, 19 Jul 2004 19: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 i6K2D3r7000330;
	Mon, 19 Jul 2004 19:13:03 -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 i6K2D00i000317
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 19:13:02 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 20 Jul 2004 12:18:23 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Tue, 20 Jul 2004 12:12:53 +1000
Subject: Re: atom:origin?
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD22BCC5.2105D%eric.scheid@ironclad.net.au>
In-Reply-To: <87hds3slp8.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: <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


> | 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 same, character-for-character, as that of the
> |    href attribute of the atom:link element that has a rel attribute
> |    value of "alternate" in that document's atom:head section (i.e., the
> |    XPath expression "/atom:feed/atom:head/atom:link[@rel='alternate']/
> |    @href").
> 
> Really? Not the atom:id of the feed? That seems...odd.

additionally, 

(1) there may actually be multiple elements that match that XPath, they just
might have different @type values...

    <feed>
        <head>
            <link rel="alternate" type="text/html" href="..." />
            <link rel="alternate" type="application/atom+xml" href="..." />
            ...

(2) another problem which might arise is xml:base implications...

  <feed xml:base="http://example.org/myblog/">
    <link rel="alternate" type="application/atom+xml"
        href="latest.atom" />

character for character, atom:origin would be thus be "latest.atom". Not
very useful.

e.



From owner-atom-syntax@mail.imc.org  Mon Jul 19 22:40:07 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24173
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 22:40:06 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K2UIwS004551;
	Mon, 19 Jul 2004 19: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 i6K2UImp004550;
	Mon, 19 Jul 2004 19:30:18 -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 i6K2UHhZ004536
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 19:30:17 -0700 (PDT)
	(envelope-from distobj@acm.org)
Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian))
	id 1BmkPC-0005AN-00; Mon, 19 Jul 2004 22:30:58 -0400
Date: Mon, 19 Jul 2004 22:30:58 -0400
To: David Orchard <dorchard@bea.com>
Cc: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Private extension support (was Re: Q: Put request should return Atom entry?
Message-ID: <20040720023058.GA30868@markbaker.ca>
References: <32D5845A745BFB429CBDBADA57CD41AF08FA6DCF@ussjex01.amer.bea.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <32D5845A745BFB429CBDBADA57CD41AF08FA6DCF@ussjex01.amer.bea.com>
User-Agent: Mutt/1.3.28i
From: Mark Baker <distobj@acm.org>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


On Mon, Jul 19, 2004 at 09:49:49AM -0700, David Orchard wrote:
> I wrote up some thoughts a while ago on applying some "standard" format extensibility rules to protocols
> 
> http://www.pacificspirit.com/blog/2004/06/14/protocol_extensibility_and_versioning

Right-o.

> Seems like a reasonable question to ask, but it's harder to figure out what to do...

As I see it, we have three options, at least to begin with;

1. support (RESTful) SOAP
2. support RFC 2774
3. forget about it

With both #1 and #2, my plan is that vanilla HTTP would be used by
agents not implementing an incompatible extension.  For agents that do
support such an extension, we'd recommend that the extension be defined
using whichever one of those options we decide upon.  Where it gets
tricky is that we'd also need to define behaviour for agents that choose
not to support either option (since to support one is a significant
burden with no immediate payback) so that their behaviour is
consistent with that of an agent which does support it, but no
extensions.  For example, if we opted to use SOAP, then an Atom server
choosing not to support it would still need to be able to respond with a
SOAP mustUnderstand fault to all incoming SOAP requests (as we're
assuming that SOAP is only used when mustUnderstand is used, though
there's some wiggle room there we can play with).

FWIW, I'd personally like to see SOAP supported since extensibility is
what it's best at, and, unlike RFC 2774, actually has a deployed SDK or
two. 8-)

I'd be happy to spend the time writing a Pace on this - I just wanted to
get a feel from folks about whether that would be a waste of my time or
not.  Obviously I'd be looking directly to you, Dave, for support and
input because I believe you appreciate the importance and complexity of
this space.

Mark.



From owner-atom-syntax@mail.imc.org  Mon Jul 19 22:44: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 WAA24371
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 22: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 i6K2XURe005344;
	Mon, 19 Jul 2004 19:33: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 i6K2XUsg005342;
	Mon, 19 Jul 2004 19:33:30 -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 i6K2XTca005315
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 19:33:29 -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 <20040720023328015003m3fse>; Tue, 20 Jul 2004 02:33:29 +0000
Date: Mon, 19 Jul 2004 20:33:28 -0600
Mime-Version: 1.0 (Apple Message framework v553)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Subject: PaceExtensionNamespace created
From: Antone Roundy <antone@geckotribe.com>
To: atom-syntax@imc.org
Content-Transfer-Encoding: 7bit
Message-Id: <2F1E54F4-D9F5-11D8-B499-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


http://www.intertwingly.net/wiki/pie/PaceExtensionNamespace

I may be crazy, but I've frittered away more time than it takes to 
listen to an episode of Car Talk creating another proposal to attack 
the whole Link conundrum.  It might be described as a fusion of 
PaceLinkPurpose, PaceServiceElement, PaceReplaceLinkElement, and who 
knows what else.  Here are the most interesting portions of the 
proposal:

Rationale

A number of extensibility issues have been raised, primarily in 
connection with the discussion of Link Constructs and the link element:

    1. The current extension model for the Link Construct, adding to the 
list of values for the link element's rel attribute, cannot not 
accomodate third-party extensions without introducing qnames in the rel 
attribute--an idea that has been strongly opposed by many.

    2. Some have recognized benefits to a third-party extensible Link 
Construct allowing default processing of unknown Link Constructs.

    3. The link element, as it now stands and as proposed by various 
proposals, is overloaded with a variety of different purposes: 
specifying hyperlinks (user-activatable links), pointing to API 
endpoints, pointed to content to be embedded, etc. Each of these 
classes of link could be grouped into a Construct which could benefit 
from extensibility.

Proposal

All changes are stated in relation to [WWW]this draft of the Atom 
Syndication Format

Insert the following before section 3.1:

3.1. Extension Namespace

The Atom Extension Namespace defines a number of attributes by which 
common constructs may be recognized. The extension namespace URI for 
this specification is:

       http://purl.org/atom/extension-ns#draft-ietf-atompub-format-01

The attributes defined by the extension namespace may be recognized in 
this specification by the namespace "atomex". Attributes from the 
extension namespace MUST be explicitly namespace qualified, meaning 
that the extension namespace MUST NOT be the default namespace. 
Elements, whether defined in this specification or by an extension, 
which use these attributes MUST conform the to requirements for that 
construct defined in the following sections. Additionally, such 
elements MUST NOT require understanding of any additional attributes or 
element children.

Replace section 3.4 with the following (section numbers below have NOT 
been adjusted to reflect the insertion or deletion of other sections):

3.4 Link Constructs

       A link construct specifies a hyperlink primarily intended to be 
activated through explicit user interactions such as clicking, 
selecting a menu item, drag and drop, etc. The resource pointed to MUST 
be accessible using only the indicated URI, wiht no additional XML or 
other content. When accessing the resource pointed to by the href 
attribute using HTTP, the GET method MUST be used.

It MUST NOT have any child content. A link construct has the following 
attributes:

Remove section 3.4.1 ("rel" Attribute)

Replace section 3.4.3 ("href" Attribute) with:

3.4.3 "atomex:link-href" Attribute

       The "atomex:link-href" attribute contains the link's URI. Link 
constructs MUST have an atomex:link-href attribute, whose value MUST be 
a URI [RFC2396].

       xml:base [W3C.REC-xmlbase-20010627] processing MUST be applied to 
the atomex:link-href attribute's content.

Insert the following after section 3.4:

3.5 Service Constructs

       A service construct specifies a link to an endpoint for the Atom 
API or an extension thereto. It MUST NOT have any child content. A 
service construct has the following attributes:

3.5.1 "atomex:service-href" Attribute

       The "atomex:service-href" attribute specifies the URI of an Atom 
API endpoint. Service constructs MUST have an atomex:service-href 
attribute, which MUST be a URI [RFC2396].

       xml:base [W3C.REC-xmlbase-20010627] processing MUST be applied to 
the atomex:service-href attribute's content.

3.5.2 "methods" Attribute

       The methods attribute specifies which HTTP methods can be used 
with the API endpoint. Service constucts MUST have a methods attribute. 
The value of this attribute is a space separated list of methods, which 
MUST only include methods supported for the API endpoint to which the 
service construct points, as specified by the controlling specification.

3.6 Embed Constructs

       An embed constrct specifies a link to external data intended to 
be automatically loaded asynchronously with and embedded in a feed or 
entry.

3.6.1 "atomex:embed-src" Attribute

       The "atomex:embed-src" attribute specifies the URI of the 
resource to be embedded. Embed constructs MUST have an 
"atomex:embed-src" attribute, which MUST be a URI [RFC2396].

       xml:base [W3C.REC-xmlbase-20010627] processing MUST be applied to 
the atomex:service-href attribute's content.

3.6.2 "type" Attribute

       The "type" attribute indicates an advisory media type; 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. Note 
that the type attribute does not override the actual media type 
returned with the representation.

       Embed constructs MAY have a type attribute, whose value MUST be a 
registered media type [RFC2045].

Replace section 4.2.2 with the following:

4.2.2 Link Construct Elements

       The following elements are link constructs.

4.2.2.1 "atom:alternate" Element

       The "atom:alternate" element specifies a link to an alternate 
representation of the feed. atom:head MUST contain at least one 
atom:alternate element. atom:head MUST NOT contain more than one 
atom:alternate element with the same type attribute value.

4.2.2.2 "atom:start" Element

       [[[Specification text be written]]]

4.2.2.3 "atom:prev" Element

       [[[Specification text be written]]]

4.2.2.4 "atom:next" Element

       [[[Specification text be written]]]

Insert section 4.2.3 as follows:

4.2.3 Service Construct Elements

       The following elements are service constructs.

4.2.3.1 "atom:edit" Element

       [[[Specification text be written]]]

4.2.3.2 "atom:post" Element

       [[[Specification text be written]]]

4.2.3.3 "atom:delete" Element

       [[[Specification text be written]]]



From owner-atom-syntax@mail.imc.org  Mon Jul 19 22: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 WAA25093
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 22: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 i6K2lS2l007909;
	Mon, 19 Jul 2004 19:47: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 i6K2lSfK007908;
	Mon, 19 Jul 2004 19:47:28 -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 i6K2lRXA007888
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 19:47:28 -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 i6K2lS53019523
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 21:47:28 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6K2lSUc019519;
	Mon, 19 Jul 2004 21:47:28 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: atom-syntax@imc.org
Subject: Re: PaceLinkAttrDefaults
References: <EFC99BA0-D9DB-11D8-B499-003065EA6144@geckotribe.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 19 Jul 2004 21:47:28 -0500
In-Reply-To: <EFC99BA0-D9DB-11D8-B499-003065EA6144@geckotribe.com>
Message-ID: <m3y8lfbdj3.fsf@bitsko.slc.ut.us>
Lines: 116
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: <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> writes:

> Okay, that much was obvious.  You've posted a similar comment in
> PaceLinkPurpose.  Here are a few comments and assumptions on each:

Comparison matrix copied to LinkReferences -- excellent work!

[updated from followup message]
> C) If we can decide on a way to recognize Link Constructs and adopt
> section 3.4 from PaceLinkPurpose, I would support
> PaceReplaceLinkElement to the extent that it is compatible with
> PaceLinkPurpose.  That would answer #1 and #2 for PaceLinkPurpose.
> The difficult part is deciding how to make Link Constructs
> recognizable.  Of the ideas mentioned thus far, I think the least
> potentially problematic is to have a separate namespace for Link
> Construct attributes, the use of which indicates that the element
> using them can be processed as a Link Construct.  For example:
> 
> <feed xmlns="atom's namespace"
> 	xmlns:ex="atom's extension namespace"
> 	xmlns:ox="some other extension's namespace">
> 
> <some-core-link-construct ex:href="uri" ... />
> 
> <ox:some-extension-link-construct ex:href="uri" ... />
> <ox:some-core-NON-link-construct href="uri" ... />
> <ox:some-core-NON-link-construct ox:href="uri" ... />
> 
> <ox:some-extension-NON-link-construct href="uri" ... />
> 
> </feed>
> 
> Only @ex:href indicates a "Link Construct" as defined by
> PaceLinkConstruct.  @href and @ox:href do not.

Yes, PaceReplaceLinkElement can modified to support link types.
@atom:href for human clickable links and @atom:service for service
links would work.  New link types are also extensible using XML
namespaces.

However, first we have to come to consensus on what link types are (or
what types we're only interested in) and whether we want to encode
link types.

Dare and Graham have said that they won't implement link types, they
will look at each relation by name to determine client action.
However, Graham might be ok with a human-clickable link type.

Sam says that link types are a non-goal, but then he might support
human-clickable and service link types.

Tim said we shouldn't do types but then says he supports
human-clickable and service link types.

Norm seems to be favoring many tightly clustered link types with @rel
values.

PaceLinkPurpose defines a human-clickable link type and indicates
other elements (PaceServiceElement) should be used for other link
types.

Regardless of link types, there are many people who say they favor
element names for the relation name.

I'm neutral on speccing link types.  I can see how they can be useful
in generic processing, yet I can see the benefit of being concrete on
a link-name basis.  For either type or name, I'm a little more in
favor of XML Namespace extension, which we already have, over IANA
registration.

So, it seems like we're choosing between these:


1) No link types, IANA registration of relation name (@rel):

    <link rel="via" type="text/html" uri="URI"/>
    <link rel="alternate" type="text/html" uri="URI"/>
    <link rel="service.edit" type="application/atom+xml" uri="URI"/>
    <link rel="image.favicon" type="image/png" uri="URI"/>
    <link rel="extension.name" type="text/anything" uri="URI"/>

2) No link types, qnames for relation name (element name):

    <via type="text/html" uri="URI"/>
    <alternate type="text/html" uri="URI"/>
    <edit type="application/atom+xml" uri="URI"/>
    <favicon type="image/png" uri="URI"/>
    <extns:name type="text/anything" uri="URI"/>

3) Link types, qname for link type (element name), IANA registration
   of relation name (@rel):

    <link rel="via" type="text/html" uri="URI"/>
    <link rel="alternate" type="text/html" uri="URI"/>
    <service rel="edit" type="application/atom+xml" uri="URI"/>
    <image rel="favicon" type="image/png" uri="URI"/>
    <extns:type rel="name" type="text/anything" uri="URI"/>

4) Link types, qname for link type (URI attribute), qname for relation
   name (element name):

    <via type="text/html" atom:href="URI"/>
    <alternate type="text/html" atom:href="URI"/>
    <edit type="application/atom+xml" atom:service="URI"/>
    <favicon type="image/png" atom:uri="URI"/>
    <extns:name type="text/anything" extns:type="URI"/>

PaceLinkPurpose and PaceServiceElement are (3), PaceLinkAttrDefaults
is currently (1) but could be (3), PaceReplaceLinkElement is currently
(2) but could be (4).  PaceExtensionNamespace (just posted) appears to
be (4).

Note that the (4) example has a "generic" link type (atom:uri) case
which is "no link type" so only the relation name has significance.

  -- Ken



From owner-atom-syntax@mail.imc.org  Mon Jul 19 23:00: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 XAA25322
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 23:00: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 i6K2qR6M008763;
	Mon, 19 Jul 2004 19:52: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 i6K2qRIp008762;
	Mon, 19 Jul 2004 19:52: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 (mproxy.gmail.com [216.239.56.250])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6K2qQDP008741
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 19:52:26 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so6794198cwc
        for <atom-syntax@imc.org>; Mon, 19 Jul 2004 19:52:28 -0700 (PDT)
Received: by 10.11.99.11 with SMTP id w11mr165332cwb;
        Mon, 19 Jul 2004 19:52:28 -0700 (PDT)
Message-ID: <3f1451f504071919522f3785e8@mail.gmail.com>
Date: Mon, 19 Jul 2004 22:52:28 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Mark Baker <distobj@acm.org>
Subject: Re: Private extension support (was Re: Q: Put request should return Atom entry?
Cc: David Orchard <dorchard@bea.com>, Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <20040720023058.GA30868@markbaker.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <32D5845A745BFB429CBDBADA57CD41AF08FA6DCF@ussjex01.amer.bea.com> <20040720023058.GA30868@markbaker.ca>
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 Mon, 19 Jul 2004 22:30:58 -0400, Mark Baker <distobj@acm.org> wrote:
> 
> On Mon, Jul 19, 2004 at 09:49:49AM -0700, David Orchard wrote:
> > I wrote up some thoughts a while ago on applying some "standard" format extensibility rules to protocols
> >
> > http://www.pacificspirit.com/blog/2004/06/14/protocol_extensibility_and_versioning
> 
> Right-o.
> 
> > Seems like a reasonable question to ask, but it's harder to figure out what to do...
> 
> As I see it, we have three options, at least to begin with;
> 
> 1. support (RESTful) SOAP
> 2. support RFC 2774
> 3. forget about it

This did raise one question in my mind, right now the entries
used in the Publishing Protocol will contain a version of the 
Atom format. Does the Publishing Protocol needs its own 
version number on top of that?

I'll also note that an Introspection file [1] would be a good
place to enumerate versions and extensions.

[1]  http://intertwingly.net/wiki/pie/PaceIntrospection

    Thanks,
    -joe

-- 
Joe Gregorio        http://bitworking.org



From owner-atom-syntax@mail.imc.org  Mon Jul 19 23: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 XAA25380
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 23: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 i6K2tL64009289;
	Mon, 19 Jul 2004 19:55: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 i6K2tLJm009288;
	Mon, 19 Jul 2004 19:55:21 -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 i6K2tKfN009255
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 19:55:20 -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 i6K2tL53019650
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 21:55:21 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6K2tLhU019646;
	Mon, 19 Jul 2004 21:55:21 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: atom:origin?
References: <200407191919.PAA17914@ietf.org> <87hds3slp8.fsf@nwalsh.com>
	<40FC4B18.7020400@dehora.net> <40FC5E56.90505@intertwingly.net>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 19 Jul 2004 21:55:21 -0500
In-Reply-To: <40FC5E56.90505@intertwingly.net>
Message-ID: <m3u0w3bd5y.fsf@bitsko.slc.ut.us>
Lines: 17
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 i6K2tLfN009283
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


Sam Ruby <rubys@intertwingly.net> writes:

> Bill de hÓra wrote:
> > Not that odd, since atom:id is optional. I would have used atom:id
> > were that not the case.
> 
> http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-01.txt
> 
> Section 5.5  "atom:id" Element :
> 
>     atom:entry MUST contain exactly one atom:id element.  The
>     content of this element MUST be a URI.

I think Bill's referring to 4.2.6, atom:feed/atom:id, which is still
optional.

  -k



From owner-atom-syntax@mail.imc.org  Mon Jul 19 23:22: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 XAA26522
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 23:22: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 i6K3DTWY012420;
	Mon, 19 Jul 2004 20: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 i6K3DTtL012418;
	Mon, 19 Jul 2004 20:13: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.194])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6K3DRVh012402
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 20:13:28 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d78so672948rnf
        for <atom-syntax@imc.org>; Mon, 19 Jul 2004 20:13:34 -0700 (PDT)
Received: by 10.38.102.75 with SMTP id z75mr273353rnb;
        Mon, 19 Jul 2004 20:13:34 -0700 (PDT)
Message-ID: <14be96d304071920136492cc4@mail.gmail.com>
Date: Mon, 19 Jul 2004 23:13:34 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Eric Scheid <eric.scheid@ironclad.net.au>
Subject: Re: atom:origin?
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <BD22BCC5.2105D%eric.scheid@ironclad.net.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <BD22BCC5.2105D%eric.scheid@ironclad.net.au>
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, 20 Jul 2004 12:12:53 +1000, Eric Scheid
<eric.scheid@ironclad.net.au> wrote:
> 
> > | 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 same, character-for-character, as that of the
> > |    href attribute of the atom:link element that has a rel attribute
> > |    value of "alternate" in that document's atom:head section (i.e., the
> > |    XPath expression "/atom:feed/atom:head/atom:link[@rel='alternate']/
> > |    @href").
> >
> > Really? Not the atom:id of the feed? That seems...odd.
> 
> additionally,
> 
> (1) there may actually be multiple elements that match that XPath, they just
> might have different @type values...

Or different @hreflang values.

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Mon Jul 19 23:26: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 XAA26721
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 23:26: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 i6K3B96U011994;
	Mon, 19 Jul 2004 20:11: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 i6K3B987011993;
	Mon, 19 Jul 2004 20:11:09 -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 i6K3B7vY011967
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 20:11:08 -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 1285590 for atom-syntax@imc.org; Tue, 20 Jul 2004 13:11:15 +1000
Received: from [192.168.25.1] (HELO [192.168.45.134])
  by afc.gov.au (CommuniGate Pro SMTP 4.1.8)
  with ESMTP id 1400436 for atom-syntax@imc.org; Tue, 20 Jul 2004 13:11:13 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Tue, 20 Jul 2004 13:11:05 +1000
Subject: Re: atom:origin?
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD22CA69.2106E%eric.scheid@ironclad.net.au>
In-Reply-To: <40FC5E56.90505@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: <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 20/7/04 9:50 AM, "Sam Ruby" <rubys@intertwingly.net> wrote:

>>> Really? Not the atom:id of the feed? That seems...odd.
>> 
>> 
>> Not that odd, since atom:id is optional. I would have used atom:id were
>> that not the case.
> 
> http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-01.txt
> 
> Section 5.5  "atom:id" Element :
> 
>   atom:entry MUST contain exactly one atom:id element.  The content of
>   this element MUST be a URI.

clarification please...

    is atom:origin meant to reference the origin <feed>,
    or the origin <entry>?

Section 5.12 (atom:entry/atom:origin) says <feed>, which doesn't sound as
useful as <entry>, and I also note that "/atom:feed/atom:head/atom:id" is
actually optional (section 4.2.6 atom:head/atom:id).

e.



From owner-atom-syntax@mail.imc.org  Mon Jul 19 23:27: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 XAA26785
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 23:27: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 i6K3IX2t013428;
	Mon, 19 Jul 2004 20:18:33 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6K3IXbF013426;
	Mon, 19 Jul 2004 20:18:33 -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 i6K3IWKX013409
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 20:18:32 -0700 (PDT)
	(envelope-from ken@bitsko.slc.ut.us)
Received: from localhost.localdomain (tara [127.0.0.1])
	by bitsko.slc.ut.us (8.12.8/8.12.8) with ESMTP id i6K3IX53019902
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 22:18:33 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6K3IXkB019898;
	Mon, 19 Jul 2004 22:18:33 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: atom-syntax@imc.org
Subject: Re: PaceExtensionNamespace created
References: <2F1E54F4-D9F5-11D8-B499-003065EA6144@geckotribe.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 19 Jul 2004 22:18:33 -0500
In-Reply-To: <2F1E54F4-D9F5-11D8-B499-003065EA6144@geckotribe.com>
Message-ID: <m3pt6rbc3a.fsf@bitsko.slc.ut.us>
Lines: 42
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: <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> writes:

> http://www.intertwingly.net/wiki/pie/PaceExtensionNamespace

+1, iff we want link types.

> 3.1. Extension Namespace
> 
> The Atom Extension Namespace defines a number of attributes by which
> common constructs may be recognized. The extension namespace URI for
> this specification is:
> 
>        http://purl.org/atom/extension-ns#draft-ietf-atompub-format-01
> 
> The attributes defined by the extension namespace may be recognized
> in this specification by the namespace "atomex".

The existing Atom namespace would work equally as well here:
atom:link-href, atom:service-href, etc.  But yes, the attributes must
still be explicitly namespace qualified.

> 3.5.2 "methods" Attribute
> 
>        The methods attribute specifies which HTTP methods can be
> used with the API endpoint. Service constucts MUST have a methods
> attribute. The value of this attribute is a space separated list of
> methods, which MUST only include methods supported for the API
> endpoint to which the service construct points, as specified by the
> controlling specification.

I don't see the purpose of this attribute.

Listing HTTP methods does not provide enough information to properly
use the endpoint, you still need to know what kind of resources can be
accessed there, what fields must be used/not used, etc.  All of that
information is already defined by the link relation name.

> 4.2.3.3 "atom:delete" Element

There is no delete endpoint.

  -- Ken



From owner-atom-syntax@mail.imc.org  Mon Jul 19 23: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 XAA28746
	for <atompub-archive@lists.ietf.org>; Mon, 19 Jul 2004 23:55: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 i6K3hXqX017777;
	Mon, 19 Jul 2004 20:43: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 i6K3hXoH017776;
	Mon, 19 Jul 2004 20:43:33 -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 i6K3hXOg017758
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 20:43: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 (rwcrmhc11) with SMTP
          id <20040720034334013003f0aue>; Tue, 20 Jul 2004 03:43:34 +0000
Date: Mon, 19 Jul 2004 21:43:34 -0600
Subject: Re: PaceExtensionNamespace created
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: <m3pt6rbc3a.fsf@bitsko.slc.ut.us>
Message-Id: <FA23639F-D9FE-11D8-B499-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


>> 3.1. Extension Namespace
>>
>> The Atom Extension Namespace defines a number of attributes by which
>> common constructs may be recognized. The extension namespace URI for
>> this specification is:
>>
>>        http://purl.org/atom/extension-ns#draft-ietf-atompub-format-01
>>
>> The attributes defined by the extension namespace may be recognized
>> in this specification by the namespace "atomex".
>
> The existing Atom namespace would work equally as well here:
> atom:link-href, atom:service-href, etc.  But yes, the attributes must
> still be explicitly namespace qualified.
Yeah, it could be done either way.  To explicitly qualify it, if you 
want to use a default namespace for things that don't have to be 
explicitly qualified, you'd have to do this:

<feed xmlns="atom's namespace" xmlns:atom="atom's namespace">

...which works fine, but perhaps looks a little strange.

>> 3.5.2 "methods" Attribute
>>
>>        The methods attribute specifies which HTTP methods can be
>> used with the API endpoint. Service constucts MUST have a methods
>> attribute. The value of this attribute is a space separated list of
>> methods, which MUST only include methods supported for the API
>> endpoint to which the service construct points, as specified by the
>> controlling specification.
>
> I don't see the purpose of this attribute.
>
> Listing HTTP methods does not provide enough information to properly
> use the endpoint, you still need to know what kind of resources can be
> accessed there, what fields must be used/not used, etc.  All of that
> information is already defined by the link relation name.
The purpose is for servers to indicate whether they support the 
preferred methods, which I assume are going to include GET POST PUT and 
DELETE, or only the fallback methods, which I assume will all run 
through GET and POST, or both.

>> 4.2.3.3 "atom:delete" Element
>
> There is no delete endpoint.
I threw that in there on the assumption that the fallback method for 
servers that don't support DELETE might need it.



From owner-atom-syntax@mail.imc.org  Tue Jul 20 00:27: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 AAA00754
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 00:27: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 i6K4FNoc023909;
	Mon, 19 Jul 2004 21: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 i6K4FNhI023908;
	Mon, 19 Jul 2004 21:15:23 -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 i6K4FMEB023891
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 21:15:23 -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 i6K4FO53020615
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 23:15:24 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6K4FOwc020611;
	Mon, 19 Jul 2004 23:15:24 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: atom-syntax@imc.org
Subject: Re: PaceExtensionNamespace created
References: <FA23639F-D9FE-11D8-B499-003065EA6144@geckotribe.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 19 Jul 2004 23:15:24 -0500
In-Reply-To: <FA23639F-D9FE-11D8-B499-003065EA6144@geckotribe.com>
Message-ID: <m3llhfb9gj.fsf@bitsko.slc.ut.us>
Lines: 33
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: <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> writes:

> >> 3.5.2 "methods" Attribute

> > I don't see the purpose of this attribute.
> >
> > Listing HTTP methods does not provide enough information to
> > properly use the endpoint, you still need to know what kind of
> > resources can be accessed there, what fields must be used/not
> > used, etc.  All of that information is already defined by the link
> > relation name.

> The purpose is for servers to indicate whether they support the
> preferred methods, which I assume are going to include GET POST PUT
> and DELETE, or only the fallback methods, which I assume will all
> run through GET and POST, or both.

If that were necessary, I'd suggest using a different attribute name
and value.  The attribute would be based on which types of support the
server offers, rather than HTTP method names.

However, I don't think *server* support is an issue with respect to
HTTP methods.  It's clients that have PUT/DELETE issues.  Servers will
implement all of the methods (e.g. always indicate they support all
methods), while clients really want to know if they can use the
fallback techniques if *they* need to.

Since server support of fallbacks are an all-or-nothing thing, there's
no need to include @method (or any other indicator) on every service
element, it'd be easier to put that in one place in the feed or site
introspection file.

  -- Ken



From owner-atom-syntax@mail.imc.org  Tue Jul 20 00:55:13 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02738
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 00:55:12 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K4hGBn029640;
	Mon, 19 Jul 2004 21:43: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 i6K4hGxc029639;
	Mon, 19 Jul 2004 21:43:16 -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 i6K4hEpD029610
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 21:43:15 -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 1285865 for atom-syntax@imc.org; Tue, 20 Jul 2004 14:43:24 +1000
Received: from [192.168.25.1] (HELO [192.168.45.134])
  by afc.gov.au (CommuniGate Pro SMTP 4.1.8)
  with ESMTP id 1400824 for atom-syntax@imc.org; Tue, 20 Jul 2004 14:43:22 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Tue, 20 Jul 2004 14:43:13 +1000
Subject: 3.1.1  "type" Attribute
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD22E001.21074%eric.scheid@ironclad.net.au>
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


> 3.1.1  "type" Attribute
> 
>  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".

given the MUST clause, we should include spec text that explains that the
'type' attribute is only advisory, right?

e.



From owner-atom-syntax@mail.imc.org  Tue Jul 20 01:21: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 BAA04475
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 01:21: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 i6K58opr036750;
	Mon, 19 Jul 2004 22:08:50 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6K58oGf036748;
	Mon, 19 Jul 2004 22:08:50 -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 i6K58msH036692
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 22:08:49 -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 1285937 for atom-syntax@imc.org; Tue, 20 Jul 2004 15:08:58 +1000
Received: from [192.168.25.1] (HELO [192.168.45.134])
  by afc.gov.au (CommuniGate Pro SMTP 4.1.8)
  with ESMTP id 1400940 for atom-syntax@imc.org; Tue, 20 Jul 2004 15:08:56 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Tue, 20 Jul 2004 15:08:47 +1000
Subject: @type in <content> vs <link>
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD22E5FF.21079%eric.scheid@ironclad.net.au>
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


the 'type' attribute as described in and 3.1.1 and 3.4.2 are not harmonious
and could lead to confusion.

> 3.1.1  "type" Attribute
> 
>  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 ...

> 3.4.2  "type" Attribute
> 
>  The "type" attribute indicates an advisory media type; 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.  Note
>  that the type attribute does not override the actual media type
>  returned with the representation.
> 
>  Link constructs MUST have a type attribute, whose value MUST be a
>  media type [RFC2045].
> 

3.1.1 is silent on the advisory nature of @type in content, while 3.4.2
explains a lot (including precedence)

should @type be optional in both cases, and if optional should it also not
default to some value (eg. text/plain), instead defaulting to
"not-specified", since it is also only advisory?

e.



From owner-atom-syntax@mail.imc.org  Tue Jul 20 01: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 BAA05061
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 01: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 i6K5IZwx041417;
	Mon, 19 Jul 2004 22:18: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 i6K5IZX1041416;
	Mon, 19 Jul 2004 22:18:35 -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 i6K5IXsR041359
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 22:18:34 -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 1285976 for atom-syntax@imc.org; Tue, 20 Jul 2004 15:18:43 +1000
Received: from [192.168.25.1] (HELO [192.168.45.134])
  by afc.gov.au (CommuniGate Pro SMTP 4.1.8)
  with ESMTP id 1401000 for atom-syntax@imc.org; Tue, 20 Jul 2004 15:18:41 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Tue, 20 Jul 2004 15:18:33 +1000
Subject: 4.2.2 hreflang alternates?
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD22E849.2107B%eric.scheid@ironclad.net.au>
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


> 4.2.2  "atom:link" Element
> 
>  atom:head elements MUST NOT contain more than one atom:link element
>  with a rel attribute value of "alternate" that has the same type
>  attribute value.

please add "and same hreflang attribute value simultaneously.", otherwise we
can't do this:

    <link rel="alternate" type="text/html" hreflang="en" .../>
    <link rel="alternate" type="text/html" hreflang="fr" .../>

meaning that there are two alternates available, one in english, one in
french, both in html.

e.



From owner-atom-syntax@mail.imc.org  Tue Jul 20 02: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 CAA11480
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 02:04: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 i6K5v9qj064175;
	Mon, 19 Jul 2004 22: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 i6K5v9x8064174;
	Mon, 19 Jul 2004 22:57:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.87])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6K5v8IT064166
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 22:57:08 -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 i6K5vFBC018688;
	Mon, 19 Jul 2004 22:57:15 -0700 (PDT)
Received: from [192.168.1.101] (66-108-153-170.nyc.rr.com [66.108.153.170])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id i6K5vCaA004492;
	Mon, 19 Jul 2004 22:57:12 -0700 (PDT)
In-Reply-To: <F52A7810-D9D4-11D8-92AF-000A95A51C9E@sun.com>
References: <40FC0A55.5090409@intertwingly.net> <F52A7810-D9D4-11D8-92AF-000A95A51C9E@sun.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-326608884; protocol="application/pkcs7-signature"
Message-Id: <78E926EA-DA11-11D8-B3AB-000A95DC3D90@mac.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: PaceLinkAttrDefaults
Date: Tue, 20 Jul 2004 01:55:58 -0400
To: Tim Bray <Tim.Bray@Sun.COM>
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-326608884
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 19 Jul 2004, at 6:42 pm, Tim Bray wrote:

> +1 to removing rel= from current drafts until we have a coherent 
> proposal on the table (if someone thinks that there's an existing Pace 
> worth serious consideration, point it out)

PaceReplaceLinkElement was intended to be the first step out of the 
@rel quagmire, because it doesn't immediately change any functionality. 
The problem we have now is that everything is tangled up inside one 
element, and it's very hard to make changes because everyone's Paces 
are overlapping. If we can get everything into separate elements, we 
can consider each one separately and make changes, even if it's just to 
come up with a new grouping scheme.

(re: PaceLinkAttrDefaults itself, I think rel="alternate" is a special 
case. rel="related" should be the default and rel="alternate" should be 
moved to a separate element entirely)

Graham
--Apple-Mail-2-326608884
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
9w0BCQUxDxcNMDQwNzIwMDU1NTU4WjAjBgkqhkiG9w0BCQQxFgQUpmjQrlKhlKxLtc7zQnJUGJ+o
ciEweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAjp5D4rED4xgcKOUa6kCVlxv8
VMdRB3aZHIWcBQqRDZlFQi9jfiihG7au7EfI1SBcuiqwJxJhD7iUtDlPEao+x/04ENW16/imvkRM
fl/d2jbkS7x8yZ6+cLeTfxmBpAe53VNNvRwS4SOvv2qYOykAOE3vclGH6EMrNVoYfEtyOGnieO/I
YRS70mHemi9p3UPzpixLS+8+OalHSddayZbYh9utD+lSmqDKWFsLIN79H73oxj/HCoAigwdUDOqd
r0Mu1rUeIud2UOlIOnqzvk4H+aBNFGtWCBHnUqZOGpLzEJmo4ptoSHxExgnEXf85tPXyRv4dq4CD
Z201qLescuvZIwAAAAAAAA==

--Apple-Mail-2-326608884--



From owner-atom-syntax@mail.imc.org  Tue Jul 20 02:42: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 CAA22821
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 02:42: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 i6K6V4AW081724;
	Mon, 19 Jul 2004 23:31: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 i6K6V45A081723;
	Mon, 19 Jul 2004 23:31:04 -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 i6K6V34n081591
	for <atom-syntax@imc.org>; Mon, 19 Jul 2004 23:31: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 1286209 for atom-syntax@imc.org; Tue, 20 Jul 2004 16:30:57 +1000
Received: from [192.168.25.1] (HELO [192.168.45.134])
  by afc.gov.au (CommuniGate Pro SMTP 4.1.8)
  with ESMTP id 1401317 for atom-syntax@imc.org; Tue, 20 Jul 2004 16:30:54 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Tue, 20 Jul 2004 16:30:47 +1000
Subject: Re: 3.1.1  "type" Attribute
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD22F937.21132%eric.scheid@ironclad.net.au>
In-Reply-To: <BD22E001.21074%eric.scheid@ironclad.net.au>
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 20/7/04 2:43 PM, "Eric Scheid" <eric.scheid@ironclad.net.au> wrote:

>> 3.1.1  "type" Attribute
>> 
>>  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".
> 
> given the MUST clause, we should include spec text that explains that the
> 'type' attribute is only advisory, right?

doh!

it's been pointed out to me off list that the content being described by
@type in <content> is right there in the feed itself, and so should match
unless something is really screwed.

down the track however: if we ever allow @src for out of band content then
@type would then (in that use case) need to be advisory only.

e.



From owner-atom-syntax@mail.imc.org  Tue Jul 20 08:07: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 IAA12925
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 08:07: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 i6KBvm9o006863;
	Tue, 20 Jul 2004 04:57: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 i6KBvmcU006862;
	Tue, 20 Jul 2004 04:57:48 -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 i6KBvlTN006843
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 04:57:48 -0700 (PDT)
	(envelope-from distobj@acm.org)
Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian))
	id 1BmtGK-0006HH-00
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 07:58:24 -0400
Date: Tue, 20 Jul 2004 07:58:23 -0400
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Private extension support (was Re: Q: Put request should return Atom entry?
Message-ID: <20040720115823.GB30868@markbaker.ca>
References: <32D5845A745BFB429CBDBADA57CD41AF08FA6DCF@ussjex01.amer.bea.com> <20040720023058.GA30868@markbaker.ca> <3f1451f504071919522f3785e8@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3f1451f504071919522f3785e8@mail.gmail.com>
User-Agent: Mutt/1.3.28i
From: Mark Baker <distobj@acm.org>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


On Mon, Jul 19, 2004 at 10:52:28PM -0400, Joe Gregorio wrote:
> This did raise one question in my mind, right now the entries
> used in the Publishing Protocol will contain a version of the 
> Atom format. Does the Publishing Protocol needs its own 
> version number on top of that?

I hope and expect that it won't.

Mark.



From owner-atom-syntax@mail.imc.org  Tue Jul 20 08:51: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 IAA15878
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 08:51:30 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KCgkru014607;
	Tue, 20 Jul 2004 05: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 i6KCgk99014606;
	Tue, 20 Jul 2004 05:42:46 -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 i6KCgjwa014587
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 05:42:45 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040720124242.25368.qmail@web41212.mail.yahoo.com>
Received: from [131.107.3.74] by web41212.mail.yahoo.com via HTTP; Tue, 20 Jul 2004 05:42:42 PDT
Date: Tue, 20 Jul 2004 05:42:42 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: PaceLinkAttrDefaults
To: Ken MacLeod <ken@bitsko.slc.ut.us>, atom-syntax@imc.org
In-Reply-To: <m3y8lfbdj3.fsf@bitsko.slc.ut.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>


--- Ken MacLeod <ken@bitsko.slc.ut.us> wrote:
> 
> 
> 1) No link types, IANA registration of relation name
> (@rel):
> 
>     <link rel="via" type="text/html" uri="URI"/>
>     <link rel="alternate" type="text/html"
> uri="URI"/>
>     <link rel="service.edit"
> type="application/atom+xml" uri="URI"/>
>     <link rel="image.favicon" type="image/png"
> uri="URI"/>
>     <link rel="extension.name" type="text/anything"
> uri="URI"/>

I like this idea since the number of link types will
be sufficiently reduced to make it feasible to deal
with. Of course, then I don't see why anyone would go
through the trouble of creating a link type when they
could just create their own namespaced element. 
 
> 2) No link types, qnames for relation name (element
> name):
> 
>     <via type="text/html" uri="URI"/>
>     <alternate type="text/html" uri="URI"/>
>     <edit type="application/atom+xml" uri="URI"/>
>     <favicon type="image/png" uri="URI"/>
>     <extns:name type="text/anything" uri="URI"/>

I'm not sure what this means. It seems you are saying
that there will be a number of elements that have a
uri and type attribute but besides that there is no
explicit or implicit relationship between them. If so,
I like this idea as well although it may cause people
to see a pattern where none exists. 

> 3) Link types, qname for link type (element name),
> IANA registration
>    of relation name (@rel):
> 
>     <link rel="via" type="text/html" uri="URI"/>
>     <link rel="alternate" type="text/html"
> uri="URI"/>
>     <service rel="edit" type="application/atom+xml"
> uri="URI"/>
>     <image rel="favicon" type="image/png"
> uri="URI"/>
>     <extns:type rel="name" type="text/anything"
> uri="URI"/>

I'm not sure what the point of differentiating this
from (1). To me what is key is either making all links
in a particular types have uniform semantics or
setting the bar high for creating new link classes. 

The above is an in-between that doesn't seem
necessary. An <image> link type isn't very useful
since the behavior of a client on rel="favicon" vs.
rel="logo" is very different. This is just fragmenting
the <link> element without adding clarity. 

So the main benefit of this approach would then be
IANA registration of rel values. Then why bother
having link types.


> 4) Link types, qname for link type (URI attribute),
> qname for relation
>    name (element name):
> 
>     <via type="text/html" atom:href="URI"/>
>     <alternate type="text/html" atom:href="URI"/>
>     <edit type="application/atom+xml"
> atom:service="URI"/>
>     <favicon type="image/png" atom:uri="URI"/>
>     <extns:name type="text/anything"
> extns:type="URI"/>

-1 

This combines the worst characteristics of all the
aforementioned approaches. 
 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
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 Jul 20 09:00: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 JAA16639
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 09: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 i6KCpQti016034;
	Tue, 20 Jul 2004 05:51: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 i6KCpQ5K016033;
	Tue, 20 Jul 2004 05:51:26 -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 i6KCpQu6016015
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 05:51:26 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 79103 messnum 7801519 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 20 Jul 2004 12:51:22 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail01.svc.cra.dublin.eircom.net (qp 79103) with SMTP; 20 Jul 2004 12:51:22 -0000
Message-ID: <40FD154A.2090706@dehora.net>
Date: Tue, 20 Jul 2004 13:51:22 +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: Sam Ruby <rubys@intertwingly.net>
CC: Norman Walsh <ndw@nwalsh.com>, Atom Syntax <atom-syntax@imc.org>
Subject: Re: atom:origin?
References: <200407191919.PAA17914@ietf.org> <87hds3slp8.fsf@nwalsh.com> <40FC4B18.7020400@dehora.net> <40FC5E56.90505@intertwingly.net>
In-Reply-To: <40FC5E56.90505@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:


> P.S.  Yes, this is a change from format-00

(mumble... on vacation.. excuses... mumble...)

I would be happy for this element to point at atom:id then.


OT: did I miss discussion for that change here?

cheers
Bill




From owner-atom-syntax@mail.imc.org  Tue Jul 20 09:03: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 JAA16853
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 09:03: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 i6KCsRGp016482;
	Tue, 20 Jul 2004 05: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 i6KCsRt5016481;
	Tue, 20 Jul 2004 05:54: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.198])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6KCsPfJ016474
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 05:54:26 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id 55so226165rni
        for <atom-syntax@imc.org>; Tue, 20 Jul 2004 05:54:27 -0700 (PDT)
Received: by 10.38.9.61 with SMTP id 61mr342378rni;
        Tue, 20 Jul 2004 05:54:27 -0700 (PDT)
Message-ID: <14be96d30407200554372e2f8c@mail.gmail.com>
Date: Tue, 20 Jul 2004 08:54:27 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Eric Scheid <eric.scheid@ironclad.net.au>
Subject: Re: 4.2.2 hreflang alternates?
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <BD22E849.2107B%eric.scheid@ironclad.net.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <BD22E849.2107B%eric.scheid@ironclad.net.au>
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, 20 Jul 2004 15:18:33 +1000, Eric Scheid
<eric.scheid@ironclad.net.au> wrote:
> 
> > 4.2.2  "atom:link" Element
> >
> >  atom:head elements MUST NOT contain more than one atom:link element
> >  with a rel attribute value of "alternate" that has the same type
> >  attribute value.
> 
> please add "and same hreflang attribute value simultaneously.", otherwise we
> can't do this:
> 
>     <link rel="alternate" type="text/html" hreflang="en" .../>
>     <link rel="alternate" type="text/html" hreflang="fr" .../>
> 
> meaning that there are two alternates available, one in english, one in
> french, both in html.

+1.  This is stated explicitly in the new hreflang section, but we
missed the fact that it had text implications elsewhere.

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Tue Jul 20 09:14: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 JAA17619
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 09: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 i6KD3EQG018165;
	Tue, 20 Jul 2004 06:03: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 i6KD3EGJ018164;
	Tue, 20 Jul 2004 06:03:14 -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 i6KD3DIC018138
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 06:03:14 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 9404 messnum 1884445 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 20 Jul 2004 13:03:10 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail02.svc.cra.dublin.eircom.net (qp 9404) with SMTP; 20 Jul 2004 13:03:10 -0000
Message-ID: <40FD180E.2070203@dehora.net>
Date: Tue, 20 Jul 2004 14:03:10 +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: Eric Scheid <eric.scheid@ironclad.net.au>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Unstructured text
References: <BD22B042.21030%eric.scheid@ironclad.net.au>
In-Reply-To: <BD22B042.21030%eric.scheid@ironclad.net.au>
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


Eric Scheid wrote:
> On 20/7/04 8:25 AM, "Bill de hÓra" <bill@dehora.net> wrote:
> 
> 
>>>   Person constructs MUST contain exactly one "atom:name"
>>>   element, whose content is unstructured text. The "atom:name" element
>>>   must not contain any embedded element markup.
>>
>>
>>  Person constructs MUST contain exactly one
>>  "atom:name" element, whose content must not
>>  contain any embedded element markup.
>>
>>Once you say no tags the "unstructured text" bit is redundant.
> 
> 
> Not entirely. Some places might want to emit names like this:
> 
>     <name>de hÓra, Bill</name>
> 
> that is structured, but it has no embedded markup.

I'm not sure what you;re after here - are you looking to constrain 
processing on the text of atom:name?

I read unstructured text as not being relevant to Person constructs, 
but relevant to the version attribute - ie for Person "unstructured 
text" is a moniker for #PCDATA.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Tue Jul 20 09:24: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 JAA18279
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 09:24: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 i6KDDSqm020225;
	Tue, 20 Jul 2004 06:13:28 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6KDDSRR020224;
	Tue, 20 Jul 2004 06:13:28 -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 i6KDDRgn020198
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 06:13:27 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040720131319.34943.qmail@web41201.mail.yahoo.com>
Received: from [207.46.238.133] by web41201.mail.yahoo.com via HTTP; Tue, 20 Jul 2004 06:13:19 PDT
Date: Tue, 20 Jul 2004 06:13:19 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Unstructured text
To: Tim Bray <Tim.Bray@Sun.COM>, Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <8F9CAA61-D9D6-11D8-92AF-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:
> 
> 
> Which, by the way, I probably disagree with; I
> believe 
> extensibility/versioning proposals such as Dave
> Orchard's recent 
> submission are going to work better if there is a
> clear ordering on 
> version stamps. 

Why? What is wrong with 'if this is a namespace I
recognize then I support this format'? This is the
essence of Dave Orchard's model and one I tend to
agree with. 

Overlaying such semantics on version numbers as well
means that clients then slice versioning across
multiple axes, do I support this major or minor
version number or do I support this namespace name.
There should be a clear single point for applications
to determine compatibility. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


	
		
__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/



From owner-atom-syntax@mail.imc.org  Tue Jul 20 09:29:27 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18556
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 09:29:26 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KDKJoE021454;
	Tue, 20 Jul 2004 06:20: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 i6KDKJpX021453;
	Tue, 20 Jul 2004 06:20:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.193])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6KDKHXS021442
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 06:20:17 -0700 (PDT)
	(envelope-from eliast@gmail.com)
Received: by mproxy.gmail.com with SMTP id c11so320356rnb
        for <atom-syntax@imc.org>; Tue, 20 Jul 2004 06:20:19 -0700 (PDT)
Received: by 10.38.3.70 with SMTP id 70mr54292rnc;
        Tue, 20 Jul 2004 06:20:19 -0700 (PDT)
Message-ID: <905f7c91040720062010e6cfd2@mail.gmail.com>
Date: Tue, 20 Jul 2004 09:20:19 -0400
From: Elias Torres <eliast@gmail.com>
Reply-To: elias@torrez.us
To: Mark Pilgrim <pilgrim@gmail.com>
Subject: Re: 4.2.2 hreflang alternates?
Cc: Eric Scheid <eric.scheid@ironclad.net.au>,
        Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <14be96d30407200554372e2f8c@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <BD22E849.2107B%eric.scheid@ironclad.net.au> <14be96d30407200554372e2f8c@mail.gmail.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


How do we know which one is default if we don't have locale
information? Or is it a MUST use locale kind of thing?

On Tue, 20 Jul 2004 08:54:27 -0400, Mark Pilgrim <pilgrim@gmail.com> wrote:
> 
> 
> 
> On Tue, 20 Jul 2004 15:18:33 +1000, Eric Scheid
> <eric.scheid@ironclad.net.au> wrote:
> >
> > > 4.2.2  "atom:link" Element
> > >
> > >  atom:head elements MUST NOT contain more than one atom:link element
> > >  with a rel attribute value of "alternate" that has the same type
> > >  attribute value.
> >
> > please add "and same hreflang attribute value simultaneously.", otherwise we
> > can't do this:
> >
> >     <link rel="alternate" type="text/html" hreflang="en" .../>
> >     <link rel="alternate" type="text/html" hreflang="fr" .../>
> >
> > meaning that there are two alternates available, one in english, one in
> > french, both in html.
> 
> +1.  This is stated explicitly in the new hreflang section, but we
> missed the fact that it had text implications elsewhere.
> 
> --
> Cheers,
> -Mark
> 
>



From owner-atom-syntax@mail.imc.org  Tue Jul 20 09:44: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 JAA19451
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 09:44: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 i6KDaCNZ024086;
	Tue, 20 Jul 2004 06: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 i6KDaChg024085;
	Tue, 20 Jul 2004 06:36: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 i6KDaBKX024077
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 06:36: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 i6KDb23H008050;
	Tue, 20 Jul 2004 09:37:02 -0400
Message-ID: <40FD1FCB.7010803@intertwingly.net>
Date: Tue, 20 Jul 2004 09:36:11 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: atom:origin?
References: <200407191919.PAA17914@ietf.org> <87hds3slp8.fsf@nwalsh.com> <40FC4B18.7020400@dehora.net> <40FC5E56.90505@intertwingly.net> <40FD154A.2090706@dehora.net>
In-Reply-To: <40FD154A.2090706@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:
> 
> Sam Ruby wrote:
> 
>> P.S.  Yes, this is a change from format-00
> 
> (mumble... on vacation.. excuses... mumble...)
> 
> I would be happy for this element to point at atom:id then.
> 
> OT: did I miss discussion for that change here?

http://www.intertwingly.net/wiki/pie/PaceEntryIdRequired
http://www.imc.org/atom-syntax/mail-archive/msg07152.html
http://www.imc.org/atom-syntax/mail-archive/msg06955.html

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Tue Jul 20 09:51: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 JAA19865
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 09:51: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 i6KDfSrd025074;
	Tue, 20 Jul 2004 06:41: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 i6KDfS3A025073;
	Tue, 20 Jul 2004 06:41:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KDfQGX025059
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 06:41:27 -0700 (PDT)
	(envelope-from Janne.Jalkanen@nokia.com)
Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121])
	by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6KDcYx21783;
	Tue, 20 Jul 2004 16:38:34 +0300 (EET DST)
X-Scanned: Tue, 20 Jul 2004 16:37:57 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost)
	by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i6KDbvfD030168;
	Tue, 20 Jul 2004 16:37:57 +0300
Received: from mgw-int2.ntc.nokia.com (172.21.143.97)
	by esdks002.ntc.nokia.com 00U1CtuI; Tue, 20 Jul 2004 16:37:56 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 i6KDbuu09129;
	Tue, 20 Jul 2004 16:37:56 +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);
	 Tue, 20 Jul 2004 16:37:55 +0300
Message-ID: <40FD2033.5040907@nokia.com>
Date: Tue, 20 Jul 2004 16:37:55 +0300
From: Janne Jalkanen <Janne.Jalkanen@nokia.com>
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: ext John Panzer <jpanzer@aol.net>
CC: Robert Sayre <mint@franklinmint.fm>, kwark.1511609@bloglines.com,
        joe.gregorio@gmail.com, Atom Syntax <atom-syntax@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net>
In-Reply-To: <40FAA6D3.30701@aol.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 20 Jul 2004 13:37:55.0424 (UTC) FILETIME=[C3352E00:01C46E5E]
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



> Is an X-ATOM-xxx HTTP request header a reasonable 90% solution?  This 
> would work for both Atom XML and binary resources, is implementable 
> even by CGI scripts on the server side, and I'm guessing has a nice 
> simple specification (if present, overrides the HTTP method used in 
> the original request).

I think it is.  I took the alternate solution from PacePutDelete and 
codified it as a new Pace.

http://intertwingly.net/wiki/pie/PaceAtomActionHeader

/Janne



From owner-atom-syntax@mail.imc.org  Tue Jul 20 09:51: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 JAA19910
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 09:51:35 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KDcERV024553;
	Tue, 20 Jul 2004 06:38:14 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6KDcE6S024552;
	Tue, 20 Jul 2004 06:38: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 i6KDcD0u024546
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 06:38:13 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from phys-bur-1 ([129.148.9.72])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6KDcAil018584
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 07:38:15 -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 <0I1500H01KCZWU@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com)
 for atom-syntax@imc.org; Tue, 20 Jul 2004 09:38:10 -0400 (EDT)
Received: from mercury (vpn-129-150-33-70.Central.Sun.COM [129.150.33.70])
 by bur-mail1.east.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
 with ESMTP id <0I150083XKJL6K@bur-mail1.east.sun.com> for atom-syntax@imc.org;
 Tue, 20 Jul 2004 09:38:10 -0400 (EDT)
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1Bmuod-000638-00	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 09:37:55 -0400
X-URL: http://nwalsh.com/
Date: Tue, 20 Jul 2004 09:37:54 -0400
From: Norman Walsh <ndw@nwalsh.com>
Subject: Editorial comments on I-D ACTION:draft-ietf-atompub-format-01.txt
In-reply-to: <200407191919.PAA17914@ietf.org>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <878ydeol3h.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: <200407191919.PAA17914@ietf.org>
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-Type: text/plain

[...]
| 1.  Introduction
| 
|    Atom is an XML-based document format intended to allow lists of
|    related information, known as "feeds", to be synchronised between
|    publishers and consumers.  Feeds are composed of a number of items,
|    known as "entries", each with an extensible set of attached metadata.
|    For example, each entry has a title.
| 
|    The primary use case that Atom addresses is the syndication of Web
|    content such as Weblogs and news headlines, to Web sites as well as
            ^ add comma or        delete comma ^
[...]
| 1.2  Example
| 
|    A minimal, single-entry Atom Feed Document:
| 
|    <?xml version="1.0" encoding="utf-8"?>
|    <feed version="draft-ietf-atompub-format-01: do not deploy"
|     xmlns="http://purl.org/atom/ns#draft-ietf-atompub-format-01">
|      <head>
|        <title>Example Feed</title>
|        <link rel="alternate" type="text/html"
|         href="http://example.org/index.atom"/>

The extension .atom seems odd for a text/html document.

[...]
| 3.1.2  "mode" Attribute
| 
|    Content constructs MAY have a "mode" attribute, whose value indicates
|    the method used to encode the content.  When present, this
|    attribute's value MUST be listed below.  If not present, its value
|    MUST be considered to be "xml".

"If not present,...be 'xml'" seems a little clumsy. Rephrase?

[...]
| 3.2.3  "atom:email" Element
| 
|    The "atom:email" element's content conveys an e-mail address
|    associated with the persons.  Person constructs MAY contain an
|    atom:email element, but MUST NOT contain more than one.  Its content
|    MUST be an e-mail address [RFC2822].
| 
|    Person constructs MAY be extended by namespace-qualified element
|    children.
| 
|    Ordering of the element children of Person constructs MUST NOT be
|    considered significant.

The last two paras should go before 3.2.1, I think.

[...]
| 3.4  Link Constructs
| 
|    A Link construct is an element that MUST NOT have any child content,
|    and has the following attributes:

Woudl it be clearer to express this in the affirmative rather than the
negative: "MUST be empty"?

[...]
| 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.

Links are empty so I find "determined by the element's content"
ambiguous. Which element's content? This might be read as meaning the
content returned by dereferencing the link, which I don't think is
intended.

[...]
| 4.2.7  "atom:generator" Element
| 
|    The "atom:generator" element's content indentifies the software agent
|    used to generate the feed, for debugging and other purposes.
|    atom:head elements MAY contain an atom:generator element, but MUST
|    NOT contain more than one.
| 
|    The content of this element, when present, MUST be a string that is a
|    human-readable name for the generating agent.

I think "MUST be a string" is clearer than "unstructured text" (in the
element context, not the attribute context). I suggest using it
throughout.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Growth for the sake of growth is the
http://nwalsh.com/            | ideology of the cancer cell.--Edward
                              | Abbey

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA/SAzOyltUcwYWjsRAnxcAKCc514M+nOWH5W8dPZWHCzPLhRASQCfaq3i
qcm+VGtrI61s5ZmV6csHCb8=
=Pd8l
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Tue Jul 20 10: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 KAA21228
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 10: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 i6KDr1rp026871;
	Tue, 20 Jul 2004 06:53: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 i6KDr1V9026870;
	Tue, 20 Jul 2004 06:53: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 i6KDr0we026859
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 06:53:00 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from phys-bur-1 ([129.148.9.72])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i6KDol57007016
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 07:50:48 -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 <0I1500L01L3DGG@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com)
 for atom-syntax@imc.org; Tue, 20 Jul 2004 09:53:00 -0400 (EDT)
Received: from mercury (vpn-129-150-33-70.Central.Sun.COM [129.150.33.70])
 by bur-mail1.east.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
 with ESMTP id <0I15008L8L8B6K@bur-mail1.east.sun.com> for atom-syntax@imc.org;
 Tue, 20 Jul 2004 09:53:00 -0400 (EDT)
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1Bmv37-0006Pb-00	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 09:52:53 -0400
X-URL: http://nwalsh.com/
Date: Tue, 20 Jul 2004 09:52:51 -0400
From: Norman Walsh <ndw@nwalsh.com>
Subject: RELAX NG Schema for draft...-01 Atom
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <87zn5un5u4.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)
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-Type: text/plain

Dave and I are still working, but here's a snapshot that I believe is
correct. (It passes my smoke test, anyway.)

# -*- Relax NG -*-

namespace local = ""
namespace atom = "http://purl.org/atom/ns#draft-ietf-atompub-format-01"
namespace s = "http://www.ascc.net/xml/schematron"

start = atomFeed | atomEntry

# Attribute definitions

atomCommonAttributes =
   attribute xml:base { atomUri }?,
   attribute xml:lang { atomLanguageTag }?

atomVersionAttribute = attribute version { text }

# Common Atom Constructs

atomContentConstruct =
   atomCommonAttributes,
   attribute type { atomRegisteredMediaType }?,
   attribute mode { "xml" | "escaped" | "base64" }?,
   (text|anyElement)*

atomPersonConstruct =
   atomCommonAttributes,
   (element atom:name { text }
    & element atom:uri { atomUri }?
    & element atom:email { atomEmailAddress }?)

atomDateConstruct =
   atomCommonAttributes,
   xsd:dateTime

atomLinkConstruct =
   atomCommonAttributes,
   attribute rel {
      "alternate"
    | "start"
    | "next"
    | "prev"
    | "service.edit"
    | "service.post"
    | "service.feed" },
   attribute type { atomMediaType },
   attribute href { atomUri },
   attribute hreflang { atomLanguageTag }?,
   attribute title { text }?,
   empty

# atom:feed
# TODO: Test for multiple atom:link/@rel='alternate' with the same @type
# The following tests are simple to do, but my validator is giving me trouble.
# TODO: Debug and add them back
#       Test for at least one atom:link/@rel='alternate'
#       Test for atom:author or all atom:entry have atom:author

atomFeed =
   [
      s:rule [
         context = "/atom:feed"
         s:assert [
            test = "atom:head/atom:link[@rel='alternate']"
            "An atom:feed must have at least one link element with a rel attribute of 'alternate'."
         ]
      ]
      s:rule [
         context = "/atom:feed"
         s:assert [
            test = "atom:head/atom:author or not(atom:entry[count(atom:author) = 0])"
            "An atom:feed must have an atom:author unless all of its atom:entry children have an atom:author."
         ]
      ]
   ]
   element atom:feed {
      atomCommonAttributes,
      atomVersionAttribute,
      atomHead,
      (atomEntry|anyForeignElement)*
   }

atomHead = element atom:head {
   atomCommonAttributes,
   (atomTitle
    & atomLink+
    & atomAuthor?
    & atomContributor*
    & atomTagline?
    & atomId?
    & atomGenerator?
    & atomCopyright?
    & atomInfo?
    & atomModified)
}

# atom:title

atomTitle = element atom:title { atomContentConstruct }

# atom:link

atomLink = element atom:link { atomLinkConstruct }

# atom:author

atomAuthor = element atom:author { atomPersonConstruct }

# atom:contributor

atomContributor = element atom:contributor { atomPersonConstruct }

# atom:tagline

atomTagline = element atom:tagline { atomContentConstruct }

# atom:id

atomId = element atom:id { atomUri }

# atom:generator

atomGenerator = element atom:generator {
   atomCommonAttributes,
   atomVersionAttribute?,
   attribute uri { atomUri }?,
   text
}

# atom:copyright

atomCopyright = element atom:copyright { atomContentConstruct }

# atom:info

atomInfo = element atom:info { atomContentConstruct }

# atom:modified
# TODO: Test for a timezone that SHOULD be UTC

atomModified = element atom:modified { atomDateConstruct }

# atom:entry
# TODO: Test for multiple atom:link @rel='alternate' with the same @type

atomEntry =
   [
      s:rule [
         context = "/atom:entry"
         s:assert [
            test = "@version"
            "The version attribute is required on standalone atom:entry elements."
         ]
      ]
      s:rule [
         context = "atom:entry"
         s:assert [
            test = "atom:link[@rel='alternate']"
            "An atom:entry must have at least one link element with a rel attribute of 'alternate'."
         ]
      ]
      s:rule [
         context = "atom:entry"
         s:assert [
            test = "atom:author or ../atom:author"
            "An atom:entry must have an atom:author if the parent atom:feed does not."
         ]
      ]
   ]
   element atom:entry {
      atomCommonAttributes,
      atomVersionAttribute?,
      (atomTitle
       & atomLink+
       & atomAuthor?
       & atomContributor*
       & atomId?
       & atomModified
       & atomIssued?
       & atomCreated?
       & atomSummary?
       & atomContent?
       & atomCopyright?
       & atomOrigin?
       & anyForeignElement*)
   }

# atom:issued

atomIssued = element atom:issued { atomDateConstruct }

# atom:created
# TODO: Test for a timezone that SHOULD be UTC

atomCreated = element atom:created { atomDateConstruct }

# atom:summary

atomSummary = element atom:summary { atomContentConstruct }

# atom:content

atomContent =
   [
      s:rule [
         context = "atom:content"
         s:assert [
            test = "@type != 'multipart/alternative' or not(@mode)"
            "Multipart/alternative content cannot have a mode attribute."
         ]
      ]
      s:rule [
         context = "atom:content"
         s:assert [
            test = "@type = 'multipart/alternative' and *[@type = 'multipart/alternative']"
            "Multipart/alternative content cannot have multipart/alternative children."
         ]
      ]
      s:rule [
         context = "atom:content"
         s:assert [
            test = "@type != 'multipart/alternative' or child::*"
            "Multipart/alternative content must have children content elements."
         ]
      ]
   ]
   element atom:content { atomContentConstruct }

# atom:origin

atomOrigin = element atom:origin { atomUri }

# Low-level simple types

# TODO: can anything more specific be said about these types?

atomMediaType = text
atomRegisteredMediaType = text
atomLanguageTag = text
atomUri = text
atomEmailAddress = text

# Extensibility

anyForeignElement =
   element * - (atom:* | local:*)
   {
      (attribute * { text }
       | text
       | anyForeignElement)*
   }

anyForeignAttribute =
   attribute * - (atom:* | local:* | xml:*) { text }

anyElement =
   element * - local:*
   {
      (attribute * { text }
       | text
       | anyElement)*
   }

# EOF

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | 'All is vanity,' saith the Preacher.
http://nwalsh.com/            | But if all were only vanity, who would
                              | mind? Alas, it is too often worse than
                              | vanity: agony, darkness, death
                              | also.--Thomas Hardy

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA/SO0OyltUcwYWjsRAh9DAKCoNKwnU9VFkq36EOE9MNVU1ZbLhACffBD1
yagfYofAcwZ0zR3ASKIapN0=
=zqX2
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Tue Jul 20 10:38: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 KAA24586
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 10:38: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 i6KENsLm032233;
	Tue, 20 Jul 2004 07:23:54 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6KENsBe032231;
	Tue, 20 Jul 2004 07:23: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 (mproxy.gmail.com [216.239.56.249])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6KENrJj032221
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 07:23:53 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so7394369cwc
        for <atom-syntax@imc.org>; Tue, 20 Jul 2004 07:23:56 -0700 (PDT)
Received: by 10.11.116.34 with SMTP id o34mr165669cwc;
        Tue, 20 Jul 2004 07:23:56 -0700 (PDT)
Message-ID: <3f1451f504072007233fc8ec82@mail.gmail.com>
Date: Tue, 20 Jul 2004 10:23:56 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Janne Jalkanen <janne.jalkanen@nokia.com>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
Cc: ext John Panzer <jpanzer@aol.net>, Robert Sayre <mint@franklinmint.fm>,
        kwark.1511609@bloglines.com, Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <40FD2033.5040907@nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


On Tue, 20 Jul 2004 16:37:55 +0300, Janne Jalkanen
<janne.jalkanen@nokia.com> wrote:
> 
> > Is an X-ATOM-xxx HTTP request header a reasonable 90% solution?  This
> > would work for both Atom XML and binary resources, is implementable
> > even by CGI scripts on the server side, and I'm guessing has a nice
> > simple specification (if present, overrides the HTTP method used in
> > the original request).
> 
> I think it is.  I took the alternate solution from PacePutDelete and
> codified it as a new Pace.
> 
> http://intertwingly.net/wiki/pie/PaceAtomActionHeader

Looks good, but would you mind removing the
WSSE headers from the examples so we don't 
accidently conflate the two issues of 
authentication and the Action header?

    Thanks,
    -joe

-- 
Joe Gregorio        http://bitworking.org



From owner-atom-syntax@mail.imc.org  Tue Jul 20 10:44: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 KAA25093
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 10:44: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 i6KEXnBO033576;
	Tue, 20 Jul 2004 07: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 i6KEXnjL033575;
	Tue, 20 Jul 2004 07: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] (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 i6KEXPP6033529;
	Tue, 20 Jul 2004 07:33:26 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p06110404bd22ddbcaeb5@[10.20.30.249]>
In-Reply-To: <p0611040dbd1e1be6f1be@[10.20.30.249]>
References: <BD1DDB85.13D53%mint@franklinmint.fm>
 <p0611040dbd1e1be6f1be@[10.20.30.249]>
Date: Tue, 20 Jul 2004 07:34:01 -0700
To: Robert Sayre <mint@franklinmint.fm>, <kwark.1511609@bloglines.com>,
        <joe.gregorio@gmail.com>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
Cc: Atom Syntax <atom-syntax@imc.org>
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>


And yet another data point, this time from Symbian:

>Symbian OS HTTP requests support all the methods in RFC 2616 
>(OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT).
>These are available in the public API, so anyone can write an 
>application to phone can use them.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Tue Jul 20 10: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 KAA25425
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 10:50:09 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KEdjRl034607;
	Tue, 20 Jul 2004 07:39:45 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6KEdjqA034606;
	Tue, 20 Jul 2004 07:39:45 -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 i6KEdiUV034598
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 07:39:44 -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 i6KEePI4010886;
	Tue, 20 Jul 2004 10:40:25 -0400
Message-ID: <40FD2EA6.9020903@intertwingly.net>
Date: Tue, 20 Jul 2004 10:39:34 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Janne Jalkanen <Janne.Jalkanen@nokia.com>
CC: ext John Panzer <jpanzer@aol.net>, Robert Sayre <mint@franklinmint.fm>,
        kwark.1511609@bloglines.com, joe.gregorio@gmail.com,
        Atom Syntax <atom-syntax@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com>
In-Reply-To: <40FD2033.5040907@nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


Janne Jalkanen wrote:
> 
>> Is an X-ATOM-xxx HTTP request header a reasonable 90% solution?  This 
>> would work for both Atom XML and binary resources, is implementable 
>> even by CGI scripts on the server side, and I'm guessing has a nice 
>> simple specification (if present, overrides the HTTP method used in 
>> the original request).
> 
> I think it is.  I took the alternate solution from PacePutDelete and 
> codified it as a new Pace.
> 
> http://intertwingly.net/wiki/pie/PaceAtomActionHeader

Are we *SURE* that there are *NO* gateways that "eat" headers?

I do not want to have multiple "fallbacks".

HTTP is a reasonable 90% solution - most clients have full support, and 
most of the rest have adequate support for the most common operations.

- Sam Ruby

http://www.imc.org/atom-syntax/mail-archive/msg07173.html
http://www.imc.org/atom-syntax/mail-archive/msg07178.html
http://www.intertwingly.net/wiki/pie/DifferentlyAbledClients



From owner-atom-syntax@mail.imc.org  Tue Jul 20 10:53: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 KAA21230
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 10: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 i6KDvnmU027510;
	Tue, 20 Jul 2004 06:57: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 i6KDvnbH027509;
	Tue, 20 Jul 2004 06:57:49 -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 i6KDvmRg027491
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 06:57:48 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040720135746.4900.qmail@web41207.mail.yahoo.com>
Received: from [207.46.228.98] by web41207.mail.yahoo.com via HTTP; Tue, 20 Jul 2004 06:57:46 PDT
Date: Tue, 20 Jul 2004 06:57:46 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: 4.2.2 hreflang alternates?
To: elias@torrez.us, Mark Pilgrim <pilgrim@gmail.com>
Cc: Eric Scheid <eric.scheid@ironclad.net.au>,
        Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <905f7c91040720062010e6cfd2@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>


--- Elias Torres <eliast@gmail.com> wrote:
> 
> How do we know which one is default if we don't have
> locale
> information? Or is it a MUST use locale kind of
> thing?


Why does the locale of the feed matter? What if the
client is an English speaker and the feed is for a
French website?  

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


	
		
__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/



From owner-atom-syntax@mail.imc.org  Tue Jul 20 11:00: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 LAA26080
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 11:00: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 i6KEjUjH035493;
	Tue, 20 Jul 2004 07:45:30 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6KEjUUK035492;
	Tue, 20 Jul 2004 07:45:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from dumle.webhuset.no (dumle.webhuset.no [81.27.32.66])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6KEjT7A035471
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 07:45:29 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Message-Id: <200407201445.i6KEjT7A035471@above.proper.com>
Received: (qmail 21032 invoked from network); 20 Jul 2004 14:43:54 -0000
Received: from unknown (HELO localhost.localdomain) (81.27.34.19)
  by 0 with SMTP; 20 Jul 2004 14:43:54 -0000
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
MIME-Version: 1.0
From: arve@virtuelvis.com
To: Norman Walsh <ndw@nwalsh.com>, atom-syntax@imc.org
Subject: Re: atom:created same as atom:modified?
Date: Tue, 20 Jul 2004 16:45:24 +0200
X-Mailer: WHMail 1.0 (http://www.webhuset.no)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6KEjU7A035487
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


*Norman Walsh:

> |    If atom:created is not present, its content MUST considered to be the
> |    same as that of atom:modified.
> 
> I would have expected it to be the same as atom:issued. I'm not sure
> either is really the obviously correct answer. Is there value in
> providing a default if it isn't specified?

I'm not sure specifying it as either is a good option.	To my ears,
"created", is a machine-generated-date entered when the entry first enters
the publishing system, never again to be changed.

Opening the can of worms again:
My suggestion is making all of created, issued and modified MUST dates. Make
them objective dates, and provide an optional subjective, freeform
"displaydate" element.

Since CMSes have to be changed anyway to provide (meaningful) Atom support, I
suggest that these applications,  set created to be the earliest of any
"issued" or "modified" date when updating their database schemes.

-- 
Arve Bersvendsen



From owner-atom-syntax@mail.imc.org  Tue Jul 20 11:33:06 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28330
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 11: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 i6KFHGxE040340;
	Tue, 20 Jul 2004 08:17: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 i6KFHGg4040339;
	Tue, 20 Jul 2004 08:17: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 i6KFHF3i040323
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 08:17: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 1BmwMW-00074Z-BV; Tue, 20 Jul 2004 15:17:00 +0000
Message-ID: <40FD376D.8080407@franklinmint.fm>
Date: Tue, 20 Jul 2004 11:17:01 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sam Ruby <rubys@intertwingly.net>
CC: Janne Jalkanen <Janne.Jalkanen@nokia.com>,
        ext John Panzer <jpanzer@aol.net>, kwark.1511609@bloglines.com,
        joe.gregorio@gmail.com, Atom Syntax <atom-syntax@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net>
In-Reply-To: <40FD2EA6.9020903@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: <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:

> Janne Jalkanen wrote:
>
>>> Is an X-ATOM-xxx HTTP request header a reasonable 90% solution?  
>>> This would work for both Atom XML and binary resources, is 
>>> implementable even by CGI scripts on the server side, and I'm 
>>> guessing has a nice simple specification (if present, overrides the 
>>> HTTP method used in the original request).
>>
>>
>> I think it is.  I took the alternate solution from PacePutDelete and 
>> codified it as a new Pace.
>>
>> http://intertwingly.net/wiki/pie/PaceAtomActionHeader
>
>
> Are we *SURE* that there are *NO* gateways that "eat" headers?
>
> I do not want to have multiple "fallbacks".


Yeah, we are bending over backwards for the one client platform we can 
find that can set headers, but not the request method. This doesn't help 
Flash or existing SOAP software.

Since this method is preferable to SOAP for binary resources, and the 
Pace lists support for Atom-Action as a MUST,  how would one use this 
method to PUT or DELETE a .jpg file on a server that can run only CGI 
scripts? I think this would require mod_actions access for an Apache 
account. In Appendix A of the APP draft, SOAP Enabling and support for 
the SOAPAction header are a SHOULD.

The SOAP 1.2 HTTP binding[0] would seem to solve all of the problems 
this Pace does, with the exception of binary PUT uploads. Would it be 
acceptable to require base64 for the infrequent case of editing on a 
cell phone? It seems reasonable to assume that cell phone clients will 
mostly be POSTing, and that mobile platforms that are somewhat pleasant 
to use for editing are more likely to have the ability to PUT.

Robert Sayre

[0] http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#soapinhttp



From owner-atom-syntax@mail.imc.org  Tue Jul 20 11:44:24 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29093
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 11:44: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 i6KFXCfi042706;
	Tue, 20 Jul 2004 08:33: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 i6KFXCsj042705;
	Tue, 20 Jul 2004 08:33:12 -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 i6KFXAfI042689
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 08:33:11 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 4984 messnum 5060867 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 20 Jul 2004 15:33:08 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail04.svc.cra.dublin.eircom.net (qp 4984) with SMTP; 20 Jul 2004 15:33:08 -0000
Message-ID: <40FD3B34.3090401@dehora.net>
Date: Tue, 20 Jul 2004 16:33:08 +0100
From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520
X-Accept-Language: en-gb, en, en-us
MIME-Version: 1.0
To: Sam Ruby <rubys@intertwingly.net>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: atom:origin?
References: <200407191919.PAA17914@ietf.org> <87hds3slp8.fsf@nwalsh.com> <40FC4B18.7020400@dehora.net> <40FC5E56.90505@intertwingly.net> <40FD154A.2090706@dehora.net> <40FD1FCB.7010803@intertwingly.net>
In-Reply-To: <40FD1FCB.7010803@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: <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


Sam Ruby wrote:

> 
> Bill de hÓra wrote:
>> OT: did I miss discussion for that change here?
> 
> 
> http://www.intertwingly.net/wiki/pie/PaceEntryIdRequired
> http://www.imc.org/atom-syntax/mail-archive/msg07152.html
> http://www.imc.org/atom-syntax/mail-archive/msg06955.html

Ahh; belated +1 from me then :)

cheers
Bill



From owner-atom-syntax@mail.imc.org  Tue Jul 20 12: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 MAA00774
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 12:03: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 i6KFrdO7045968;
	Tue, 20 Jul 2004 08:53:39 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6KFrd9s045967;
	Tue, 20 Jul 2004 08:53: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 (mproxy.gmail.com [216.239.56.246])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6KFrckI045961
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 08:53:38 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so7459495cwc
        for <atom-syntax@imc.org>; Tue, 20 Jul 2004 08:53:41 -0700 (PDT)
Received: by 10.11.99.56 with SMTP id w56mr182912cwb;
        Tue, 20 Jul 2004 08:53:41 -0700 (PDT)
Message-ID: <3f1451f504072008533002b6f4@mail.gmail.com>
Date: Tue, 20 Jul 2004 11:53:41 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: mint@franklinmint.fm
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
Cc: Sam Ruby <rubys@intertwingly.net>,
        Janne Jalkanen <janne.jalkanen@nokia.com>,
        ext John Panzer <jpanzer@aol.net>, kwark.1511609@bloglines.com,
        Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <40FD376D.8080407@franklinmint.fm>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@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 Tue, 20 Jul 2004 11:17:01 -0400, Robert Sayre <mint@franklinmint.fm> wrote:
> Sam Ruby wrote:
> 
> > Janne Jalkanen wrote:
> >
> >>> Is an X-ATOM-xxx HTTP request header a reasonable 90% solution?
> >>> This would work for both Atom XML and binary resources, is
> >>> implementable even by CGI scripts on the server side, and I'm
> >>> guessing has a nice simple specification (if present, overrides the
> >>> HTTP method used in the original request).
> >>
> >>
> >> I think it is.  I took the alternate solution from PacePutDelete and
> >> codified it as a new Pace.
> >>
> >> http://intertwingly.net/wiki/pie/PaceAtomActionHeader
> >
> >
> > Are we *SURE* that there are *NO* gateways that "eat" headers?
> >
> > I do not want to have multiple "fallbacks".
> 
> 
> Yeah, we are bending over backwards for the one client platform we can
> find that can set headers, but not the request method. 

We are bending over backwards for clients that do
not fully support HTTP, which is questionable 
given our charter.

> This doesn't help
> Flash or existing SOAP software.

How does this not help Flash, can Flash not set headers?
I thought it's only problem was lack of PUT and DELETE.

> Since this method is preferable to SOAP for binary resources, and the
> Pace lists support for Atom-Action as a MUST,  how would one use this
> method to PUT or DELETE a .jpg file on a server that can run only CGI
> scripts? 

What does binary have to do with cgi scripts?

    -joe

-- 
Joe Gregorio        http://bitworking.org



From owner-atom-syntax@mail.imc.org  Tue Jul 20 12:10:55 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01219
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 12:10: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 i6KFwkam046692;
	Tue, 20 Jul 2004 08:58: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 i6KFwkdI046691;
	Tue, 20 Jul 2004 08:58:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail06.svc.cra.dublin.eircom.net (mail06.svc.cra.dublin.eircom.net [159.134.118.22])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6KFwjZJ046665
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 08:58:46 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 16448 messnum 2824619 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 20 Jul 2004 15:58:43 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail06.svc.cra.dublin.eircom.net (qp 16448) with SMTP; 20 Jul 2004 15:58:43 -0000
Message-ID: <40FD4133.4040206@dehora.net>
Date: Tue, 20 Jul 2004 16:58: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: Sam Ruby <rubys@intertwingly.net>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: atom:origin?
References: <200407191919.PAA17914@ietf.org> <87hds3slp8.fsf@nwalsh.com> <40FC4B18.7020400@dehora.net> <40FC5E56.90505@intertwingly.net> <40FD154A.2090706@dehora.net> <40FD1FCB.7010803@intertwingly.net>
In-Reply-To: <40FD1FCB.7010803@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: <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


Sam Ruby wrote:

> Bill de hÓra wrote:
> 
>>
>> Sam Ruby wrote:
>>
>>> P.S.  Yes, this is a change from format-00

It seems there is some confusion here. The atom:origin element 
points to the feed/head id not the feed/entry id (the refs you 
mentioned were for entry ids). The feed/head id is still optional in 
[01]. If the feed/head is published without an id there is nothing 
for an atom:origin to relate to, hence the original reason to point 
at the link remains. In other words if we were to change origin to 
point at the feed/head id, it wouldn't make sense to have an origin 
element in a feed that doesn't have a feed/head id, when that entry 
is in fact in its origin feed (the non-synthetic case). I think my 
first reply to Norm stands.


[01] 
http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-01.txt



From owner-atom-syntax@mail.imc.org  Tue Jul 20 12: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 MAA01498
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 12: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 i6KG3Bug047494;
	Tue, 20 Jul 2004 09:03: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 i6KG3A1R047493;
	Tue, 20 Jul 2004 09:03: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 i6KG3Af7047487
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 09:03: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 1Bmx51-0000yp-Jn; Tue, 20 Jul 2004 16:02:59 +0000
Message-ID: <40FD4233.7040101@franklinmint.fm>
Date: Tue, 20 Jul 2004 12:02:59 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Joe Gregorio <joe.gregorio@gmail.com>
CC: Sam Ruby <rubys@intertwingly.net>,
        Janne Jalkanen <janne.jalkanen@nokia.com>,
        ext John Panzer <jpanzer@aol.net>, kwark.1511609@bloglines.com,
        Atom Syntax <atom-syntax@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <3f1451f504072008533002b6f4@mail.gmail.com>
In-Reply-To: <3f1451f504072008533002b6f4@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - web02.designerslab.net
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - franklinmint.fm
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


Joe Gregorio wrote:

>On Tue, 20 Jul 2004 11:17:01 -0400, Robert Sayre <mint@franklinmint.fm> wrote:
>  
>
>>This doesn't help
>>Flash or existing SOAP software.
>>    
>>
>
>How does this not help Flash, can Flash not set headers?
>I thought it's only problem was lack of PUT and DELETE.
>  
>
My mistake. Flash Player v6 and later can set them.

>>Since this method is preferable to SOAP for binary resources, and the
>>Pace lists support for Atom-Action as a MUST,  how would one use this
>>method to PUT or DELETE a .jpg file on a server that can run only CGI
>>scripts? 
>>    
>>
>
>What does binary have to do with cgi scripts?
>  
>

How could something like Movable Type support the following?

POST /images/foo.jpg HTTP/1.1
Content-type: image/jpg
Atom-Action: PUT


Robert Sayre



From owner-atom-syntax@mail.imc.org  Tue Jul 20 12:19: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 MAA01867
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 12:19: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 i6KG7nEC048206;
	Tue, 20 Jul 2004 09:07: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 i6KG7nId048205;
	Tue, 20 Jul 2004 09:07:49 -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 i6KG7m3E048199
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 09:07:49 -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 1Bmx9X-0001K6-PN; Tue, 20 Jul 2004 16:07:39 +0000
Message-ID: <40FD434C.60807@franklinmint.fm>
Date: Tue, 20 Jul 2004 12:07:40 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: mint@franklinmint.fm
CC: Joe Gregorio <joe.gregorio@gmail.com>, Sam Ruby <rubys@intertwingly.net>,
        Janne Jalkanen <janne.jalkanen@nokia.com>,
        ext John Panzer <jpanzer@aol.net>, kwark.1511609@bloglines.com,
        Atom Syntax <atom-syntax@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <3f1451f504072008533002b6f4@mail.gmail.com> <40FD4233.7040101@franklinmint.fm>
In-Reply-To: <40FD4233.7040101@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: <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:

> Joe Gregorio wrote:
>
>> How does this not help Flash, can Flash not set headers?
>> I thought it's only problem was lack of PUT and DELETE.
>>
> My mistake. Flash Player v6 and later can set them.


doh! My mistake again. This capability was added in minor revisions to 
Flash Player 6:

Windows and Mac Classic: version 6.0r65
Mac OS X: version 6.0r67
Linux: version 6.0r69

Robert Sayre



From owner-atom-syntax@mail.imc.org  Tue Jul 20 12: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 MAA02446
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 12:25:02 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KGGlYa049459;
	Tue, 20 Jul 2004 09:16: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 i6KGGlSO049458;
	Tue, 20 Jul 2004 09:16: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 i6KGGkt1049443
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 09:16:46 -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 i6KGHXws015992;
	Tue, 20 Jul 2004 12:17:33 -0400
Message-ID: <40FD4569.4070401@intertwingly.net>
Date: Tue, 20 Jul 2004 12:16:41 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: mint@franklinmint.fm
CC: Joe Gregorio <joe.gregorio@gmail.com>,
        Janne Jalkanen <janne.jalkanen@nokia.com>,
        ext John Panzer <jpanzer@aol.net>, kwark.1511609@bloglines.com,
        Atom Syntax <atom-syntax@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <3f1451f504072008533002b6f4@mail.gmail.com> <40FD4233.7040101@franklinmint.fm>
In-Reply-To: <40FD4233.7040101@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:
> 
> How could something like Movable Type support the following?
> 
> POST /images/foo.jpg HTTP/1.1
> Content-type: image/jpg
> Atom-Action: PUT

The following environment variables would be set:

   REQUEST_URI=/images/foo.jpg
   CONTENT_TYPE=image/jpg
   HTTP_ATOM_ACTION=PUT

image itself would be available as stdin

  - - -

If we, as a group, decide we don't need no steenken fallback, I would be 
willing to go along with the consensus.  I wouldn't be happy, but I 
would go along with it.

But, if we decide that we need do need a fallback, then I believe that 
we should seek the one that has the widest possible coverage and makes 
the fewest possible assumptions as to what a client/gateway combination 
would support.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Tue Jul 20 12:41: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 MAA03785
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 12:41:21 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KGSGTZ051589;
	Tue, 20 Jul 2004 09:28: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 i6KGSGXT051588;
	Tue, 20 Jul 2004 09:28:16 -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 i6KGSFj5051582
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 09:28:16 -0700 (PDT)
	(envelope-from distobj@acm.org)
Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian))
	id 1BmxU2-0007Fc-00
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 12:28:50 -0400
Date: Tue, 20 Jul 2004 12:28:50 -0400
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
Message-ID: <20040720162850.GC30868@markbaker.ca>
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <40FD2EA6.9020903@intertwingly.net>
User-Agent: Mutt/1.3.28i
From: Mark Baker <distobj@acm.org>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


On Tue, Jul 20, 2004 at 10:39:34AM -0400, Sam Ruby wrote:
> Are we *SURE* that there are *NO* gateways that "eat" headers?

Ironically, an early version of the RIM Blackberry Enterprise Server
(circa spring 2002, IIRC) ate extension headers.  It was fixed shortly
after we (Idokorro) reported the problem.  I don't know how well
deployed it was, but I suspect not very.

Mark.



From owner-atom-syntax@mail.imc.org  Tue Jul 20 12:43: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 MAA03938
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 12:43: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 i6KGSApX051565;
	Tue, 20 Jul 2004 09:28: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 i6KGSAZZ051564;
	Tue, 20 Jul 2004 09:28: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 i6KGS9QL051558
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 09:28: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 1BmxTN-0002Nh-9p; Tue, 20 Jul 2004 16:28:09 +0000
Message-ID: <40FD481A.40009@franklinmint.fm>
Date: Tue, 20 Jul 2004 12:28:10 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sam Ruby <rubys@intertwingly.net>
CC: Joe Gregorio <joe.gregorio@gmail.com>,
        Janne Jalkanen <janne.jalkanen@nokia.com>,
        ext John Panzer <jpanzer@aol.net>, kwark.1511609@bloglines.com,
        Atom Syntax <atom-syntax@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <3f1451f504072008533002b6f4@mail.gmail.com> <40FD4233.7040101@franklinmint.fm> <40FD4569.4070401@intertwingly.net>
In-Reply-To: <40FD4569.4070401@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: <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:

>
> Robert Sayre wrote:
>
>>
>> How could something like Movable Type support the following?
>>
>> POST /images/foo.jpg HTTP/1.1
>> Content-type: image/jpg
>> Atom-Action: PUT
>
>
> The following environment variables would be set:
>
>   REQUEST_URI=/images/foo.jpg
>   CONTENT_TYPE=image/jpg
>   HTTP_ATOM_ACTION=PUT
>
> image itself would be available as stdin


But wouldn't the ability to redirect PUTs and DELETEs to a CGI require a 
degree of control over the server that we haven't previously required?

I guess I'm confused how the edit endpoint for a binary resource would 
be configured. Would binary resources have their own EditURIs?

Robert Sayre



From owner-atom-syntax@mail.imc.org  Tue Jul 20 12:46:09 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04130
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 12:46:08 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KGYcR7052648;
	Tue, 20 Jul 2004 09:34:38 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6KGYc2i052647;
	Tue, 20 Jul 2004 09:34:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KGYb6T052641
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 09:34:38 -0700 (PDT)
	(envelope-from EB2M-MRT@asahi-net.or.jp)
Received: from [127.0.0.1] (h223087.ppp.asahi-net.or.jp [61.114.223.87])
	by mail.asahi-net.or.jp (Postfix) with ESMTP id 4074B12293
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 01:34:40 +0900 (JST)
Date: Wed, 21 Jul 2004 01:34:00 +0900
From: "MURATA Makoto (FAMILY Given)" <EB2M-MRT@asahi-net.or.jp>
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: RELAX NG Grammar for draft-...-00.txt
In-Reply-To: <877jtaldla.fsf@nwalsh.com>
References: <87eknkow28.fsf@nwalsh.com> <877jtaldla.fsf@nwalsh.com>
Message-Id: <20040721011939.5DF2.EB2M-MRT@asahi-net.or.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.09.01 [ja]
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



> 4. I've added Schematron rules in a few places to test for things that
> a grammar based schema can't practically test.

This is a great example.  For those who do not know Schematron, 
here are some good introductions.

http://www.xml.com/pub/a/2004/02/11/relaxtron.html
http://www.xml.com/pub/a/2003/11/12/schematron.html

Cheers,
-- 
MURATA Makoto (FAMILY Given) <EB2M-MRT@asahi-net.or.jp>




From owner-atom-syntax@mail.imc.org  Tue Jul 20 13:00:21 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05412
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 13:00:21 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KGkMj6054792;
	Tue, 20 Jul 2004 09:46: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 i6KGkMSj054791;
	Tue, 20 Jul 2004 09:46: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 i6KGkLAl054785
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 09:46: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 i6KGkPil004045
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 10:46:25 -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 <0I1500C1YT9CXV@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Tue, 20 Jul 2004 10:46:25 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.45])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I1500KXYT9B3K@mail.sun.net> for atom-syntax@imc.org; Tue,
 20 Jul 2004 10:46:24 -0600 (MDT)
Date: Tue, 20 Jul 2004 09:46:32 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
In-reply-to: <3f1451f504072008533002b6f4@mail.gmail.com>
To: Joe Gregorio <joe.gregorio@gmail.com>
Cc: Robert Sayre <mint@franklinmint.fm>, kwark.1511609@bloglines.com,
        Atom Syntax <atom-syntax@imc.org>,
        Janne Jalkanen <janne.jalkanen@nokia.com>,
        Sam Ruby <rubys@intertwingly.net>, ext John Panzer <jpanzer@aol.net>
Message-id: <5B112DC0-DA6C-11D8-92AF-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: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net>
 <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net>
 <40FD376D.8080407@franklinmint.fm> <3f1451f504072008533002b6f4@mail.gmail.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 Jul 20, 2004, at 8:53 AM, Joe Gregorio wrote:

> We are bending over backwards for clients that do
> not fully support HTTP, which is questionable
> given our charter.

[me, not the co-chair] The notion that we would even think of shipping 
a protocol designed for use by (among others) bloggers that is not 
usable on the world's most popular smart-phone system seems ludicrous 
on the face of it, to me.  -Tim



From owner-atom-syntax@mail.imc.org  Tue Jul 20 13: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 NAA06135
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 13:10: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 i6KGtFJA056364;
	Tue, 20 Jul 2004 09:55: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 i6KGtFxI056363;
	Tue, 20 Jul 2004 09:55:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KGtEIb056356
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 09:55:14 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6KGtHil009230
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 10:55:17 -0600 (MDT)
Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0I1500CUSTO5XV@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Tue, 20 Jul 2004 10:55:17 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.45])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I1500KCZTO43Q@mail.sun.net> for atom-syntax@imc.org; Tue,
 20 Jul 2004 10:55:17 -0600 (MDT)
Date: Tue, 20 Jul 2004 09:55:25 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
In-reply-to: <40FD481A.40009@franklinmint.fm>
To: mint@franklinmint.fm
Cc: Joe Gregorio <joe.gregorio@gmail.com>, kwark.1511609@bloglines.com,
        Atom Syntax <atom-syntax@imc.org>,
        Janne Jalkanen <janne.jalkanen@nokia.com>,
        Sam Ruby <rubys@intertwingly.net>, ext John Panzer <jpanzer@aol.net>
Message-id: <98DE9BC4-DA6D-11D8-92AF-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: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net>
 <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net>
 <40FD376D.8080407@franklinmint.fm> <3f1451f504072008533002b6f4@mail.gmail.com>
 <40FD4233.7040101@franklinmint.fm> <40FD4569.4070401@intertwingly.net>
 <40FD481A.40009@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 Jul 20, 2004, at 9:28 AM, Robert Sayre wrote:

> But wouldn't the ability to redirect PUTs and DELETEs to a CGI require 
> a degree of control over the server that we haven't previously 
> required?

Pretty straightforward on Apache they tell me, not really any harder 
than catching GET/POST. -Tim



From owner-atom-syntax@mail.imc.org  Tue Jul 20 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 NAA06883
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 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 i6KHEDkl059597;
	Tue, 20 Jul 2004 10:14: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 i6KHEDqP059596;
	Tue, 20 Jul 2004 10:14: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 i6KHECn4059590
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 10:14:12 -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 i6KHF2rv019296;
	Tue, 20 Jul 2004 13:15:02 -0400
Message-ID: <40FD52E2.5010606@intertwingly.net>
Date: Tue, 20 Jul 2004 13:14:10 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <Tim.Bray@Sun.COM>
CC: mint@franklinmint.fm, Joe Gregorio <joe.gregorio@gmail.com>,
        kwark.1511609@bloglines.com, Atom Syntax <atom-syntax@imc.org>,
        Janne Jalkanen <janne.jalkanen@nokia.com>,
        ext John Panzer <jpanzer@aol.net>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <3f1451f504072008533002b6f4@mail.gmail.com> <40FD4233.7040101@franklinmint.fm> <40FD4569.4070401@intertwingly.net> <40FD481A.40009@franklinmint.fm> <98DE9BC4-DA6D-11D8-92AF-000A95A51C9E@sun.com>
In-Reply-To: <98DE9BC4-DA6D-11D8-92AF-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 Jul 20, 2004, at 9:28 AM, Robert Sayre wrote:
> 
>> But wouldn't the ability to redirect PUTs and DELETEs to a CGI require 
>> a degree of control over the server that we haven't previously required?
> 
> Pretty straightforward on Apache they tell me, not really any harder 
> than catching GET/POST. -Tim

Any Apache CGI that can recieve a POST can also recieve a PUT.  They 
simply need to check the "REQUEST_METHOD" in order to distinguish 
between the two.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Tue Jul 20 13:37: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 NAA07991
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 13:37: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 i6KHOCv1061029;
	Tue, 20 Jul 2004 10:24: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 i6KHOC5J061028;
	Tue, 20 Jul 2004 10:24: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 i6KHOBmV061022
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 10:24: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 1BmyLa-0005SD-VG; Tue, 20 Jul 2004 17:24:11 +0000
Message-ID: <40FD5537.2080500@franklinmint.fm>
Date: Tue, 20 Jul 2004 13:24:07 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sam Ruby <rubys@intertwingly.net>
CC: Tim Bray <Tim.Bray@Sun.COM>, Joe Gregorio <joe.gregorio@gmail.com>,
        kwark.1511609@bloglines.com, Atom Syntax <atom-syntax@imc.org>,
        Janne Jalkanen <janne.jalkanen@nokia.com>,
        ext John Panzer <jpanzer@aol.net>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <3f1451f504072008533002b6f4@mail.gmail.com> <40FD4233.7040101@franklinmint.fm> <40FD4569.4070401@intertwingly.net> <40FD481A.40009@franklinmint.fm> <98DE9BC4-DA6D-11D8-92AF-000A95A51C9E@sun.com> <40FD52E2.5010606@intertwingly.net>
In-Reply-To: <40FD52E2.5010606@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: <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:

> Tim Bray wrote:
>
>>
>> On Jul 20, 2004, at 9:28 AM, Robert Sayre wrote:
>>
>>> But wouldn't the ability to redirect PUTs and DELETEs to a CGI 
>>> require a degree of control over the server that we haven't 
>>> previously required?
>>
>>
>> Pretty straightforward on Apache they tell me, not really any harder 
>> than catching GET/POST. -Tim
>
>
> Any Apache CGI that can recieve a POST can also recieve a PUT.  They 
> simply need to check the "REQUEST_METHOD" in order to distinguish 
> between the two.


I phrased my question badly, but note that I wrote *redirect*. What does 
it take to serve a .jpg file on a GET, while directing POSTs, PUTs, and 
DELETEs to a CGI? This is an issue Atom entries don't encounter, because 
they can specify an EditURI. If the server user has somewhere to stick a 
"Script" directive, it's no problem:

Script PUT /~bob/put.cgi

Does a standard shared hosting account allow the following?

This request would go to a CGI specified in a "Script" directive:
PUT /images/foo.jpg HTTP/1.1
Content-type: image/jpg

This request would just serve the file:
GET /images/foo.jpg HTTP/1.1

Robert Sayre



From owner-atom-syntax@mail.imc.org  Tue Jul 20 13:42: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 NAA08458
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 13:42: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 i6KHSffu061721;
	Tue, 20 Jul 2004 10:28: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 i6KHSf97061720;
	Tue, 20 Jul 2004 10:28:41 -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 i6KHSdL8061714
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 10:28:40 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p0611041cbd230570fce9@[10.20.30.249]>
Date: Tue, 20 Jul 2004 10:28:58 -0700
To: Atom WG <atom-syntax@imc.org>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Cancelling the WG meeting in San Diego
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>


Greetings again. After my earlier query asking who was going to be in 
San Diego, I only got two responses. Even if that was off by a factor 
of ten, it seems that having a face-to-face meeting in San Diego 
might not help the WG move forwards, but would cost a lot of people a 
lot of time and money. As I have said before, the purpose of the 
face-to-face meetings is to do things that can't be done on the 
mailing list, but it seems like the mailing list is doing quite well 
and few of the active participants want to go to San Diego.

Tim and I propose that we cancel the WG meeting and just keep doing 
the good work we are doing here. At the same time, Tim and I will be 
giving a presentation about Atompub at the Applications Area meeting 
at the IETF (in the Monday morning time slot). That presentation 
should generate more participation from IETF regulars who have dealt 
with some of the same issues we are dealing with now.

If this potential cancellation is a major concern to anyone, please 
speak up now, or send Tim or me off-line mail. Thanks!

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Tue Jul 20 13:48: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 NAA09435
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 13:48: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 i6KHZYHG062904;
	Tue, 20 Jul 2004 10:35: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 i6KHZYOG062903;
	Tue, 20 Jul 2004 10:35: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 i6KHZXCi062894
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 10:35:33 -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 i6KHaS1x020620;
	Tue, 20 Jul 2004 13:36:28 -0400
Message-ID: <40FD57E8.2000503@intertwingly.net>
Date: Tue, 20 Jul 2004 13:35:36 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: mint@franklinmint.fm
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <3f1451f504072008533002b6f4@mail.gmail.com> <40FD4233.7040101@franklinmint.fm> <40FD4569.4070401@intertwingly.net> <40FD481A.40009@franklinmint.fm> <98DE9BC4-DA6D-11D8-92AF-000A95A51C9E@sun.com> <40FD52E2.5010606@intertwingly.net> <40FD5537.2080500@franklinmint.fm>
In-Reply-To: <40FD5537.2080500@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:
>>
>> Any Apache CGI that can recieve a POST can also recieve a PUT.  They 
>> simply need to check the "REQUEST_METHOD" in order to distinguish 
>> between the two.
> 
> I phrased my question badly, but note that I wrote *redirect*. What does 
> it take to serve a .jpg file on a GET, while directing POSTs, PUTs, and 
> DELETEs to a CGI?

I'll answer a question with a question, then.  Why is a redirect 
required?  If you find that you can't do a redirect, you can simply 
serve the GET via your CGI, thus:

   #!/usr/bin/python
   print "Content-type: image/jpg\r\n\r\n" + open("foo.jpg").read()

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Tue Jul 20 13: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 NAA09509
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 13:48:28 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KHfInX063708;
	Tue, 20 Jul 2004 10: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 i6KHfIxb063707;
	Tue, 20 Jul 2004 10:41:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.241])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6KHfIAk063690
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 10:41:18 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so7532900cwc
        for <atom-syntax@imc.org>; Tue, 20 Jul 2004 10:41:16 -0700 (PDT)
Received: by 10.11.116.22 with SMTP id o22mr185115cwc;
        Tue, 20 Jul 2004 10:41:16 -0700 (PDT)
Message-ID: <3f1451f5040720104134622441@mail.gmail.com>
Date: Tue, 20 Jul 2004 13:41:16 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: mint@franklinmint.fm
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
Cc: Sam Ruby <rubys@intertwingly.net>, Tim Bray <tim.bray@sun.com>,
        kwark.1511609@bloglines.com, Atom Syntax <atom-syntax@imc.org>,
        Janne Jalkanen <janne.jalkanen@nokia.com>,
        ext John Panzer <jpanzer@aol.net>
In-Reply-To: <40FD5537.2080500@franklinmint.fm>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <3f1451f504072008533002b6f4@mail.gmail.com> <40FD4233.7040101@franklinmint.fm> <40FD4569.4070401@intertwingly.net> <40FD481A.40009@franklinmint.fm> <98DE9BC4-DA6D-11D8-92AF-000A95A51C9E@sun.com> <40FD52E2.5010606@intertwingly.net> <40FD5537.2080500@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 Tue, 20 Jul 2004 13:24:07 -0400, Robert Sayre <mint@franklinmint.fm> wrote:
> Sam Ruby wrote:
> > Any Apache CGI that can recieve a POST can also recieve a PUT.  They
> > simply need to check the "REQUEST_METHOD" in order to distinguish
> > between the two.
> 
> 
> I phrased my question badly, but note that I wrote *redirect*. What does
> it take to serve a .jpg file on a GET, while directing POSTs, PUTs, and
> DELETEs to a CGI? This is an issue Atom entries don't encounter, because
> they can specify an EditURI. If the server user has somewhere to stick a
> "Script" directive, it's no problem:
> 
> Script PUT /~bob/put.cgi
> 
> Does a standard shared hosting account allow the following?
> 
> This request would go to a CGI specified in a "Script" directive:
> PUT /images/foo.jpg HTTP/1.1
> Content-type: image/jpg
> 
> This request would just serve the file:
> GET /images/foo.jpg HTTP/1.1



if os.environ["REQUEST_METHOD"] == "GET":
    print "Content-type: image/jpg\r\n\r\n"
    f = file("foo.jpg", "r")
    os.stdout.write(f.read())
elif  os.environ["REQUEST_METHOD"] == "PUT":
    f = file("foo.jpg", "w")
    f.write(os.stdin.read())
    f.close()

   
    -joe

-- 
Joe Gregorio        http://bitworking.org



From owner-atom-syntax@mail.imc.org  Tue Jul 20 14:04: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 OAA10625
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 14:04: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 i6KHnxvS065085;
	Tue, 20 Jul 2004 10: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 i6KHnxCx065084;
	Tue, 20 Jul 2004 10:49:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KHnwV4065078
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 10:49:59 -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 1BmykW-0006tx-G2; Tue, 20 Jul 2004 17:49:56 +0000
Message-ID: <40FD5B45.2030202@franklinmint.fm>
Date: Tue, 20 Jul 2004 13:49:57 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Joe Gregorio <joe.gregorio@gmail.com>
CC: Sam Ruby <rubys@intertwingly.net>, Tim Bray <tim.bray@sun.com>,
        kwark.1511609@bloglines.com, Atom Syntax <atom-syntax@imc.org>,
        Janne Jalkanen <janne.jalkanen@nokia.com>,
        ext John Panzer <jpanzer@aol.net>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <3f1451f504072008533002b6f4@mail.gmail.com> <40FD4233.7040101@franklinmint.fm> <40FD4569.4070401@intertwingly.net> <40FD481A.40009@franklinmint.fm> <98DE9BC4-DA6D-11D8-92AF-000A95A51C9E@sun.com> <40FD52E2.5010606@intertwingly.net> <40FD5537.2080500@franklinmint.fm> <3f1451f5040720104134622441@mail.gmail.com>
In-Reply-To: <3f1451f5040720104134622441@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - web02.designerslab.net
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - franklinmint.fm
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


Sam Ruby wrote:

> I'll answer a question with a question, then.  Why is a redirect 
> required?  If you find that you can't do a redirect, you can simply 
> serve the GET via your CGI, thus:
>
>   #!/usr/bin/python
>   print "Content-type: image/jpg\r\n\r\n" + open("foo.jpg").read()



Joe Gregorio wrote:

>if os.environ["REQUEST_METHOD"] == "GET":
>    print "Content-type: image/jpg\r\n\r\n"
>    f = file("foo.jpg", "r")
>    os.stdout.write(f.read())
>elif  os.environ["REQUEST_METHOD"] == "PUT":
>    f = file("foo.jpg", "w")
>    f.write(os.stdin.read())
>    f.close()
>  
>

OK. Both of these answers imply an EditURI for binary resources, 
correct? I don't think I would want to include the CGI output in my 
feed. I would rather use the static resource (e.g. <img src="foo.jpg">). 
Is the relationship between the static resource and the EditURI one we 
want to make explicit?

Robert Sayre



From owner-atom-syntax@mail.imc.org  Tue Jul 20 14:18: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 OAA12327
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 14:18: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 i6KI7GqZ067873;
	Tue, 20 Jul 2004 11:07: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 i6KI7Ggh067872;
	Tue, 20 Jul 2004 11:07:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from vspmail.nscp.aoltw.net (h-64-236-139-249.aoltw.net [64.236.139.249])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KI7Fig067856
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 11:07:15 -0700 (PDT)
	(envelope-from jpanzer@AOL.NET)
Received: from h-10-169-146-121.nscp.aoltw.net (h-10-169-146-121.nscp.aoltw.net [10.169.146.121])
	by vspmail.nscp.aoltw.net (8.11.6/8.11.6) with ESMTP id i6KICFs01480;
	Tue, 20 Jul 2004 11:12:15 -0700
Date: Tue, 20 Jul 2004 11:07:01 -0700
From: "John Panzer" <jpanzer@aol.net>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
To: mint@franklinmint.fm
cc: "Sam Ruby" <rubys@intertwingly.net>,
        "Joe Gregorio" <joe.gregorio@gmail.com>,
        "Janne Jalkanen" <janne.jalkanen@nokia.com>,
        kwark.1511609@bloglines.com, "Atom Syntax" <atom-syntax@imc.org>
In-Reply-To: <40FD481A.40009@franklinmint.fm>
Message-ID: <40FD5F45.7010106@AOL.NET>
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <3f1451f504072008533002b6f4@mail.gmail.com> <40FD4233.7040101@franklinmint.fm> <40FD4569.4070401@intertwingly.net> <40FD481A.40009@franklinmint.fm>
X-Mailer: AOL Communicator (20030919.3 Win)
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 wrote on 7/20/2004, 9:28 AM:

 >
 > Sam Ruby wrote:
 >
 > >
 > > Robert Sayre wrote:
 > >
 > >>
 > >> How could something like Movable Type support the following?
 > >>
 > >> POST /images/foo.jpg HTTP/1.1
 > >> Content-type: image/jpg
 > >> Atom-Action: PUT
 > >
 > >
 > > The following environment variables would be set:
 > >
 > >   REQUEST_URI=/images/foo.jpg
 > >   CONTENT_TYPE=image/jpg
 > >   HTTP_ATOM_ACTION=PUT
 > >
 > > image itself would be available as stdin
 >
 >
 > But wouldn't the ability to redirect PUTs and DELETEs to a CGI require a
 > degree of control over the server that we haven't previously required?
 >
 > I guess I'm confused how the edit endpoint for a binary resource would
 > be configured. Would binary resources have their own EditURIs?

I think that for binary resources, the EditURI needs to be the same as 
the ResourceURI (that is, the same URI needs to accept both GET and, if 
supported, PUT/DELETE).  This is the assumption in 
PaceSimpleResourcePosting and it's not in conflict with 
PaceNonEntryResources.

Reasoning:  For the most common use case, the way to find a URI for a 
non entry binary resource is to parse (X)HTML and look for things like 
<img @src="..."/>.  Clearly this is the ResourceURI used for GETs. 
Given that URI, then, how do you discover the EditURI to use for 
PUTs/DELETEs?  The simplest way is to assume EditURI = ResourceURI.

-John Panzer






From owner-atom-syntax@mail.imc.org  Tue Jul 20 14: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 OAA12624
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 14: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 i6KI8YOp068279;
	Tue, 20 Jul 2004 11:08: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 i6KI8YhT068278;
	Tue, 20 Jul 2004 11:08:34 -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 i6KI8WE3068059
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 11:08:33 -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 i6KI8Q53032499
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 13:08:26 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6KI8PUB032495;
	Tue, 20 Jul 2004 13:08:25 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net>
	<40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net>
	<40FD376D.8080407@franklinmint.fm>
	<3f1451f504072008533002b6f4@mail.gmail.com>
	<40FD4233.7040101@franklinmint.fm> <40FD4569.4070401@intertwingly.net>
	<40FD481A.40009@franklinmint.fm>
	<98DE9BC4-DA6D-11D8-92AF-000A95A51C9E@sun.com>
	<40FD52E2.5010606@intertwingly.net> <40FD5537.2080500@franklinmint.fm>
	<3f1451f5040720104134622441@mail.gmail.com>
	<40FD5B45.2030202@franklinmint.fm>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 20 Jul 2004 13:08:25 -0500
In-Reply-To: <40FD5B45.2030202@franklinmint.fm>
Message-ID: <m3hds2blgm.fsf@bitsko.slc.ut.us>
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: <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> writes:

> OK. Both of these answers imply an EditURI for binary resources,
> correct? I don't think I would want to include the CGI output in my
> feed. I would rather use the static resource (e.g. <img
> src="foo.jpg">). Is the relationship between the static resource and
> the EditURI one we want to make explicit?

Just so I'm clear, are we confusing the "public" GETable URI for the
resource for reading clients with the "private" EditURI intended for
editing clients?

The EditURI supports GET/PUT/DELETE.  The public URI supports GET.
Those URIs could be the same, if that's how one's publishing system
works, but they don't need to be.

A redirect from the "public" URI to the EditURI isn't necessary.

  -- Ken



From owner-atom-syntax@mail.imc.org  Tue Jul 20 14:43: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 NAA09429
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 13:48: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 i6KHcd5o063321;
	Tue, 20 Jul 2004 10: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 i6KHcdZO063320;
	Tue, 20 Jul 2004 10:38:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from vspmail.nscp.aoltw.net (h-64-236-139-249.aoltw.net [64.236.139.249])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KHcdKC063300
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 10:38:39 -0700 (PDT)
	(envelope-from jpanzer@AOL.NET)
Received: from h-10-169-146-121.nscp.aoltw.net (h-10-169-146-121.nscp.aoltw.net [10.169.146.121])
	by vspmail.nscp.aoltw.net (8.11.6/8.11.6) with ESMTP id i6KHePs01439;
	Tue, 20 Jul 2004 10:40:25 -0700
Date: Tue, 20 Jul 2004 10:35:11 -0700
From: "John Panzer" <jpanzer@aol.net>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
To: mint@franklinmint.fm
cc: "Sam Ruby" <rubys@intertwingly.net>, "Tim Bray" <Tim.Bray@Sun.COM>,
        "Joe Gregorio" <joe.gregorio@gmail.com>, kwark.1511609@bloglines.com,
        "Atom Syntax" <atom-syntax@imc.org>,
        "Janne Jalkanen" <janne.jalkanen@nokia.com>
In-Reply-To: <40FD5537.2080500@franklinmint.fm>
Message-ID: <40FD57CE.7010300@AOL.NET>
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <3f1451f504072008533002b6f4@mail.gmail.com> <40FD4233.7040101@franklinmint.fm> <40FD4569.4070401@intertwingly.net> <40FD481A.40009@franklinmint.fm> <98DE9BC4-DA6D-11D8-92AF-000A95A51C9E@sun.com> <40FD52E2.5010606@intertwingly.net> <40FD5537.2080500@franklinmint.fm>
X-Mailer: AOL Communicator (20030919.3 Win)
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 wrote on 7/20/2004, 10:24 AM:

 >
 > Sam Ruby wrote:
 >
 > > Tim Bray wrote:
 > >
 > >>
 > >> On Jul 20, 2004, at 9:28 AM, Robert Sayre wrote:
 > >>
 > >>> But wouldn't the ability to redirect PUTs and DELETEs to a CGI
 > >>> require a degree of control over the server that we haven't
 > >>> previously required?
 > >>
 > >>
 > >> Pretty straightforward on Apache they tell me, not really any harder
 > >> than catching GET/POST. -Tim
 > >
 > >
 > > Any Apache CGI that can recieve a POST can also recieve a PUT.  They
 > > simply need to check the "REQUEST_METHOD" in order to distinguish
 > > between the two.
 >
 >
 > I phrased my question badly, but note that I wrote *redirect*. What does
 > it take to serve a .jpg file on a GET, while directing POSTs, PUTs, and
 > DELETEs to a CGI? This is an issue Atom entries don't encounter, because
 > they can specify an EditURI. If the server user has somewhere to stick a
 > "Script" directive, it's no problem:
 >
 > Script PUT /~bob/put.cgi
 >
 > Does a standard shared hosting account allow the following?
 >
 > This request would go to a CGI specified in a "Script" directive:
 > PUT /images/foo.jpg HTTP/1.1
 > Content-type: image/jpg
 >
 > This request would just serve the file:
 > GET /images/foo.jpg HTTP/1.1
 >

In the absolute worst case, the CGI script can stream the bits of the 
JPG image back to the client when it sees the GET.  So in the edge case 
where you can't use "Script" or its moral equivalent, there is an 
(inefficient) workaround.  I'd assert this is sufficient, but perhaps 
I'm missing something?

-John



From owner-atom-syntax@mail.imc.org  Tue Jul 20 14: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 OAA14536
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 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 i6KIWnk8072608;
	Tue, 20 Jul 2004 11:32: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 i6KIWmIR072607;
	Tue, 20 Jul 2004 11:32:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from vspmail.nscp.aoltw.net (h-64-236-139-249.aoltw.net [64.236.139.249])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KIWmXH072591
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 11:32:48 -0700 (PDT)
	(envelope-from jpanzer@AOL.NET)
Received: from h-10-169-146-121.nscp.aoltw.net (h-10-169-146-121.nscp.aoltw.net [10.169.146.121])
	by vspmail.nscp.aoltw.net (8.11.6/8.11.6) with ESMTP id i6KIbcs01509;
	Tue, 20 Jul 2004 11:37:41 -0700
Date: Tue, 20 Jul 2004 11:32:24 -0700
From: "John Panzer" <jpanzer@AOL.NET>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
To: "Ken MacLeod" <ken@bitsko.slc.ut.us>
cc: "Atom Syntax" <atom-syntax@imc.org>
In-Reply-To: <m3hds2blgm.fsf@bitsko.slc.ut.us>
Message-ID: <40FD6538.7020301@AOL.NET>
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <3f1451f504072008533002b6f4@mail.gmail.com> <40FD4233.7040101@franklinmint.fm> <40FD4569.4070401@intertwingly.net> <40FD481A.40009@franklinmint.fm> <98DE9BC4-DA6D-11D8-92AF-000A95A51C9E@sun.com> <40FD52E2.5010606@intertwingly.net> <40FD5537.2080500@franklinmint.fm> <3f1451f5040720104134622441@mail.gmail.com> <40FD5B45.2030202@franklinmint.fm> <m3hds2blgm.fsf@bitsko.slc.ut.us>
X-Mailer: AOL Communicator (20030919.3 Win)
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>




Ken MacLeod wrote on 7/20/2004, 11:08 AM:

 >
 > Robert Sayre <mint@franklinmint.fm> writes:
 >
 > > OK. Both of these answers imply an EditURI for binary resources,
 > > correct? I don't think I would want to include the CGI output in my
 > > feed. I would rather use the static resource (e.g. <img
 > > src="foo.jpg">). Is the relationship between the static resource and
 > > the EditURI one we want to make explicit?
 >
 > Just so I'm clear, are we confusing the "public" GETable URI for the
 > resource for reading clients with the "private" EditURI intended for
 > editing clients?
 >
 > The EditURI supports GET/PUT/DELETE.  The public URI supports GET.
 > Those URIs could be the same, if that's how one's publishing system
 > works, but they don't need to be.

Please see my earlier post on this thread, though, for an argument as to 
why EditURI should be the same as the "public" GETable URI for binary 
resources.  Although this is a restriction on what publishing systems 
are allowed to do, I think it's a reasonable restriction that enables 
important functionality, namely, discovering the EditURIs of non entry 
resources associated with a referring atom:entry.

I believe that one rationale for separating the EditURI and "public" 
GETable URI for Atom entries is that the two may have different content 
representations, e.g., for Wiki text that maps to publicly viewable 
HTML.  Is there a use case for this in the case of binary resources? 
That's about the only reason I can think of for a publishing system 
_not_ making the URIs the same.

(In which case, I would ask whoever comes up with that use case also 
give a proposal for how to map from the "public" GETtable URI to the 
EditURI.  In the case of atom:entries, this is easy using a <link> 
construct.  For binary resources, this doesn't work.  So what's the 
alternative?)

-John Panzer




From owner-atom-syntax@mail.imc.org  Tue Jul 20 15:05:01 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16360
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 15:05: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 i6KIpj62075755;
	Tue, 20 Jul 2004 11:51: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 i6KIpjdd075754;
	Tue, 20 Jul 2004 11:51: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 i6KIpj7P075745
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 11:51: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 LAA27782
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 11:51:44 -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 LAA01362
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 11:51:43 -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, 20 Jul 2004 11:51:43 -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 <0I15005FBZ1F7O@shazam.verity.com> for atom-syntax@imc.org; Tue,
 20 Jul 2004 11:51:42 -0700 (PDT)
Date: Tue, 20 Jul 2004 11:51:19 -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: Unstructured text
In-reply-to: <BD22B042.21030%eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: 
 <605A99DE882CEC36E3B093C1@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: <BD22B042.21030%eric.scheid@ironclad.net.au>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6KIpj7P075749
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 Tuesday, July 20, 2004 11:19 AM +1000 Eric Scheid <eric.scheid@ironclad.net.au> wrote:
>
> Not entirely. Some places might want to emit names like this:
>
>     <name>de hÓra, Bill</name>
>
> that is structured, but it has no embedded markup.

That is essentially unstructured because it is a mess to interpret.
You have to special case ", Jr." and so on. Context-sensitive parsing.

Real structured names look like this:

<name><given>Bill</given><family>de hÓra</family></name>

That also works for "Murata Makoto".

If we want structured names, we start with the X.500 name system
(above) and also look at AACR2 (library cataloguing rules).
Anything short of that is US-centric hacks.

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Tue Jul 20 15:06: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 PAA16569
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 15:06:48 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KItI06076327;
	Tue, 20 Jul 2004 11:55: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 i6KItIvC076326;
	Tue, 20 Jul 2004 11:55: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 i6KItH1T076305
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 11:55: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 50DE17C115; Tue, 20 Jul 2004 21:52:04 +0200 (CEST)
To: arve@virtuelvis.com
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: atom:created same as atom:modified?
References: <200407201445.i6KEjT7A035471@above.proper.com>
Message-ID: <opsbf9ofu4uvpchu@quark>
Date: Tue, 20 Jul 2004 20:58:53 +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: <200407201445.i6KEjT7A035471@above.proper.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Tue, 20 Jul 2004 16:45:24 +0200, <arve@virtuelvis.com> wrote:

> My suggestion is making all of created, issued and modified MUST dates.  
> Make them objective dates, and provide an optional subjective, freeform
> "displaydate" element.

+1.

> Since CMSes have to be changed anyway to provide (meaningful) Atom  
> support, I suggest that these applications,  set created to be the  
> earliest
> of any "issued" or "modified" date when updating their database schemes.

Indeed.

-- 
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 Jul 20 15:12: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 PAA17366
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 15: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 i6KJ128u077130;
	Tue, 20 Jul 2004 12:01:02 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6KJ12C6077129;
	Tue, 20 Jul 2004 12:01:02 -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 i6KJ11pR077099
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 12:01:01 -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 MAA28557
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 12:01: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 MAA02817
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 12:00:59 -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, 20 Jul 2004 12:00:59 -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 <0I15005KIZHL7O@shazam.verity.com> for atom-syntax@imc.org; Tue,
 20 Jul 2004 12:00:58 -0700 (PDT)
Date: Tue, 20 Jul 2004 12:01:01 -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: PaceExtensionNamespace created
In-reply-to: <m3llhfb9gj.fsf@bitsko.slc.ut.us>
To: atom-syntax@imc.org
Message-id: 
 <595D16010B9F72B68E5FD151@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: <FA23639F-D9FE-11D8-B499-003065EA6144@geckotribe.com>
 <m3llhfb9gj.fsf@bitsko.slc.ut.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 Monday, July 19, 2004 11:15 PM -0500 Ken MacLeod <ken@bitsko.slc.ut.us> wrote:
>
> Since server support of fallbacks are an all-or-nothing thing, there's
> no need to include @method (or any other indicator) on every service
> element, it'd be easier to put that in one place in the feed or site
> introspection file.

There is some advantage to standalone documents. It sure would be
nice to have all the info right here, without needing to fetch one
more doc. In REST terms, I would like to fetch enough state to
make the next move.

I can see a use for @method in spiders as a safety mechanism.
Spider never want to do anything but a GET. Unless it is a spider
signing up a spammer for free catalog subscriptions, but that is
not our domain.

Hmmm, that makes me think. Should Atom require that non-GET URLs
return a 405 Method Not Supported on GET? That way, a spider can
decide to not return to that URL, even if they get there through
a normally-followed link.

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Tue Jul 20 15:27: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 PAA19285
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 15:27: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 i6KJG0fm079604;
	Tue, 20 Jul 2004 12:16:00 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6KJG0Cl079603;
	Tue, 20 Jul 2004 12:16:00 -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 i6KJFw1v079576
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 12:15:59 -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 i6KJFu53001264
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 14:15:56 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6KJFuBK001258;
	Tue, 20 Jul 2004 14:15:56 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: "Atom Syntax" <atom-syntax@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net>
	<40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net>
	<40FD376D.8080407@franklinmint.fm>
	<3f1451f504072008533002b6f4@mail.gmail.com>
	<40FD4233.7040101@franklinmint.fm> <40FD4569.4070401@intertwingly.net>
	<40FD481A.40009@franklinmint.fm>
	<98DE9BC4-DA6D-11D8-92AF-000A95A51C9E@sun.com>
	<40FD52E2.5010606@intertwingly.net> <40FD5537.2080500@franklinmint.fm>
	<3f1451f5040720104134622441@mail.gmail.com>
	<40FD5B45.2030202@franklinmint.fm> <m3hds2blgm.fsf@bitsko.slc.ut.us>
	<40FD6538.7020301@AOL.NET>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 20 Jul 2004 14:15:56 -0500
In-Reply-To: <40FD6538.7020301@AOL.NET>
Message-ID: <m3d62qbic3.fsf@bitsko.slc.ut.us>
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


"John Panzer" <jpanzer@aol.net> writes:

> I believe that one rationale for separating the EditURI and "public"
> GETable URI for Atom entries is that the two may have different
> content representations, e.g., for Wiki text that maps to publicly
> viewable HTML.  Is there a use case for this in the case of binary
> resources?  That's about the only reason I can think of for a
> publishing system _not_ making the URIs the same.

Use Case #1: Serving static files from the web server directly.  The
benefits are many: proper headers, performance, no locking on large
requests (PCGI is single threaded, for example), etc.

Use Case #2: Output resources served from a different host than the
editing system.

I think both of these are significant cases in current practice.

> (In which case, I would ask whoever comes up with that use case also
> give a proposal for how to map from the "public" GETtable URI to the
> EditURI.  In the case of atom:entries, this is easy using a <link>
> construct.  For binary resources, this doesn't work.  So what's the
> alternative?)

Two alternatives:

1) Do nothing.  If the user is cutting-n-pasting the URL of an <entry>
   output web page so the client can autodiscover the <link> to the
   EditURI, the user can cut-n-pasted the URL of the resource from the
   publishing system's "list resources" page that lists editable
   resources.

2) Include the resources in the Atom index "feeds" (the "feeds" used
   by the editing clients to index posts no longer in the dynamic
   feed).

   PaceExtendedResourcePosting specifies adding a "full" metadata
   wrapper for non-entry resources, but a "minimal" metadata wrapper
   can be provided by the system.

  -- Ken

PS. Third alternative:  WebDAV PROPFIND ;)

PPS. It might also be politically incorrect in Atom circles to
consider that the ResourceBaseURI might be an FTP URL, but in that
situation the alternative is FTP's LIST command.  I wonder if there
aren't already editing clients that support FTP servers?



From owner-atom-syntax@mail.imc.org  Tue Jul 20 15:32: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 PAA19684
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 15:32: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 i6KJNJtp080797;
	Tue, 20 Jul 2004 12:23: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 i6KJNJao080796;
	Tue, 20 Jul 2004 12:23:19 -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 i6KJNJRF080780
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 12:23:19 -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 <20040720192318015003gqgde>; Tue, 20 Jul 2004 19:23:18 +0000
Date: Tue, 20 Jul 2004 13:23:16 -0600
Mime-Version: 1.0 (Apple Message framework v553)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Subject: Re: atom:created same as atom:modified?
From: Antone Roundy <antone@geckotribe.com>
To: atom-syntax@imc.org
Content-Transfer-Encoding: 7bit
Message-Id: <4004BE0A-DA82-11D8-95E3-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 Tue, 20 Jul 2004 16:45:24 +0200, <arve@virtuelvis.com> wrote:
> My suggestion is making all of created, issued and modified MUST 
> dates. Make them objective dates, and provide an optional subjective, 
> freeform
> "displaydate" element.
>
I'd have to say that requiring three dates in each entry, and possibly 
ending up with four, feels a little heavy.  As I've already mentioned, 
I don't think created is going to be useful to many people.  And in 
many cases, issued and modified are likely to be identical.  We could 
at least specify that if one of those two is omitted, that it may be 
assumed to be the same as the other--which to require and which to 
allow to omit doesn't matter much to me, so I'll defer to anyone who 
has a reason for preferring one of the other.

> Since CMSes have to be changed anyway to provide (meaningful) Atom 
> support, I suggest that these applications,  set created to be the 
> earliest
> of any "issued" or "modified" date when updating their database 
> schemes.
>
While that should be encouraged, I'd still advocate not requiring any 
objective dates.  I think there are just too many potential methods of 
generating feeds from a variety of data sources to be able to expect 
that generating objective dates for them to be feasible.  The more 
feeds there are where those dates really aren't "objective", the less 
value there will be in claiming that they are objective dates.



From owner-atom-syntax@mail.imc.org  Tue Jul 20 15:50: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 PAA21356
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 15:50: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 i6KJaPDh082958;
	Tue, 20 Jul 2004 12:36: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 i6KJaPs3082957;
	Tue, 20 Jul 2004 12:36:25 -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 i6KJaLWR082920
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 12:36:24 -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 i6KJaK53001650
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 14:36:20 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6KJaJ7T001646;
	Tue, 20 Jul 2004 14:36:19 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: atom-syntax@imc.org
Subject: Re: PaceExtensionNamespace created
References: <FA23639F-D9FE-11D8-B499-003065EA6144@geckotribe.com>
	<m3llhfb9gj.fsf@bitsko.slc.ut.us>
	<595D16010B9F72B68E5FD151@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 20 Jul 2004 14:36:19 -0500
In-Reply-To:  <595D16010B9F72B68E5FD151@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
Message-ID: <m38ydebhe4.fsf@bitsko.slc.ut.us>
Lines: 36
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


Walter Underwood <wunder@verity.com> writes:

> --On Monday, July 19, 2004 11:15 PM -0500 Ken MacLeod <ken@bitsko.slc.ut.us> wrote:
> >
> > Since server support of fallbacks are an all-or-nothing thing,
> > there's no need to include @method (or any other indicator) on
> > every service element, it'd be easier to put that in one place in
> > the feed or site introspection file.
> 
> There is some advantage to standalone documents. It sure would be
> nice to have all the info right here, without needing to fetch one
> more doc. In REST terms, I would like to fetch enough state to make
> the next move.

If we consider that necessary, I'd prefer the server report that
information in a header on every request, rather than on every service
URI reference in content.

  HTTP/1.1 200 OK
  Date: Tue, 20 Jul 2004 19:38:24 GMT
  Server: Apache/2.0.49-dev (Unix) DAV/2 SVN/1.0.5
  Last-Modified: Mon, 02 Sep 2002 07:58:11 GMT
  ETag: "94f4b-ffa-909c6ac0"
  Atom-Fallback-Support: Atom-Action; SOAP
  ...

> I can see a use for @method in spiders as a safety mechanism.
> Spider never want to do anything but a GET. Unless it is a spider
> signing up a spammer for free catalog subscriptions, but that is
> not our domain.

If spiders are randomly fetching anything that looks like a URI
location without understanding the Atom link relation names, I doubt
they're gonna be looking at the @method attribute either.

  -- Ken



From owner-atom-syntax@mail.imc.org  Tue Jul 20 16: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 QAA29486
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 16:39:48 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KKNCHV088469;
	Tue, 20 Jul 2004 13:23: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 i6KKNCae088468;
	Tue, 20 Jul 2004 13:23:12 -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 i6KKNCR2088454
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 13:23:12 -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 NAA05604
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 13:23:11 -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 NAA18401
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 13:23:10 -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, 20 Jul 2004 13:23:10 -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 <0I16005ZW3AK7O@shazam.verity.com> for atom-syntax@imc.org; Tue,
 20 Jul 2004 13:23:09 -0700 (PDT)
Date: Tue, 20 Jul 2004 13:23: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: PaceExtensionNamespace created
In-reply-to: <m38ydebhe4.fsf@bitsko.slc.ut.us>
To: atom-syntax@imc.org
Message-id: 
 <AD2CD35EFDF0B082A8422773@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: <FA23639F-D9FE-11D8-B499-003065EA6144@geckotribe.com>
 <m3llhfb9gj.fsf@bitsko.slc.ut.us>
 <595D16010B9F72B68E5FD151@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
 <m38ydebhe4.fsf@bitsko.slc.ut.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 Tuesday, July 20, 2004 2:36 PM -0500 Ken MacLeod <ken@bitsko.slc.ut.us> wrote:
>
> If spiders are randomly fetching anything that looks like a URI
> location without understanding the Atom link relation names, I doubt
> they're gonna be looking at the @method attribute either.

The link names might be extensions. Yes, the spider should have
an exact list of the known @rel values. It is a safety method,
as I said.

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Tue Jul 20 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 RAA04290
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 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 i6KL2tNd091872;
	Tue, 20 Jul 2004 14:02:55 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6KL2trr091871;
	Tue, 20 Jul 2004 14:02:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from vspmail.nscp.aoltw.net (h-64-236-139-249.aoltw.net [64.236.139.249])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KL2tdW091857
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 14:02:55 -0700 (PDT)
	(envelope-from jpanzer@AOL.NET)
Received: from h-10-169-146-121.nscp.aoltw.net (h-10-169-146-121.nscp.aoltw.net [10.169.146.121])
	by vspmail.nscp.aoltw.net (8.11.6/8.11.6) with ESMTP id i6KL85s01617;
	Tue, 20 Jul 2004 14:08:05 -0700
Date: Tue, 20 Jul 2004 14:02:52 -0700
From: "John Panzer" <jpanzer@aol.net>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
To: "Ken MacLeod" <ken@bitsko.slc.ut.us>
cc: "Atom Syntax" <atom-syntax@imc.org>
In-Reply-To: <m3d62qbic3.fsf@bitsko.slc.ut.us>
Message-ID: <40FD887C.5010909@AOL.NET>
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <3f1451f504072008533002b6f4@mail.gmail.com> <40FD4233.7040101@franklinmint.fm> <40FD4569.4070401@intertwingly.net> <40FD481A.40009@franklinmint.fm> <98DE9BC4-DA6D-11D8-92AF-000A95A51C9E@sun.com> <40FD52E2.5010606@intertwingly.net> <40FD5537.2080500@franklinmint.fm> <3f1451f5040720104134622441@mail.gmail.com> <40FD5B45.2030202@franklinmint.fm> <m3hds2blgm.fsf@bitsko.slc.ut.us> <40FD6538.7020301@AOL.NET> <m3d62qbic3.fsf@bitsko.slc.ut.us>
X-Mailer: AOL Communicator (20030919.3 Win)
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>


Ken MacLeod wrote on 7/20/2004, 12:15 PM:

 >
 > "John Panzer" <jpanzer@aol.net> writes:
 >
 > > I believe that one rationale for separating the EditURI and "public"
 > > GETable URI for Atom entries is that the two may have different
 > > content representations, e.g., for Wiki text that maps to publicly
 > > viewable HTML.  Is there a use case for this in the case of binary
 > > resources?  That's about the only reason I can think of for a
 > > publishing system _not_ making the URIs the same.
 >
 > Use Case #1: Serving static files from the web server directly.  The
 > benefits are many: proper headers, performance, no locking on large
 > requests (PCGI is single threaded, for example), etc.

(Aside: Should we be worried about optimizing the performance of CGI 
based servers?)  I think this is a valid point, but it might be an edge 
case (most servers capable of high volume static file GET requests can 
fairly easily shunt low volume PUT/DELETE requests to other code, IMHO.)

 >
 > Use Case #2: Output resources served from a different host than the
 > editing system.
 >

This one I have some sympathy for.  But I do wonder if there are really 
existing systems where a high-volume server farm is set up for binaries, 
where the provider wants to support PUT/DELETE as well as creation for 
said resources, and where the high-volume server farm cannot reasonably 
also support PUT/DELETE.  Is this in the 80% of cases we should worry about?

 > I think both of these are significant cases in current practice.
 >
 > > (In which case, I would ask whoever comes up with that use case also
 > > give a proposal for how to map from the "public" GETtable URI to the
 > > EditURI.  In the case of atom:entries, this is easy using a <link>
 > > construct.  For binary resources, this doesn't work.  So what's the
 > > alternative?)
 >
 > Two alternatives:
 >
 > 1) Do nothing.  If the user is cutting-n-pasting the URL of an <entry>
 >    output web page so the client can autodiscover the <link> to the
 >    EditURI, the user can cut-n-pasted the URL of the resource from the
 >    publishing system's "list resources" page that lists editable
 >    resources.

I'm not sure I understand the above.

Here's my use case:  I retrieve the Atom entry using the Atom API with 
the intent of editing it; presumably I use a GET to whatever URI returns 
the 'editable' or 'native' content in order to do this (EditURI?).  I 
then display it in my WYSIWYG editor, which renders the picture of my 
cat inline based on the XHTML content: <img 
src="http://example.org/cat1.jpg"/>.  I then drag a better cat picture 
on top of the original, and save the entry.  My client sees that I have 
only made a change to the picture, and decides to automatically replace 
the old picture.  How does it do this?

Some suggestions:
(1) Assume EditURI == "public" GET URI.  No problems.
(2) When the atom:entry is retrieved in 'edtiable' mode, the 
atom:content data refers to the _resource_ 'editable' URLs as well. 
That is, instead of <img src="http://example.org/cat1.jpg"/> you see 
<img src="http://edit.example.org/res/cat1.jpg"/>, and then this 
devolves just to suggestion (1).
(2) Provide metadata on the "public" GET URI via HTTP headers.  Requires 
an extra HEAD request to get metadata, followed by a PUT to the 
retrieved resource EditURI.  Also requires server to support metadata on 
every GET request.
(3) Give up on mapping from entries to associated resources.  Don't 
support updating pictures as discovered via entries.
(4) Why do you even care about this?

 > 2) Include the resources in the Atom index "feeds" (the "feeds" used
 >    by the editing clients to index posts no longer in the dynamic
 >    feed).
 >

Sure, but this doesn't help relate the resources to the individual 
entrie(s) they're associated with.  That's a use case I'm interested in; 
do you think this isn't useful?


 >    PaceExtendedResourcePosting specifies adding a "full" metadata
 >    wrapper for non-entry resources, but a "minimal" metadata wrapper
 >    can be provided by the system.
 >

I don't have a problem with PaceExtendedResourcePosting as an option, 
but I don't think that it should necessarily be _required_ of servers.

Note that if the hypothetical binary resource server farm above can 
provide even a "minimal" metadata wrapper for non-entry resources on 
GETs... why couldn't it just as easily provide support for PUT and 
DELETE and be done with it?

 >   -- Ken
 >
 > PS. Third alternative:  WebDAV PROPFIND ;)
 >

:) Of course if a server can support PROPFIND easily, could it support 
PUT and DELETE...? :)

 > PPS. It might also be politically incorrect in Atom circles to
 > consider that the ResourceBaseURI might be an FTP URL, but in that
 > situation the alternative is FTP's LIST command.  I wonder if there
 > aren't already editing clients that support FTP servers?
 >

That would be an interesting use case -- non-HTTP editing of resources?

-John Panzer




From owner-atom-syntax@mail.imc.org  Tue Jul 20 17:37:07 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08657
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 17:37: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 i6KLPYIA093291;
	Tue, 20 Jul 2004 14: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 i6KLPYKC093290;
	Tue, 20 Jul 2004 14:25:34 -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 i6KLPY6K093284
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 14:25:34 -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 i6KLPakN016619;
	Tue, 20 Jul 2004 14:25:37 -0700 (PDT)
Received: from [149.123.77.132] ([149.123.77.132])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id i6KLPUD2007881;
	Tue, 20 Jul 2004 14:25:32 -0700 (PDT)
In-Reply-To: <40FD4133.4040206@dehora.net>
References: <200407191919.PAA17914@ietf.org> <87hds3slp8.fsf@nwalsh.com> <40FC4B18.7020400@dehora.net> <40FC5E56.90505@intertwingly.net> <40FD154A.2090706@dehora.net> <40FD1FCB.7010803@intertwingly.net> <40FD4133.4040206@dehora.net>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5-382378999; protocol="application/pkcs7-signature"
Message-Id: <527D65FB-DA93-11D8-B3AB-000A95DC3D90@mac.com>
Cc: Atom Syntax <atom-syntax@imc.org>, Sam Ruby <rubys@intertwingly.net>
From: Graham <dtcd@mac.com>
Subject: Re: atom:origin?
Date: Tue, 20 Jul 2004 17:25:28 -0400
To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.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-5-382378999
Content-Type: text/plain;
	charset=ISO-8859-1;
	format=flowed
Content-Transfer-Encoding: quoted-printable

On 20 Jul 2004, at 11:58 am, Bill de h=D3ra wrote:

> It seems there is some confusion here. The atom:origin element points=20=

> to the feed/head id not the feed/entry id (the refs you mentioned were=20=

> for entry ids). The feed/head id is still optional in [01]. If the=20
> feed/head is published without an id there is nothing for an=20
> atom:origin to relate to, hence the original reason to point at the=20
> link remains. In other words if we were to change origin to point at=20=

> the feed/head id, it wouldn't make sense to have an origin element in=20=

> a feed that doesn't have a feed/head id, when that entry is in fact in=20=

> its origin feed (the non-synthetic case). I think my first reply to=20
> Norm stands.

Isn't the sane thing to do to point to the address of the actual feed?

Beyond that, maybe you could include other data too:

<entry>
   <origin href=3D"url of feed">
     <id>id of feed</id>
     <link rel=3D"alternate" type=3D"text/html"=20
href=3D"http://www.example.org/feed/" />
</entry>

Anyway, as others have mentioned, because there can be more than one=20
link@alternated in a feed, the current wording is nonsensical.

(also, why bother saying "character for character"? Surely, to be the=20
same address, it has to be the same characters?)

Graham=

--Apple-Mail-5-382378999
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
9w0BCQUxDxcNMDQwNzIwMjEyNTI4WjAjBgkqhkiG9w0BCQQxFgQUraVhhAyorf8EZziPjFhq7J4p
PrMweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAuQh+vOf8ZiUHF8lPmLPnrLm6
LzTya9R1MORi7HiKaK+/+hgKyqca7Mt/35TSwSdI/XBBNiO0ONTtbEURPdSEb+8yuiJyDGpDakNT
RZjLVMWersOoj55rQ9l2TGltsvlnKpUcrUbNYKfJ5fZgrpW8ttaeFMjQG7Pio2Gta3QkEFxzRHDt
lzQTg2fbMUPrSn6oF03fZdkObYJQi9XCUTPfaEJP2KNaFn75wifQOIECth2ZIQ2znEqWFdiHavfn
MwuB4sz2yOeFmBh9xyy0B6qJTmEGf6m+dRi67k6nM22k4ns9vbBmRaLhvK/531g/UTNbzQGwBtYi
NOBsk6Lms+st0AAAAAAAAA==

--Apple-Mail-5-382378999--



From owner-atom-syntax@mail.imc.org  Tue Jul 20 18:07: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 SAA13707
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 18:07:14 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KLrmo2095208;
	Tue, 20 Jul 2004 14:53: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 i6KLrmTN095207;
	Tue, 20 Jul 2004 14:53:48 -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 i6KLrmY7095199
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 14:53:48 -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 OAA12302
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 14: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 OAA03494
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 14:53:45 -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, 20 Jul 2004 14:53:45 -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 <0I1600EN87HJWW@shazam.verity.com> for atom-syntax@imc.org; Tue,
 20 Jul 2004 14:53:45 -0700 (PDT)
Date: Tue, 20 Jul 2004 14:53:47 -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: atom:created same as atom:modified?
In-reply-to: <87pt6rslub.fsf@nwalsh.com>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: 
 <46D11D8EABC45A2598E8E534@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: <200407191919.PAA17914@ietf.org> <87pt6rslub.fsf@nwalsh.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 Monday, July 19, 2004 5:55 PM -0400 Norman Walsh <ndw@nwalsh.com> wrote:
>|    If atom:created is not present, its content MUST considered to be the
>|    same as that of atom:modified.
>
> I would have expected it to be the same as atom:issued. I'm not sure
> either is really the obviously correct answer. Is there value in
> providing a default if it isn't specified?

To satisfy causality, it would need to be equal to the earlier of
atom:modified and atom:issued. It could not have been created at
a later date than it was issued or modified.

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Tue Jul 20 18: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 SAA15931
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 18: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 i6KM69pn096016;
	Tue, 20 Jul 2004 15:06: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 i6KM69vO096015;
	Tue, 20 Jul 2004 15:06:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KM6821096008
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 15:06: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 16D257C115
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 01:03:02 +0200 (CEST)
Date: Wed, 21 Jul 2004 00:09:32 +0200
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Those dates again
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: <opsbgih6u4uvpchu@quark>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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


This is probably not a popular issue, but as we don't seem to have reached  
any consensus on the matter, I've blogged some on the dates of Atom:

<url: http://www.virtuelvis.com/quark/archives/188.html>

I'm trying to explain why especially 'issued' is so essential as it is,  
and what other dates might be useful to an Atom entry. I probably don't  
cover everything (I'm pretty confident that I don't), so please feel free  
to comment on anything I write about in the entry. Here's an ultra-short  
summary of the entry:

This is the dates Atom seems to need:

  * Issued
  * Modified
  * Created
  * Display

Only the two first should be required. The two last will probably be  
available most of the time, but they are not very useful seen through my  
publishing binoculars and from a data model point of view.

-- 
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 Jul 20 18:17: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 SAA16116
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 18:17: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 i6KM6wOR096044;
	Tue, 20 Jul 2004 15:06:58 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6KM6wnF096043;
	Tue, 20 Jul 2004 15:06:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail06.svc.cra.dublin.eircom.net (mail06.svc.cra.dublin.eircom.net [159.134.118.22])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6KM6vod096034
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 15:06:58 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 71730 messnum 2836728 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 20 Jul 2004 22:06:57 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail06.svc.cra.dublin.eircom.net (qp 71730) with SMTP; 20 Jul 2004 22:06:57 -0000
Message-ID: <40FD9780.4020102@dehora.net>
Date: Tue, 20 Jul 2004 23:06:56 +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: atom:origin?
References: <200407191919.PAA17914@ietf.org> <87hds3slp8.fsf@nwalsh.com> <40FC4B18.7020400@dehora.net> <40FC5E56.90505@intertwingly.net> <40FD154A.2090706@dehora.net> <40FD1FCB.7010803@intertwingly.net> <40FD4133.4040206@dehora.net> <527D65FB-DA93-11D8-B3AB-000A95DC3D90@mac.com>
In-Reply-To: <527D65FB-DA93-11D8-B3AB-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: <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:

> Isn't the sane thing to do to point to the address of the actual feed?

Not really, unless we add words about origin only appearing when id 
does (co-occurence constraint - yuck).

> 
> Beyond that, maybe you could include other data too:
> 
> <entry>
>   <origin href="url of feed">
>     <id>id of feed</id>
>     <link rel="alternate" type="text/html" 
> href="http://www.example.org/feed/" />
> </entry>

Featuritis objection ;)


> Anyway, as others have mentioned, because there can be more than one 
> link@alternated in a feed, the current wording is nonsensical.

I think this is telling us more about the sense or not of our 
identity model than anything else. We have mandated ids for entries 
but not for feeds. What's that about?


> (also, why bother saying "character for character"? Surely, to be the 
> same address, it has to be the same characters?)

With URIs, not neccessarily, but that's a different matter.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Tue Jul 20 18:24: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 SAA17666
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 18:24: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 i6KMHhsb096633;
	Tue, 20 Jul 2004 15:17:43 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6KMHhhF096632;
	Tue, 20 Jul 2004 15:17: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 i6KMHg9j096624
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 15:17: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 1DF8B7C115; Wed, 21 Jul 2004 01:14:36 +0200 (CEST)
Date: Wed, 21 Jul 2004 00:21:08 +0200
To: "Antone Roundy" <antone@geckotribe.com>
Subject: Re: atom:created same as atom:modified?
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <4004BE0A-DA82-11D8-95E3-003065EA6144@geckotribe.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: <opsbgi1ivjuvpchu@quark>
In-Reply-To: <4004BE0A-DA82-11D8-95E3-003065EA6144@geckotribe.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Tue, 20 Jul 2004 13:23:16 -0600, Antone Roundy <antone@geckotribe.com>  
wrote:

> As I've already mentioned, I don't think created is going to be useful
> to many people.

Probably true, unless it differs much from 'Issued'. I've written some  
about this here:

<url: http://www.virtuelvis.com/quark/archives/188.html>

> And in many cases, issued and modified are likely to be identical.

How's that? I can understand it if the last change is saved at the same  
instance the entry is published to the web, but if these two actions are  
done seperately, the dates will be different. Also, viewing current  
practice as the wholy grail of date handling is imho not the way to go, as  
the current date handling couldn't be any simpler than it is.

> We could at least specify that if one of those two is omitted, that it
> may be assumed to be the same as the other--which to require and which
> to allow to omit doesn't matter much to me, so I'll defer to anyone who
> has a reason for preferring one of the other.

 From a publisher's point of view, 'issued' is the far most important one.  
 From an aggregator writer's point of view, I assume 'modified' to be the  
most important one. To get these two viewpoints to agree is like making  
friends of zebra's and aligators. Not that they hate or eat each other;  
they just have so different needs that it isn't reconcilable.

> While that should be encouraged, I'd still advocate not requiring any  
> objective dates.

-1.

> I think there are just too many potential methods of generating feeds
> from a variety of data sources to be able to expect that generating
> objective dates for them to be feasible.

Exceptions are of course okay, but the norm should be that 'issued',  
'modified' and 'created' is objective, or at least as objective as  
possible. There's really no reason for them not to be, as all publishing  
systems has actions corresponding to the dates:

   * A resource can't be put out on the web without being published.
   * A resource can't be published without being created.
   * A resource is most often modified several times both before and
     after issuance.

> The more feeds there are where those dates really aren't "objective",
> the less value there will be in claiming that they are objective dates.

True. That's why the specification needs to be clear on the issue, and why  
the tools should start supporting this and changing their internal data  
models now. As I've said before, this isn't a large change. It is at most  
a couple of lines of code per date, and the old entries which doesn't have  
these dates just set the missing dates to the exisiting one.

Having bad dates on old entries and good dates on new ones is better than  
having bad dates on both old and new.

-- 
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 Jul 20 18:34: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 SAA19465
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 18: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 i6KMLl4X097033;
	Tue, 20 Jul 2004 15:21:47 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6KMLlTk097032;
	Tue, 20 Jul 2004 15:21: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 i6KMLkoG097026
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 15:21:46 -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 i6KMJd53003405
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 16:19:39 -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 <0I1600LMO8SF2B@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Tue, 20 Jul 2004 16:21:51 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.45])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I1600KJ88SE3N@mail.sun.net> for atom-syntax@imc.org; Tue,
 20 Jul 2004 16:21:51 -0600 (MDT)
Date: Tue, 20 Jul 2004 15:21:58 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: PaceLinkConstruct issues & next steps
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <3733B5B6-DA9B-11D8-BFCB-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: <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 I look at the link-related discourse over the past few days, I 
observe a striking lack of consensus around

(a) whether it's useful to class or group links
(b) if so, how this should be done

Furthermore, I think that what progress there was in the discussion has 
been slowing down.  So, I'm casting about for what areas of agreement 
there are and how we can move this along.

Here are the links that we seem to have agreement must be in Atom 
(harvested from format & protocol drafts):

1. website of person (currently <atom:uri>*</atom:uri>)
2. feed-level link to publication (currently <atom:link rel="alternate" 
href="*">)
3. feed-level unique identifier (<atom:id>*</atom:id>)
4. generator uri (<atom:generator uri="*">)
5. basic link from atom:entry to its resource (<atom:link 
rel="alternate" href="*">)
6. entry-level unique identifier (<atom:id>*</atom:id>)
7. service.X endpoints (<link rel="service.X" href="*">)

There are some "secondary" links that have been talked up: via, 
in-reply-to, replaces, next, previous, attachment  (Did I miss any?)

OK, so..... unless someone comes up with a coherent proposal for how to 
do "rel=" and can get consensus around it, I see no choice but to nuke 
it.  That means that every link that anyone wants to have in Atom gets 
its own element or it isn't there.

NEXT STEP.  Since this is decision is quite significant to the look and 
feel of Atom, and since look and feel is important, I don't want to 
declare defeat on link grouping and extension (whatever my personal 
opinions).  So, I think we should push this one back on the stack and 
ask Sam to rotate the work queue.  The people who want to retain rel= 
or some other grouping/extension mechanism should feel free to work up 
proposals, make comparison charts on the wiki, or whatever.  Because, 
next time we take this up, the default action, unless there's consensus 
on grouping/extension, is to go element-by-element.

I'll wait for a day or two to give people a chance to shout one of:
(a) give up and go to distinct elements now
(b) yes, push it on the queue and give us a chance to work something up
(c) hey, there is too consensus on XXXX, you just didn't notice

No shouting => b.

OPINION: I don't think this issue is that big at the end of the day.  
Doing it right will probably give us better readability by end-users, 
but when we make up our minds I think the implementors will say "yeah, 
whatever" and code it up whichever way without any angst.

  -Tim



From owner-atom-syntax@mail.imc.org  Tue Jul 20 18:46:48 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21470
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 18: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 i6KMbm6R097845;
	Tue, 20 Jul 2004 15:37: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 i6KMbm2Y097844;
	Tue, 20 Jul 2004 15:37: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 i6KMblDI097835
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 15:37: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 E08D07C115; Wed, 21 Jul 2004 01:34:40 +0200 (CEST)
Date: Wed, 21 Jul 2004 00:41:17 +0200
To: "Ken MacLeod" <ken@bitsko.slc.ut.us>
Subject: Re: PaceLinkParent updated, tightened
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <m3vfgjdctl.fsf@bitsko.slc.ut.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: <opsbgjy3uouvpchu@quark>
In-Reply-To: <m3vfgjdctl.fsf@bitsko.slc.ut.us>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 19 Jul 2004 14:19:50 -0500, Ken MacLeod <ken@bitsko.slc.ut.us> wrote:

> I've updated PaceLinkParent [...]

Although I'm +1 on the idea the pace expresses, I do not agree with the  
concrete implementation. I think Atom should use the Dublin Core element  
<relation>, as its semantics is already defined there. <relation> also has  
the bonus that it defines other relation issues, like IsBasedOn  
(supersedes or «re-issuance» of resources) and such.

-- 
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 Jul 20 18:49: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 SAA22114
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 18: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 i6KMgC7b098153;
	Tue, 20 Jul 2004 15:42: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 i6KMgCYL098152;
	Tue, 20 Jul 2004 15:42:12 -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 i6KMgB7o098143
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 15:42:11 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040720224159.51681.qmail@web41201.mail.yahoo.com>
Received: from [207.46.228.98] by web41201.mail.yahoo.com via HTTP; Tue, 20 Jul 2004 15:41:59 PDT
Date: Tue, 20 Jul 2004 15:41:59 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Those dates again
To: "Asbjørn_Ulsberg" <asbjorn@tigerstaden.no>,
        Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <opsbgih6u4uvpchu@quark>
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>


--- Asbjørn_Ulsberg <asbjorn@tigerstaden.no> wrote:
> > 
>   * Issued
>   * Modified
>   * Created
>   * Display
> 
> Only the two first should be required. 

Agreed. 

> The two last
> will probably be  
> available most of the time, but they are not very
> useful seen through my  
> publishing binoculars and from a data model point of
> view.

As an aggregator author I'd never use either of least
two dates but assume they are of use to someone. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


	
		
__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/



From owner-atom-syntax@mail.imc.org  Tue Jul 20 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 SAA22686
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 18:52: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 i6KMl7QF098351;
	Tue, 20 Jul 2004 15:47: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 i6KMl7TB098350;
	Tue, 20 Jul 2004 15:47:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from dd1516.kasserver.com (dd1516.kasserver.com [81.209.148.207])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KMl6sd098344
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 15:47:06 -0700 (PDT)
	(envelope-from sc@itst.org)
Received: from [192.168.1.10] (p50816BF0.dip0.t-ipconnect.de [80.129.107.240])
	by dd1516.kasserver.com (Postfix) with ESMTP id A0D422C5237
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 00:47:05 +0200 (CEST)
Message-ID: <40FDA159.507@itst.org>
Date: Wed, 21 Jul 2004 00:48:57 +0200
From: Sascha Carlin <sc@itst.org>
User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707)
X-Accept-Language: de, en
MIME-Version: 1.0
To: atom-syntax@imc.org
Subject: Re: Those dates again
References: <opsbgih6u4uvpchu@quark>
In-Reply-To: <opsbgih6u4uvpchu@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:

>  * Issued
>  * Modified
>  * Created
>  * Display

What does Display mean?

Created seems to me to be important for use inside the application the 
entry is created in/from. An editor could be presented with a view of 
all entries created in a certain period of time to see how old a piece 
information really is.

Regards, Sascha

-- 
Sascha Carlin * Heinrich-Heine-Str. 1 * 64319 Pfungstadt
http://www.itst.org/         **         +49 6157 157 205



From owner-atom-syntax@mail.imc.org  Tue Jul 20 19:06:27 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25212
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 19:06:26 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KMtR9m098917;
	Tue, 20 Jul 2004 15:55: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 i6KMtReb098916;
	Tue, 20 Jul 2004 15:55:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KMtR2Q098900;
	Tue, 20 Jul 2004 15:55:27 -0700 (PDT)
	(envelope-from gstein@google.com)
Received: from buu.corp.google.com (buu.corp.google.com [172.24.67.34])
	by 216-239-45-4.google.com (8.12.11/8.12.9) with ESMTP id i6KMtN1t011997
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 20 Jul 2004 15:55:23 -0700
Received: from gstein by buu.corp.google.com with local (Exim 4.14 #4)
	id 1Bn3W6-0007Tb-Jr by authid <gstein>; Tue, 20 Jul 2004 15:55:22 -0700
Date: Tue, 20 Jul 2004 15:55:22 -0700
From: Greg Stein <gstein@google.com>
To: Paul Hoffman / IMC <phoffman@imc.org>
Cc: Atom WG <atom-syntax@imc.org>
Subject: Re: Cancelling the WG meeting in San Diego
Message-ID: <20040720225522.GA28724@google.com>
References: <p0611041cbd230570fce9@[10.20.30.249]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <p0611041cbd230570fce9@[10.20.30.249]>
User-Agent: Mutt/1.4.1i
X-URL: http://www.lyra.org/greg/
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>


Steve Jenson and I are planning to be there for the meeting. It would be a
pain in the butt to spend that time/money to go there and NOT have a
meeting.

-g

On Tue, Jul 20, 2004 at 10:28:58AM -0700, Paul Hoffman / IMC wrote:
> 
> Greetings again. After my earlier query asking who was going to be in 
> San Diego, I only got two responses. Even if that was off by a factor 
> of ten, it seems that having a face-to-face meeting in San Diego 
> might not help the WG move forwards, but would cost a lot of people a 
> lot of time and money. As I have said before, the purpose of the 
> face-to-face meetings is to do things that can't be done on the 
> mailing list, but it seems like the mailing list is doing quite well 
> and few of the active participants want to go to San Diego.
> 
> Tim and I propose that we cancel the WG meeting and just keep doing 
> the good work we are doing here. At the same time, Tim and I will be 
> giving a presentation about Atompub at the Applications Area meeting 
> at the IETF (in the Monday morning time slot). That presentation 
> should generate more participation from IETF regulars who have dealt 
> with some of the same issues we are dealing with now.
> 
> If this potential cancellation is a major concern to anyone, please 
> speak up now, or send Tim or me off-line mail. Thanks!
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
> 



From owner-atom-syntax@mail.imc.org  Tue Jul 20 19:20:41 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27723
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 19:20:40 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KNAYLY000764;
	Tue, 20 Jul 2004 16:10: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 i6KNAXZo000757;
	Tue, 20 Jul 2004 16:10:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KNAWKi000731;
	Tue, 20 Jul 2004 16:10:32 -0700 (PDT)
	(envelope-from jasnell@us.ibm.com)
Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32])
	by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i6KNAWIl603100;
	Tue, 20 Jul 2004 19:10:32 -0400
Received: from d03nm122.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170])
	by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6KNAV3K201372;
	Tue, 20 Jul 2004 17:10:31 -0600
In-Reply-To: <20040720224159.51681.qmail@web41201.mail.yahoo.com>
To: Dare Obasanjo <kpako@yahoo.com>
Cc: "=?ISO-8859-1?Q?Asbj=F8rn=5FUlsberg?=" <asbjorn@tigerstaden.no>,
        Atom-Syntax <atom-syntax@imc.org>, owner-atom-syntax@mail.imc.org
MIME-Version: 1.0
Subject: Re: Those dates again
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
From: James M Snell <jasnell@us.ibm.com>
X-MIMETrack: S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/20/2004 04:02:50 PM,
	Serialize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/20/2004 04:02:50 PM,
	Serialize complete at 07/20/2004 04:02:50 PM,
	Itemize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/20/2004 04:02:51 PM,
	S/MIME Sign complete at 07/20/2004 04:02:51 PM,
	S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/20/2004 04:10:26 PM,
	S/MIME Sign complete at 07/20/2004 04:10:26 PM,
	Serialize by Router on D03NM122/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at
 07/20/2004 17:10:31,
	Serialize complete at 07/20/2004 17:10:31
Message-ID: <OFE7A4F269.0DE76AA9-ON88256ED7.007E774E-88256ED7.007F4C7A@us.ibm.com>
Date: Tue, 20 Jul 2004 17:10:29 -0600
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z16497_boundary_sign
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>


This is an S/MIME signed message.

---------z16497_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 007E9A5488256ED7_="

This is a multipart message in MIME format.
--=_alternative 007E9A5488256ED7_=
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

Dare Obasanjo wrote on 07/20/2004 03:41:59 PM:

>=20
> --- Asbj=F8rn=5FUlsberg <asbjorn@tigerstaden.no> wrote:
> > >=20
> >   * Issued
> >   * Modified
> >   * Created
> >   * Display
> >=20
> > Only the two first should be required.=20
>=20
> Agreed.=20
>=20
> > The two last
> > will probably be=20
> > available most of the time, but they are not very
> > useful seen through my=20
> > publishing binoculars and from a data model point of
> > view.
>=20
> As an aggregator author I'd never use either of least
> two dates but assume they are of use to someone.=20
>=20

Why assume that?  If they are not useful as part of the core model (which=20
I agree they are not, btw) then they shouldn't be defined by the core=20
model.  If a certain subset of folks want 'em, let that certain subset=20
define them as extensions.

> =3D=3D=3D=3D=3D
> THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
> My dungeon will have its own qualified medical staff complete with=20
> bodyguards. That way if a prisoner becomes sick and his cellmate=20
> tells the guard it's an emergency, the guard will fetch a trauma=20
> team instead of opening up the cell for a look.
>=20
>=20
>=20
>=20
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> Do you Yahoo!?
> Vote for the stars of Yahoo!'s next ad campaign!
> http://advision.webevents.yahoo.com/yahoo/votelifeengine/
>=20


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

--=_alternative 007E9A5488256ED7_=
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable


<br><font size=3D2><tt>Dare Obasanjo wrote on 07/20/2004 03:41:59 PM:<br>
<br>
&gt; <br>
&gt; --- Asbj=F8rn=5FUlsberg &lt;asbjorn@tigerstaden.no&gt; wrote:<br>
&gt; &gt; &gt; <br>
&gt; &gt; &nbsp; * Issued<br>
&gt; &gt; &nbsp; * Modified<br>
&gt; &gt; &nbsp; * Created<br>
&gt; &gt; &nbsp; * Display<br>
&gt; &gt; <br>
&gt; &gt; Only the two first should be required. <br>
&gt; <br>
&gt; Agreed. <br>
&gt; <br>
&gt; &gt; The two last<br>
&gt; &gt; will probably be &nbsp;<br>
&gt; &gt; available most of the time, but they are not very<br>
&gt; &gt; useful seen through my &nbsp;<br>
&gt; &gt; publishing binoculars and from a data model point of<br>
&gt; &gt; view.<br>
&gt; <br>
&gt; As an aggregator author I'd never use either of least<br>
&gt; two dates but assume they are of use to someone. <br>
&gt; </tt></font>
<br>
<br><font size=3D2><tt>Why assume that? &nbsp;If they are not useful as part
of the core model (which I agree they are not, btw) then they shouldn't
be defined by the core model. &nbsp;If a certain subset of folks want 'em,
let that certain subset define them as extensions.</tt></font>
<br><font size=3D2><tt><br>
&gt; =3D=3D=3D=3D=3D<br>
&gt; THINGS TO DO IF I BECOME AN EVIL OVERLORD #95<br>
&gt; My dungeon will have its own qualified medical staff complete with
<br>
&gt; bodyguards. That way if a prisoner becomes sick and his cellmate <br>
&gt; tells the guard it's an emergency, the guard will fetch a trauma <br>
&gt; team instead of opening up the cell for a look.<br>
&gt; <br>
&gt; <br>
&gt; &nbsp; &nbsp;<br>
&gt; &nbsp; &nbsp; &nbsp; <br>
&gt; =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F<br>
&gt; Do you Yahoo!?<br>
&gt; Vote for the stars of Yahoo!'s next ad campaign!<br>
&gt; http://advision.webevents.yahoo.com/yahoo/votelifeengine/<br>
&gt; <br>
</tt></font>
<br>
<br><font size=3D2 face=3D"sans-serif">- James M Snell<br>
 &nbsp;jasnell@us.ibm.com<br>
 &nbsp;http://www.ibm.com<br>
 &nbsp;(877) 511-5082 / Office<br>
 &nbsp;930-1979 / Tie Line</font>
<br>
--=_alternative 007E9A5488256ED7_=--

---------z16497_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIIUOAIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIISWDCCAtow
ggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1
aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAy
MDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA629xc49NpAPz
cAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7glzJKgPkPzlTZZfznznGbmAWVnNBQ
lyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnwNclOnnP2sKufuPzbTImQTTi5c8JZNZcM
J0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEEBAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1Ud
DgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAPBgNVHRMBAf8EBTADAQH/MDEGA1UdJQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUH
AwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvu
jQupk2oCScMd3FIHLE7hOfu8YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14ke
McF9ViNdewEoBGiAycUq8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIC2jCCAkOgAwIB
AgIDAxS2MA0GCSqGSIb3DQEBBAUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwMTE0MjIw
NzExWhcNMTExMjMxMjIwNzExWjBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25h
bCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrb3Fzj02kA/NwCy5KFMiY
tFgyTJ6kMSQLVSs9uwVHIAVkqy/enDQwZ9b/7uCXMkqA+Q/OVNll/OfOcZuYBZWc0FCXI9qw60KO
J/rTd65FdF4dwp8cw8si0qjOJtYg8cm46fA1yU6ec/awq5+4/NtMiZBNOLlzwlk1lwwnRgXNNwID
AQABo4GqMIGnMBEGCWCGSAGG+EIBAQQEAwIAhzAOBgNVHQ8BAf8EBAMCAcYwHQYDVR0OBBYEFK5U
DpLqqDOpKyQtx8hvMNze80pAMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMA8GA1Ud
EwEB/wQFMAMBAf8wMQYDVR0lBCowKAYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYB
BQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAMnJ7c2YLyrY/PKlFl+7sm8NENfWtFxqdm+6NC6mTagJJ
wx3cUgcsTuE5+7xh9+/G0tTfLzA1qZAQ5GNMPXvmoB9+vJfKnC2JWMFQpIOUEJDXiR4xwX1WI117
ASgEaIDJxSrxHcuuV/hMIO9bgZ6C41MUVmdLTKBgBOImTuIPK8QwggMgMIICiaADAgECAgQ13vTP
MA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQL
EyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0MTUxWhcN
MTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMk
RXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKKlQRkrPFr
U18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkwrFEeO68r
1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOgYaRfMF0x
CzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBD
ZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAxODA4MjIx
NjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAdBgNV
HQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0HQQAEDTAL
GwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwlMQ0AppJu
f7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn00DbOyZY
sih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMgMIICiaADAgEC
AgQ13vTPMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0
MTUxWhcNMTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsG
A1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKK
lQRkrPFrU18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkw
rFEeO68r1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOg
YaRfMF0xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNl
Y3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAx
ODA4MjIxNjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAdBgNVHQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0H
QQAEDTALGwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwl
MQ0AppJuf7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn
00DbOyZYsih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMmMIIC
j6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIxNjM2NTRaMIGFMQsw
CQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEXMBUGA1UEAxMOSmFt
ZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkqhkiG9w0BCQEWEmph
c25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwKpbDG3zMatEuuOT
FYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSyd+7nwqAvbBfPj+0S
vcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7tBJlLrwDRCMoNlPuQ
Kg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQW
BBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOgFAwSamFzbmVs
bEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pAMCcGA1UdJQQgMB4G
CCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAZMKevB7dFfb9
23OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY8BjwVHxiYgG4xkxf
B1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOIzj3lz3xd+uOzqRFg
/Wsg/VMwggMmMIICj6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAy
BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNV
BAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIx
NjM2NTRaMIGFMQswCQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEX
MBUGA1UEAxMOSmFtZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkq
hkiG9w0BCQEWEmphc25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
wKpbDG3zMatEuuOTFYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSy
d+7nwqAvbBfPj+0SvcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7t
BJlLrwDRCMoNlPuQKg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQD
AgXgMB0GA1UdDgQWBBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcU
AgOgFAwSamFzbmVsbEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA
MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQAD
gYEAZMKevB7dFfb923OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY
8BjwVHxiYgG4xkxfB1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOI
zj3lz3xd+uOzqRFg/Wsg/VMxggG7MIIBtwIBATBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJ
bnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0g
Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwF+kzAJBgUrDgMCGgUAoIGiMBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDcyMDIzMDI1MVowIwYJKoZIhvcNAQkEMRYE
FB+Duvn2nveMjr4lApkr0Ullrk00MEMGCSqGSIb3DQEJDzE2MDQwBwYFKw4DAh0wDgYIKoZIhvcN
AwICAgCAMAoGCCqGSIb3DQMHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGABkPsg0lC
G3FCis+3Ozwc0nO1Q/dy7lrWnmg1kx9csmRr7srpr862V+S3iJj75ZuGsqQBZOGDzTKDVOXVS4wm
WKdogkAQN1NLrr7uXgEbYV6VQJ6mvfKcDZ4lOFTLU2dHULJMsHddSZRJIgMFFoBjrt2IR9Aq0pXI
ErT9otqayusAAAAA

---------z16497_boundary_sign--



From owner-atom-syntax@mail.imc.org  Tue Jul 20 19:23: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 TAA28319
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 19:23: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 i6KNEAhS001134;
	Tue, 20 Jul 2004 16:14: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 i6KNEA0R001133;
	Tue, 20 Jul 2004 16:14: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 i6KNE9XC001126
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 16:14: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 A8C1A7C115; Wed, 21 Jul 2004 02:11:02 +0200 (CEST)
Date: Wed, 21 Jul 2004 01:17:46 +0200
To: "Sascha Carlin" <sc@itst.org>
Subject: Re: Those dates again
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <opsbgih6u4uvpchu@quark> <40FDA159.507@itst.org>
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: <opsbglnwmfuvpchu@quark>
In-Reply-To: <40FDA159.507@itst.org>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Wed, 21 Jul 2004 00:48:57 +0200, Sascha Carlin <sc@itst.org> wrote:

> What does Display mean?

Sam Ruby introduced the 'Display date' term[1] and explained it as:

   Date 2: Display

   This date is effectively a user entered date. It means whatever the
   user wants it to mean. It can be fictitious, it can be in the future.
   It can even be fanciful (Samuel Pepsys comes to mind).

   This date is effectively part of the content. Accordingly, if the
   display timestamp changes, the updated timestamp should also change.

   We could define it as a string, but an ability to internationalize
   and search on this field is desirable. One would rarely sort on this
   field. Having an ability to express perceived relative local time in
   this field is also desirable.

> Created seems to me to be important for use inside the application the  
> entry is created in/from.

Sure. For archives, it's probably also important, but I'm not sure it's  
necessary to require the date, because it's not very useful in most cases,  
if the provided 'issued' and 'modified' are (as) objective and reliable  
(as can be).

> An editor could be presented with a view of all entries created in a
> certain period of time to see how old a piece information really is.

Yes, it's an useful date, but probably nothing it's worth requiring in all  
Atom entries. I'm not sure about this, though. If there is a strong use  
case of the date, I have no problems with requiring it, since it's just as  
easy to provide this date as 'issued'. Basically: the more (factual)  
dates, the merrier.

____
[1] <url: http://www.imc.org/atom-syntax/mail-archive/msg06946.html>

-- 
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 Jul 20 19:27: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 TAA29039
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 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 i6KNHecg001312;
	Tue, 20 Jul 2004 16:17:40 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6KNHecQ001311;
	Tue, 20 Jul 2004 16:17:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KNHdk8001284
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 16:17:40 -0700 (PDT)
	(envelope-from asbjorn@tigerstaden.no)
Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19])
	by smtpgateway.itweb.no (Postfix) with ESMTP
	id D64237C115; Wed, 21 Jul 2004 02:14:33 +0200 (CEST)
To: davep@dpawson.co.uk
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: a methodical approach to defining what date  elements we need
References: <14B72756-D419-11D8-9D0B-003065EA6144@geckotribe.com>  <40F2C2CD.9020307@intertwingly.net>  <47071860-D42A-11D8-82B1-000A95DC3D90@mac.com>  <opsa1nlh1u6dxgxk@mail.online.no>  <6C2098C54ED33AE163D3E2F5@adsl-64-166-133-244.dsl.snfc21.pacbell.net>  <opsa3eddg8uvpchu@quark> <1089832992.2849.16.camel@homer>  <opsa5bya0ruvpchu@quark> <1089915775.2692.38.camel@homer>
Message-ID: <opsbglttgcuvpchu@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: Wed, 21 Jul 2004 01:21:19 +0200
In-Reply-To: <1089915775.2692.38.camel@homer>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Thu, 15 Jul 2004 19:22:56 +0100, Dave Pawson <davep@dpawson.co.uk>  
wrote:

> Yes. I'm saying that the 'tools' to generate such a 'full' date may
> not be to hand, which makes it harder to produce valid content.
> If I look at the computer clock, and can type the date/time, I'll maybe
> do it. If its hassle, its unlikely to be done at all.

That's why users shouldn't do this at all. The tools should provide the  
dates that are useful for other tools. Users MAY provide dates that are  
useful to other users, but I see this as an absolute non-requirement.

-- 
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 Jul 20 19:41:58 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02145
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 19:41: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 i6KNUfSk002353;
	Tue, 20 Jul 2004 16: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 i6KNUfKX002352;
	Tue, 20 Jul 2004 16:30:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from dd1516.kasserver.com (dd1516.kasserver.com [81.209.148.207])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KNUeHK002345
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 16:30:41 -0700 (PDT)
	(envelope-from sc@itst.org)
Received: from [192.168.1.10] (p50816BF0.dip0.t-ipconnect.de [80.129.107.240])
	by dd1516.kasserver.com (Postfix) with ESMTP id D63BF2C5294
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 01:30:44 +0200 (CEST)
Message-ID: <40FDAB97.8050401@itst.org>
Date: Wed, 21 Jul 2004 01:32:39 +0200
From: Sascha Carlin <sc@itst.org>
User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707)
X-Accept-Language: de, en
MIME-Version: 1.0
To: atom-syntax@imc.org
Subject: Re: Those dates again
References: <opsbgih6u4uvpchu@quark> <40FDA159.507@itst.org> <opsbglnwmfuvpchu@quark>
In-Reply-To: <opsbglnwmfuvpchu@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:

> Sam Ruby introduced the 'Display date' term[1] and explained it as:
[snip]

Ok, thanks. On the client side this could also be used to mark an entry 
as 'read on a certain date'. Cool thing ;)


> Yes, it's an useful date, but probably nothing it's worth requiring in 
> all  Atom entries. I'm not sure about this, though. If there is a strong 
> use  case of the date, I have no problems with requiring it, since it's 
> just as  easy to provide this date as 'issued'. Basically: the more 
> (factual)  dates, the merrier.

Created != Issued, but for many applications this would suffice. But 
even now most CMS have the ability to mark an entry as 'Draft' resp. 
'Not published yet'. So you create content, proof read and then issue 
it. Later you modify and/or update it and at some point users read it 
(see Display above).

Hmm... Shouldn't we make a distinction here, too? Modified means just 
cleaning up, fixing errors, and Updated means really updating the 
content to represent current information.

Required dates should be Issued and Modified (these do suffice for most 
use cases), but I strongly hope, coming from an IA/LS background, that 
the other dates including Modified/Updated will be there, too - so that 
people who need this information can have it without breaking the standard.

Regards, Sascha

-- 
Sascha Carlin * Heinrich-Heine-Str. 1 * 64319 Pfungstadt
http://www.itst.org/         **         +49 6157 157 205



From owner-atom-syntax@mail.imc.org  Tue Jul 20 19:44: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 TAA02823
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 19:44: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 i6KNX28i002456;
	Tue, 20 Jul 2004 16:33: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 i6KNX2cU002455;
	Tue, 20 Jul 2004 16:33:02 -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 i6KNX1Yk002449
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 16:33:01 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040720233302.11120.qmail@web41215.mail.yahoo.com>
Received: from [131.107.3.70] by web41215.mail.yahoo.com via HTTP; Tue, 20 Jul 2004 16:33:02 PDT
Date: Tue, 20 Jul 2004 16:33:02 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Those dates again
To: "Asbjørn_Ulsberg" <asbjorn@tigerstaden.no>, Sascha Carlin <sc@itst.org>
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <opsbglnwmfuvpchu@quark>
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>


--- Asbjørn_Ulsberg <asbjorn@tigerstaden.no> wrote:
> 
> On Wed, 21 Jul 2004 00:48:57 +0200, Sascha Carlin
> <sc@itst.org> wrote:
> 
> > What does Display mean?
> 
> Sam Ruby introduced the 'Display date' term[1] and
> explained it as:
> 
>    Date 2: Display

On pressing Sam about this date I seem to remember he
eventually described it as being akin to issued. If
issued and modified are in the feed I can't see any
reason why an aggregator would need some fictitious
and bogus additional date. 

The main point of contention seems to be that some
people felt that 'issued' is to formal a term to
define what is meant by 'user entered publish date in
some CMS' so they wanted a fourth date field to
capture this semantic. 

I think this is an unnecessary distinction. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
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 Jul 20 19: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 TAA03936
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 19:51: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 i6KNecMd002896;
	Tue, 20 Jul 2004 16: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 i6KNecuH002895;
	Tue, 20 Jul 2004 16: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 ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KNebHs002887
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 16:40: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 22E077C115; Wed, 21 Jul 2004 02:37:31 +0200 (CEST)
Date: Wed, 21 Jul 2004 01:44:21 +0200
To: "Norman Walsh" <ndw@nwalsh.com>
Subject: Re: atom:created same as atom:modified?
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <200407191919.PAA17914@ietf.org> <87pt6rslub.fsf@nwalsh.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: <opsbgmv70buvpchu@quark>
In-Reply-To: <87pt6rslub.fsf@nwalsh.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Mon, 19 Jul 2004 17:55:56 -0400, Norman Walsh <ndw@nwalsh.com> wrote:

> I would have expected it to be the same as atom:issued. I'm not sure
> either is really the obviously correct answer. Is there value in
> providing a default if it isn't specified?

Not really, imho. I thought we were slowly but steadily moving away from  
default values. If so, this is one of the default values we should get rid  
of. If something's missing, it's... Missing. Null. Nothing. Zip. Zilch.  
Nothing else.

-- 
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 Jul 20 20:02: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 UAA06041
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 20:02: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 i6KNrGRv004449;
	Tue, 20 Jul 2004 16: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 i6KNrGBQ004448;
	Tue, 20 Jul 2004 16:53:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KNrFbh004395
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 16:53: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 DAB277C115; Wed, 21 Jul 2004 02:50:08 +0200 (CEST)
Date: Wed, 21 Jul 2004 01:57:01 +0200
To: "Dare Obasanjo" <kpako@yahoo.com>
Subject: Re: Those dates again
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <20040720233302.11120.qmail@web41215.mail.yahoo.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: <opsbgnhbj9uvpchu@quark>
In-Reply-To: <20040720233302.11120.qmail@web41215.mail.yahoo.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Tue, 20 Jul 2004 16:33:02 -0700 (PDT), Dare Obasanjo <kpako@yahoo.com>  
wrote:

>> Date 2: Display
>
> On pressing Sam about this date I seem to remember he
> eventually described it as being akin to issued.

I think that would depend heavily on what the subjective date is used for.  
If it's a «publish this entry in the future» mechanism, I agree, but if  
it's a fictional, random, totally unreliable date, I don't.

If the subjective date is altered by the user to make the entry appear  
before another on his HTML front page (this is how Movable Type works,  
btw), it's not 'issued', but a sorting mechanism. If the subjective date  
is edited or altered by the user because she actually meant to publish the  
entry two hours earlier, that's not 'issued', since 'issued' is formal.  
Formal is factual. Factual dates shouldn't lie.

If the subjective date is hacked by the user to assert something like  
«Noon on Wednesday», it is not 'issued'. If 'issued' is displayed as «Noon  
on Wednesday» that's not up to the author, but to the reader. The format  
of 'issued' should be ISO-8601 and not an arbitrary string.

E.g., I can't agree that 'Display' is 'issued', at least not for all uses  
of 'Display' or other subjective dates.

> If issued and modified are in the feed I can't see any
> reason why an aggregator would need some fictitious
> and bogus additional date.

I agree, other than that if 'Issued' is allowed (by not saying otherwise  
in the specification) to be subjective and bogus, we really just have  
'Modified' as a reliable date. Only that Movable Type lets the user alter  
'Modified' as well, of course. So, basically, we have _no_ reliable dates  
today. I think this should be fixed.

> The main point of contention seems to be that some
> people felt that 'issued' is to formal a term to
> define what is meant by 'user entered publish date in
> some CMS' so they wanted a fourth date field to
> capture this semantic.

True.

> I think this is an unnecessary distinction.

In a strict publishing sence, the distinction is very important, as I try  
to explain in my 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  Tue Jul 20 20: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 UAA06080
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 20:02: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 i6KNkkMm003169;
	Tue, 20 Jul 2004 16: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 i6KNkkfr003168;
	Tue, 20 Jul 2004 16:46: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 i6KNkjdj003161
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 16:46: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 1Bn4Ji-0006Oy-OJ; Tue, 20 Jul 2004 23:46:38 +0000
Message-ID: <40FDAEE0.7020807@franklinmint.fm>
Date: Tue, 20 Jul 2004 19:46:40 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dare Obasanjo <kpako@yahoo.com>
CC: =?ISO-8859-1?Q?Asbj=F8rn=5FUlsberg?= <asbjorn@tigerstaden.no>,
        Sascha Carlin <sc@itst.org>, Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Those dates again
References: <20040720233302.11120.qmail@web41215.mail.yahoo.com>
In-Reply-To: <20040720233302.11120.qmail@web41215.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 main point of contention seems to be that some
>people felt that 'issued' is to formal a term to
>define what is meant by 'user entered publish date in
>some CMS' so they wanted a fourth date field to
>capture this semantic. 
>
>I think this is an unnecessary distinction. 
>  
>
+1

Robert Sayre



From owner-atom-syntax@mail.imc.org  Tue Jul 20 20: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 UAA06277
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 20: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 i6KNqmaF004371;
	Tue, 20 Jul 2004 16:52: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 i6KNqmwX004370;
	Tue, 20 Jul 2004 16:52: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 [18.29.0.30])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KNqmO3004357;
	Tue, 20 Jul 2004 16:52:48 -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 3DEB64F043;
	Tue, 20 Jul 2004 19:52:32 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040721084829.05cc14c0@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Wed, 21 Jul 2004 08:49:50 +0900
To: Greg Stein <gstein@google.com>, Paul Hoffman / IMC <phoffman@imc.org>
From: Martin Duerst <duerst@w3.org>
Subject: Re: Cancelling the WG meeting in San Diego
Cc: Atom WG <atom-syntax@imc.org>
In-Reply-To: <20040720225522.GA28724@google.com>
References: <p0611041cbd230570fce9@[10.20.30.249]>
 <p0611041cbd230570fce9@[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 15:55 04/07/20 -0700, Greg Stein wrote:

>Steve Jenson and I are planning to be there for the meeting. It would be a
>pain in the butt to spend that time/money to go there and NOT have a
>meeting.

+1

It's not the only reason I'm going to the IETF, but for those who
are going, canceling the meeting after they have booked their flight
and registered and paid the cheaper advanced fee may lead to
serious problems.

Regards,    Martin.

>-g
>
>On Tue, Jul 20, 2004 at 10:28:58AM -0700, Paul Hoffman / IMC wrote:
> >
> > Greetings again. After my earlier query asking who was going to be in
> > San Diego, I only got two responses. Even if that was off by a factor
> > of ten, it seems that having a face-to-face meeting in San Diego
> > might not help the WG move forwards, but would cost a lot of people a
> > lot of time and money. As I have said before, the purpose of the
> > face-to-face meetings is to do things that can't be done on the
> > mailing list, but it seems like the mailing list is doing quite well
> > and few of the active participants want to go to San Diego.
> >
> > Tim and I propose that we cancel the WG meeting and just keep doing
> > the good work we are doing here. At the same time, Tim and I will be
> > giving a presentation about Atompub at the Applications Area meeting
> > at the IETF (in the Monday morning time slot). That presentation
> > should generate more participation from IETF regulars who have dealt
> > with some of the same issues we are dealing with now.
> >
> > If this potential cancellation is a major concern to anyone, please
> > speak up now, or send Tim or me off-line mail. Thanks!
> >
> > --Paul Hoffman, Director
> > --Internet Mail Consortium
> >



From owner-atom-syntax@mail.imc.org  Tue Jul 20 20:08: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 UAA06971
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 20:08: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 i6KNrceZ004482;
	Tue, 20 Jul 2004 16:53:38 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6KNrcBS004481;
	Tue, 20 Jul 2004 16:53:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web41205.mail.yahoo.com (web41205.mail.yahoo.com [66.218.93.38])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6KNrcKL004457
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 16:53:38 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040720235335.14051.qmail@web41205.mail.yahoo.com>
Received: from [207.46.238.137] by web41205.mail.yahoo.com via HTTP; Tue, 20 Jul 2004 16:53:35 PDT
Date: Tue, 20 Jul 2004 16:53:35 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Those dates again
To: Sascha Carlin <sc@itst.org>, atom-syntax@imc.org
In-Reply-To: <40FDAB97.8050401@itst.org>
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>


--- Sascha Carlin <sc@itst.org> wrote:
> 
> Ok, thanks. On the client side this could also be
> used to mark an entry 
> as 'read on a certain date'. Cool thing ;)

How? I'm an aggregator author and I'm unsure how or
why I'd use this field in a feed to determine what
date the item was read [or why keeping track of this
is relevant]. 
 
 
> Hmm... Shouldn't we make a distinction here, too?
> Modified means just 
> cleaning up, fixing errors, and Updated means really
> updating the 
> content to represent current information.

As pointed out the last time somebody brought this up.
Exactly what is the quantitative difference between
'fixing errors' and 'updating the content to represent
current information'? Is software supposed to
determine this programatically or is this something
the author of the piece does? Why exactly should the
date-last-typo-was-fixed and
date-lat-major-revision-was-made be treated
differently by a client consuming the feed as opposed
to processing last-modified-date? 
 
> Required dates should be Issued and Modified (these
> do suffice for most 
> use cases), but I strongly hope, coming from an
> IA/LS background, that 
> the other dates including Modified/Updated will be
> there, too - so that 
> people who need this information can have it without
> breaking the standard.

What does breaking the standard mean?  

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
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 Jul 20 20:10: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 UAA07202
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 20:10:01 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6KNw2tm004961;
	Tue, 20 Jul 2004 16:58: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 i6KNw2te004960;
	Tue, 20 Jul 2004 16:58: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 i6KNw1XJ004953
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 16:58:01 -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 1Bn4Ul-0006wU-9Y; Tue, 20 Jul 2004 23:58:03 +0000
Message-ID: <40FDB18C.9050303@franklinmint.fm>
Date: Tue, 20 Jul 2004 19:58:04 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: John Panzer <jpanzer@aol.net>
CC: Ken MacLeod <ken@bitsko.slc.ut.us>, Atom Syntax <atom-syntax@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <3f1451f504072008533002b6f4@mail.gmail.com> <40FD4233.7040101@franklinmint.fm> <40FD4569.4070401@intertwingly.net> <40FD481A.40009@franklinmint.fm> <98DE9BC4-DA6D-11D8-92AF-000A95A51C9E@sun.com> <40FD52E2.5010606@intertwingly.net> <40FD5537.2080500@franklinmint.fm> <3f1451f5040720104134622441@mail.gmail.com> <40FD5B45.2030202@franklinmint.fm> <m3hds2blgm.fsf@bitsko.slc.ut.us> <40FD6538.7020301@AOL.NET> <m3d62qbic3.fsf@bitsko.slc.ut.us> <40FD887C.5010909@AOL.NET>
In-Reply-To: <40FD887C.5010909@AOL.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


John Panzer wrote:

>Ken MacLeod wrote on 7/20/2004, 12:15 PM:
>
> >
> > "John Panzer" <jpanzer@aol.net> writes:
> >
> > > I believe that one rationale for separating the EditURI and "public"
> > > GETable URI for Atom entries is that the two may have different
> > > content representations, e.g., for Wiki text that maps to publicly
> > > viewable HTML.  Is there a use case for this in the case of binary
> > > resources?  That's about the only reason I can think of for a
> > > publishing system _not_ making the URIs the same.
> >
> > Use Case #1: Serving static files from the web server directly.  The
> > benefits are many: proper headers, performance, no locking on large
> > requests (PCGI is single threaded, for example), etc.
>
>(Aside: Should we be worried about optimizing the performance of CGI 
>based servers?)  I think this is a valid point, but it might be an edge 
>case (most servers capable of high volume static file GET requests can 
>fairly easily shunt low volume PUT/DELETE requests to other code, IMHO.)**
>  
>

The MetaWeblog API's newMediaObject[0] endpoint works with CGI, but it 
has problems when it comes to PUTing and DELETEing resources and it 
requires base64. Existing software expects this functionality. We should 
provide it and improve obvious deficiencies of current approaches.

Robert Sayre

[0] http://www.xmlrpc.com/metaWeblogApi#metaweblognewmediaobject



From owner-atom-syntax@mail.imc.org  Tue Jul 20 20:12: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 UAA07477
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 20:12: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 i6L04I5A005501;
	Tue, 20 Jul 2004 17:04: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 i6L04ITC005500;
	Tue, 20 Jul 2004 17:04: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 i6L04Hir005491
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 17:04: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 5D82E7C115; Wed, 21 Jul 2004 03:01:11 +0200 (CEST)
Date: Wed, 21 Jul 2004 02:08:06 +0200
To: "Sascha Carlin" <sc@itst.org>
Subject: Re: Those dates again
References: <opsbgih6u4uvpchu@quark> <40FDA159.507@itst.org> <opsbglnwmfuvpchu@quark> <40FDAB97.8050401@itst.org>
Cc: Atom-Syntax <atom-syntax@imc.org>
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: <opsbgnzsfhuvpchu@quark>
In-Reply-To: <40FDAB97.8050401@itst.org>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Wed, 21 Jul 2004 01:32:39 +0200, Sascha Carlin <sc@itst.org> wrote:

>> Sam Ruby introduced the 'Display date' term[1] and explained it as:
> [snip]
>
> Ok, thanks. On the client side this could also be used to mark an entry  
> as 'read on a certain date'. Cool thing ;)

That depends on what the format of the element is, eventually.

> Created != Issued, but for many applications this would suffice.

Yes, the distinction isn't very important, but as most tools has both an  
'save' and 'publish' action, both of these actions can be time-stamped and  
saved in a database.

> But even now most CMS have the ability to mark an entry as 'Draft' resp.  
> 'Not published yet'.

Movable Type has all the proper actions but still only offer one  
user-alterable date. I really wonder why.

> So you create content, proof read and then issue it. Later you modify
> and/or update it and at some point users read it (see Display above).

Yup. This is what I think as well, and what most big CMS's does today.  
They offer an objective 'Created', 'Issued' and 'Modified'. Some also have  
'Available' fields which one can enter a timespan the article should be  
available to and from. No 'Display' date, though. Everything is objective,  
factual and reliable.

> Hmm... Shouldn't we make a distinction here, too? Modified means just  
> cleaning up, fixing errors, and Updated means really updating the  
> content to represent current information.

No, not really. If you want to distinguish minor from major modifications,  
you should rather implement something like supersedes, where one entry  
supersedes another. If you want advanced functionality, you should imho  
implement somewhat advanced mechanisms too. To supersede documents with  
new versions is the common practice almost everywhere, ranging from  
official documents, hospital journals, internet standards, USENET, book  
publishing, and so on.

> Required dates should be Issued and Modified (these do suffice for most  
> use cases), but I strongly hope, coming from an IA/LS background, that  
> the other dates including Modified/Updated will be there, too - so that  
> people who need this information can have it without breaking the  
> standard.

Supporting supersedes is really very simple. Most advanced CMS's support  
versioning already. Supporting the supersede mechanism in Atom itself, is  
100% optional for both comsumers and producers. This pace is a concrete  
proposal of a supersede mechanism, implemented with the Dublin Core  
element <relation>:

<url: http://intertwingly.net/wiki/pie/PaceIssuedAndRelation>

-- 
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 Jul 20 20:18: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 UAA08981
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 20:18: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 i6L06cUp005707;
	Tue, 20 Jul 2004 17:06: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 i6L06cnu005703;
	Tue, 20 Jul 2004 17:06:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from vspmail.nscp.aoltw.net (h-64-236-139-249.aoltw.net [64.236.139.249])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6L06cbw005680
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 17:06:38 -0700 (PDT)
	(envelope-from jpanzer@AOL.NET)
Received: from h-10-169-146-121.nscp.aoltw.net (h-10-169-146-121.nscp.aoltw.net [10.169.146.121])
	by vspmail.nscp.aoltw.net (8.11.6/8.11.6) with ESMTP id i6L0Brs01796
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 17:11:53 -0700
Date: Tue, 20 Jul 2004 17:06:40 -0700
From: "John Panzer" <jpanzer@aol.net>
Subject: Re: Cancelling the WG meeting in San Diego
To: "Atom WG" <atom-syntax@imc.org>
In-Reply-To: <20040720225522.GA28724@google.com>
Message-ID: <40FDB390.60607@AOL.NET>
References: <p0611041cbd230570fce9@[10.20.30.249]> <20040720225522.GA28724@google.com>
X-Mailer: AOL Communicator (20030919.3 Win)
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>


I'm planning to be there for the meeting; I think it would be useful 
(well, assuming enough other people show up!).

-John Panzer

Greg Stein wrote on 7/20/2004, 3:55 PM:

 >
 > Steve Jenson and I are planning to be there for the meeting. It would
 > be a
 > pain in the butt to spend that time/money to go there and NOT have a
 > meeting.
 >
 > -g
 >
 > On Tue, Jul 20, 2004 at 10:28:58AM -0700, Paul Hoffman / IMC wrote:
 > >
 > > Greetings again. After my earlier query asking who was going to be in
 > > San Diego, I only got two responses. Even if that was off by a factor
 > > of ten, it seems that having a face-to-face meeting in San Diego
 > > might not help the WG move forwards, but would cost a lot of people a
 > > lot of time and money. As I have said before, the purpose of the
 > > face-to-face meetings is to do things that can't be done on the
 > > mailing list, but it seems like the mailing list is doing quite well
 > > and few of the active participants want to go to San Diego.
 > >
 > > Tim and I propose that we cancel the WG meeting and just keep doing
 > > the good work we are doing here. At the same time, Tim and I will be
 > > giving a presentation about Atompub at the Applications Area meeting
 > > at the IETF (in the Monday morning time slot). That presentation
 > > should generate more participation from IETF regulars who have dealt
 > > with some of the same issues we are dealing with now.
 > >
 > > If this potential cancellation is a major concern to anyone, please
 > > speak up now, or send Tim or me off-line mail. Thanks!
 > >
 > > --Paul Hoffman, Director
 > > --Internet Mail Consortium
 > >
 >




From owner-atom-syntax@mail.imc.org  Tue Jul 20 20:18: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 UAA09018
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 20:18: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 i6L08iGa005857;
	Tue, 20 Jul 2004 17:08: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 i6L08iCD005856;
	Tue, 20 Jul 2004 17:08:44 -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 i6L08iqO005847
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 17:08: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 (rwcrmhc13) with SMTP
          id <20040721000844015003g24ue>; Wed, 21 Jul 2004 00:08:44 +0000
Date: Tue, 20 Jul 2004 18:08:43 -0600
Subject: Re: PaceLinkConstruct issues & next steps
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: <3733B5B6-DA9B-11D8-BFCB-000A95A51C9E@sun.com>
Message-Id: <2078F2F7-DAAA-11D8-95E3-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, July 20, 2004, at 04:21  PM, Tim Bray wrote:
> As I look at the link-related discourse over the past few days, I 
> observe a striking lack of consensus around
> (a) whether it's useful to class or group links
> (b) if so, how this should be done
Agreed--no consensus is emerging.  At best, we're clarifying the 
division between the various opinions.  I suppose that progress of a 
sort.

> So, I think we should push this one back on the stack and ask Sam to 
> rotate the work queue.
+1

In preparation for the final round of discussion, I'd be interested in 
EVERYONE's opinion on one thing.  The discussion on the mail list has 
mostly been carried on by a small number of people, with occasional 
input from a slightly larger group.  I'd like to get a bigger picture 
of where everyone stands (whether you've had specific comments to add 
to the discussion or not) as a guide to one last effort at crafting a 
proposal.

Below is a list of proposals relevant to this discussion (sorry if I 
missed something important).  Could ANY/EVERYONE who cares put these 
roughly in order of how well you like them (best first, worst 
last--note that they are not all mutally exclusive) and email them 
either to the list or to me directly.  (If you email directly to me, 
please leave "PaceLinkConstruct" in the subject--that will ensure that 
your message gets through my SPAM filter).  If there are small details 
in a proposal that you disagree with, but you like the overall 
philosophy behind that, please don't let the small details move it to 
the bottom of your list.

# PaceExtensionNamespace - divide up link/@rel values between Link, 
Service, and Embed Constructs, and give each element its own name. 
Construct types to be regonizable by the presence of a particular 
attribute. (no @rel - extensible outside the Atom core).

# PaceLinkPurpose - tighten the scope of what can go into the link 
element--anything not fitting that scope has to go to some other 
element (keeps @rel - could be extensible, but doesn't specify how)

# PacePersonLinks - replace <url> in Person Constructs with <link>, 
using a variety of @rel values (doesn't comment on extensibility 
outside of the core)

# PaceReplaceLinkElement - replace link/@rel with a number of elements 
(no apparent extensibility outside the core)

# PaceLinkConstruct - use @rel and @rev with a longer list of values 
(fixed list of allowed values -- thus not extensible outside the core)

# PaceLinkAttrDefaults - make "alternate" the default @rel, and make 
@type optional (doesn't comment on extensibility outside of the core)

# PaceUseBrokenLinkSyntaxEverywhere - Not only keep @rel for link, but 
also use it in person and date constructs (doesn't comment on 
extensibility outside of the core)

# PaceLinkRelMechanism - use qnames in @rel for links defined in 
extensions (thus, extensible)

Note: the preceding list is in my approximate order of liking.  I won't 
be put out if you put them in the opposite order--rather I'll be glad 
that you educated me on your point of view.  I'll likewise be glad to 
hear from people who generally agree with this order so that I'll know 
I'm not along.

Thanks all,

Antone



From owner-atom-syntax@mail.imc.org  Tue Jul 20 20:30:43 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11340
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 20:30:42 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6L0Imlx006964;
	Tue, 20 Jul 2004 17: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 i6L0ImPq006963;
	Tue, 20 Jul 2004 17:18:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6L0IlJi006957
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 17:18:47 -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 i6L0Ge53018501
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 18:16:40 -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 <0I1600C6OE7GXV@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Tue, 20 Jul 2004 18:18:52 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.45])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I1600CBME7FE4@mail.sun.net> for atom-syntax@imc.org; Tue,
 20 Jul 2004 18:18:52 -0600 (MDT)
Date: Tue, 20 Jul 2004 17:19:00 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Those dates again
In-reply-to: <20040720233302.11120.qmail@web41215.mail.yahoo.com>
To: Dare Obasanjo <kpako@yahoo.com>
Cc: =?ISO-8859-1?Q?Asbj=F8rn=5FUlsberg?= <asbjorn@tigerstaden.no>,
        Sascha Carlin <sc@itst.org>, Atom-Syntax <atom-syntax@imc.org>
Message-id: <9041A008-DAAB-11D8-BF7F-000A95A51C9E@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.618)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
References: <20040720233302.11120.qmail@web41215.mail.yahoo.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6L0ImJi006958
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 Jul 20, 2004, at 4:33 PM, Dare Obasanjo wrote:

> The main point of contention seems to be that some
> people felt that 'issued' is to formal a term to
> define what is meant by 'user entered publish date in
> some CMS' so they wanted a fourth date field to
> capture this semantic.

I'm not sure.  The "display" date is well-understood, implemented by 
running code @ liveJournal & other places, and easily explained by the 
analogy of the travel journal - the entry for the 8th is the entry for 
the 8th, regardless of when it was created/updated.

"Issued" is a can of worms.  Asbjørn has a very specific semantic in 
mind, joined at the hip to the notion of update-by-replacement, tuned 
to the needs of a particular publishing application.  Other voices on 
this subject are less precise in what they mean, but it's pretty clear 
they mean different things. -Tim




From owner-atom-syntax@mail.imc.org  Tue Jul 20 20:41: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 UAA13049
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 20:41: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 i6L0UaBE008041;
	Tue, 20 Jul 2004 17:30: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 i6L0Ua6a008040;
	Tue, 20 Jul 2004 17:30:36 -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 i6L0Uabf008030;
	Tue, 20 Jul 2004 17:30:36 -0700 (PDT)
	(envelope-from danbri@w3.org)
Received: by homer.w3.org (Postfix, from userid 13522)
	id D54504F06C; Tue, 20 Jul 2004 20:30:41 -0400 (EDT)
Date: Tue, 20 Jul 2004 20:30:41 -0400
From: Dan Brickley <danbri@w3.org>
To: Paul Hoffman / IMC <phoffman@imc.org>
Cc: Atom WG <atom-syntax@imc.org>
Subject: Re: Cancelling the WG meeting in San Diego
Message-ID: <20040721003041.GG20353@homer.w3.org>
References: <p0611041cbd230570fce9@[10.20.30.249]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <p0611041cbd230570fce9@[10.20.30.249]>
User-Agent: Mutt/1.5.6+20040523i
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>


slight tangent, but do IETF WGs have phone conference, IRC/Jabber etc
meetings at all?

Dan



From owner-atom-syntax@mail.imc.org  Tue Jul 20 20: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 UAA13533
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 20: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 i6L0Xost008218;
	Tue, 20 Jul 2004 17:33:50 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6L0Xoao008217;
	Tue, 20 Jul 2004 17:33:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from dd1516.kasserver.com (dd1516.kasserver.com [81.209.148.207])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6L0XnhG008206
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 17:33:49 -0700 (PDT)
	(envelope-from sc@itst.org)
Received: from [192.168.1.10] (p50816BF0.dip0.t-ipconnect.de [80.129.107.240])
	by dd1516.kasserver.com (Postfix) with ESMTP id 4F4A12C5591
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 02:33:47 +0200 (CEST)
Message-ID: <40FDBA5D.1070103@itst.org>
Date: Wed, 21 Jul 2004 02:35:41 +0200
From: Sascha Carlin <sc@itst.org>
User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707)
X-Accept-Language: de, en
MIME-Version: 1.0
To: atom-syntax@imc.org
Subject: Re: Those dates again
References: <20040720235335.14051.qmail@web41205.mail.yahoo.com>
In-Reply-To: <20040720235335.14051.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: <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:

>>Hmm... Shouldn't we make a distinction here, too?
>>Modified means just 
>>cleaning up, fixing errors, and Updated means really
>>updating the 
>>content to represent current information.
> 
> As pointed out the last time somebody brought this up.
> Exactly what is the quantitative difference between
> 'fixing errors' and 'updating the content to represent
> current information'? Is software supposed to
> determine this programatically or is this something
> the author of the piece does? Why exactly should the
> date-last-typo-was-fixed and
> date-lat-major-revision-was-made be treated
> differently by a client consuming the feed as opposed
> to processing last-modified-date? 

Because of their semantically different meaning. Fixing a typo is 
something else than updating information. I admit this discussion is 
rather a side issue, but it has got its entitlement (Sorry for my bogus 
English, is this the correct term?).


> What does breaking the standard mean?  

Doing something the standard does not allow/offer?

Creating an extension for this special use cases (where we distinct 
Modified from Updated) could be a solution, as suggested in [1]. Or we 
could use supersedes, as suggested in [2].

 From my point of view, Atom should address this problem anyway. People 
are more and more talking about the Semantic Web, and Atom is a part of 
this greater entity. If we just come up with possibilities to express 
meta information we need and use /today/, we are not going any step 
forward - and make things even harder for our descendants.

So we should keep in mind that there are use cases we /now/ don't feel 
to be important.

Just my 2 cents, kind regards and good night for today, Sascha

[1] James, jasnell@us.ibm.com, Date: Tue, 20 Jul 2004 17:10:29 -0600
[2] Asbjorn, asbjorn@tigerstaden.no, Date: Wed, 21 Jul 2004 02:08:06 +0200

Sorry, these are not yet in the archive.

-- 
Sascha Carlin * Heinrich-Heine-Str. 1 * 64319 Pfungstadt
http://www.itst.org/         **         +49 6157 157 205



From owner-atom-syntax@mail.imc.org  Tue Jul 20 20:58:45 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15654
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 20:58:44 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6L0oRvl009906;
	Tue, 20 Jul 2004 17:50: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 i6L0oRZv009905;
	Tue, 20 Jul 2004 17:50:27 -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 i6L0oOTE009891;
	Tue, 20 Jul 2004 17:50:25 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p0611042bbd236d687331@[10.20.30.249]>
In-Reply-To: <40FDB390.60607@AOL.NET>
References: <p0611041cbd230570fce9@[10.20.30.249]>
 <20040720225522.GA28724@google.com> <40FDB390.60607@AOL.NET>
Date: Tue, 20 Jul 2004 17:51:07 -0700
To: "John Panzer" <jpanzer@aol.net>, "Atom WG" <atom-syntax@imc.org>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: Cancelling the WG meeting in San Diego
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 5:06 PM -0700 7/20/04, John Panzer wrote:
>I'm planning to be there for the meeting; I think it would be useful
>(well, assuming enough other people show up!).

The parenthetical is exactly the problem. It seems that fewer than 
ten currently-active people intend to come. Even if we were having 
problems with lack of momentum or intractable hurdles, I would say we 
would need twice that many to be useful. But we're not having such 
problems (yet!), so having people schlep to a meeting seems wasteful.

At 8:30 PM -0400 7/20/04, Dan Brickley wrote:
>slight tangent, but do IETF WGs have phone conference, IRC/Jabber etc
>meetings at all?

Phone conferences: no. IRC/Jabber: yes.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Tue Jul 20 20:58: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 UAA15672
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 20:58: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 i6L0lg72009734;
	Tue, 20 Jul 2004 17:47: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 i6L0lgxe009733;
	Tue, 20 Jul 2004 17:47: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 i6L0lfNj009727
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 17:47:41 -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 i6L0mbO3011673;
	Tue, 20 Jul 2004 20:48:38 -0400
Message-ID: <40FDBD31.4040008@intertwingly.net>
Date: Tue, 20 Jul 2004 20:47:45 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <Tim.Bray@Sun.COM>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Those dates again
References: <20040720233302.11120.qmail@web41215.mail.yahoo.com> <9041A008-DAAB-11D8-BF7F-000A95A51C9E@sun.com>
In-Reply-To: <9041A008-DAAB-11D8-BF7F-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:
> 
> On Jul 20, 2004, at 4:33 PM, Dare Obasanjo wrote:
> 
>> The main point of contention seems to be that some
>> people felt that 'issued' is to formal a term to
>> define what is meant by 'user entered publish date in
>> some CMS' so they wanted a fourth date field to
>> capture this semantic.
> 
> I'm not sure.  The "display" date is well-understood, implemented by 
> running code @ liveJournal & other places, and easily explained by the 
> analogy of the travel journal - the entry for the 8th is the entry for 
> the 8th, regardless of when it was created/updated.
> 
> "Issued" is a can of worms.  Asbjørn has a very specific semantic in 
> mind, joined at the hip to the notion of update-by-replacement, tuned to 
> the needs of a particular publishing application.  Other voices on this 
> subject are less precise in what they mean, but it's pretty clear they 
> mean different things. -Tim

Whatever the name are to be (and yes, names are important) my take is 
that there are two "core" dates.

The first is whatever LJ, TypePad, Blogger, JournURL and undoubtably 
countless others allow the end user to directly adjust.

The second is whatever was done over a dozen times to:
   http://www.tbray.org/ongoing/When/200x/2004/02/20/GenxStatus

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Tue Jul 20 21:03:38 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16295
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 21:03: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 i6L0tb8X010224;
	Tue, 20 Jul 2004 17: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 i6L0tb0R010223;
	Tue, 20 Jul 2004 17:55: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 i6L0taPQ010212
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 17:55: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 05EB07C115; Wed, 21 Jul 2004 03:52:26 +0200 (CEST)
Date: Wed, 21 Jul 2004 02:59:22 +0200
To: "Tim Bray" <Tim.Bray@sun.com>
Subject: Re: Those dates again
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <20040720233302.11120.qmail@web41215.mail.yahoo.com> <9041A008-DAAB-11D8-BF7F-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: <opsbgqc8pguvpchu@quark>
In-Reply-To: <9041A008-DAAB-11D8-BF7F-000A95A51C9E@sun.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Tue, 20 Jul 2004 17:19:00 -0700, Tim Bray <Tim.Bray@Sun.COM> wrote:

> I'm not sure.  The "display" date is well-understood, implemented by  
> running code @ liveJournal & other places, and easily explained by the  
> analogy of the travel journal - the entry for the 8th is the entry for  
> the 8th, regardless of when it was created/updated.

As long as we agree that the 'display' date has a close relation to the  
content (title) of the entry than the metadata (dates and such), and that  
it's not 'issued', I think it's well-understood.

> "Issued" is a can of worms.  Asbjørn has a very specific semantic in  
> mind, joined at the hip to the notion of update-by-replacement, tuned to  
> the needs of a particular publishing application.

'Issued' as 'First-Issued', and with Atom not supporting 'minor' and  
'major' modifications (without <relation> or something similar), my  
definition of 'Issued' is not joined at the hip with anything. The support  
for 'relation' as a supersede mechanism is totally orthogonal, detached  
and opt-in.

If we first define that 'atom:issued' MUST NOT change, we can define  
superseding mechanisms afterwards, if people need to distinguish minor  
 from major modifications. But Atom cannot support this by just altering  
'issued' in the entry, because that leaves 'issued' just as useless, or  
even more so, as it would be if it was a random user-entered 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  Tue Jul 20 21: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 VAA16805
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 21:05: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 i6L0rseC010096;
	Tue, 20 Jul 2004 17: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 i6L0rsdS010095;
	Tue, 20 Jul 2004 17:53:54 -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 i6L0rs5Y010087
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 17:53:54 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040721005354.24539.qmail@web41205.mail.yahoo.com>
Received: from [207.46.238.137] by web41205.mail.yahoo.com via HTTP; Tue, 20 Jul 2004 17:53:54 PDT
Date: Tue, 20 Jul 2004 17:53:54 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Those dates again
To: Tim Bray <Tim.Bray@Sun.COM>
Cc: "Asbjørn_Ulsberg" <asbjorn@tigerstaden.no>, Sascha Carlin <sc@itst.org>,
        Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <9041A008-DAAB-11D8-BF7F-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:
> On Jul 20, 2004, at 4:33 PM, Dare Obasanjo wrote:
>
> I'm not sure.  The "display" date is
> well-understood, implemented by 
> running code @ liveJournal & other places, and
> easily explained by the 
> analogy of the travel journal - the entry for the
> 8th is the entry for 
> the 8th, regardless of when it was created/updated.

No, it is not. Sam described the display date as a
date that can mean be some arbitrary value not just an
RFC 822 or ISO 8601 date. I haven't seen many tools
that allow you to enter '3 months from my birthday' as
a valid date. 

> "Issued" is a can of worms.  Asbjørn has a very
> specific semantic in 
> mind, joined at the hip to the notion of
> update-by-replacement, tuned 
> to the needs of a particular publishing application.
>  Other voices on 
> this subject are less precise in what they mean, but
> it's pretty clear 
> they mean different things. 

I don't see why one person's narrow focus on how one
particular tool implements one particular term should
bog down the discussion. 

issued == publication date

In blog tools today, there is no formal notion of a
publication date. In CMSs used by big media there is a
notion of a formal publication date. 

This is a fundamental dichotomy but I don't think the
answer is to try and serve 2 masters by creating three
or four date elements of which only 2 will be of use
to any particular tool. I vote for merging the notion
of user entered publication date & issued date. 
 


=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
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 Jul 20 21:22:59 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20366
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 21:22:58 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6L18o94012222;
	Tue, 20 Jul 2004 18:08:50 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6L18omc012221;
	Tue, 20 Jul 2004 18:08:50 -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 i6L18mf5012212
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 18:08:49 -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 i6L18m53005938
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 20:08:49 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6L18kLx005934;
	Tue, 20 Jul 2004 20:08:46 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: "Atom Syntax" <atom-syntax@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net>
	<40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net>
	<40FD376D.8080407@franklinmint.fm>
	<3f1451f504072008533002b6f4@mail.gmail.com>
	<40FD4233.7040101@franklinmint.fm> <40FD4569.4070401@intertwingly.net>
	<40FD481A.40009@franklinmint.fm>
	<98DE9BC4-DA6D-11D8-92AF-000A95A51C9E@sun.com>
	<40FD52E2.5010606@intertwingly.net> <40FD5537.2080500@franklinmint.fm>
	<3f1451f5040720104134622441@mail.gmail.com>
	<40FD5B45.2030202@franklinmint.fm> <m3hds2blgm.fsf@bitsko.slc.ut.us>
	<40FD6538.7020301@AOL.NET> <m3d62qbic3.fsf@bitsko.slc.ut.us>
	<40FD887C.5010909@AOL.NET>
Summary: I think we need to look at how current publishing systems work, and
	provide a usable service for those that can work with it, rather than
	mandate how they all must work.
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 20 Jul 2004 20:08:46 -0500
In-Reply-To: <40FD887C.5010909@AOL.NET>
Message-ID: <m34qo2b201.fsf@bitsko.slc.ut.us>
Lines: 117
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


"John Panzer" <jpanzer@aol.net> writes:

> Ken MacLeod wrote on 7/20/2004, 12:15 PM:
> 
>  > "John Panzer" <jpanzer@aol.net> writes:


>  > Use Case #2: Output resources served from a different host than the
>  > editing system.
>  >
> 
> This one I have some sympathy for.  But I do wonder if there are
> really existing systems where a high-volume server farm is set up
> for binaries, where the provider wants to support PUT/DELETE as well
> as creation for said resources, and where the high-volume server
> farm cannot reasonably also support PUT/DELETE.  Is this in the 80%
> of cases we should worry about?

In the context of this use-case, it's more likely that *all* published
resources are pushed to a static site, rendered HTML and binaries
alike.  Very common.


> Here's my use case: I retrieve the Atom entry using the Atom API
> with the intent of editing it; presumably I use a GET to whatever
> URI returns the 'editable' or 'native' content in order to do this
> (EditURI?).  I then display it in my WYSIWYG editor, which renders
> the picture of my cat inline based on the XHTML content: <img
> src="http://example.org/cat1.jpg"/>.  I then drag a better cat
> picture on top of the original, and save the entry.  My client sees
> that I have only made a change to the picture, and decides to
> automatically replace the old picture.  How does it do this?
> 
> Some suggestions:
> (1) Assume EditURI == "public" GET URI.  No problems.
> (2) When the atom:entry is retrieved in 'edtiable' mode, the
> atom:content data refers to the _resource_ 'editable' URLs as well.
> That is, instead of <img src="http://example.org/cat1.jpg"/> you see
> <img src="http://edit.example.org/res/cat1.jpg"/>, and then this
> devolves just to suggestion (1).
> (2) Provide metadata on the "public" GET URI via HTTP headers.
> Requires an extra HEAD request to get metadata, followed by a PUT to
> the retrieved resource EditURI.  Also requires server to support
> metadata on every GET request.
> (3) Give up on mapping from entries to associated resources.  Don't
> support updating pictures as discovered via entries.
> (4) Why do you even care about this?

I think we need to look at how current publishing systems work, and
provide a usable protocol for those that can work with it, rather than
mandate how they all must work.

(1) seems like the best possible level of support that we can spec in
the core.  (first #2) seems hackish, but doable; I'd suggest in an
extension.  (second #2) would require server support that may not be
possible in many cases where (1) would work anyway, so we should give
up on it.  (3) must be a consideration by clients *in any case*, that
some sites may not provide resource mapping, or that resources linked
from entries might not even be from the same publishing system!
(4) I care!

>  > 2) Include the resources in the Atom index "feeds" (the "feeds"
>  >    used by the editing clients to index posts no longer in the
>  >    dynamic feed).
>  >
> 
> Sure, but this doesn't help relate the resources to the individual
> entrie(s) they're associated with.  That's a use case I'm interested
> in; do you think this isn't useful?

Like (first #2) above, if a) you know the published resource location,
and b) have the index mapping the published resource location to the
EditURI, then you have both ends of that connection.

>  >    PaceExtendedResourcePosting specifies adding a "full" metadata
>  >    wrapper for non-entry resources, but a "minimal" metadata
>  >    wrapper can be provided by the system.
>  >
> 
> I don't have a problem with PaceExtendedResourcePosting as an
> option, but I don't think that it should necessarily be _required_
> of servers.
> 
> Note that if the hypothetical binary resource server farm above can
> provide even a "minimal" metadata wrapper for non-entry resources on
> GETs... why couldn't it just as easily provide support for PUT and
> DELETE and be done with it?

Because those metadata wrappers can 1) be retrieved at separate URLs,
and 2) appear in index feeds (static or dynamic), neither of which
requires any server support beyond a static server.


>  > PS. Third alternative:  WebDAV PROPFIND ;)
> 
> :) Of course if a server can support PROPFIND easily, could it support 
> PUT and DELETE...? :)

I meant PROPFIND on the editing server, for locating all the editable
resources.  WebDAV then also defines the "source" property for mapping
the source resource to the output resource, which could then be used
for (first #2) above -- if the editing server itself was not also the
publishing server, as in (1) above.

>  > PPS. It might also be politically incorrect in Atom circles to
>  > consider that the ResourceBaseURI might be an FTP URL, but in
>  > that situation the alternative is FTP's LIST command.  I wonder
>  > if there aren't already editing clients that support FTP servers?
>  >
> 
> That would be an interesting use case -- non-HTTP editing of
> resources?

LOL, you make that sound like a foreign concept rather than common
practice! :-)

  -- Ken



From owner-atom-syntax@mail.imc.org  Tue Jul 20 21:24:13 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20720
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 21: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 i6L1ETlq012667;
	Tue, 20 Jul 2004 18:14: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 i6L1ETdG012666;
	Tue, 20 Jul 2004 18:14:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6L1EOfN012632
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 18:14:26 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Wed, 21 Jul 2004 11:19:28 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Wed, 21 Jul 2004 11:13:55 +1000
Subject: Re: PaceLinkConstruct issues & next steps
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD240073.21433%eric.scheid@ironclad.net.au>
In-Reply-To: <3733B5B6-DA9B-11D8-BFCB-000A95A51C9E@sun.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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 21/7/04 8:21 AM, "Tim Bray" <Tim.Bray@Sun.COM> wrote:

> (b) yes, push it on the queue and give us a chance to work something up

+1 shout.

e.



From owner-atom-syntax@mail.imc.org  Tue Jul 20 21:26: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 VAA21249
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 21:26:54 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6L1GHO8012778;
	Tue, 20 Jul 2004 18:16: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 i6L1GH06012777;
	Tue, 20 Jul 2004 18:16: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 i6L1GG4F012771
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 18:16:16 -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 i6L1HEAu013037;
	Tue, 20 Jul 2004 21:17:15 -0400
Message-ID: <40FDC3E6.6010601@intertwingly.net>
Date: Tue, 20 Jul 2004 21:16:22 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Dare Obasanjo <kpako@yahoo.com>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Those dates again
References: <20040721005354.24539.qmail@web41205.mail.yahoo.com>
In-Reply-To: <20040721005354.24539.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: <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:

> --- Tim Bray <Tim.Bray@Sun.COM> wrote:
> 
>>On Jul 20, 2004, at 4:33 PM, Dare Obasanjo wrote:
>>
>>I'm not sure.  The "display" date is
>>well-understood, implemented by 
>>running code @ liveJournal & other places, and
>>easily explained by the 
>>analogy of the travel journal - the entry for the
>>8th is the entry for 
>>the 8th, regardless of when it was created/updated.
> 
> No, it is not. Sam described the display date as a
> date that can mean be some arbitrary value not just an
> RFC 822 or ISO 8601 date. I haven't seen many tools
> that allow you to enter '3 months from my birthday' as
> a valid date. 

I thought I had already cleared that up[1].

In any case, can we agree that the date that is "well-understood, 
implemented by running code @ liveJournal & other places, and easily 
explained by the analogy of the travel journal" is both "core" and 
should be expressed by some profile of ISO 8601?

- Sam Ruby

[1] http://www.imc.org/atom-syntax/mail-archive/msg07098.html



From owner-atom-syntax@mail.imc.org  Tue Jul 20 21:46:34 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24151
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 21:46:33 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6L1YGxm013719;
	Tue, 20 Jul 2004 18: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 i6L1YGDe013718;
	Tue, 20 Jul 2004 18:34: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 i6L1YFlu013700
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 18:34:16 -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 i6L1YF53006279
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 20:34:16 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6L1YDS7006271;
	Tue, 20 Jul 2004 20:34:13 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceLinkParent updated, tightened
References: <m3vfgjdctl.fsf@bitsko.slc.ut.us> <opsbgjy3uouvpchu@quark>
Summary: I think it would be bad practice to use a general term
	for a very specific meaning.
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 20 Jul 2004 20:34:13 -0500
In-Reply-To: <opsbgjy3uouvpchu@quark>
Message-ID: <m3zn5u9m96.fsf@bitsko.slc.ut.us>
Lines: 44
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 i6L1YGlu013713
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 <asbjorn@tigerstaden.no> writes:

> On 19 Jul 2004 14:19:50 -0500, Ken MacLeod <ken@bitsko.slc.ut.us> wrote:
> 
> > I've updated PaceLinkParent [...]
> 
> Although I'm +1 on the idea the pace expresses, I do not agree with
> the concrete implementation. I think Atom should use the Dublin Core
> element <relation>, as its semantics is already defined
> there. <relation> also has the bonus that it defines other relation
> issues, like IsBasedOn (supersedes or «re-issuance» of resources)
> and such.

Logically,

    atom:in-reply-to
        the atom:id URI of the entry to which this one is a reply (the
        "parent entry")

is a refinement of

    dct:references
        The described resource references, cites, or otherwise points
        to the referenced resource.

which in turn is a refinement of

    dc:relation
        A reference to a related resource.

Thus, atom:in-reply-to *is* a dc:relation.  In the Dublic Core mapping
we can indicate that atom:in-reply-to can be interpreted as a
dct:references.

I think it would be bad practice to use a general term for a very
specific meaning.

  -- Ken

PS. Recall that the reason for changing "parent" to "in-reply-to" was
because "parent" was also too generic, almost equivalent to
dct:isPartOf, despite its common usage in the local context of a
message database where using "parent" to refer to the parent message
is easily understood.



From owner-atom-syntax@mail.imc.org  Tue Jul 20 21:56: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 VAA26220
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 21: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 i6KHqYW0065433;
	Tue, 20 Jul 2004 10:52: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 i6KHqYPS065432;
	Tue, 20 Jul 2004 10:52:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.241])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6KHqXi8065423
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 10:52:34 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so7541308cwc
        for <atom-syntax@imc.org>; Tue, 20 Jul 2004 10:52:34 -0700 (PDT)
Received: by 10.11.116.34 with SMTP id o34mr172162cwc;
        Tue, 20 Jul 2004 10:52:34 -0700 (PDT)
Message-ID: <3f1451f504072010526cb018f0@mail.gmail.com>
Date: Tue, 20 Jul 2004 13:52:34 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: mint@franklinmint.fm
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
Cc: Sam Ruby <rubys@intertwingly.net>, Tim Bray <tim.bray@Sun.COM>,
        kwark.1511609@bloglines.com, Atom Syntax <atom-syntax@imc.org>,
        Janne Jalkanen <janne.jalkanen@nokia.com>,
        ext John Panzer <jpanzer@aol.net>
In-Reply-To: <3f1451f5040720104134622441@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <3f1451f504072008533002b6f4@mail.gmail.com> <40FD4233.7040101@franklinmint.fm> <40FD4569.4070401@intertwingly.net> <40FD481A.40009@franklinmint.fm> <98DE9BC4-DA6D-11D8-92AF-000A95A51C9E@sun.com> <40FD52E2.5010606@intertwingly.net> <40FD5537.2080500@franklinmint.fm> <3f1451f5040720104134622441@mail.gmail.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, 20 Jul 2004 13:41:16 -0400, Joe Gregorio <joe.gregorio@gmail.com> wrote:
> On Tue, 20 Jul 2004 13:24:07 -0400, Robert Sayre <mint@franklinmint.fm> wrote:
> > Sam Ruby wrote:
> > > Any Apache CGI that can recieve a POST can also recieve a PUT.  They
> > > simply need to check the "REQUEST_METHOD" in order to distinguish
> > > between the two.
> >
> >
> > I phrased my question badly, but note that I wrote *redirect*. What does
> > it take to serve a .jpg file on a GET, while directing POSTs, PUTs, and
> > DELETEs to a CGI? This is an issue Atom entries don't encounter, because
> > they can specify an EditURI. If the server user has somewhere to stick a
> > "Script" directive, it's no problem:
> >
> > Script PUT /~bob/put.cgi
> >
> > Does a standard shared hosting account allow the following?
> >
> > This request would go to a CGI specified in a "Script" directive:
> > PUT /images/foo.jpg HTTP/1.1
> > Content-type: image/jpg
> >
> > This request would just serve the file:
> > GET /images/foo.jpg HTTP/1.1
> 
> 
> if os.environ["REQUEST_METHOD"] == "GET":
>     print "Content-type: image/jpg\r\n\r\n"
>     f = file("foo.jpg", "r")
>     os.stdout.write(f.read())
> elif  os.environ["REQUEST_METHOD"] == "PUT":
>     f = file("foo.jpg", "w")
>     f.write(os.stdin.read())
>     f.close()

Or you can serve the file off the file system
and use a .htaccess to redirect on a PUT

RewriteEngine  on
RewriteCond  %{REQUEST_METHOD} POST [nc]
RewriteRule photos(/.*)?$   /photohandler.cgi$1               [last]


-- 
Joe Gregorio        http://bitworking.org



From owner-atom-syntax@mail.imc.org  Tue Jul 20 21:57: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 VAA26546
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 21:57: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 i6L1kYsN014559;
	Tue, 20 Jul 2004 18:46: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 i6L1kYMx014558;
	Tue, 20 Jul 2004 18:46:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.243])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6L1kX01014548
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 18:46:33 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so8109358cwc
        for <atom-syntax@imc.org>; Tue, 20 Jul 2004 18:46:34 -0700 (PDT)
Received: by 10.11.99.74 with SMTP id w74mr200080cwb;
        Tue, 20 Jul 2004 18:46:34 -0700 (PDT)
Message-ID: <3f1451f5040720184649837fe9@mail.gmail.com>
Date: Tue, 20 Jul 2004 21:46:34 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: John Panzer <jpanzer@aol.net>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
Cc: Ken MacLeod <ken@bitsko.slc.ut.us>, Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <40FD887C.5010909@AOL.NET>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <3f1451f504072008533002b6f4@mail.gmail.com> <40FD4233.7040101@franklinmint.fm> <40FD4569.4070401@intertwingly.net> <40FD481A.40009@franklinmint.fm> <98DE9BC4-DA6D-11D8-92AF-000A95A51C9E@sun.com> <40FD52E2.5010606@intertwingly.net> <40FD5537.2080500@franklinmint.fm> <3f1451f5040720104134622441@mail.gmail.com> <40FD5B45.2030202@franklinmint.fm> <m3hds2blgm.fsf@bitsko.slc.ut.us> <40FD6538.7020301@AOL.NET> <m3d62qbic3.fsf@bitsko.slc.ut.us> <40FD887C.5010909@AOL.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, 20 Jul 2004 14:02:52 -0700, John Panzer <jpanzer@aol.net> wrote:
> Here's my use case:  I retrieve the Atom entry using the Atom API with
> the intent of editing it; presumably I use a GET to whatever URI returns
> the 'editable' or 'native' content in order to do this (EditURI?).  I
> then display it in my WYSIWYG editor, which renders the picture of my
> cat inline based on the XHTML content: <img
> src="http://example.org/cat1.jpg"/>.  I then drag a better cat picture
> on top of the original, and save the entry.  My client sees that I have
> only made a change to the picture, and decides to automatically replace
> the old picture.

What if the user only wanted the new picture uploaded and 
the old picture left in place to be used in another post?
How about if the picture was resized, do you replace it then?
And what if a picture was added, how to you know if that
picture was already published or if it still needs publishing?

I could go on and on.

> (4) Why do you even care about this?

I don't. And I don't think we should spent time trying to 
figure out the 'right' way to do this. Let's just provide a protocol
for publishing "(X)HTML and/or plain text" entries along
with a way to publish binary content which may or may
not use the same mechanism. 

    -joe

-- 
Joe Gregorio        http://bitworking.org



From owner-atom-syntax@mail.imc.org  Tue Jul 20 22:03: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 WAA27799
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 22:03: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 i6L1q0mc015120;
	Tue, 20 Jul 2004 18:52: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 i6L1q0i2015119;
	Tue, 20 Jul 2004 18:52: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.45])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6L1pxT1015110
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 18:51:59 -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 i6L1q5Av002837;
	Tue, 20 Jul 2004 18:52:05 -0700 (PDT)
Received: from [192.168.1.101] (66-108-153-170.nyc.rr.com [66.108.153.170])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id i6L1oSaB016201;
	Tue, 20 Jul 2004 18:51:39 -0700 (PDT)
In-Reply-To: <20040720224159.51681.qmail@web41201.mail.yahoo.com>
References: <20040720224159.51681.qmail@web41201.mail.yahoo.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-10-398344654; protocol="application/pkcs7-signature"
Message-Id: <7EC307FB-DAB8-11D8-B3AB-000A95DC3D90@mac.com>
Cc: =?ISO-8859-1?Q?Asbj=F8rn=5FUlsberg?= <asbjorn@tigerstaden.no>,
        Atom-Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: Those dates again
Date: Tue, 20 Jul 2004 21:51:33 -0400
To: Dare Obasanjo <kpako@yahoo.com>
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-10-398344654
Content-Type: text/plain;
	charset=ISO-8859-1;
	format=flowed
Content-Transfer-Encoding: quoted-printable

On 20 Jul 2004, at 6:41 pm, Dare Obasanjo wrote:

> --- Asbj=F8rn_Ulsberg <asbjorn@tigerstaden.no> wrote:
>>   * Issued
>>   * Modified
>>   * Created
>>   * Display
>>
>> Only the two first should be required.
>
> Agreed.

What do you use modified for Dare?

Graham=

--Apple-Mail-10-398344654
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
9w0BCQUxDxcNMDQwNzIxMDE1MTM0WjAjBgkqhkiG9w0BCQQxFgQUUISyBckKflb8/t7c9vvheFYo
K/MweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEA1ia9EETzcBy/co36bRm8c7iu
BCoyFlLKvINfoTeu/4n5rTWGTkwzd37LCfz8ZRW2hYvR+aA1gJqfTi9KxqpDYphbNoj/yuj+sGPK
g15ldMqX6ozSi+A0ugH9hapR+hLP1IA9biGM2zRkIpyOiOAVZ7JcTy+MtPdO/IwStfVtJ6uuC7/p
t1ehlooGkCBe4+8+LkeRONXynxjoyy3QxHV3yoUOyIwGoylIObE5SVoFZa4dfwI4qvLvNeNEchsh
Zk5zjFkqcAoGa2egSjaee7kuni6Ln8AxJa7w+TaPqBRuIoC03JbLVDgSFgeCPpvXqZqso3dntR6H
3J0ir+TXWRjYEwAAAAAAAA==

--Apple-Mail-10-398344654--



From owner-atom-syntax@mail.imc.org  Tue Jul 20 23:00: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 XAA08675
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 23:00: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 i6L2mDXN019930;
	Tue, 20 Jul 2004 19:48:13 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6L2mDOJ019929;
	Tue, 20 Jul 2004 19:48:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6L2m8B0019916
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 19:48:10 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Wed, 21 Jul 2004 12:52:05 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Wed, 21 Jul 2004 12:46:31 +1000
Subject: Re: Those dates again
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD241627.214A8%eric.scheid@ironclad.net.au>
In-Reply-To: <40FDC3E6.6010601@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: <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 21/7/04 11:16 AM, "Sam Ruby" <rubys@intertwingly.net> wrote:

> In any case, can we agree that the date that is "well-understood,
> implemented by running code @ liveJournal & other places, and easily
> explained by the analogy of the travel journal" is both "core" and
> should be expressed by some profile of ISO 8601?

+1

In the same sense that an entry has an "official title", they can also have
an "official date" ... which is orthogonal to the date it was created,
modified, updated, published, retrieved, etc etc. That is, a date which is
*part* of the content, and not an artefact of the circumstances of
publication.

e.



From owner-atom-syntax@mail.imc.org  Tue Jul 20 23:02: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 XAA08795
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 23:02: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 i6L2pqnK020427;
	Tue, 20 Jul 2004 19:51: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 i6L2pqP4020426;
	Tue, 20 Jul 2004 19:51:52 -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 i6L2pp5D020403
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 19:51:51 -0700 (PDT)
	(envelope-from roger@agincourtmedia.com)
Received: from biggreen ([216.63.148.42]) by journurl.com with MailEnable ESMTP; Tue, 20 Jul 2004 21:52:02 -0500
From: "Roger B." <roger@agincourtmedia.com>
To: "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: RE: Those dates again
Date: Tue, 20 Jul 2004 21:56:21 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <opsbgqc8pguvpchu@quark>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Thread-Index: AcRuvadsIfrXQo8dQFGoFBZmIcTBrwADqDfg
Message-ID: <300410D91BD449178EDAC1E8EB953D.MAI@journurl.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6L2pp5D020421
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


> If we first define that 'atom:issued' MUST NOT change, we can define
> superseding mechanisms afterwards, if people need to distinguish minor
>  from major modifications. But Atom cannot support this by just altering
> 'issued' in the entry, because that leaves 'issued' just as useless, or
> even more so, as it would be if it was a random user-entered date.

Asbjørn: You can keep saying it, but it won't change the reality that every
syndicated blog on the Web is using just such a date every day. Here are the
bullet points:

(1) The apps that form the basis of Atom's existence produce a date that is
generally referred to as "published date" or "pubdate". This is the
all-important date that defines how entries are sorted by default.

(2) This date can and will change. It sometimes be changed by a machine,
sometimes by a user. There is no reason for Atom to overstep itself and try
to mandate the origin of the change... it is enough to expect it.

(3) This date can be expressed in as 8601 by virtually all tools. One
significant exception can produce the date, but without a timezone. That
exception has a million users and cannot be overlooked.

(4) What we call that date ("issued", "published", "Frances McDormand") is a
side-issue. It is the only date that Atom *must* support on a practical
level. If this definition conflicts with dc:issued and people actually care,
then by all means, another name should be picked out of a hat.

(5) For Atom to differentiate itself from RSS, it must support one other
date: modified. This is the one that aggregator authors are most interested
in, and most (if not all) tools can produce it.

(6) This date can and will change. The change will usually be made by a
machine, but might be user-defined in certain edge-casey scenarios. There's
no reason for Atom to overstep itself and try to mandate the origin of the
change... it is enough to expect it.

Everything else is probably better left for an extension.

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/ 








From owner-atom-syntax@mail.imc.org  Tue Jul 20 23:28: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 XAA11999
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 23:28: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 i6L3IC6M022328;
	Tue, 20 Jul 2004 20:18: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 i6L3IC7D022327;
	Tue, 20 Jul 2004 20:18:12 -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 i6L3ICqR022314
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 20:18:12 -0700 (PDT)
	(envelope-from antone@geckotribe.com)
Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134])
          by comcast.net (rwcrmhc11) with SMTP
          id <2004072103180901300qjvkde>; Wed, 21 Jul 2004 03:18:09 +0000
Date: Tue, 20 Jul 2004 21:18:08 -0600
Subject: Re: PaceLinkConstruct issues & next steps
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: <2078F2F7-DAAA-11D8-95E3-003065EA6144@geckotribe.com>
Message-Id: <96EC6456-DAC4-11D8-95E3-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, July 20, 2004, at 06:08  PM, Antone Roundy wrote:
> # PaceLinkRelMechanism - use qnames in @rel for links defined in 
> extensions (thus, extensible)
I've been corrected on this one:

"the mechanism described on that page are NOT qnames, but a different 
thing altogether."

and

"PaceLinkRelMechanism isn't using XML qnames, it's using RFC2731 schema 
declarations."



From owner-atom-syntax@mail.imc.org  Tue Jul 20 23: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 XAA13692
	for <atompub-archive@lists.ietf.org>; Tue, 20 Jul 2004 23: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 i6L3foQQ023957;
	Tue, 20 Jul 2004 20: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 i6L3foit023956;
	Tue, 20 Jul 2004 20: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 (mproxy.gmail.com [216.239.56.243])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6L3foj0023950
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 20:41:50 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id q44so8174355cwc
        for <atom-syntax@imc.org>; Tue, 20 Jul 2004 20:41:54 -0700 (PDT)
Received: by 10.11.116.34 with SMTP id o34mr187382cwc;
        Tue, 20 Jul 2004 20:41:54 -0700 (PDT)
Message-ID: <3f1451f50407202041385e358e@mail.gmail.com>
Date: Tue, 20 Jul 2004 23:41:54 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Atom Syntax <atom-syntax@imc.org>
Subject: PacePostLocationMust created
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


http://intertwingly.net/wiki/pie/PacePostLocationMust

Hopefully a simple Pace to tighten up some 
of the language on responses from a POST
to a PostURI in the Publishing Protocol.

------------------------------------------------------------
Abstract
======

Require that the response from POST to a PostURI MUST contain a
location header. Also specify which contraints apply to the response
body.

Status
=====

Open

Rationale
=======

Clears up vagueness in the current wording and makes client editing
easier by reducing the number of round trips.

Proposal
=======

Change 3.1.3.1 to read:

The Response MUST include a Location: header with the URI of the
created resource. The URI returned must be the EditURI of the entry
just created. The body of the response SHOULD contain the newly
created entry. If the entry is present in the response body then it
MUST conform to the same constraints listed for responses to a GET on
an EditURI. User agents MUST NOT depend on the server returning a
response body. If the server does return a response body then the user
agents MUST NOT depend on the response body having a content-type of
'application/atom+xml". Note that the server may chose to omit the
content in the response, particularly if it is large.

A 201 response MAY contain an ETag response header field indicating
the current value of the entity tag for the requested variant just
created.

If the entry returned is subsequently changed the user agent can
update the entry by submitting it via PUT to the EditURI. If an ETag
was returned with the creation of the entry then the user agent SHOULD
include an If-Match header in the request that contains that ETag.

Impacts
======

Allows clients to depend upon getting the URI of the EditURI in the
response header thus avoiding a round trip to the FeedURI just to get
the EditURI of a newly created entry.

Notes
====

Note that the entry returned fits the requirements in RFC 2616 for a
201 response since it contains a link element to the HTML version of
the newly created entry. From RFC 2616:

      The response SHOULD include an entity containing a list of
resource  characteristics and location(s) from which the user or user
agent can choose the one most appropriate. The entity format is
specified by the media type given in the Content-Type header field.

------------------------------------------------------------


    Thanks,
    -joe

-- 
Joe Gregorio        http://bitworking.org



From owner-atom-syntax@mail.imc.org  Wed Jul 21 00:54: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 AAA17679
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 00:54: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 i6L4e2A4027326;
	Tue, 20 Jul 2004 21:40: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 i6L4e2at027325;
	Tue, 20 Jul 2004 21:40:02 -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 i6L4e1As027308
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 21:40:02 -0700 (PDT)
	(envelope-from roger@agincourtmedia.com)
Received: from biggreen ([216.63.148.42]) by journurl.com with MailEnable ESMTP; Tue, 20 Jul 2004 23:40:12 -0500
From: "Roger B." <roger@agincourtmedia.com>
To: "'Dare Obasanjo'" <kpako@yahoo.com>
Cc: "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: RE: Those dates again
Date: Tue, 20 Jul 2004 23:44:53 -0500
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: <20040721005354.24539.qmail@web41205.mail.yahoo.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Thread-Index: AcRuvVnwSTzk/uXuRYmXDjaes0rn3AAH28tg
Message-ID: <E4212EF9D3B64DC390431DBBBB470.MAI@journurl.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


> I vote for merging the notion
> of user entered publication date & issued date.

Dare: +1

--
Roger Benningfield







From owner-atom-syntax@mail.imc.org  Wed Jul 21 00:56: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 AAA17763
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 00:56:28 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6L4jRwe027841;
	Tue, 20 Jul 2004 21:45:27 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6L4jRkG027840;
	Tue, 20 Jul 2004 21:45:27 -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 i6L4jRVE027833
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 21:45:27 -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 i6L4jYas010710;
	Tue, 20 Jul 2004 21:45:34 -0700 (PDT)
Received: from [192.168.1.101] (66-108-153-170.nyc.rr.com [66.108.153.170])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id i6L4jVD2015965;
	Tue, 20 Jul 2004 21:45:31 -0700 (PDT)
In-Reply-To: <300410D91BD449178EDAC1E8EB953D.MAI@journurl.com>
References: <300410D91BD449178EDAC1E8EB953D.MAI@journurl.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-13-408651055; protocol="application/pkcs7-signature"
Message-Id: <7DDB0FC0-DAD0-11D8-B3AB-000A95DC3D90@mac.com>
Cc: "'Atom-Syntax'" <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: Those dates again
Date: Wed, 21 Jul 2004 00:43:20 -0400
To: "Roger B." <roger@agincourtmedia.com>
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-13-408651055
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 20 Jul 2004, at 10:56 pm, Roger B. wrote:

> (5) For Atom to differentiate itself from RSS, it must support one 
> other
> date: modified. This is the one that aggregator authors are most 
> interested
> in, and most (if not all) tools can produce it.

i) For feeds produced from, say, the result of an SQL query, it's very 
hard to offer a sensible value for modified. I don't want it to 
mandatory unless tools at the consuming end need it to be.
ii) As an aggregator author, I've never wanted it. Can you fill me in 
on why others do?

Graham
--Apple-Mail-13-408651055
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
9w0BCQUxDxcNMDQwNzIxMDQ0MzIxWjAjBgkqhkiG9w0BCQQxFgQUc3IivQFFbS532rwpT2U+LJ+X
h1cweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAXE7/kitzJLxPalJ+GiJ8wDTc
C9kPVnOMYF4t+lAxk4q4J6Nn7amcu3MBC0LDamZoT/CSFAKgMxpeFGlwcFukFDwmcGuJywOpOALV
D76I4QsBFYnRTJ53J893aBiahPddT/X+7TPfPCEBKD1Q6XoSPbmBdmiE5sxii+nPffErucAQ0uzV
CJVHBoDN5IOLnxNiXlXahyilK1bJVlQhjQqRjrsNllxCe+RuIKp7+mUKUGwvVVM6PvKqQWhJF21V
M9CxvgJ7LylhdXpTl9AGwSs5wXkQQ0ZJa0S/ce0doe677k8ynfSu0I78QsvFh5c2eYmTnWp6Q8as
ISmL5K2qgpepygAAAAAAAA==

--Apple-Mail-13-408651055--



From owner-atom-syntax@mail.imc.org  Wed Jul 21 01: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 BAA19148
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 01: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 i6L5DlH8033826;
	Tue, 20 Jul 2004 22:13: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 i6L5DlTw033825;
	Tue, 20 Jul 2004 22:13:47 -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 i6L5DkME033768
	for <atom-syntax@imc.org>; Tue, 20 Jul 2004 22:13:46 -0700 (PDT)
	(envelope-from roger@agincourtmedia.com)
Received: from biggreen ([216.63.148.42]) by journurl.com with MailEnable ESMTP; Wed, 21 Jul 2004 00:08:53 -0500
From: "Roger B." <roger@agincourtmedia.com>
To: "'Graham'" <dtcd@mac.com>
Cc: "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: RE: Those dates again
Date: Wed, 21 Jul 2004 00:13:46 -0500
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: <7DDB0FC0-DAD0-11D8-B3AB-000A95DC3D90@mac.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Thread-Index: AcRu3bBtdaoyMUuaRZOR98VUcV8wIwAAX1RA
Message-ID: <5C9766B62794C5C86608A1A151CA1.MAI@journurl.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


> ii) As an aggregator author, I've never wanted it. Can you fill me in
> on why others do?

Graham: Personally, I don't need it either. JournURL's (admittedly
simplistic) internal aggregator only needs Ye Olde PubDate, so modified
isn't something I'd use myself. If it ended up optional, I wouldn't mind at
all. 

But in desktop aggregators that mark items unread or bump them to the top
upon modification, I've seen folks voice frustration at the way RSS forces
them to use content hashes to track changes... as more and more people add
dynamic advertising to their feeds, such developers need a clean mechanism
for alerting the user when the same old item contains something additional
beyond a banner ad.

(Of course, some unscrupulous advertisers will just set modified to Now()
and abuse the system, but I suppose that's the beauty of syndication... it's
easy to unsubscribe from the unscrupulous.)

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/ 







From owner-atom-syntax@mail.imc.org  Wed Jul 21 05:57: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 FAA03307
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 05:57: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 i6L9kLUw046213;
	Wed, 21 Jul 2004 02: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 i6L9kLth046212;
	Wed, 21 Jul 2004 02:46: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 i6L9kKSW046198
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 02:46:20 -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 i6L9l8XQ009924;
	Wed, 21 Jul 2004 05:47:14 -0400
Message-ID: <40FE3B66.9030903@intertwingly.net>
Date: Wed, 21 Jul 2004 05:46:14 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: "Roger B." <roger@agincourtmedia.com>
CC: "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: Re: Those dates again
References: <300410D91BD449178EDAC1E8EB953D.MAI@journurl.com>
In-Reply-To: <300410D91BD449178EDAC1E8EB953D.MAI@journurl.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


Roger B. wrote:
> 
> (1) The apps that form the basis of Atom's existence produce a date that is
> generally referred to as "published date" or "pubdate". This is the
> all-important date that defines how entries are sorted by default.

LiveJournal calls is a "post date"
TypePad calls it a "post's date stamp"
Blogger calls it as "date/time of my post"

> (5) For Atom to differentiate itself from RSS, it must support one other
> date: modified. This is the one that aggregator authors are most interested
> in, and most (if not all) tools can produce it.

RSS 0.91 has no item level date element.

Commonly used in RSS 1.0 is dc:date.

RSS 0.93 introduced pubDate as "indicating when the item will become 
available."

RSS 2.0 defined pubDate as "indicating when the item was published. If 
it's a date in the future, aggregators may choose to not display the 
item until that date."

My read is that the the spec definition of pubDate is most closely 
aligned with the dublin core concept of Available.  Common usage of this 
element may vary from this definition.  In particular, as a number of 
aggregators use this element to determine either sort order or even 
simply "freshness", users are prone to use this element as a proxy for 
"significantly modified" or "reissued".

A goal of Atom is to be cleanly and thoroughly specified.  If different 
people use the single date in multiple ways, these ways need to be 
differentiated.

Different aggregators may chose to ignore one or more of the dates 
provided.  But even those that do ignore one of the dates benefit by 
distinguishing these two use cases.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Wed Jul 21 06:20: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 GAA04531
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 06:20: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 i6LABMQu055501;
	Wed, 21 Jul 2004 03: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 i6LABMm8055500;
	Wed, 21 Jul 2004 03:11:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from cat-proof.de (cat.cat-proof.de [213.239.198.176])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LABLLU055487
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 03:11:21 -0700 (PDT)
	(envelope-from sc@itst.net)
Received: from webmail.cat-proof.de (localhost [127.0.0.1])
	by cat-proof.de (Postfix) with SMTP id 8591D340B660
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 12:09:53 +0200 (CEST)
Received: from 217.82.43.86
        (SquirrelMail authenticated user sc@itst.net)
        by webmail.cat-proof.de with HTTP;
        Wed, 21 Jul 2004 12:09:53 +0200 (CEST)
Message-ID: <33734.217.82.43.86.1090404593.squirrel@webmail.cat-proof.de>
Date: Wed, 21 Jul 2004 12:09:53 +0200 (CEST)
From: "Sascha Carlin" <sc@itst.net>
To: atom-syntax@imc.org
Reply-To: sc@itst.org
User-Agent: SquirrelMail/1.4.2
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3
Importance: Normal
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


subscribe



From owner-atom-syntax@mail.imc.org  Wed Jul 21 07:19: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 HAA08250
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 07:19:40 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LBBhA9069499;
	Wed, 21 Jul 2004 04: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 i6LBBhOQ069498;
	Wed, 21 Jul 2004 04:11:43 -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 i6LBBfAt069477
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 04:11:42 -0700 (PDT)
	(envelope-from djpowell@djpowell.net)
Received: from cpc1-stke1-5-0-cust6.bagu.cable.ntl.com ([81.97.134.6])
          by mta08-svc.ntlworld.com
          (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP
          id <20040721111127.RTKP548.mta08-svc.ntlworld.com@cpc1-stke1-5-0-cust6.bagu.cable.ntl.com>;
          Wed, 21 Jul 2004 12:11:27 +0100
Date: Wed, 21 Jul 2004 12:11:30 +0100
From: David Powell <djpowell@djpowell.net>
X-Mailer: The Bat! (v2.12 RC/4) Business
Reply-To: David Powell <djpowell@djpowell.net>
X-Priority: 3 (Normal)
Message-ID: <19210451019.20040721121130@djpowell.net>
To: Dare Obasanjo <kpako@yahoo.com>
CC: =?ISO-8859-15?B?QXNiavhybl9VbHNiZXJn?= <asbjorn@tigerstaden.no>,
        Sascha Carlin <sc@itst.org>, Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Those dates again
In-Reply-To: <20040720233302.11120.qmail@web41215.mail.yahoo.com>
References: <opsbglnwmfuvpchu@quark>
 <20040720233302.11120.qmail@web41215.mail.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
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



Wednesday, July 21, 2004, 12:33:02 AM, kpako@yahoo.com wrote:

>>    Date 2: Display

> On pressing Sam about this date I seem to remember he
> eventually described it as being akin to issued. If
> issued and modified are in the feed I can't see any
> reason why an aggregator would need some fictitious
> and bogus additional date.

The display date is no more bogus and fictitious than atom:title or
atom:author are bogus and fictitious.

It allows a publisher to associate a date with an entry. This date is
more like a subtitle, than any of the other dates, which are records
of the publishing process. If you want to display a date, then this is
the MOST accurate date to display.

Not every publisher would be interested in supplying a display date,
so it should not be mandatory, but it should be part of the
specification. If it is left out then it just encourages people to
abuse the other fields, which have a very different meaning.

If this date is present, then it must be machine readable. I would
hope that it would contain the local timezone of the poster, but it
might be appropriate to also allow Unqualified Local Time to be used
for this field if the timezone is not available? (I'm not sure about
this).

I expect that the other process-related date fields would contain
times in UTC, or a timezone that doesn't necessarily represent the
user, this is another reason that the display date would be the most
accurate date for display.

I am not particularly bothered about atom:issued, but other people
are, especially those involved with more formal publishing processes.
But I think that removing it would reduce the value of the date fields
for everyone. I don't think that atom:issued should be mandatory
either - it is less significant to informal publishers.


-- 
Dave



From owner-atom-syntax@mail.imc.org  Wed Jul 21 07:41: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 HAA09553
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 07:41: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 i6LBVN2p071483;
	Wed, 21 Jul 2004 04:31: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 i6LBVNIG071482;
	Wed, 21 Jul 2004 04:31:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LBVLTv071473
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 04:31:22 -0700 (PDT)
	(envelope-from Janne.Jalkanen@nokia.com)
Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158])
	by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6LBUt704058;
	Wed, 21 Jul 2004 14:30:55 +0300 (EET DST)
X-Scanned: Wed, 21 Jul 2004 14:29:52 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost)
	by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i6LBTqFb018701;
	Wed, 21 Jul 2004 14:29:52 +0300
Received: from mgw-int1.ntc.nokia.com (172.21.143.96)
	by esdks003.ntc.nokia.com 00WbTVc2; Wed, 21 Jul 2004 14:29:50 EEST
Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77])
	by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6LBTdn21700;
	Wed, 21 Jul 2004 14:29:39 +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);
	 Wed, 21 Jul 2004 14:29:40 +0300
Message-ID: <40FE53A2.3040308@nokia.com>
Date: Wed, 21 Jul 2004 14:29:38 +0300
From: Janne Jalkanen <Janne.Jalkanen@nokia.com>
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: ext Joe Gregorio <joe.gregorio@gmail.com>
CC: ext John Panzer <jpanzer@aol.net>, Robert Sayre <mint@franklinmint.fm>,
        kwark.1511609@bloglines.com, Atom Syntax <atom-syntax@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <3f1451f504072007233fc8ec82@mail.gmail.com>
In-Reply-To: <3f1451f504072007233fc8ec82@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Jul 2004 11:29:40.0047 (UTC) FILETIME=[02D195F0:01C46F16]
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



>Looks good, but would you mind removing the
>WSSE headers from the examples so we don't 
>accidently conflate the two issues of 
>authentication and the Action header?
>  
>
Done.  I also added some discussions from the list into the Notes-section.

/Janne



From owner-atom-syntax@mail.imc.org  Wed Jul 21 08: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 IAA13202
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 08: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 i6LCNR4h075966;
	Wed, 21 Jul 2004 05:23: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 i6LCNRTQ075965;
	Wed, 21 Jul 2004 05:23:27 -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 i6LCNQKD075957
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 05:23:26 -0700 (PDT)
	(envelope-from Janne.Jalkanen@nokia.com)
Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121])
	by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6LCNOh28166;
	Wed, 21 Jul 2004 15:23:24 +0300 (EET DST)
X-Scanned: Wed, 21 Jul 2004 15:22:41 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost)
	by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i6LCMfP0024950;
	Wed, 21 Jul 2004 15:22:41 +0300
Received: from mgw-int2.ntc.nokia.com (172.21.143.97)
	by esdks002.ntc.nokia.com 00SZQTSI; Wed, 21 Jul 2004 15:22:40 EEST
Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28])
	by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6LCMZu20229;
	Wed, 21 Jul 2004 15:22:35 +0300 (EET DST)
Received: from [172.21.60.114] ([172.21.60.114]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Wed, 21 Jul 2004 15:22:34 +0300
Message-ID: <40FE6008.9020304@nokia.com>
Date: Wed, 21 Jul 2004 15:22:32 +0300
From: Janne Jalkanen <Janne.Jalkanen@nokia.com>
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: ext John Panzer <jpanzer@aol.net>
CC: Robert Sayre <mint@franklinmint.fm>, kwark.1511609@bloglines.com,
        joe.gregorio@gmail.com, Atom Syntax <atom-syntax@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net>
In-Reply-To: <40FAA6D3.30701@aol.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Jul 2004 12:22:34.0158 (UTC) FILETIME=[66BC7CE0:01C46F1D]
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 is possible to get around the same-host security restrictions via 
> "crossdomain.xml" files placed at the root of the Atom server.  If a 
> domain is listed in this file, Flash .swf files originally loaded from 
> that domain are allowed to at least GET/POST to/from the Atom server.

BTW, this reminds me of one drawback: if you want to protect your web 
service using method-based filtering (like using the security-constraint 
in J2EE web.xml files), you have to assume that DELETE, POST, and PUT 
have all the same access restrictions, because you don't know whether 
your client can support PUT/DELETE or not.

Which may be not what you want, but there you go anyway.  I would 
imagine that this is mostly not going to be a problem, though, as it 
only affects people who want container-based authentication.

/Janne



From owner-atom-syntax@mail.imc.org  Wed Jul 21 08:46: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 IAA13907
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 08:46: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 i6LCbKZf077722;
	Wed, 21 Jul 2004 05:37: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 i6LCbKeg077721;
	Wed, 21 Jul 2004 05:37:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LCbJiw077713
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 05:37:19 -0700 (PDT)
	(envelope-from Janne.Jalkanen@nokia.com)
Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121])
	by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6LCZS722135;
	Wed, 21 Jul 2004 15:35:28 +0300 (EET DST)
X-Scanned: Wed, 21 Jul 2004 15:34:50 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost)
	by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i6LCYoVY015248;
	Wed, 21 Jul 2004 15:34:50 +0300
Received: from mgw-int2.ntc.nokia.com (172.21.143.97)
	by esdks002.ntc.nokia.com 00QQSxlC; Wed, 21 Jul 2004 15:34:48 EEST
Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82])
	by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6LCYmu25763;
	Wed, 21 Jul 2004 15:34:48 +0300 (EET DST)
Received: from [172.21.60.114] ([172.21.60.114]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Wed, 21 Jul 2004 15:34:45 +0300
Message-ID: <40FE62E5.6030707@nokia.com>
Date: Wed, 21 Jul 2004 15:34:45 +0300
From: Janne Jalkanen <Janne.Jalkanen@nokia.com>
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: mint@franklinmint.fm
CC: Sam Ruby <rubys@intertwingly.net>, ext John Panzer <jpanzer@aol.net>,
        kwark.1511609@bloglines.com, joe.gregorio@gmail.com,
        Atom Syntax <atom-syntax@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm>
In-Reply-To: <40FD376D.8080407@franklinmint.fm>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Jul 2004 12:34:45.0158 (UTC) FILETIME=[1A723C60:01C46F1F]
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



> Yeah, we are bending over backwards for the one client platform we can 
> find that can set headers, but not the request method. This doesn't 
> help Flash or existing SOAP software.

I'm with Tim on this one; we're not bending over backwards (as in 
redesigning the entire protocol around one client platform), but just 
acknowledging the existence of a hundred million Java-enabled phones out 
there (don't quote me on the figure, I think it's in the ballpark, but I 
don't remember the official numbers :)

> The SOAP 1.2 HTTP binding[0] would seem to solve all of the problems 
> this Pace does, with the exception of binary PUT uploads. Would it be 
> acceptable to require base64 for the infrequent case of editing on a 
> cell phone? It seems reasonable to assume that cell phone clients will 
> mostly be POSTing, and that mobile platforms that are somewhat 
> pleasant to use for editing are more likely to have the ability to PUT.

Well, to me SOAP is the more dubious solution because it assumes things 
about the payload more than it should (payload always XML).  The 
Atom-Action header does not modify nor assume anything about the 
payload, and has thus less impact on both clients and the servers. It is 
also far simpler than bringing in SOAP.

And while most of our use cases don't assume editing on the cell phones, 
you can see at least in the japanese market that phones are already 
gaining image editing capabilities.  I would find it at least odd to 
make the life of third party developers more difficult just because they 
would like to have an Atom editing client.

Besides, with Wikis and other CMS systems, attachments might get edited 
far more often than with just plain weblogs (which are mostly of 
fire-and-forget) -type.

/Janne



From owner-atom-syntax@mail.imc.org  Wed Jul 21 08: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 IAA14567
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 08: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 i6LClusv078541;
	Wed, 21 Jul 2004 05: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 i6LCluQt078540;
	Wed, 21 Jul 2004 05:47:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LCltmY078533
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 05:47:55 -0700 (PDT)
	(envelope-from Janne.Jalkanen@nokia.com)
Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121])
	by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6LClpv00025;
	Wed, 21 Jul 2004 15:47:51 +0300 (EET DST)
X-Scanned: Wed, 21 Jul 2004 15:47:51 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost)
	by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i6LClpQX009672;
	Wed, 21 Jul 2004 15:47:51 +0300
Received: from mgw-int2.ntc.nokia.com (172.21.143.97)
	by esdks002.ntc.nokia.com 00fiKSng; Wed, 21 Jul 2004 15:47:49 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 i6LClnu02826;
	Wed, 21 Jul 2004 15:47:49 +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);
	 Wed, 21 Jul 2004 15:47:48 +0300
Message-ID: <40FE65F4.90503@nokia.com>
Date: Wed, 21 Jul 2004 15:47:48 +0300
From: Janne Jalkanen <Janne.Jalkanen@nokia.com>
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: ext John Panzer <jpanzer@aol.net>
CC: Ken MacLeod <ken@bitsko.slc.ut.us>, Atom Syntax <atom-syntax@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <3f1451f504072008533002b6f4@mail.gmail.com> <40FD4233.7040101@franklinmint.fm> <40FD4569.4070401@intertwingly.net> <40FD481A.40009@franklinmint.fm> <98DE9BC4-DA6D-11D8-92AF-000A95A51C9E@sun.com> <40FD52E2.5010606@intertwingly.net> <40FD5537.2080500@franklinmint.fm> <3f1451f5040720104134622441@mail.gmail.com> <40FD5B45.2030202@franklinmint.fm> <m3hds2blgm.fsf@bitsko.slc.ut.us> <40FD6538.7020301@AOL.NET> <m3d62qbic3.fsf@bitsko.slc.ut.us> <40FD887C.5010909@AOL.NET>
In-Reply-To: <40FD887C.5010909@AOL.NET>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-OriginalArrivalTime: 21 Jul 2004 12:47:48.0730 (UTC) FILETIME=[ED7DD5A0:01C46F20]
X-MIME-Autoconverted: from 8bit to quoted-printable by mgw-int2.ntc.nokia.com id i6LClnu02826
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6LClumY078535
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



>(Aside: Should we be worried about optimizing the performance of CGI 
>based servers?)  I think this is a valid point, but it might be an edge 
>case (most servers capable of high volume static file GET requests can 
>fairly easily shunt low volume PUT/DELETE requests to other code, IMHO.)
>  
>
Yup.  And with Atom-Action you are still retaining GET anyway.

>This one I have some sympathy for.  But I do wonder if there are really 
>existing systems where a high-volume server farm is set up for binaries, 
>where the provider wants to support PUT/DELETE as well as creation for 
>said resources, and where the high-volume server farm cannot reasonably 
>also support PUT/DELETE.  Is this in the 80% of cases we should worry about?
>  
>
If blogging is to become über-popular, then possibly.  The binaries 
could be hosted on akamai or some other caching service more probably, 
though.  Then again, so would probably the feeds.

>Some suggestions:
>(1) Assume EditURI == "public" GET URI.  No problems.
>  
>
Possible.

>(2) Provide metadata on the "public" GET URI via HTTP headers.  Requires 
>an extra HEAD request to get metadata, followed by a PUT to the 
>retrieved resource EditURI.  Also requires server to support metadata on 
>every GET request.
>  
>
This is what PaceExtendedResourcePosting is suggesting.  I think an 
extra HEAD for PUT is not that heavy.

And is it really required to support, say, a Meta-Location header for 
GET as well, if it's supported for HEAD?  I mean, if a blogging service 
has a dedicated binary server, they can churn out the GETs as much as 
they like, and whenever someone wants to know where the metadata for an 
image lies (mostly an editing client) it would fire off a HEAD.

>I don't have a problem with PaceExtendedResourcePosting as an option, 
>but I don't think that it should necessarily be _required_ of servers.
>  
>
I agree.  It's rather easy to check whether metadata is supported: just 
check the existence of Meta-Location on the HEAD request.  If it's not 
there, you can't post metadata.

This would allow servers to support three levels of Atom API:

* Entries only  (Atom Core)
* Entries +binaries (If a ResourcePostURI is available)
* Entries + binaries + metadata (If a Meta-Location -header is available)

>:) Of course if a server can support PROPFIND easily, could it support 
>PUT and DELETE...? :)
>  
>
Yup :)

/Janne



From owner-atom-syntax@mail.imc.org  Wed Jul 21 08:58: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 IAA14655
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 08:58: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 i6LCoa3n078736;
	Wed, 21 Jul 2004 05:50: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 i6LCoaxe078735;
	Wed, 21 Jul 2004 05:50:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LCoZIJ078728
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 05:50:35 -0700 (PDT)
	(envelope-from Janne.Jalkanen@nokia.com)
Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158])
	by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6LCoXv03112;
	Wed, 21 Jul 2004 15:50:33 +0300 (EET DST)
X-Scanned: Wed, 21 Jul 2004 15:50:28 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost)
	by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i6LCoSon027327;
	Wed, 21 Jul 2004 15:50:28 +0300
Received: from mgw-int1.ntc.nokia.com (172.21.143.96)
	by esdks003.ntc.nokia.com 00JvDNbu; Wed, 21 Jul 2004 15:50:27 EEST
Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28])
	by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6LCoQn25825;
	Wed, 21 Jul 2004 15:50:26 +0300 (EET DST)
Received: from [172.21.60.114] ([172.21.60.114]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Wed, 21 Jul 2004 15:50:23 +0300
Message-ID: <40FE668D.3070202@nokia.com>
Date: Wed, 21 Jul 2004 15:50:21 +0300
From: Janne Jalkanen <Janne.Jalkanen@nokia.com>
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: ext Ken MacLeod <ken@bitsko.slc.ut.us>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net>	<40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net>	<40FD376D.8080407@franklinmint.fm>	<3f1451f504072008533002b6f4@mail.gmail.com>	<40FD4233.7040101@franklinmint.fm> <40FD4569.4070401@intertwingly.net>	<40FD481A.40009@franklinmint.fm>	<98DE9BC4-DA6D-11D8-92AF-000A95A51C9E@sun.com>	<40FD52E2.5010606@intertwingly.net> <40FD5537.2080500@franklinmint.fm>	<3f1451f5040720104134622441@mail.gmail.com>	<40FD5B45.2030202@franklinmint.fm> <m3hds2blgm.fsf@bitsko.slc.ut.us>	<40FD6538.7020301@AOL.NET> <m3d62qbic3.fsf@bitsko.slc.ut.us>	<40FD887C.5010909@AOL.NET> <m34qo2b201.fsf@bitsko.slc.ut.us>
In-Reply-To: <m34qo2b201.fsf@bitsko.slc.ut.us>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Jul 2004 12:50:23.0238 (UTC) FILETIME=[4995E260:01C46F21]
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 meant PROPFIND on the editing server, for locating all the editable
>resources.  WebDAV then also defines the "source" property for mapping
>  
>
Of course, this does not work on the resource constrained 
(PutDeleteBorked :) platforms, as discussed on the Other Thread. :)

/Janne



From owner-atom-syntax@mail.imc.org  Wed Jul 21 09:04: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 JAA14986
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 09:04: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 i6LCuOQ6079106;
	Wed, 21 Jul 2004 05:56: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 i6LCuOl2079105;
	Wed, 21 Jul 2004 05:56:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LCuNBp079086
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 05:56:23 -0700 (PDT)
	(envelope-from Janne.Jalkanen@nokia.com)
Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158])
	by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6LCuI716414;
	Wed, 21 Jul 2004 15:56:19 +0300 (EET DST)
X-Scanned: Wed, 21 Jul 2004 15:56:14 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost)
	by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i6LCuEuP008922;
	Wed, 21 Jul 2004 15:56:14 +0300
Received: from mgw-int1.ntc.nokia.com (172.21.143.96)
	by esdks003.ntc.nokia.com 00Ja9xrl; Wed, 21 Jul 2004 15:56:13 EEST
Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82])
	by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6LCuCn00235;
	Wed, 21 Jul 2004 15:56:12 +0300 (EET DST)
Received: from [172.21.60.114] ([172.21.60.114]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Wed, 21 Jul 2004 15:56:10 +0300
Message-ID: <40FE67EA.4060708@nokia.com>
Date: Wed, 21 Jul 2004 15:56:10 +0300
From: Janne Jalkanen <Janne.Jalkanen@nokia.com>
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: ext John Panzer <jpanzer@aol.net>
CC: Ken MacLeod <ken@bitsko.slc.ut.us>, Atom Syntax <atom-syntax@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <3f1451f504072008533002b6f4@mail.gmail.com> <40FD4233.7040101@franklinmint.fm> <40FD4569.4070401@intertwingly.net> <40FD481A.40009@franklinmint.fm> <98DE9BC4-DA6D-11D8-92AF-000A95A51C9E@sun.com> <40FD52E2.5010606@intertwingly.net> <40FD5537.2080500@franklinmint.fm> <3f1451f5040720104134622441@mail.gmail.com> <40FD5B45.2030202@franklinmint.fm> <m3hds2blgm.fsf@bitsko.slc.ut.us> <40FD6538.7020301@AOL.NET>
In-Reply-To: <40FD6538.7020301@AOL.NET>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Jul 2004 12:56:10.0662 (UTC) FILETIME=[18AA9460:01C46F22]
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 believe that one rationale for separating the EditURI and "public" 
>GETable URI for Atom entries is that the two may have different content 
>representations, e.g., for Wiki text that maps to publicly viewable 
>HTML.  Is there a use case for this in the case of binary resources? 
>That's about the only reason I can think of for a publishing system 
>_not_ making the URIs the same.
>  
>
I don't see how - binary is binary is binary.  If you want to offer a 
separate (like an image transforming service) you would figure out a 
different URI for each of the types you want to produce, and probably 
would not use Atom at all.  (But serve entries like 
http://example.com/png/image1 or http://example.com/jpg/image1).

For wikis, yes, it has to be assumed that you can GET the entry in two 
(perhaps three) forms: wikimarkup, rendered HTML and some hypothetical 
WikiML, and perhaps PUT them in all formats as well.  Which should be 
fun :-/

/Janne



From owner-atom-syntax@mail.imc.org  Wed Jul 21 10:26: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 KAA21746
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 10:26: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 i6LECi7K086370;
	Wed, 21 Jul 2004 07:12: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 i6LECi71086369;
	Wed, 21 Jul 2004 07:12:44 -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 i6LEChL1086356
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 07:12:43 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 16912 messnum 1885893 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 21 Jul 2004 14:12:40 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail02.svc.cra.dublin.eircom.net (qp 16912) with SMTP; 21 Jul 2004 14:12:40 -0000
Message-ID: <40FE79D6.9070301@dehora.net>
Date: Wed, 21 Jul 2004 15:12:38 +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: Janne Jalkanen <Janne.Jalkanen@nokia.com>
CC: mint@franklinmint.fm, Sam Ruby <rubys@intertwingly.net>,
        ext John Panzer <jpanzer@aol.net>, kwark.1511609@bloglines.com,
        joe.gregorio@gmail.com, Atom Syntax <atom-syntax@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <40FE62E5.6030707@nokia.com>
In-Reply-To: <40FE62E5.6030707@nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


Janne Jalkanen wrote:

> 
> 
>> Yeah, we are bending over backwards for the one client platform we can 
>> find that can set headers, but not the request method. This doesn't 
>> help Flash or existing SOAP software.
> 
> 
> I'm with Tim on this one; we're not bending over backwards (as in 
> redesigning the entire protocol around one client platform), but just 
> acknowledging the existence of a hundred million Java-enabled phones out 
> there (don't quote me on the figure, I think it's in the ballpark, but I 
> don't remember the official numbers :)

Here's a plausible counter argument. There'll be 10 times that many 
HTTP enabled devices in 3 years. In 3 years most of those 100M 
devices will have been thrown away. So this approach will be baking 
in a subset of HTTP for the short/medium term for what will be a 
miniority of phones. It's the next 900M phones running HTTP that 
need to be thought about.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Wed Jul 21 10:45: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 KAA23212
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 10:45: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 i6LEYGoi088324;
	Wed, 21 Jul 2004 07: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 i6LEYGQO088323;
	Wed, 21 Jul 2004 07:34:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LEYFTr088317
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 07:34:15 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net ([66.57.27.65])
	(authenticated bits=0)
	by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i6LEYJ5g023911;
	Wed, 21 Jul 2004 10:34:19 -0400
Message-ID: <40FE7EB3.5090002@intertwingly.net>
Date: Wed, 21 Jul 2004 10:33:23 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>
CC: Janne Jalkanen <Janne.Jalkanen@nokia.com>, mint@franklinmint.fm,
        ext John Panzer <jpanzer@aol.net>, kwark.1511609@bloglines.com,
        joe.gregorio@gmail.com, Atom Syntax <atom-syntax@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <40FE62E5.6030707@nokia.com> <40FE79D6.9070301@dehora.net>
In-Reply-To: <40FE79D6.9070301@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:

> Janne Jalkanen wrote:
> 
>>> Yeah, we are bending over backwards for the one client platform we 
>>> can find that can set headers, but not the request method. This 
>>> doesn't help Flash or existing SOAP software.
>>
>> I'm with Tim on this one; we're not bending over backwards (as in 
>> redesigning the entire protocol around one client platform), but just 
>> acknowledging the existence of a hundred million Java-enabled phones 
>> out there (don't quote me on the figure, I think it's in the ballpark, 
>> but I don't remember the official numbers :)
> 
> Here's a plausible counter argument. There'll be 10 times that many HTTP 
> enabled devices in 3 years. In 3 years most of those 100M devices will 
> have been thrown away. So this approach will be baking in a subset of 
> HTTP for the short/medium term for what will be a miniority of phones. 
> It's the next 900M phones running HTTP that need to be thought about.

You are both right... to a point.  There is a chicken and egg problem. 
People won't produce new phones with full support for HTTP until there 
are applications that demonstrate the value.

The first question we have to face is whether we want to design for the 
least common demoninator based on the facts as we know them today, or if 
we want to have a "primary" mechanism and one or more "fallbacks".

If we decide to go for least common denominator, we need to determine if 
we can rely on HTTP methods like DELETE and Atom specific HTTP headers.

If we decide to go for one or more fallbacks, we need to determine how 
many we are going to support.

The reality is that if we go for least common denominator now, there 
will be less motivation for cell phones to update, and even if they do, 
it will be hard to change the deployed base of Atom applications.

Even if we provide both a primary and fallback mechanism (with the 
primary having clear benefits in terms of bandwidth, etc), then there 
will be a period of time where it takes for Atom to get adopted widely, 
marketing to get the message, product designers to make the product, and 
for the new products to get widely deployed.

The option of ignoring a large class of existing cell phones entirely 
would severely affect the adoption of Atom and prevent this feedback 
loop from happening.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Wed Jul 21 10: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 KAA23924
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 10:53: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 i6LEfp6o089064;
	Wed, 21 Jul 2004 07:41:51 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6LEfp8g089063;
	Wed, 21 Jul 2004 07:41:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from 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 i6LEfo1l089057
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 07:41:51 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 32130 messnum 7748143 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 21 Jul 2004 14:41:47 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail01.svc.cra.dublin.eircom.net (qp 32130) with SMTP; 21 Jul 2004 14:41:47 -0000
Message-ID: <40FE80AA.600@dehora.net>
Date: Wed, 21 Jul 2004 15:41:46 +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: Sam Ruby <rubys@intertwingly.net>
CC: Janne Jalkanen <Janne.Jalkanen@nokia.com>, mint@franklinmint.fm,
        ext John Panzer <jpanzer@aol.net>, kwark.1511609@bloglines.com,
        joe.gregorio@gmail.com, Atom Syntax <atom-syntax@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <40FE62E5.6030707@nokia.com> <40FE79D6.9070301@dehora.net> <40FE7EB3.5090002@intertwingly.net>
In-Reply-To: <40FE7EB3.5090002@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:

> You are both right... to a point.  There is a chicken and egg problem. 
> People won't produce new phones with full support for HTTP until there 
> are applications that demonstrate the value.

Yeah, it's a classics standards adoption problem :) But I take it as 
a good sign that we have this problem.


> The first question we have to face is whether we want to design for the 
> least common demoninator based on the facts as we know them today, or if 
> we want to have a "primary" mechanism and one or more "fallbacks".
 > [...]
> The option of ignoring a large class of existing cell phones entirely 
> would severely affect the adoption of Atom and prevent this feedback 
> loop from happening.

Too true. Does that leave us looking for a "graceful upgrade" path 
based on client capabilities? I think it has to, but I don't know 
what that might be yet :)

cheers
Bill



From owner-atom-syntax@mail.imc.org  Wed Jul 21 11:35: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 LAA27533
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 11:35: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 i6LFFobv093022;
	Wed, 21 Jul 2004 08:15: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 i6LFFoe3093021;
	Wed, 21 Jul 2004 08:15:50 -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 i6LFFnIh093004
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 08:15:49 -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 i6LFFevu015944
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 11:15:41 -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 BJK59908 (AUTH bob@wyman.us);
	Wed, 21 Jul 2004 11:15:47 -0400 (EDT)
Message-Id: <200407211515.BJK59908@ms8.netsolmail.com>
Reply-To: <bob@wyman.us>
From: "Bob Wyman" <bob@wyman.us>
To: "'Atom Syntax'" <atom-syntax@imc.org>
Subject: BlogOn 2004 in Berkeley: Atom Community Get-together?
Date: Wed, 21 Jul 2004 11:15:50 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Thread-Index: AcRuge9tNqQ0qzA8Ty2SbbzJIF8ZHgAEb7+AAChdCmA=
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


	Will anyone be attending the BlogOn 2004 event[1] in Berkeley later
this week? It might be fun to get together for a drink during or after the
sessions... 
	Given that the focus of the conference is on blogging and social
media, it seems like an excellent excuse to "get social" with other members
of the Atom community.

		bob wyman

[1] http://www.blogonevent.com/blogon2004/




From owner-atom-syntax@mail.imc.org  Wed Jul 21 12:25: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 MAA01316
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 12:25:25 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LG7EOB098255;
	Wed, 21 Jul 2004 09:07:14 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6LG7ElH098254;
	Wed, 21 Jul 2004 09:07:14 -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 i6LG7Dcw098246
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 09:07:14 -0700 (PDT)
	(envelope-from distobj@acm.org)
Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian))
	id 1BnJdI-00039F-00; Wed, 21 Jul 2004 12:07:52 -0400
Date: Wed, 21 Jul 2004 12:07:52 -0400
To: Sam Ruby <rubys@intertwingly.net>
Cc: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
Message-ID: <20040721160752.GD30868@markbaker.ca>
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <40FE62E5.6030707@nokia.com> <40FE79D6.9070301@dehora.net> <40FE7EB3.5090002@intertwingly.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <40FE7EB3.5090002@intertwingly.net>
User-Agent: Mutt/1.3.28i
From: Mark Baker <distobj@acm.org>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


On Wed, Jul 21, 2004 at 10:33:23AM -0400, Sam Ruby wrote:
> Even if we provide both a primary and fallback mechanism (with the 
> primary having clear benefits in terms of bandwidth, etc), then there 
> will be a period of time where it takes for Atom to get adopted widely, 
> marketing to get the message, product designers to make the product, and 
> for the new products to get widely deployed.
> 
> The option of ignoring a large class of existing cell phones entirely 
> would severely affect the adoption of Atom and prevent this feedback 
> loop from happening.

I can't recall who it was, but somebody on IRC mentioned that we already
have a fallback mechanism; those clients that can't PUT or DELETE can't,
erm, PUT or DELETE stuff.  But they can still GET/HEAD/POST, which gives
them access to a lot of functionality.

Though I was supportive of Atom-Action, I kinda like this option too as
it seems to find a happy place in the feedback loop you mentioned, Sam.

Mark.



From owner-atom-syntax@mail.imc.org  Wed Jul 21 12: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 MAA01540
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 12: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 i6LG4xrB097988;
	Wed, 21 Jul 2004 09:04: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 i6LG4xOn097987;
	Wed, 21 Jul 2004 09:04:59 -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 i6LG4vwP097980
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 09:04:58 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p06110447bd243f1e99c2@[10.20.30.249]>
In-Reply-To: <40FE7EB3.5090002@intertwingly.net> <40FE80AA.600@dehora.net>
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net>
 <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net>
 <40FD376D.8080407@franklinmint.fm> <40FE62E5.6030707@nokia.com>
 <40FE79D6.9070301@dehora.net> <40FE7EB3.5090002@intertwingly.net>
 <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net>
 <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net>
 <40FD376D.8080407@franklinmint.fm> <40FE62E5.6030707@nokia.com>
 <40FE79D6.9070301@dehora.net> <40FE7EB3.5090002@intertwingly.net>
 <40FE80AA.600@dehora.net>
Date: Wed, 21 Jul 2004 09:04:49 -0700
To: atom-syntax@imc.org
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
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 10:33 AM -0400 7/21/04, Sam Ruby wrote:
>The first question we have to face is whether we want to design for 
>the least common demoninator based on the facts as we know them 
>today, or if we want to have a "primary" mechanism and one or more 
>"fallbacks".
>
>  . . .
>
>If we decide to go for one or more fallbacks, we need to determine 
>how many we are going to support.
>
>The reality is that if we go for least common denominator now, there 
>will be less motivation for cell phones to update, and even if they 
>do, it will be hard to change the deployed base of Atom applications.

Welcome to the IETF. And a big +1 to what Sam said. We have *lots* of 
experience with grappling with these kinds of questions, but with 
different constraints. And we have lots of experience with the 
results.

Basically: if we provide a fallback, the fallback will be with us 
forever, and adoption of the primary method will be slow, like 
probably a decade (think POP vs. IMAP).

>The option of ignoring a large class of existing cell phones 
>entirely would severely affect the adoption of Atom and prevent this 
>feedback loop from happening.

Maybe. Cell phones are still in the adoption phase, and there is a 
reasonable turnover in phones. If our protocol worked on some current 
cell phones but not others, the others would be improved in the 
future, certainly in a small number of years. Some people will not be 
able to use Atom in their current phones, but will be able to use it 
in the phones they will replace their current phones with.

In the short run, services will possibly appear that act as proxies 
for the less-enabled phones to do what the more-enabled phones can do 
by themselves. As long as our solution is proxyable, we won't be 
"excluding" anyone even in the short term.

Again, the alternative is that we need to support two protocols 
forever. More specifically, we need to support the less-able protocol 
forever. A possibly-better choice would be to go with the one 
protocol we really want, and have those not able to run it possibly 
proxy in the short run and be able to run it on their new phones 
within a small number of years.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Wed Jul 21 12:33: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 MAA01809
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 12:33: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 i6LGNY0P000494;
	Wed, 21 Jul 2004 09:23:34 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6LGNYM0000493;
	Wed, 21 Jul 2004 09:23:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtp.well.com (smtp.well.com [206.14.209.7])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LGNY5T000459
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 09:23:34 -0700 (PDT)
	(envelope-from xian@well.com)
X-WELL-Auth: Yes
Received: from [10.0.1.2] (adsl-64-160-55-49.dsl.snfc21.pacbell.net [64.160.55.49])
	by smtp.well.com (8.13.0/8.13.0) with ESMTP id i6LGNKbU012587
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 09:23:22 -0700 (PDT)
Mime-Version: 1.0
X-Sender: xian@mail.well.com
Message-Id: <p0611040ebd244898610d@[10.0.1.2]>
In-Reply-To: <200407211515.BJK59908@ms8.netsolmail.com>
References: <200407211515.BJK59908@ms8.netsolmail.com>
Date: Wed, 21 Jul 2004 09:22:21 -0700
To: "'Atom Syntax'" <atom-syntax@imc.org>
From: Christian Crumlish <xian@well.com>
Subject: Re: BlogOn 2004 in Berkeley: Atom Community Get-together?
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Virus-Scanned: clamd / ClamAV version 0.74, clamav-milter version 0.74a
	on smtp
X-Virus-Status: Clean
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'll be there and I'm co-hosting a blogger dinner Friday night. All 
Atomites welcome.

	--xian

>	Will anyone be attending the BlogOn 2004 event[1] in Berkeley later
>this week? It might be fun to get together for a drink during or after the
>sessions...
>	Given that the focus of the conference is on blogging and social
>media, it seems like an excellent excuse to "get social" with other members
>of the Atom community.
>
>		bob wyman
>
>[1] http://www.blogonevent.com/blogon2004/

-- 
In an attention economy, Attention Deficit is a survival trait. 
http://ThePowerOfMany.com/



From owner-atom-syntax@mail.imc.org  Wed Jul 21 12:48: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 MAA02850
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 12:48: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 i6LGXkd1002026;
	Wed, 21 Jul 2004 09: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 i6LGXk2L002025;
	Wed, 21 Jul 2004 09:33: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 (mproxy.gmail.com [216.239.56.253])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6LGXk0d002016
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 09:33:46 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id w29so217295cwb
        for <atom-syntax@imc.org>; Wed, 21 Jul 2004 09:33:44 -0700 (PDT)
Received: by 10.11.118.39 with SMTP id q39mr10477cwc;
        Wed, 21 Jul 2004 09:33:44 -0700 (PDT)
Message-ID: <3f1451f504072109331d10f35a@mail.gmail.com>
Date: Wed, 21 Jul 2004 12:33:44 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Mark Baker <distobj@acm.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
Cc: Sam Ruby <rubys@intertwingly.net>, Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <20040721160752.GD30868@markbaker.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <40FE62E5.6030707@nokia.com> <40FE79D6.9070301@dehora.net> <40FE7EB3.5090002@intertwingly.net> <20040721160752.GD30868@markbaker.ca>
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 Wed, 21 Jul 2004 12:07:52 -0400, Mark Baker <distobj@acm.org> wrote:
> 
> On Wed, Jul 21, 2004 at 10:33:23AM -0400, Sam Ruby wrote:
> > Even if we provide both a primary and fallback mechanism (with the
> > primary having clear benefits in terms of bandwidth, etc), then there
> > will be a period of time where it takes for Atom to get adopted widely,
> > marketing to get the message, product designers to make the product, and
> > for the new products to get widely deployed.
> >
> > The option of ignoring a large class of existing cell phones entirely
> > would severely affect the adoption of Atom and prevent this feedback
> > loop from happening.
> 
> I can't recall who it was, but somebody on IRC mentioned that we already
> have a fallback mechanism; those clients that can't PUT or DELETE can't,
> erm, PUT or DELETE stuff.  But they can still GET/HEAD/POST, which gives
> them access to a lot of functionality.

That was me. I was in particular referencing our charter:

    The working group will also take steps to ensure interoperability, by:
    ...
    * clearly nominating conformance levels for different types of
        software

    -joe

-- 
Joe Gregorio        http://bitworking.org



From owner-atom-syntax@mail.imc.org  Wed Jul 21 13:08: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 NAA04071
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 13:08: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 i6LGtmRY005821;
	Wed, 21 Jul 2004 09: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 i6LGtmfx005820;
	Wed, 21 Jul 2004 09:55: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 i6LGtl77005806;
	Wed, 21 Jul 2004 09:55:47 -0700 (PDT)
	(envelope-from mint@franklinmint.fm)
Received: from w122.z065105092.nyc-ny.dsl.cnc.net ([65.105.92.122] helo=[192.168.254.94])
	by web02.designerslab.net with asmtp (Exim 4.34)
	id 1BnKNe-0007AB-K3; Wed, 21 Jul 2004 16:55:46 +0000
Message-ID: <40FEA00E.7050304@franklinmint.fm>
Date: Wed, 21 Jul 2004 12:55:42 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Hoffman / IMC <phoffman@imc.org>
CC: atom-syntax@imc.org
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <40FE62E5.6030707@nokia.com> <40FE79D6.9070301@dehora.net> <40FE7EB3.5090002@intertwingly.net> <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <40FE62E5.6030707@nokia.com> <40FE79D6.9070301@dehora.net> <40FE7EB3.5090002@intertwingly.net> <40FE80AA.600@dehora.net> <p06110447bd243f1e99c2@[10.20.30.249]>
In-Reply-To: <p06110447bd243f1e99c2@[10.20.30.249]>
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


Paul Hoffman / IMC wrote:

> 
> Again, the alternative is that we need to support two protocols forever. 
> More specifically, we need to support the less-able protocol forever. A 
> possibly-better choice would be to go with the one protocol we really 
> want

This is a great argument against inventing our own fallback mechanism, 
like a custom header or <action> element. However, I'm not sure "the one 
protocol we really want" is a completely settled issue. I think the 
current SHOULD-level requirement for SOAP is a decent compromise, as 
there is demand for SOAP, especially on Intranets and other private 
networks. Existing implementations have implemented the SOAP fallback 
without much difficulty or duplication of infrastructure.

It may be that the SOAP solution will not have all the capabilities of 
the ReST one (e.g. PUT/DELETE on binary content), and that's ok, too.

I agree with Anil Dash:

"It may be that we're all so close to the deeply web-savvy part of the
software world that people who do all their coding in Visual Studio,
implementing SOAP services with a WSDL drag and drop, are invisible. I 
know they ain't cool, but they're important for growing this entire 
industry we're in, and they probably *don't* have a voice on this 
mailing list since they're not yet very aware of weblogs at all." [0]

Robert Sayre

[0] http://www.imc.org/atom-syntax/mail-archive/msg03106.html



From owner-atom-syntax@mail.imc.org  Wed Jul 21 13:18: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 NAA04902
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 13: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 i6LH3c0V006901;
	Wed, 21 Jul 2004 10:03: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 i6LH3cKZ006900;
	Wed, 21 Jul 2004 10:03: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 SMTP id i6LH3boN006882
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 10:03:37 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id d78so18463rnf
        for <atom-syntax@imc.org>; Wed, 21 Jul 2004 10:03:38 -0700 (PDT)
Received: by 10.38.181.24 with SMTP id d24mr35610rnf;
        Wed, 21 Jul 2004 10:03:38 -0700 (PDT)
Message-ID: <14be96d3040721100379e0ffe5@mail.gmail.com>
Date: Wed, 21 Jul 2004 13:03:38 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
Cc: atom-syntax@imc.org
In-Reply-To: <p06110447bd243f1e99c2@10.20.30.249>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net>
 <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net>
 <40FD376D.8080407@franklinmint.fm> <40FE62E5.6030707@nokia.com>
 <40FE79D6.9070301@dehora.net> <40FE7EB3.5090002@intertwingly.net>
 <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net>
 <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net>
 <40FD376D.8080407@franklinmint.fm> <40FE62E5.6030707@nokia.com>
 <40FE79D6.9070301@dehora.net> <40FE7EB3.5090002@intertwingly.net>
 <40FE80AA.600@dehora.net> <p06110447bd243f1e99c2@10.20.30.249>
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 Wed, 21 Jul 2004 09:04:49 -0700, Paul Hoffman / IMC <phoffman@imc.org> wrote:

> Again, the alternative is that we need to support two protocols
> forever. More specifically, we need to support the less-able protocol
> forever. A possibly-better choice would be to go with the one
> protocol we really want, and have those not able to run it possibly
> proxy in the short run and be able to run it on their new phones

+1 on going with the protocol we really want.  I'm not convinced that
any of the vendors of "differently abled" clients are paying attention
to us in the short term anyway.

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Wed Jul 21 13:30: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 NAA06142
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 13:30: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 i6LHMEnG008354;
	Wed, 21 Jul 2004 10:22: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 i6LHMEso008353;
	Wed, 21 Jul 2004 10:22:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.245])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6LHMDO3008337
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 10:22:13 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id w41so263949cwb
        for <atom-syntax@imc.org>; Wed, 21 Jul 2004 10:22:12 -0700 (PDT)
Received: by 10.11.116.80 with SMTP id o80mr11995cwc;
        Wed, 21 Jul 2004 10:22:12 -0700 (PDT)
Message-ID: <3f1451f504072110225e5f1f0c@mail.gmail.com>
Date: Wed, 21 Jul 2004 13:22:12 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: mint@franklinmint.fm
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
Cc: Paul Hoffman / IMC <phoffman@imc.org>, atom-syntax@imc.org
In-Reply-To: <40FEA00E.7050304@franklinmint.fm>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <40FE62E5.6030707@nokia.com> <40FE79D6.9070301@dehora.net> <40FE7EB3.5090002@intertwingly.net> <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <40FE62E5.6030707@nokia.com> <40FE79D6.9070301@dehora.net> <40FE7EB3.5090002@intertwingly.net> <40FE80AA.600@dehora.net> <p06110447bd243f1e99c2@[10.20.30.249]> <40FEA00E.7050304@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 Wed, 21 Jul 2004 12:55:42 -0400, Robert Sayre <mint@franklinmint.fm> wrote:
> I agree with Anil Dash:
> 
> "It may be that we're all so close to the deeply web-savvy part of the
> software world that people who do all their coding in Visual Studio,
> implementing SOAP services with a WSDL drag and drop, are invisible. I
> know they ain't cool, but they're important for growing this entire
> industry we're in, and they probably *don't* have a voice on this
> mailing list since they're not yet very aware of weblogs at all." [0]

We are an IETF Working Group. To participate, to have a voice,
is simply a matter of joining a mailing list.

-1 to trying to guessing the desires of 
    developers unwilling to join a mailing list.

-1  to guessing the desires of developers who
    don't even know they need to implement Atom yet.

    Thanks,
    -joe

-- 
Joe Gregorio        http://bitworking.org



From owner-atom-syntax@mail.imc.org  Wed Jul 21 13: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 NAA07317
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 13: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 i6LHYeIf009329;
	Wed, 21 Jul 2004 10:34: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 i6LHYeJW009328;
	Wed, 21 Jul 2004 10:34: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 i6LHYdpB009315;
	Wed, 21 Jul 2004 10:34: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 1BnKzJ-0000ZH-Ma; Wed, 21 Jul 2004 17:34:41 +0000
Message-ID: <40FEA92F.7000407@franklinmint.fm>
Date: Wed, 21 Jul 2004 13:34:39 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Joe Gregorio <joe.gregorio@gmail.com>
CC: Paul Hoffman / IMC <phoffman@imc.org>, atom-syntax@imc.org
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <40FE62E5.6030707@nokia.com> <40FE79D6.9070301@dehora.net> <40FE7EB3.5090002@intertwingly.net> <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <40FE62E5.6030707@nokia.com> <40FE79D6.9070301@dehora.net> <40FE7EB3.5090002@intertwingly.net> <40FE80AA.600@dehora.net> <p06110447bd243f1e99c2@[10.20.30.249]> <40FEA00E.7050304@franklinmint.fm> <3f1451f504072110225e5f1f0c@mail.gmail.com>
In-Reply-To: <3f1451f504072110225e5f1f0c@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - web02.designerslab.net
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - franklinmint.fm
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


Joe Gregorio wrote:

> 
> -1 to trying to guessing the desires of 
>     developers unwilling to join a mailing list.
> 
> -1  to guessing the desires of developers who
>     don't even know they need to implement Atom yet.
> 

um, Anil works for a vendor of blogging software. He is telling us what 
his customers are asking for. Should I go through the mailing list 
*again* and list all of the voices in support of SOAP?

Robert Sayre



From owner-atom-syntax@mail.imc.org  Wed Jul 21 14:07:32 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08711
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 14:07:32 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LHssF0011050;
	Wed, 21 Jul 2004 10: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 i6LHssQ6011049;
	Wed, 21 Jul 2004 10:54: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 i6LHsrna011035;
	Wed, 21 Jul 2004 10:54: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 1BnLIt-0001On-Oz; Wed, 21 Jul 2004 17:54:55 +0000
Message-ID: <40FEADEE.6020700@franklinmint.fm>
Date: Wed, 21 Jul 2004 13:54:54 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Joe Gregorio <joe.gregorio@gmail.com>
CC: Paul Hoffman / IMC <phoffman@imc.org>, atom-syntax@imc.org
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <40FE62E5.6030707@nokia.com> <40FE79D6.9070301@dehora.net> <40FE7EB3.5090002@intertwingly.net> <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <40FE62E5.6030707@nokia.com> <40FE79D6.9070301@dehora.net> <40FE7EB3.5090002@intertwingly.net> <40FE80AA.600@dehora.net> <p06110447bd243f1e99c2@[10.20.30.249]> <40FEA00E.7050304@franklinmint.fm> <3f1451f504072110225e5f1f0c@mail.gmail.com> <40FEA92F.7000407@franklinmint.fm> <3f1451f504072110472e85cffd@mail.gmail.com>
In-Reply-To: <3f1451f504072110472e85cffd@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - web02.designerslab.net
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - franklinmint.fm
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


Joe Gregorio wrote:

> 
> And I believe you erroneously put me on that 
> list the last time you compiled it :)

haha, yeah. I think that was the only mistake, though.

> 
> As I have stated strongly before [1], I believe the voices
> on the list are the ones that matter. 
> 

I am strongly in favor of including an optional SOAP interface in this 
WG's deliverables. It can be a MAY rather than a SHOULD.

Robert Sayre



From owner-atom-syntax@mail.imc.org  Wed Jul 21 14:10: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 OAA08849
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 14:10: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 i6LHkH2M010435;
	Wed, 21 Jul 2004 10:46: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 i6LHkHp3010434;
	Wed, 21 Jul 2004 10:46:17 -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 i6LHkGDI010421;
	Wed, 21 Jul 2004 10:46:16 -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 i6LHkJil029759;
	Wed, 21 Jul 2004 11:46:19 -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 <0I17005Y6QP7ON@edgemail1.Central.Sun.COM>; Wed,
 21 Jul 2004 11:46:19 -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 <0I1700CZCQP6E1@mail.sun.net>; Wed,
 21 Jul 2004 11:46:19 -0600 (MDT)
Date: Wed, 21 Jul 2004 10:46:26 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
In-reply-to: <3f1451f504072110225e5f1f0c@mail.gmail.com>
To: Joe Gregorio <joe.gregorio@gmail.com>
Cc: Paul Hoffman / IMC <phoffman@imc.org>, atom-syntax@imc.org,
        mint@franklinmint.fm
Message-id: <E3575CA1-DB3D-11D8-AC8C-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: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net>
 <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net>
 <40FD376D.8080407@franklinmint.fm> <40FE62E5.6030707@nokia.com>
 <40FE79D6.9070301@dehora.net> <40FE7EB3.5090002@intertwingly.net>
 <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net>
 <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net>
 <40FD376D.8080407@franklinmint.fm> <40FE62E5.6030707@nokia.com>
 <40FE79D6.9070301@dehora.net> <40FE7EB3.5090002@intertwingly.net>
 <40FE80AA.600@dehora.net> <p06110447bd243f1e99c2@[10.20.30.249]>
 <40FEA00E.7050304@franklinmint.fm> <3f1451f504072110225e5f1f0c@mail.gmail.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 Jul 21, 2004, at 10:22 AM, Joe Gregorio wrote:

> We are an IETF Working Group. To participate, to have a voice,
> is simply a matter of joining a mailing list.
>
> -1 to trying to guessing the desires of
>     developers unwilling to join a mailing list.
>
> -1  to guessing the desires of developers who
>     don't even know they need to implement Atom yet.

I'm a member of this Working Group and I plan to take the needs of 
large existing communities very seriously in the design of Atom.   I 
guess there's no rule that says you have to do this, but fortunately 
there's no rule that prevents it. -Tim



From owner-atom-syntax@mail.imc.org  Wed Jul 21 14: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 OAA09121
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 14:12: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 i6LHlgSi010566;
	Wed, 21 Jul 2004 10:47: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 i6LHlgfs010565;
	Wed, 21 Jul 2004 10:47: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 (mproxy.gmail.com [216.239.56.253])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6LHlfLL010553
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 10:47:41 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id w41so280221cwb
        for <atom-syntax@imc.org>; Wed, 21 Jul 2004 10:47:40 -0700 (PDT)
Received: by 10.11.116.63 with SMTP id o63mr13000cwc;
        Wed, 21 Jul 2004 10:47:40 -0700 (PDT)
Message-ID: <3f1451f504072110472e85cffd@mail.gmail.com>
Date: Wed, 21 Jul 2004 13:47:40 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: mint@franklinmint.fm
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
Cc: Paul Hoffman / IMC <phoffman@imc.org>, atom-syntax@imc.org
In-Reply-To: <40FEA92F.7000407@franklinmint.fm>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <40FE62E5.6030707@nokia.com> <40FE79D6.9070301@dehora.net> <40FE7EB3.5090002@intertwingly.net> <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <40FE62E5.6030707@nokia.com> <40FE79D6.9070301@dehora.net> <40FE7EB3.5090002@intertwingly.net> <40FE80AA.600@dehora.net> <p06110447bd243f1e99c2@[10.20.30.249]> <40FEA00E.7050304@franklinmint.fm> <3f1451f504072110225e5f1f0c@mail.gmail.com> <40FEA92F.7000407@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 Wed, 21 Jul 2004 13:34:39 -0400, Robert Sayre <mint@franklinmint.fm> wrote:
> Joe Gregorio wrote:
> 
> >
> > -1 to trying to guessing the desires of
> >     developers unwilling to join a mailing list.
> >
> > -1  to guessing the desires of developers who
> >     don't even know they need to implement Atom yet.
> >
> 
> um, Anil works for a vendor of blogging software. He is telling us what
> his customers are asking for. Should I go through the mailing list
> *again* and list all of the voices in support of SOAP?

And I believe you erroneously put me on that 
list the last time you compiled it :)

As I have stated strongly before [1], I believe the voices
on the list are the ones that matter. 

[1] http://www.imc.org/atom-syntax/mail-archive/msg04636.html

    -joe

-- 
Joe Gregorio        http://bitworking.org



From owner-atom-syntax@mail.imc.org  Wed Jul 21 14: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 OAA10359
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 14:27: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 i6LIICHn013029;
	Wed, 21 Jul 2004 11:18: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 i6LIICAk013028;
	Wed, 21 Jul 2004 11:18:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LIIBGo013021
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 11:18: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 i6LIIEil016318
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 12:18: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 <0I17005JYS6EON@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Wed, 21 Jul 2004 12:18:15 -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 <0I17009ZZS6DIV@mail.sun.net> for atom-syntax@imc.org; Wed,
 21 Jul 2004 12:18:14 -0600 (MDT)
Date: Wed, 21 Jul 2004 11:18:21 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Propose partial consensus on dates
To: Atom-Syntax Syntax <atom-syntax@imc.org>
Message-id: <593B9E26-DB42-11D8-AC8C-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: <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 know this isn't officially in the current-work list, but a lot of 
people have been putting furious energy into the dates discussion.  As 
co-chair I *think* I detect rough consensus on part of the problem.  If 
I'm right, then we can retire that part of it and focus on what's left 
over.

BTW, on this one, *rough* consensus may be the best we can do, I'm 
enumerating what look like strong-majority positions.  As always, the 
list is hard to keep on top of, my reading may be wrong, feel free to 
disagree.

1. Each entry must have a "modified" which is an assertion from the 
publisher as to when the resource was last changed.  This should be in 
RFC3339 format.  Example: a travel journal, the entry for the 8th was 
<atom:modified> on the 17th.
2. Each entry may have a "display" date - you can think of it as part 
of the title - which is the date primarily associated by the publisher 
with the resource.  Example: the travel-journal entry for the 8th has 
an <atom:display> of the 8th.  There remain outstanding problems of 
both name and format on this one, see below; however, the date is 
machine-processable, not free text.
3. Each entry may have a "created" date - the date on which it came to 
be.  For example, the travel-journal entry for the 8th was 
<atom:created> on the 11th.  RFC3339.

NOTES: It seems that substantial amounts of existing software use 
either or both of the "modified" and "display" semantics.  It also 
seems that while some software records the "created" semantic, nobody 
actually does anything with it; on the other hand nobody suggests that 
it causes any problems.

PROBLEMS:
- the name "display" is not that great.  I've seen suggestions of 
"base" and "described".  It occurs to me that in North American 
journalistic lingo, the word "dateline" *exactly* describes the 
semantics.
- it might not be possible to use RFC3339 syntax for "display".  
Existing deployments are not able to use timezones.
- there are a variety of incompatible requirements (some of them quite 
strong) for another date called "issued" which doesn't seem to be any 
of these.

So, we need proposals for:
- a better name than "display".  
<just-tim-not-cochair>I</just-tim-not-cochair> hereby propose 
"dateline"
- what the right format is for "display"
- are there any must-have missing dates (I wonder if "created" could be 
defined in a way that would meet at least some of the needs around 
"issued").

NEXT:
- if you disagree that we have rough consensus as outlined, say so, 
nobody's feelings will be hurt.
- if you have brilliant proposals for any of the problems, speak up

  -Tim



From owner-atom-syntax@mail.imc.org  Wed Jul 21 14:39:49 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11333
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 14:39:48 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LIQch3013661;
	Wed, 21 Jul 2004 11:26: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 i6LIQcQI013660;
	Wed, 21 Jul 2004 11:26:38 -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 i6LIQbXh013654
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 11:26:37 -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 i6LIQeBC017998;
	Wed, 21 Jul 2004 11:26:40 -0700 (PDT)
Received: from [149.123.77.131] ([149.123.77.131])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id i6LIQTVd017108;
	Wed, 21 Jul 2004 11:26:40 -0700 (PDT)
In-Reply-To: <5C9766B62794C5C86608A1A151CA1.MAI@journurl.com>
References: <5C9766B62794C5C86608A1A151CA1.MAI@journurl.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-14-454225069; protocol="application/pkcs7-signature"
Message-Id: <9A158B22-DB3A-11D8-B3AB-000A95DC3D90@mac.com>
Cc: "'Atom-Syntax'" <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: Those dates again
Date: Wed, 21 Jul 2004 13:22:54 -0400
To: "Roger B." <roger@agincourtmedia.com>
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-14-454225069
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 21 Jul 2004, at 1:13 am, Roger B. wrote:

> But in desktop aggregators that mark items unread or bump them to the 
> top
> upon modification, I've seen folks voice frustration at the way RSS 
> forces
> them to use content hashes to track changes... as more and more people 
> add
> dynamic advertising to their feeds, such developers need a clean 
> mechanism
> for alerting the user when the same old item contains something 
> additional
> beyond a banner ad.

I haven't seen many feeds with adverts in, but I have seen lots where 
people constantly meddle with wording and punctuation, which <modified> 
isn't going to solve. The <updated> element discussed by Sam a few days 
ago seems much more appropriate.

Graham
--Apple-Mail-14-454225069
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
9w0BCQUxDxcNMDQwNzIxMTcyMjU1WjAjBgkqhkiG9w0BCQQxFgQUe9sRGR4Vdb8Xi/wLk+CN24UO
eZQweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAcYvf1xUa4oJs79uhk2ZfF2ox
YdEofQVD47pTbuMcnCbGI/3CCbVm9ojDj4p25DRABV1oWjoyprWTTcF0aeVp7ybEY6aCumTY05uP
YSnAiH5HN0j6iAYjqyYxqlyzIwJQ3Flw7Naqm23cc0ekD18Kc6utlnRP1GViISohh6LMrp/0JI9M
T49A70VK8mo925FxTqHreU7BgT5Qv7ZfJWehxBo+VQ6sfrCYdmoQ83qFd3GiFrywOlKFjv9S/dMG
RbFHJ+spfYG76xGboaFcLyyA6rClnURlg+qFNCT5FtWfbfy9aECAj6ah1tSErk4k0XvwC0k0iqvg
BTse4zBAQoyAGAAAAAAAAA==

--Apple-Mail-14-454225069--



From owner-atom-syntax@mail.imc.org  Wed Jul 21 14:58: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 OAA12686
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 14:58: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 i6LIeECK015270;
	Wed, 21 Jul 2004 11: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 i6LIeEQD015269;
	Wed, 21 Jul 2004 11: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.85])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LIeE6M015263
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 11:40:14 -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 i6LIeIas000130;
	Wed, 21 Jul 2004 11:40:18 -0700 (PDT)
Received: from [149.123.77.131] ([149.123.77.131])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin01/MantshX 4.0) with ESMTP id i6LIeE3b015148;
	Wed, 21 Jul 2004 11:40:17 -0700 (PDT)
In-Reply-To: <593B9E26-DB42-11D8-AC8C-000A95A51C9E@sun.com>
References: <593B9E26-DB42-11D8-AC8C-000A95A51C9E@sun.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-15-458864742; protocol="application/pkcs7-signature"
Message-Id: <678B8DFE-DB45-11D8-B3AB-000A95DC3D90@mac.com>
Cc: Atom-Syntax Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: Propose partial consensus on dates
Date: Wed, 21 Jul 2004 14:40:13 -0400
To: Tim Bray <Tim.Bray@Sun.COM>
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-15-458864742
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 21 Jul 2004, at 2:18 pm, Tim Bray wrote:

> 1. Each entry must have a "modified" which is an assertion from the 
> publisher as to when the resource was last changed.  This should be in 
> RFC3339 format.  Example: a travel journal, the entry for the 8th was 
> <atom:modified> on the 17th.

Why "must"? We don't have a real use case for it yet. It's certainly 
not very interesting to end users in the way a real Updated date would 
be.

> 2. Each entry may have a "display" date - you can think of it as part 
> of the title - which is the date primarily associated by the publisher 
> with the resource.  Example: the travel-journal entry for the 8th has 
> an <atom:display> of the 8th.  There remain outstanding problems of 
> both name and format on this one, see below; however, the date is 
> machine-processable, not free text.

Fair enough.

> 3. Each entry may have a "created" date - the date on which it came to 
> be.  For example, the travel-journal entry for the 8th was 
> <atom:created> on the 11th.  RFC3339.

Maybe.

> - the name "display" is not that great.  I've seen suggestions of 
> "base" and "described".  It occurs to me that in North American 
> journalistic lingo, the word "dateline" *exactly* describes the 
> semantics.

Agreed "display" is not a good. "timestamp" (or "datestamp") might be 
OK.

> - there are a variety of incompatible requirements (some of them quite 
> strong) for another date called "issued" which doesn't seem to be any 
> of these.

The only incompatibity I saw was whether it could be changed over time, 
and <updated> solves that problem. <issued> seemed to be the only one 
there's consensus on.

And <updated>? I liked that. Sam liked it. It solves a major problem 
(we can't go to version 1.0 without a real mechanism for flagging 
updated entries - and the <supercedes> nonsense is a non-starter).

Graham
--Apple-Mail-15-458864742
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
9w0BCQUxDxcNMDQwNzIxMTg0MDE0WjAjBgkqhkiG9w0BCQQxFgQUJ6Y6wCHZcnRh4EZGbB27qxz4
5rAweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAFeB1IVFkhP0TKLC+H0ajOG2g
KCukPX+WGqGlg+d9kIYQTcEM5LE58qWxI2raA/uFHIGe0K/TA2n9aWT4uMTzLIM026OU2pDWhWnc
evkQJNPY5XjMDrvoHtuTHWtxF3BL5Fb0aWf37wo6Zghpmj3Ph2EmS9JYag1Ec7VADYzUwLqY7M5+
vEJazEG99JGLh5g/ufABqnqzJruV8G3BM7brjf2OWFhUVPXF/13GNYbkk0Kr8bRoImWtm5FYJ1hq
q9O6Ot6WC0EObSSfHAF+Eh/OE3mgF+m74WTIOJW/rj8gBW38DVqKrxUU0hqJ8x4TwgSowcrqvhej
42pSdD59a1prowAAAAAAAA==

--Apple-Mail-15-458864742--



From owner-atom-syntax@mail.imc.org  Wed Jul 21 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 PAA16854
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 15:37: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 i6LJREop019288;
	Wed, 21 Jul 2004 12:27: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 i6LJRDdd019287;
	Wed, 21 Jul 2004 12:27: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.47])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LJRDGk019281
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 12:27:13 -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 i6LJRGGQ013239;
	Wed, 21 Jul 2004 12:27:16 -0700 (PDT)
Received: from [149.123.77.131] ([149.123.77.131])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id i6LJQkaA009248;
	Wed, 21 Jul 2004 12:26:52 -0700 (PDT)
In-Reply-To: <40FE79D6.9070301@dehora.net>
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <40FE62E5.6030707@nokia.com> <40FE79D6.9070301@dehora.net>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-16-461656583; protocol="application/pkcs7-signature"
Message-Id: <E79CB9C2-DB4B-11D8-B3AB-000A95DC3D90@mac.com>
Cc: Atom Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
Date: Wed, 21 Jul 2004 15:26:45 -0400
To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.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-16-461656583
Content-Type: text/plain;
	charset=ISO-8859-1;
	format=flowed
Content-Transfer-Encoding: quoted-printable

On 21 Jul 2004, at 10:12 am, Bill de h=D3ra wrote:

> Here's a plausible counter argument. There'll be 10 times that many=20
> HTTP enabled devices in 3 years. In 3 years most of those 100M devices=20=

> will have been thrown away. So this approach will be baking in a=20
> subset of HTTP for the short/medium term for what will be a miniority=20=

> of phones. It's the next 900M phones running HTTP that need to be=20
> thought about.

Who says the next 900M phones will be running full HTTP? Your argument=20=

relies on all phones being sold today being sold today being capable of=20=

full HTTP, which is so not true. Market share figures are surprisingly=20=

hard to find on the web, but walk into any phone shop and you'll see=20
far more J2ME handsets than Smartphones. Look at this page from Nokia=20
of their latest 20 models:

  http://www.nokia.com/nokia/0,8764,73,00.html

I count 8 smartphones, 10 J2ME-enabled, and 2 that are neither. And=20
most of the smartphones are niche models, the J2ME are the high-volume=20=

models. So, no, relying on the old handsets being thrown away is not an=20=

option when they still make up the majority of the market for new=20
phones. If we're serious about supporting Atom on mobile phones, then=20
that means J2ME.

Graham=

--Apple-Mail-16-461656583
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
9w0BCQUxDxcNMDQwNzIxMTkyNjQ2WjAjBgkqhkiG9w0BCQQxFgQU1dOJyvICMzI3iv2FboEbsEP2
RDwweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAzYSv6elJQ0xmbxG+SkUDu/Wa
IO0c1Ajs4y2wwtBehbKTHJAhtEQFzjd2+i972rRtdLUpPI0hYFiGFX+v9/VCwbQYTG0JuOw2xlvx
/TSnwgV9Q6cYcyHjVxp8h4WdjpFl6AwIl63tr4CcpY3FjRRZaDunXB/cMn+NZkgdlBklWCuvYHdh
hjO6b6CPKwQhnmyaUq7DFE2ADTFZZOkeaVcvdc9pbjHQ8Zrzo/FerimzqzoCRtX2uZ+Fl0yWej58
D59GcuUqeg3nT9CgGtx49+qBBSWmhIcrEkxOdg0ei9gZaqM5KkwG1enZ4KdAKLwVUGPcynCylTKk
xcReeS4LYg9I0wAAAAAAAA==

--Apple-Mail-16-461656583--



From owner-atom-syntax@mail.imc.org  Wed Jul 21 15:40: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 PAA17132
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 15:40: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 i6LJThTe019483;
	Wed, 21 Jul 2004 12:29: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 i6LJThsR019482;
	Wed, 21 Jul 2004 12:29:43 -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 i6LJThIX019476
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 12:29:43 -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 i6LJRY53025343
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 13:27:34 -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 <0I1700G8EVHMZE@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Wed, 21 Jul 2004 13:29:47 -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 <0I1700KWIVHM3N@mail.sun.net> for atom-syntax@imc.org; Wed,
 21 Jul 2004 13:29:46 -0600 (MDT)
Date: Wed, 21 Jul 2004 12:29:55 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Propose partial consensus on dates
In-reply-to: <678B8DFE-DB45-11D8-B3AB-000A95DC3D90@mac.com>
To: Atom-Syntax Syntax <atom-syntax@imc.org>
Message-id: <58451030-DB4C-11D8-AC8C-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: <593B9E26-DB42-11D8-AC8C-000A95A51C9E@sun.com>
 <678B8DFE-DB45-11D8-B3AB-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 Jul 21, 2004, at 11:40 AM, Graham wrote:

>> 1. Each entry must have a "modified" which is an assertion from the 
>> publisher as to when the resource was last changed.  This should be 
>> in RFC3339 format.  Example: a travel journal, the entry for the 8th 
>> was <atom:modified> on the 17th.
>
> Why "must"? We don't have a real use case for it yet. It's certainly 
> not very interesting to end users in the way a real Updated date would 
> be.
...
> And <updated>? I liked that. Sam liked it. It solves a major problem 
> (we can't go to version 1.0 without a real mechanism for flagging 
> updated entries - and the <supercedes> nonsense is a non-starter).

Er it's possible I may have conflated "updated" and "modified"... 
someone want to explain the difference? -Tim



From owner-atom-syntax@mail.imc.org  Wed Jul 21 15: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 PAA17771
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 15: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 i6LJe4WI020148;
	Wed, 21 Jul 2004 12:40: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 i6LJe4Tg020147;
	Wed, 21 Jul 2004 12:40:04 -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 i6LJe4h1020141
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 12:40:04 -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 i6LJe8BC029745
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 12:40:08 -0700 (PDT)
Received: from [149.123.77.131] ([149.123.77.131])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id i6LJe7D2018184
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 12:40:08 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v618)
In-Reply-To: <858C8D66-DB46-11D8-AC8C-000A95A51C9E@sun.com>
References: <593B9E26-DB42-11D8-AC8C-000A95A51C9E@sun.com> <678B8DFE-DB45-11D8-B3AB-000A95DC3D90@mac.com> <858C8D66-DB46-11D8-AC8C-000A95A51C9E@sun.com>
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-17-462456718; protocol="application/pkcs7-signature"
Message-Id: <C487AD01-DB4D-11D8-B3AB-000A95DC3D90@mac.com>
From: Graham <dtcd@mac.com>
Subject: Re: Propose partial consensus on dates
Date: Wed, 21 Jul 2004 15:40:06 -0400
To: Atom Syntax <atom-syntax@imc.org>
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-17-462456718
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 21 Jul 2004, at 2:48 pm, Tim Bray wrote:

> Er, I think you need to explain the semantics for "updated".  
> Presumably it differs from "modified" in more than name.  I don't 
> understand, so probably others don't either. -Tim

<updated> proposed by Sam here:
  http://www.imc.org/atom-syntax/mail-archive/msg06946.html

Refined by me here:
  http://www.imc.org/atom-syntax/mail-archive/msg07057.html

+1'ed by Sam here:
  http://www.imc.org/atom-syntax/mail-archive/msg07065.html

Graham
--Apple-Mail-17-462456718
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
9w0BCQUxDxcNMDQwNzIxMTk0MDA2WjAjBgkqhkiG9w0BCQQxFgQUFuT/84GnAuAfOYVCXifu8jmA
NxgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAPFGcOTwukKfGWu0KiXP8PUgY
WqRdRSCqArru4oh4091JZ4V7zi5uU3cNZlVNrABfZPhjJhVsKBjBV38CfA+NZaGz6i7abtNvPiY6
7q9YmqJrJxEeip97V3GsWCmixb9+hq5a1JVZoGZ8TvbZLl4rTFOlsOX4061gRBqPqQsn3956cTKK
9kAmm4Tj9gaemLbC+lUd9qc/IXNycPL52ptNflOUXSfq8WTVmppvGNDqW36pppA2hsi41T9xn0DC
Vo5BQS9/bh9sl0jjGnKmOFhZ4AtaRJNMj4P7lWmkDGUEFszdwRyozmRDR0T5s1v9lx9/SdS0M18m
liqUDFs2eV2+MwAAAAAAAA==

--Apple-Mail-17-462456718--



From owner-atom-syntax@mail.imc.org  Wed Jul 21 16:14: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 QAA21739
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 16:14: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 i6LK1RAB021968;
	Wed, 21 Jul 2004 13:01:27 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6LK1RMo021967;
	Wed, 21 Jul 2004 13:01:27 -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 i6LK1QIS021959
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 13:01:26 -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 i6LK1Gvw007457;
	Wed, 21 Jul 2004 16:01: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 BJL75415 (AUTH bob@wyman.us);
	Wed, 21 Jul 2004 16:01:23 -0400 (EDT)
Message-Id: <200407212001.BJL75415@ms8.netsolmail.com>
Reply-To: <bob@wyman.us>
From: "Bob Wyman" <bob@wyman.us>
To: "'Tim Bray'" <Tim.Bray@Sun.COM>,
        "'Atom-Syntax Syntax'" <atom-syntax@imc.org>
Subject: RE: Propose partial consensus on dates
Date: Wed, 21 Jul 2004 16:01:28 -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: AcRvW7HdtJp2mWyQQbmfMv56+lEI7wAALjHg
In-Reply-To: <58451030-DB4C-11D8-AC8C-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


Tim Bray wrote:
> I may have conflated "updated" and "modified"... 
> someone want to explain the difference? -Tim
	The usage that is growing seems to be:
	Modified: At least one byte changed. However the change might not be
significant and worthy of notice if you had already read a previous version
of the entry. Thus, atom:modified would be changed when a publisher did
things like correct spelling mistakes, made minor grammatical errors, or
inserted/modified an advertisement embedded in an entry. Modified would
typically indicate that the form of the entry has changed -- not its
meaning.
	Updated: At least one byte has changed and the publisher considers
the change to be of such significance that readers should consider reading
the entry even if they had read an earlier version. Atom:updated would be
used when adding additional paragraphs to an entry, modifying a position
taken in an entry, modifying the content in such a way that the semantics of
the entry (not just it's syntax) has changed.
	I think that a modification to atom:updated would always require a
similar modification to atom:modified; however, a modification to
atom:modified would not always require a similar modification to
atom:updated.

	At least, I think that's what the distinction is...

		bob wyman



From owner-atom-syntax@mail.imc.org  Wed Jul 21 16:24: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 QAA23873
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 16:24: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 i6LKFDVJ023510;
	Wed, 21 Jul 2004 13:15:13 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6LKFDwt023509;
	Wed, 21 Jul 2004 13:15: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-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 i6LKFCEj023503
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 13:15:12 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6LKFHil013559
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 14:15:17 -0600 (MDT)
Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0I17005H9XLGON@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Wed, 21 Jul 2004 14:15:16 -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 <0I1700KB2XLF3N@mail.sun.net> for atom-syntax@imc.org; Wed,
 21 Jul 2004 14:15:16 -0600 (MDT)
Date: Wed, 21 Jul 2004 13:15:25 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Propose partial consensus on dates
In-reply-to: <C487AD01-DB4D-11D8-B3AB-000A95DC3D90@mac.com>
To: Graham <dtcd@mac.com>
Cc: Atom Syntax <atom-syntax@imc.org>
Message-id: <B37A5054-DB52-11D8-AC8C-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: <593B9E26-DB42-11D8-AC8C-000A95A51C9E@sun.com>
 <678B8DFE-DB45-11D8-B3AB-000A95DC3D90@mac.com>
 <858C8D66-DB46-11D8-AC8C-000A95A51C9E@sun.com>
 <C487AD01-DB4D-11D8-B3AB-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 Jul 21, 2004, at 12:40 PM, Graham wrote:

>> Er, I think you need to explain the semantics for "updated".  
>> Presumably it differs from "modified" in more than name.  I don't 
>> understand, so probably others don't either. -Tim
> <updated> proposed by Sam here:
>  http://www.imc.org/atom-syntax/mail-archive/msg06946.html
> Refined by me here:
>  http://www.imc.org/atom-syntax/mail-archive/msg07057.html
> +1'ed by Sam here:
>  http://www.imc.org/atom-syntax/mail-archive/msg07065.html

Er, exactly.  That's what I meant.  s/modified/updated/g in my 
consensus proposal.  And if you look at my original description of the 
semantcs, that's exactly what I was trying to capture: an assertion by 
the publisher as to when things changed.   -Tim



From owner-atom-syntax@mail.imc.org  Wed Jul 21 16:25:41 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24217
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 16:25:41 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LKGsTj023652;
	Wed, 21 Jul 2004 13:16: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 i6LKGsl3023651;
	Wed, 21 Jul 2004 13:16:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LKGr7F023644
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 13:16:53 -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 i6LKGvil014424
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 14:16:57 -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 <0I17005YQXO9ON@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Wed, 21 Jul 2004 14:16:57 -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 <0I1700KT0XO73Q@mail.sun.net> for atom-syntax@imc.org; Wed,
 21 Jul 2004 14:16:57 -0600 (MDT)
Date: Wed, 21 Jul 2004 13:17:05 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Propose partial consensus on dates
In-reply-to: <200407212001.BJL75415@ms8.netsolmail.com>
To: bob@wyman.us
Cc: "'Atom-Syntax Syntax'" <atom-syntax@imc.org>
Message-id: <EF6AF7D2-DB52-11D8-AC8C-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: <200407212001.BJL75415@ms8.netsolmail.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 Jul 21, 2004, at 1:01 PM, Bob Wyman wrote:

> 	Modified: At least one byte changed. However the change might not be
> significant and worthy of notice if you had already read a previous 
> version
> of the entry. Thus, atom:modified would be changed when a publisher did
> things like correct spelling mistakes, made minor grammatical errors, 
> or
> inserted/modified an advertisement embedded in an entry. Modified would
> typically indicate that the form of the entry has changed -- not its
> meaning.
> 	Updated: At least one byte has changed and the publisher considers
> the change to be of such significance that readers should consider 
> reading
> the entry even if they had read an earlier version. Atom:updated would 
> be
> used when adding additional paragraphs to an entry, modifying a 
> position
> taken in an entry, modifying the content in such a way that the 
> semantics of
> the entry (not just it's syntax) has changed.

I agree 100%.  However, I do not recall seeing consensus around putting 
Modified into Atom, just around Updated.    -Tim



From owner-atom-syntax@mail.imc.org  Wed Jul 21 16:41: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 QAA27055
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 16:41: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 i6LKUVpG025236;
	Wed, 21 Jul 2004 13:30: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 i6LKUVVO025235;
	Wed, 21 Jul 2004 13:30:31 -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 i6LKUVvE025229
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 13:30:31 -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 i6LKUZas029315;
	Wed, 21 Jul 2004 13:30:36 -0700 (PDT)
Received: from [149.123.77.131] ([149.123.77.131])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id i6LKUYaA028312;
	Wed, 21 Jul 2004 13:30:35 -0700 (PDT)
In-Reply-To: <B37A5054-DB52-11D8-AC8C-000A95A51C9E@sun.com>
References: <593B9E26-DB42-11D8-AC8C-000A95A51C9E@sun.com> <678B8DFE-DB45-11D8-B3AB-000A95DC3D90@mac.com> <858C8D66-DB46-11D8-AC8C-000A95A51C9E@sun.com> <C487AD01-DB4D-11D8-B3AB-000A95DC3D90@mac.com> <B37A5054-DB52-11D8-AC8C-000A95A51C9E@sun.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-20-465484345; protocol="application/pkcs7-signature"
Message-Id: <D122D0A1-DB54-11D8-B3AB-000A95DC3D90@mac.com>
Cc: Atom Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: Propose partial consensus on dates
Date: Wed, 21 Jul 2004 16:30:33 -0400
To: Tim Bray <Tim.Bray@Sun.COM>
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-20-465484345
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 21 Jul 2004, at 4:15 pm, Tim Bray wrote:

> Er, exactly.  That's what I meant.  s/modified/updated/g in my 
> consensus proposal.  And if you look at my original description of the 
> semantcs, that's exactly what I was trying to capture: an assertion by 
> the publisher as to when things changed.   -Tim

I took that to mean any change (ie Fiddling with punctuation). If you 
meant it to be like <updated>, it can only be required when the 
publisher/tool keeps track of it, which most don't. Otherwise, it's 
useless.

Graham
--Apple-Mail-20-465484345
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
9w0BCQUxDxcNMDQwNzIxMjAzMDM0WjAjBgkqhkiG9w0BCQQxFgQUYf74lvqbvCAi1/AkpX7hRyQl
qkIweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAGhqICWdCiAQfW8qvuVflgV5a
/RYLpidPGffk7ILl5EjYSC/CTCv6sMwyaqMHZSMYPJC+s6JRDNVdh6eJPU2LAjH9SJexRibYaq5P
Gw0QOTtfWWhwub90islDhfYMegc/Q2GR4E2v+ddqYBncxdJd4EuMyOAz+w/vujnixKNMCLQ5xn56
WrndPMYF0CpeSaDVrk8VaWjsCIS4XvJsg2VYcIP+RJPK8VgLvzDCjVX601j0MQNaccTC9GVMk95H
kNVub2RDRjOgQqBLRVO+nslLyIPiaoCbCkR1pjfNNQMFImlHJ+1smF3SwHb3RGgp5bvad1339q2R
ZYFtFB98iLTE0QAAAAAAAA==

--Apple-Mail-20-465484345--



From owner-atom-syntax@mail.imc.org  Wed Jul 21 17:07: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 RAA01722
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 17:07: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 i6LKuY9d028829;
	Wed, 21 Jul 2004 13:56:34 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6LKuYnH028828;
	Wed, 21 Jul 2004 13:56:34 -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 i6LKuVjf028821
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 13:56:31 -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 i6LKuWn6021451;
	Wed, 21 Jul 2004 13:56:32 -0700 (PDT)
Received: from [149.123.77.131] ([149.123.77.131])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id i6LKuVaA006202;
	Wed, 21 Jul 2004 13:56:32 -0700 (PDT)
In-Reply-To: <40FD9780.4020102@dehora.net>
References: <200407191919.PAA17914@ietf.org> <87hds3slp8.fsf@nwalsh.com> <40FC4B18.7020400@dehora.net> <40FC5E56.90505@intertwingly.net> <40FD154A.2090706@dehora.net> <40FD1FCB.7010803@intertwingly.net> <40FD4133.4040206@dehora.net> <527D65FB-DA93-11D8-B3AB-000A95DC3D90@mac.com> <40FD9780.4020102@dehora.net>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-21-467040958; protocol="application/pkcs7-signature"
Message-Id: <70F318DF-DB58-11D8-B3AB-000A95DC3D90@mac.com>
Cc: Atom Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: atom:origin?
Date: Wed, 21 Jul 2004 16:56:30 -0400
To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.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-21-467040958
Content-Type: text/plain;
	charset=ISO-8859-1;
	format=flowed
Content-Transfer-Encoding: quoted-printable

On 20 Jul 2004, at 6:06 pm, Bill de h=D3ra wrote:

>> Isn't the sane thing to do to point to the address of the actual =
feed?
>
> Not really, unless we add words about origin only appearing when id=20
> does (co-occurence constraint - yuck).

I don't understand. Surely if we made origin contain the address of the=20=

feed where the entry was found, the id would never enter into it?

> I think this is telling us more about the sense or not of our identity=20=

> model than anything else. We have mandated ids for entries but not for=20=

> feeds. What's that about?

The much narrower use case, I presume.

> With URIs, not neccessarily, but that's a different matter.

Well OK. What's wrong with it being the same address made out of=20
different characters?

Graham=

--Apple-Mail-21-467040958
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
9w0BCQUxDxcNMDQwNzIxMjA1NjMwWjAjBgkqhkiG9w0BCQQxFgQUtwmSd8Bjoey07Cd5WiY3k0Qs
uNoweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAbNn6fHwzmuG1sMyUUGvmfAtC
jXp9qDXMtjwZwtpaSojj95TUM5D6zcxfXEZ0liTrcSlb9wV5fLVfxzJnByu2FILGxLWLCMCRKMsI
zgbucPD3lnshXd5L+oFR8C+4IRcusdr8rjs4BosRZHrikRGtnSXIGecIJxcG0e/siEgcjXTb/bXT
MqZkrfQRhLWB2Qy8pwGhchAP/wNkRbgo02HTxhQgSO56+AW4aTpr0aGjP8vEBggD+stdFVoMt6v5
cc4QkWKFXIfTkp62ziTT9c3gvXtWsv0imlZTn+tVH97Qtzakg8nHzPPmY6tV/grizY4D+MwcNREt
GLi5+/7qq67N8AAAAAAAAA==

--Apple-Mail-21-467040958--



From owner-atom-syntax@mail.imc.org  Wed Jul 21 17:12: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 RAA02689
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 17:12: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 i6LL1AL6029148;
	Wed, 21 Jul 2004 14:01: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 i6LL1Aha029147;
	Wed, 21 Jul 2004 14:01:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from dumle.webhuset.no (dumle.webhuset.no [81.27.32.66])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6LL19i4029123
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 14:01:10 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Message-Id: <200407212101.i6LL19i4029123@above.proper.com>
Received: (qmail 29452 invoked from network); 21 Jul 2004 20:59:35 -0000
Received: from unknown (HELO localhost.localdomain) (81.27.34.17)
  by 0 with SMTP; 21 Jul 2004 20:59:35 -0000
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
MIME-Version: 1.0
From: "Arve Bersvendsen" <arve@virtuelvis.com>
To: Tim Bray <Tim.Bray@Sun.COM>, atom-syntax@imc.org
Subject: Re: Propose partial consensus on dates
Date: Wed, 21 Jul 2004 23:01:06 +0200
X-Mailer: WHMail 1.0 (http://www.webhuset.no)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6LL1Ai4029142
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

> 1. Each entry must have a "modified" which is an assertion from the 
> publisher as to when the resource was last changed.  This should be in 
> RFC3339 format.  Example: a travel journal, the entry for the 8th was 
> <atom:modified> on the 17th.

+1 on the assumption that this is a date generated by a tool, not a person.

> 2. Each entry may have a "display" date - you can think of it as part 
> of the title - which is the date primarily associated by the publisher 
> with the resource.  Example: the travel-journal entry for the 8th has 
> an <atom:display> of the 8th.  There remain outstanding problems of 
> both name and format on this one, see below; however, the date is 
> machine-processable, not free text.

See below.

> 3. Each entry may have a "created" date - the date on which it came to 
> be.  For example, the travel-journal entry for the 8th was 
> <atom:created> on the 11th.  RFC3339.

+1 on the assumption that this date is immutable and machine generated

> - what the right format is for "display"

If we can agree that "display" is a user-submitted, subjective date, my
suggestion is that it should simply be treated as a string for human - not
machine - consumption. Alternatively that this is made to be some construct
providing both, e.g.

<date>
  <created ... />
  <issued ... />
  <modified .../>
  <display>
    <utc>2004-12-31T23:59:59Z</utc>
    <string>New year's eve</string>
  </display>
</date>

> - are there any must-have missing dates (I wonder if "created" could be 
> defined in a way that would meet at least some of the needs around 
> "issued").

I don't think so. In publishing processes beyond the blog scope, "issued" has
a very specific meaning, very different from "created".

> - if you disagree that we have rough consensus as outlined, say so, 
> nobody's feelings will be hurt.

I (too?) believe that there is rough consensus on 'created' and 'modified',
given my previously mentioned assumptions.

The biggest issue with dates, however, seems to be 'issued', and that issue
is heavily bound to the notion of re-issuance and entry:id:

- My view is that if a major modification is made to an entry, it is no
longer the same entry, but a new entry, with a new entry:id.
- This new entry MUST contain explicit information about which entry it
"supersedes" [1]. 
- Hence: an issued date becomes immutable, and as "objective" as the
authoring tool makes it.

This view of issued, together with "display" solves the Samuel Pepys Use
Case, since the display date is then not bound to anything specific, except
the original author's perceptual timeline [2]. 

Further: 
- When the "issued" date is immutable, simplistic aggregators (without any
notion of "revisioning") will not suffer any data loss when reading from an
aggregator that supports "minor and major edits" [3]. An aggregator with
revision support, would pick up the minor edits anyway, so no data is "lost"
as such. These aggregators could, when reading from 'untrusted' sources
(sources with no known revisioning support) also apply additional heuristics
to determine the "size" of an edit, to determine if it should re-display the
entry
- For two aggregators that supporting revisioning, they now have a way to
positively recognize whether an edit is minor or major, making Atom more
usable in a b2b scenario.

The only "inconveniences" ever possible, are these:
- a revisioning aggregator that doesn't redisplay minor modifications, _and_
that lacks the notion of differencing. I presume it will still show the
modified entry when explicitly asked to redisplay.
- an aggregator without revisioning support, might view "re-issued" as new
entries (which they, from the author's point of view are, anyway) without
giving a notion that this entry supersedes a previous entry.

Turning on my "end-user"-glasses, these two inconveniences are, IMHO, far
outweighed by the advantages.

___
[1] "Supersedes" as a generic term - the exact semantics might as well be
borrowed from Dublin Core, for instance relation @isVersionOf

[2] I assume that Samuel Pepys diary was not 'formally issued' until it was
released in book-form. This way, my current proposal would allow all aspects
of the diary to be represented: When it was created within the publishing
system. When it was last modified (again within the publishing system), when
Samuel Pepys wrote it, and when it was first unleashed upon the public.

[3] What "minor" and "major" is, will always, sadly, be open to
interpretation, no matter _how_ we choose to word it.


-- 
Arve Bersvendsen



From owner-atom-syntax@mail.imc.org  Wed Jul 21 17:14: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 RAA02884
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 17:14: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 i6LL0LnC029053;
	Wed, 21 Jul 2004 14:00: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 i6LL0Ls2029052;
	Wed, 21 Jul 2004 14:00:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LL0IS2029041
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 14:00:20 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p06110450bd247f63d889@[10.20.30.249]>
In-Reply-To: <E79CB9C2-DB4B-11D8-B3AB-000A95DC3D90@mac.com>
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net>
 <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net>
 <40FD376D.8080407@franklinmint.fm> <40FE62E5.6030707@nokia.com>
 <40FE79D6.9070301@dehora.net>
 <E79CB9C2-DB4B-11D8-B3AB-000A95DC3D90@mac.com>
Date: Wed, 21 Jul 2004 13:47:07 -0700
To: Atom WG <atom-syntax@imc.org>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
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:26 PM -0400 7/21/04, Graham wrote:
>So, no, relying on the old handsets being thrown away is not an 
>option when they still make up the majority of the market for new 
>phones.

-1. You are speaking about today and next year. Our protocol will 
last a decade, at least. If we used arguments like that, we would 
never have created protocols that ran at faster than 28.8 K baud.

>  If we're serious about supporting Atom on mobile phones, then that 
>means J2ME.

-1 for the same reason. If the future market demands Atom, J2ME 
devices (or whatever doesn't handle our protocol) will change to 
handle Atom. If the future market doesn't demand Atom, there is no 
reason for us to tailor Atom for a market that doesn't care.

BUT

1) It is far from clear in this discussion whether "the protocol that 
doesn't run on J2ME" is *technically* better than "the protocol that 
runs on J2ME"

2) Even if (1) was shown to be clear, it is far from clear that "the 
protocol that doesn't run on J2ME" could not be modified to run on 
J2ME and still retain nearly the same *technical* goodness.

We're not talking about purity here. Things that are "purely" RESTy 
or "purely" SOAPy are good starting points. However, if we can step 
away from the purity in order to embrace more current platforms at no 
significant *technical* cost, we should. Doing so is not only good 
for current stuff: it helps future platforms as well.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Wed Jul 21 17:23: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 RAA04441
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 17:23: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 i6LLFlRO030711;
	Wed, 21 Jul 2004 14: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 i6LLFlv5030710;
	Wed, 21 Jul 2004 14:15:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from dumle.webhuset.no (dumle.webhuset.no [81.27.32.66])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6LLFj3c030696
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 14:15:46 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Message-Id: <200407212115.i6LLFj3c030696@above.proper.com>
Received: (qmail 29509 invoked from network); 21 Jul 2004 21:14:12 -0000
Received: from unknown (HELO localhost.localdomain) (81.27.34.19)
  by 0 with SMTP; 21 Jul 2004 21:14:12 -0000
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
MIME-Version: 1.0
From: "Arve Bersvendsen" <arve@virtuelvis.com>
To: atom-syntax@imc.org, Tim.Bray@Sun.COM, dtd@mac.com
Subject: Re: Propose partial consensus on dates
Date: Wed, 21 Jul 2004 23:15:43 +0200
X-Mailer: WHMail 1.0 (http://www.webhuset.no)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6LLFl3c030705
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


* First, quoting Graham <dtd@mac.com>
> > And <updated>? I liked that. Sam liked it. It solves a major problem 
> > (we can't go to version 1.0 without a real mechanism for flagging 
> > updated entries - and the <supercedes> nonsense is a non-starter).

Instead of labelling a _mechanism_ as "nonsense", could you please qualify
the failures of an explicit mechanism for "superseding".

* Then, Tim Bray <Tim.Bray@Sun.COM>
> Er it's possible I may have conflated "updated" and "modified"... 
> someone want to explain the difference?

I am -1 on using "Updated". Part of the reasoning should be found in this
simple question: Any "modification" is an "update".



From owner-atom-syntax@mail.imc.org  Wed Jul 21 17:23: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 RAA04467
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 17:23: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 i6LLHH5a030794;
	Wed, 21 Jul 2004 14:17:17 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6LLHH8E030793;
	Wed, 21 Jul 2004 14:17:17 -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 i6LLHGRj030771
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 14:17:17 -0700 (PDT)
	(envelope-from roger@agincourtmedia.com)
Received: from biggreen ([216.63.148.42]) by journurl.com with MailEnable ESMTP; Wed, 21 Jul 2004 16:17:27 -0500
From: "Roger B." <roger@agincourtmedia.com>
To: "'Tim Bray'" <Tim.Bray@Sun.COM>,
        "'Atom-Syntax Syntax'" <atom-syntax@imc.org>
Subject: RE: Propose partial consensus on dates
Date: Wed, 21 Jul 2004 16:22:37 -0500
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: <593B9E26-DB42-11D8-AC8C-000A95A51C9E@sun.com>
Thread-Index: AcRvTygn+7ArQSK+TTyGSFZ6N86lGgAGHAAw
Message-ID: <5EDC389E44E42BE9CED0A1655E67.MAI@journurl.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


> 1. Each entry must have a "modified" which is an assertion from the
> publisher as to when the resource was last changed.  This should be in
> RFC3339 format.  Example: a travel journal, the entry for the 8th was
> <atom:modified> on the 17th.

Tim: +1 as written. If the element is intended to be used solely for
substantive updates, then it needs to be "may" rather than "must"... many
(most?) tools don't differentiate between "substantive" and "minor" at this
point.

> 2. Each entry may have a "display" date - you can think of it as part
> of the title - which is the date primarily associated by the publisher
> with the resource.  Example: the travel-journal entry for the 8th has
> an <atom:display> of the 8th.  There remain outstanding problems of
> both name and format on this one, see below; however, the date is
> machine-processable, not free text.

+1, although if any date were to merit "must" status, this would be the one.
I'm fine with an all "may" collection of date elements, though.

> 3. Each entry may have a "created" date - the date on which it came to
> be.  For example, the travel-journal entry for the 8th was
> <atom:created> on the 11th.  RFC3339.

+1

> <just-tim-not-cochair>I</just-tim-not-cochair> hereby propose
> "dateline"

+1. Works for me, seems descriptive.

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/ 







From owner-atom-syntax@mail.imc.org  Wed Jul 21 17:24: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 RAA04626
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 17: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 i6LLJC5x030930;
	Wed, 21 Jul 2004 14: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 i6LLJCvr030929;
	Wed, 21 Jul 2004 14:19:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from dumle.webhuset.no (dumle.webhuset.no [81.27.32.66])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6LLJAFo030920
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 14:19:11 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Message-Id: <200407212119.i6LLJAFo030920@above.proper.com>
Received: (qmail 29522 invoked from network); 21 Jul 2004 21:17:43 -0000
Received: from unknown (HELO localhost.localdomain) (81.27.34.17)
  by 0 with SMTP; 21 Jul 2004 21:17:43 -0000
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
MIME-Version: 1.0
From: "Arve Bersvendsen" <arve@virtuelvis.com>
To: Tim.Bray@sun.com, atom-syntax@imc.org
Subject: Re: Propose partial consensus on dates
Date: Wed, 21 Jul 2004 23:19:14 +0200
X-Mailer: WHMail 1.0 (http://www.webhuset.no)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6LLJBFo030923
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


(Apologies if this appears twice - I received an incomprehensible bounce when
attempting to send) 

* First, quoting Graham <dtd@mac.com>
> > And <updated>? I liked that. Sam liked it. It solves a major problem 
> > (we can't go to version 1.0 without a real mechanism for flagging 
> > updated entries - and the <supercedes> nonsense is a non-starter).

Instead of labelling a _mechanism_ as "nonsense", could you please qualify
the failures of an explicit mechanism for "superseding".

* Then, Tim Bray <Tim.Bray@Sun.COM>
> Er it's possible I may have conflated "updated" and "modified"... 
> someone want to explain the difference?

I am -1 on using "Updated". Part of the reasoning should be found in this
simple question: Any "modification" is an "update".



From owner-atom-syntax@mail.imc.org  Wed Jul 21 17:31: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 RAA05760
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 17:31: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 i6LLOYtH031338;
	Wed, 21 Jul 2004 14:24:34 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6LLOYQT031337;
	Wed, 21 Jul 2004 14:24:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail06.svc.cra.dublin.eircom.net (mail06.svc.cra.dublin.eircom.net [159.134.118.22])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6LLOXcm031329
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 14:24:33 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 87652 messnum 2825562 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 21 Jul 2004 21:24:32 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail06.svc.cra.dublin.eircom.net (qp 87652) with SMTP; 21 Jul 2004 21:24:32 -0000
Message-ID: <40FEDF0F.3020006@dehora.net>
Date: Wed, 21 Jul 2004 22:24:31 +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: Graham <dtcd@mac.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: atom:origin?
References: <200407191919.PAA17914@ietf.org> <87hds3slp8.fsf@nwalsh.com> <40FC4B18.7020400@dehora.net> <40FC5E56.90505@intertwingly.net> <40FD154A.2090706@dehora.net> <40FD1FCB.7010803@intertwingly.net> <40FD4133.4040206@dehora.net> <527D65FB-DA93-11D8-B3AB-000A95DC3D90@mac.com> <40FD9780.4020102@dehora.net> <70F318DF-DB58-11D8-B3AB-000A95DC3D90@mac.com>
In-Reply-To: <70F318DF-DB58-11D8-B3AB-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: <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:

> I don't understand. Surely if we made origin contain the address of the 
> feed where the entry was found, the id would never enter into it?

That's ok, I don't understand either - what bit of the format do you 
mean by address?



cheers
Bill



From owner-atom-syntax@mail.imc.org  Wed Jul 21 17: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 RAA06788
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 17: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 i6LLLLGL031113;
	Wed, 21 Jul 2004 14:21: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 i6LLLLCC031112;
	Wed, 21 Jul 2004 14:21:21 -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 i6LLLK5b031092
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 14:21:20 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 63231 messnum 3855187 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 21 Jul 2004 21:21:19 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail08.svc.cra.dublin.eircom.net (qp 63231) with SMTP; 21 Jul 2004 21:21:19 -0000
Message-ID: <40FEDE4D.3020401@dehora.net>
Date: Wed, 21 Jul 2004 22:21:17 +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: Graham <dtcd@mac.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <40FE62E5.6030707@nokia.com> <40FE79D6.9070301@dehora.net> <E79CB9C2-DB4B-11D8-B3AB-000A95DC3D90@mac.com>
In-Reply-To: <E79CB9C2-DB4B-11D8-B3AB-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: <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:


> Who says the next 900M phones will be running full HTTP? 

Yes, who's to say. But would you bet against them running /HTTP/?


> I count 8 smartphones, 10 J2ME-enabled, and 2 that are neither. And most 
> of the smartphones are niche models, the J2ME are the high-volume 
> models. 

For now.


> So, no, relying on the old handsets being thrown away is not an 
> option when they still make up the majority of the market for new 
> phones. 

For now.


> If we're serious about supporting Atom on mobile phones, then 
> that means J2ME.

For now.

These are the premises of the counter-argument I put out:

  1. we've only seen a fraction of the HTTP/J2ME enabled devices 
that will come onto the market,

  2. today's devices and software stacks have designed-in-obsolence, 
and,

  3. future devices will harness a lot more computing and network 
power.

[Moore and Gilder are in this corner - Ding! Ding!]

I submit 2 and 3 are no-brainers and to dispute 1 is to argue that 
device adoption is topping out (if so, some of my employer's 
customers are in for a shock).

Not supporting PUT/DELETE is a random bug inherited from HTML forms 
(where HTML forms got the bright idea from I have no idea). Bug 
compatability we can live with as long as we *understand* we're 
committing the Atom specs to the sos that everyone who has come 
before us has committed their specs to. We can be serious about 
wanting supporting Atom on Java phones without wanting to subset 
HTTP as a matter of specification. It is a trade off that needs to 
be assessed without freaking out either about a zillion java phones 
or web architectural dogma.

But I'd better shut up - another thousand mobiles just shipped ;)

cheers
Bill



From owner-atom-syntax@mail.imc.org  Wed Jul 21 17:44: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 RAA08500
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 17:44: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 i6LLaRnS032668;
	Wed, 21 Jul 2004 14:36: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 i6LLaRQM032664;
	Wed, 21 Jul 2004 14:36:27 -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 i6LLaRfI032650
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 14:36:27 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040721213626.51427.qmail@web41209.mail.yahoo.com>
Received: from [207.46.238.133] by web41209.mail.yahoo.com via HTTP; Wed, 21 Jul 2004 14:36:26 PDT
Date: Wed, 21 Jul 2004 14:36:26 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
To: mint@franklinmint.fm, Joe Gregorio <joe.gregorio@gmail.com>
Cc: Paul Hoffman / IMC <phoffman@imc.org>, atom-syntax@imc.org
In-Reply-To: <40FEA92F.7000407@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:
>  
> um, Anil works for a vendor of blogging software. He
> is telling us what 
> his customers are asking for. Should I go through
> the mailing list 
> *again* and list all of the voices in support of
> SOAP?

I haven't been paying much attention but I definitely
would add my voice to those who'd point out that SOAP
support should be a part of Atom to encourage wide
spread development on many popular development
platforms. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
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 Jul 21 17:44: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 RAA08641
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 17:44: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 i6LLbDEV032716;
	Wed, 21 Jul 2004 14:37:13 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6LLbDxt032715;
	Wed, 21 Jul 2004 14:37: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.84])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LLbDgd032709
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 14:37:13 -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 i6LLbH97015546;
	Wed, 21 Jul 2004 14:37:17 -0700 (PDT)
Received: from [149.123.77.131] ([149.123.77.131])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id i6LLbGD2025839;
	Wed, 21 Jul 2004 14:37:17 -0700 (PDT)
In-Reply-To: <200407212115.i6LLFj3c030696@above.proper.com>
References: <200407212115.i6LLFj3c030696@above.proper.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-24-469486519; protocol="application/pkcs7-signature"
Message-Id: <229E26AC-DB5E-11D8-B3AB-000A95DC3D90@mac.com>
Cc: Atom Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: Propose partial consensus on dates
Date: Wed, 21 Jul 2004 17:37:14 -0400
To: Arve Bersvendsen <arve@virtuelvis.com>
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-24-469486519
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 21 Jul 2004, at 5:15 pm, Arve Bersvendsen wrote:

> Instead of labelling a _mechanism_ as "nonsense", could you please 
> qualify
> the failures of an explicit mechanism for "superseding".

I was summarizing my position from previous discussion about it. See 
here:
  http://www.imc.org/atom-syntax/mail-archive/msg06940.html

> I am -1 on using "Updated". Part of the reasoning should be found in 
> this
> simple question: Any "modification" is an "update".

Only if you define it that way.

Graham
--Apple-Mail-24-469486519
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
9w0BCQUxDxcNMDQwNzIxMjEzNzE1WjAjBgkqhkiG9w0BCQQxFgQUkjFbn93HGoVIdGtYgz/kwRfK
A8EweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAFPu9EWKgTWVvEXH9+aJJnOqN
a1wEWeMsnfGsKSlGfi4o9YJAipWpwPpnjinfiYK5PC7utdQcIvtXoQO5ecN8ccUQgyCr+ahM8Ghb
M21iXzdmmuNhj0uAwnRpEMMSE9MH5CAmkA67Qkhg0SkXX8f21jeUpAYzAE7NGIYzQde/ITuQu5BQ
602n26lF3PvlBTbvvKb+FU1jX8pqXroilxrkJa5uYCHMiUu47gVPBqVP65FDN2i8QXt801BNSKM/
evb4SNNPpNstkDW1MNtzMiXc8bnjuwnROk1vLIeK9fUx8pNA/5zkjYa6hRF0uEF5h//xwAkG94z3
2I2HSjD/zy0LXgAAAAAAAA==

--Apple-Mail-24-469486519--



From owner-atom-syntax@mail.imc.org  Wed Jul 21 18: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 SAA10217
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 18:00: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 i6LLd9og032884;
	Wed, 21 Jul 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 i6LLd9mM032883;
	Wed, 21 Jul 2004 14:39:09 -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 i6LLd9TO032874
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 14:39:09 -0700 (PDT)
	(envelope-from antone@geckotribe.com)
Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134])
          by comcast.net (rwcrmhc11) with SMTP
          id <2004072121390901300qivl4e>; Wed, 21 Jul 2004 21:39:09 +0000
Date: Wed, 21 Jul 2004 15:39:05 -0600
Subject: Re: Propose partial consensus on dates
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: <5EDC389E44E42BE9CED0A1655E67.MAI@journurl.com>
Message-Id: <63A872F8-DB5E-11D8-B243-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 Wednesday, July 21, 2004, at 03:22  PM, Roger B. wrote:
>> <just-tim-not-cochair>I</just-tim-not-cochair> hereby propose
>> "dateline"
>
> +1. Works for me, seems descriptive.
>
+1.  Part of the virtue of "dateline" from my POV is that I wouldn't 
have any preconceived notions of what it means.  If those who DO have 
preconceived notions about its meaning do in fact use it as desired, 
then I can't think of any reason not to go with it.

...and if I pause a moment to think about what it SOUNDS like it might 
mean, then the meaning we're aiming at does seem to fit perfectly.



From owner-atom-syntax@mail.imc.org  Wed Jul 21 18:12: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 SAA11580
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 18:12: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 i6LM0fsP034395;
	Wed, 21 Jul 2004 15:00: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 i6LM0fIr034394;
	Wed, 21 Jul 2004 15:00:41 -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 i6LM0fT5034375
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 15:00:41 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040721220041.95499.qmail@web41210.mail.yahoo.com>
Received: from [131.107.3.70] by web41210.mail.yahoo.com via HTTP; Wed, 21 Jul 2004 15:00:41 PDT
Date: Wed, 21 Jul 2004 15:00:41 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Propose partial consensus on dates
To: Arve Bersvendsen <arve@virtuelvis.com>, Tim Bray <Tim.Bray@Sun.COM>,
        atom-syntax@imc.org
In-Reply-To: <200407212101.i6LL19i4029123@above.proper.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


--- Arve Bersvendsen <arve@virtuelvis.com> wrote:
> > > - what the right format is for "display"
> 
> If we can agree that "display" is a user-submitted,
> subjective date, my
> suggestion is that it should simply be treated as a
> string for human - not
> machine - consumption. 

Strong disagreement here. The primarily need for this
date is to model pubDate in RSS which is a user
configurable field in most blogging tools but machine
readable. Creating a field that can be any garbage
text the user wants makes this field quite useless. 
 

 
> I (too?) believe that there is rough consensus on
> 'created' and 'modified',
> given my previously mentioned assumptions.

What is the consensus? My position is that 'created'
is unnecessary in general although somebody may find
use for it if they were using Atom as an archival
format. In the debate of modified vs. updated I'd
point out that few (if any blogging tools) today
support the functionality described by updated.
Specifically the ability for a user to specify that a
significantly edited article should somehow be
highlighted as rewritten which differs from tracking
if any modification such as fixed typos have occured
isn't something I've seen in any blog tool nor have I
heard anyone requesting this functionality before
until the Atom date debate began.  
 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.


		
__________________________________
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 Jul 21 18:12:34 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11609
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 18: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 i6LM4ucY034627;
	Wed, 21 Jul 2004 15:04: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 i6LM4ua5034626;
	Wed, 21 Jul 2004 15:04:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from dumle.webhuset.no (dumle.webhuset.no [81.27.32.66])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6LM4tE1034615
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 15:04:55 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Message-Id: <200407212204.i6LM4tE1034615@above.proper.com>
Received: (qmail 29701 invoked from network); 21 Jul 2004 22:03:21 -0000
Received: from unknown (HELO localhost.localdomain) (81.27.34.17)
  by 0 with SMTP; 21 Jul 2004 22:03:21 -0000
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
MIME-Version: 1.0
From: "Arve Bersvendsen" <arve@virtuelvis.com>
To: atom-syntax@imc.org, dtcd@mac.com
Subject: Re: Propose partial consensus on dates
Date: Thu, 22 Jul 2004 00:04:53 +0200
X-Mailer: WHMail 1.0 (http://www.webhuset.no)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6LM4uE1034621
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



> > Instead of labelling a _mechanism_ as "nonsense", could you please 
> > qualify
> > the failures of an explicit mechanism for "superseding".
> 
> I was summarizing my position from previous discussion about it. See 
> here:
>   http://www.imc.org/atom-syntax/mail-archive/msg06940.html

Ok, to recap:

1. You're afraid that if A supersedes B supersedes C, and B is missing, you
won't know that A supersedes C.

* I see no harm in keeping explicit information for every supersede. This is
hardly going to be a common bandwith-eating bloat problem.
* I see no harm in keeping _just_ the first supersede. If entry C supersedes
A, it must also (naturally) supersede B if C newer than B.

-- 
Arve Bersvendsen



From owner-atom-syntax@mail.imc.org  Wed Jul 21 18: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 SAA11992
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 18:14: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 i6LM75VC034726;
	Wed, 21 Jul 2004 15:07: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 i6LM75qZ034725;
	Wed, 21 Jul 2004 15:07:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LM75mo034716
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 15:07:05 -0700 (PDT)
	(envelope-from antone@geckotribe.com)
Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134])
          by comcast.net (sccrmhc12) with SMTP
          id <2004072122070401200fkm5ge>; Wed, 21 Jul 2004 22:07:04 +0000
Date: Wed, 21 Jul 2004 16:07:03 -0600
Subject: Re: Propose partial consensus on dates
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: <200407212001.BJL75415@ms8.netsolmail.com>
Message-Id: <4BE4B9DC-DB62-11D8-B243-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 Wednesday, July 21, 2004, at 02:01  PM, Bob Wyman wrote:

>> I may have conflated "updated" and "modified"...
>> someone want to explain the difference? -Tim

> 	Modified: At least one byte changed. However the change might not be
> significant and worthy of notice if you had already read a previous 
> version
> of the entry. Thus, atom:modified would be changed when a publisher did
> things like correct spelling mistakes, made minor grammatical errors, 
> or
> inserted/modified an advertisement embedded in an entry. Modified would
> typically indicate that the form of the entry has changed -- not its
> meaning.
> 	Updated: At least one byte has changed and the publisher considers
> the change to be of such significance that readers should consider 
> reading
> the entry even if they had read an earlier version. Atom:updated would 
> be
> used when adding additional paragraphs to an entry, modifying a 
> position
> taken in an entry, modifying the content in such a way that the 
> semantics of
> the entry (not just it's syntax) has changed.
>
My sense is that more people aren't interested in having both of these 
than are.  I'm satisfied to go with the consensus on this, though I 
lean towards wanting both, but would like to raise one issue.  I would 
think that if a particular feature is desired by a significant minority 
of people, and it wouldn't cause problems for everyone else, then it 
might be worth putting in.  The questions are:

1) How large a minority would need to want something for it to get in?
2) How large a minority (assuming I'm correct that it's a minority) 
wants this?
3) Last but not least, would this in fact not cause problems for those 
who don't particularly want it?

If we don't end up taking both, I'd favor having "updated" as defined 
above, and not "modified".



From owner-atom-syntax@mail.imc.org  Wed Jul 21 18: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 SAA14013
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 18: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 i6LMFLpT035318;
	Wed, 21 Jul 2004 15:15:21 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6LMFLnn035317;
	Wed, 21 Jul 2004 15:15:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from dumle.webhuset.no (dumle.webhuset.no [81.27.32.66])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6LMFK0k035308
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 15:15:21 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Message-Id: <200407212215.i6LMFK0k035308@above.proper.com>
Received: (qmail 29741 invoked from network); 21 Jul 2004 22:13:47 -0000
Received: from unknown (HELO localhost.localdomain) (81.27.34.17)
  by 0 with SMTP; 21 Jul 2004 22:13:47 -0000
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
MIME-Version: 1.0
From: "Arve Bersvendsen" <arve@virtuelvis.com>
To: Dare Obasanjo <kpako@yahoo.com>, atom-syntax@imc.org
Subject: Re: Propose partial consensus on dates
Date: Thu, 22 Jul 2004 00:15:18 +0200
X-Mailer: WHMail 1.0 (http://www.webhuset.no)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6LMFL0k035312
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
[On Display]

> Strong disagreement here. The primarily need for this
> date is to model pubDate in RSS which is a user
> configurable field in most blogging tools but machine
> readable. Creating a field that can be any garbage
> text the user wants makes this field quite useless. 

This argument makes sense to me.

> > I (too?) believe that there is rough consensus on
> > 'created' and 'modified',
> > given my previously mentioned assumptions.
> 
> What is the consensus? My position is that 'created'
> is unnecessary in general although somebody may find
> use for it if they were using Atom as an archival
> format. 

Atom is both an archival and publishing format. As for "rough consensus",
read Tim Bray's definition on the date.

> In the debate of modified vs. updated I'd
> point out that few (if any blogging tools) today
> support the functionality described by updated.
> Specifically the ability for a user to specify that a
> significantly edited article should somehow be
> highlighted as rewritten which differs from tracking
> if any modification such as fixed typos have occured
> isn't something I've seen in any blog tool nor have I
> heard anyone requesting this functionality before
> until the Atom date debate began.  

Note that I dislike the "Update" date as such, as I prefer "re-issuance" with
explicit pointers to the entries affected (read, "Supersede"). This is both
for archival reasons, and for feed->aggregator use in more formalized
processes than the typical blog scenario. I would hate to see Atom
disqualified by default.

An aggregator that doesn't support revisioning would never suffer any data
loss when any supersede/replaces mechanism is used, compared to today.

(I'd like to remind people that Dublin Core didn't pull a rabbit out of some
random magic hat when they defined replaces/isVersionOf/hasVersion as
refinements of dct:relation)



From owner-atom-syntax@mail.imc.org  Wed Jul 21 18:53: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 SAA22499
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 18:53: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 i6LMhubO037650;
	Wed, 21 Jul 2004 15: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 i6LMhuYw037649;
	Wed, 21 Jul 2004 15:43: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 i6LMhtoo037597
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 15:43: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 1E58B7C115; Thu, 22 Jul 2004 01:40:32 +0200 (CEST)
Date: Thu, 22 Jul 2004 00:48:14 +0200
To: "Dare Obasanjo" <kpako@yahoo.com>
Subject: Re: Propose partial consensus on dates
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <20040721220041.95499.qmail@web41210.mail.yahoo.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: <opsbieyottuvpchu@quark>
In-Reply-To: <20040721220041.95499.qmail@web41210.mail.yahoo.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Wed, 21 Jul 2004 15:00:41 -0700 (PDT), Dare Obasanjo <kpako@yahoo.com>  
wrote:

> In the debate of modified vs. updated I'd point out that few (if any
> blogging tools) today support the functionality described by updated.

What's funny is, however, that any «supersede» mechanism I and Arve have  
proposed is _already_ supported in _all_ aggregators. Okay, they don't do  
anything smart with the reference to the previous version of the entry,  
but they display it as a new entry. Just as they should.

> Specifically the ability for a user to specify that a significantly
> edited article should somehow be highlighted as rewritten which
> differs from tracking if any modification such as fixed typos have
> occured isn't something I've seen in any blog tool nor have I heard
> anyone requesting this functionality before until the Atom date debate
> began.

True, but it doesn't need to be like that either. It's a hypothetical use  
case. The advantages of re-issuing entries as new entries (with new ID's)  
instead of infinately updating the same entry still outweighs any  
drawbacks (which I think are itsy bitsy) with not supporting the supersede  
mechanism.

-- 
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 Jul 21 19:04: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 TAA24306
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 19: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 i6LMuxAi038633;
	Wed, 21 Jul 2004 15:56:59 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6LMuxBx038632;
	Wed, 21 Jul 2004 15:56: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 (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LMuwQo038622
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 15:56: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 2E1F87C115; Thu, 22 Jul 2004 01:53:42 +0200 (CEST)
Date: Thu, 22 Jul 2004 01:01:27 +0200
To: "Tim Bray" <Tim.Bray@sun.com>
Subject: Re: Propose partial consensus on dates
References: <593B9E26-DB42-11D8-AC8C-000A95A51C9E@sun.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
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: <opsbifkpapuvpchu@quark>
In-Reply-To: <593B9E26-DB42-11D8-AC8C-000A95A51C9E@sun.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Wed, 21 Jul 2004 11:18:21 -0700, Tim Bray <Tim.Bray@Sun.COM> wrote:

> 1. Each entry must have a "modified" which is an assertion from the  
> publisher as to when the resource was last changed.  This should be in  
> RFC3339 format.  Example: a travel journal, the entry for the 8th was  
> <atom:modified> on the 17th.

+1.

> 2. Each entry may have a "display" date - you can think of it as part of  
> the title - which is the date primarily associated by the publisher with  
> the resource.  Example: the travel-journal entry for the 8th has an  
> <atom:display> of the 8th.  There remain outstanding problems of both  
> name and format on this one, see below; however, the date is  
> machine-processable, not free text.

+1.

> 3. Each entry may have a "created" date - the date on which it came to  
> be.  For example, the travel-journal entry for the 8th was  
> <atom:created> on the 11th.  RFC3339.


+1.

> - there are a variety of incompatible requirements (some of them quite  
> strong) for another date called "issued" which doesn't seem to be any of  
> these.

Yes. To just ask some simple questions on 'issued':

   - Do we agree that the current date situation (of RSS) isn't something
     we want to build Atom on?

   - Do we agree that all tools have an action corresponding to 'issued'
     (that is, publishing the resource to the web)?

   - Do we agree that the word 'formal' in DC's description of 'issued'
     outrules that it might be a subjective date?

   - Do we agree that Atom might not only be used and targeted at personal
     weblogs?

If the answer to all of the above questions is «yes» I see no harm in  
requiring tools to provide an 'issued' date. Okay, many people don't  
understand the use for it now, but I've stated on numerous occasions that  
this date is crucial in a publishing process.

E.g., I see no reason _not_ to have an 'issued' date. The only debate,  
after agreeing on having 'issued' as a required date in Atom Core, would  
be if 'issued' can ever be changed. Changing 'issued' would be a way to  
signify «major» modifications, which I think we agree that an 'updated'  
date, or something else, rather should take care of.

If we agree that 'issued' is immutable, and all of the above points, I  
think we agree on the following:

   - 'issued' should be required.
   - 'issued' is an objective, tool-provided date.
   - 'issued' indicates when the resource was _first_ published

If people disagree with this, I'd like to know why. If the «why» is  
because «I'd like to hack my issued date», the answer is «use 'display'».  
If it is because «I'd like to change it to re-issue my entry», the answer  
is «Use 'updated' or any supersede mechanism». If the reasons are any  
other, I'd really like to hear about them.

> <just-tim-not-cochair>I</just-tim-not-cochair> hereby propose "dateline"

Sounds okay.

> - what the right format is for "display"

Probably something close to the author's heart, so at least not required  
UTC.

> - are there any must-have missing dates (I wonder if "created" could be  
> defined in a way that would meet at least some of the needs around  
> "issued").

I could easilly loose 'created' in favour of 'issued'. I don't mind having  
both, but 'issued' is, without a doubt, any publishing process' singular  
most important 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 Jul 21 19:07: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 TAA25002
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 19:07: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 i6LN0qVW039012;
	Wed, 21 Jul 2004 16:00: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 i6LN0qN8039011;
	Wed, 21 Jul 2004 16:00:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from dumle.webhuset.no (dumle.webhuset.no [81.27.32.66])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6LN0oFL039004
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 16:00:51 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Message-Id: <200407212300.i6LN0oFL039004@above.proper.com>
Received: (qmail 29889 invoked from network); 21 Jul 2004 22:59:17 -0000
Received: from unknown (HELO localhost.localdomain) (81.27.34.17)
  by 0 with SMTP; 21 Jul 2004 22:59:17 -0000
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
MIME-Version: 1.0
From: "Arve Bersvendsen" <arve@virtuelvis.com>
To: <bob@wyman.us>, atom-syntax@imc.org
Subject: Re: Propose partial consensus on dates
Date: Thu, 22 Jul 2004 01:00:49 +0200
X-Mailer: WHMail 1.0 (http://www.webhuset.no)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6LN0qFL039006
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



>	Updated: At least one byte has changed and the publisher considers
> the change to be of such significance that readers should consider reading
> the entry even if they had read an earlier version. Atom:updated would be
> used when adding additional paragraphs to an entry, modifying a position
> taken in an entry, modifying the content in such a way that the semantics
of
> the entry (not just it's syntax) has changed.

Disregarding "atom as feed format", and looking at the "atom as archive
format": How is one going to represent a complete history of revisions with
this model, when multiple, and differing entry:id's are disallowed?

-- 
Arve Bersvendsen



From owner-atom-syntax@mail.imc.org  Wed Jul 21 19:11:15 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26020
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 19:11: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 i6LN2Asn039080;
	Wed, 21 Jul 2004 16: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 i6LN2A5X039079;
	Wed, 21 Jul 2004 16:02: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 (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LN29qR039073
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 16:02: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 1E1AA7C115; Thu, 22 Jul 2004 01:58:53 +0200 (CEST)
To: Graham <dtcd@mac.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Those dates again
References: <300410D91BD449178EDAC1E8EB953D.MAI@journurl.com> <7DDB0FC0-DAD0-11D8-B3AB-000A95DC3D90@mac.com>
Message-ID: <opsbifrlcvuvpchu@quark>
Date: Thu, 22 Jul 2004 01:05:35 +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: <7DDB0FC0-DAD0-11D8-B3AB-000A95DC3D90@mac.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Wed, 21 Jul 2004 00:43:20 -0400, Graham <dtcd@mac.com> wrote:

> i) For feeds produced from, say, the result of an SQL query, it's very
> hard to offer a sensible value for modified. I don't want it to
> mandatory unless tools at the consuming end need it to be.

Uhm. Huh? How did the data get itself into the SQL server in the first  
place? By themself? If not, why couldn't the tool putting it there, say  
when it did?

> ii) As an aggregator author, I've never wanted it. Can you fill me in
> on why others do?

To signify (by e.g. marking an entry in bold) that an entry has been  
modified. How great the modification is, is out of scope for 'modified',  
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  Wed Jul 21 19: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 TAA00312
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 19: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 i6LNP2ah040740;
	Wed, 21 Jul 2004 16:25: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 i6LNP2cr040739;
	Wed, 21 Jul 2004 16:25:02 -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 i6LNP1C7040728
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 16:25:01 -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 i6LNTZh8012088;
	Wed, 21 Jul 2004 19:29:35 -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 BJM56249 (AUTH bob@wyman.us);
	Wed, 21 Jul 2004 19:25:02 -0400 (EDT)
Message-Id: <200407212325.BJM56249@ms8.netsolmail.com>
Reply-To: <bob@wyman.us>
From: "Bob Wyman" <bob@wyman.us>
To: "'Arve Bersvendsen'" <arve@virtuelvis.com>, <atom-syntax@imc.org>
Subject: RE: Propose partial consensus on dates
Date: Wed, 21 Jul 2004 19:25: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: AcRvdr/s1avbnjqKRt61D+QABi6zAQAAqlbg
In-Reply-To: <200407212300.i6LN0rcT003249@imr4.netsolmail.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


Arve Bersvendsen wrote:
> Disregarding "atom as feed format", and looking at the "atom as
> archive format": How is one going to represent a complete history
> of revisions with this model, when multiple, and differing
> entry:id's are disallowed?
	Your database key would have to be a compound key built from
"atom:id + atom:updated". Of course, to be really precise you should make
the key "atom:id + atom:modified", but, it doesn't look like folk are
supporting atom:modified...

		Bob wyman




From owner-atom-syntax@mail.imc.org  Wed Jul 21 19: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 TAA00655
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 19:32: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 i6LNObBs040706;
	Wed, 21 Jul 2004 16:24: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 i6LNObEA040705;
	Wed, 21 Jul 2004 16:24: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 i6LNOanE040696
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 16:24: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 83A507C115; Thu, 22 Jul 2004 02:21:19 +0200 (CEST)
Date: Thu, 22 Jul 2004 01:28:05 +0200
To: "Roger B." <roger@agincourtmedia.com>
Subject: Re: Those dates again
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <300410D91BD449178EDAC1E8EB953D.MAI@journurl.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: <opsbigs3lzuvpchu@quark>
In-Reply-To: <300410D91BD449178EDAC1E8EB953D.MAI@journurl.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Tue, 20 Jul 2004 21:56:21 -0500, Roger B. <roger@agincourtmedia.com>  
wrote:

>> If we first define that 'atom:issued' MUST NOT change, we can define
>> superseding mechanisms afterwards, if people need to distinguish minor
>>  from major modifications. But Atom cannot support this by just altering
>> 'issued' in the entry, because that leaves 'issued' just as useless, or
>> even more so, as it would be if it was a random user-entered date.
>
> Asbjørn: You can keep saying it, but it won't change the reality that  
> every syndicated blog on the Web is using just such a date every day.

Is it so that Atom should be modeled solely after current practice? If so,  
why do we bother to define anything but a vague 'date' for entries, and  
why bother specifying what goes in <title> and <content>? If current  
practice is so good, and shouldn't change, Atom == RSS.


I thought that part of the point with Atom was to define a better  
specification, a better model and a better practice than the current state  
of affairs.If you disagree in this, please say so.

> (1) The apps that form the basis of Atom's existence

Why does this matter? Atom is young. Heck, RSS is even young. We can  
define a strict set of dates and clearly specify what they should be, and  
I actually believe most tool providers will support this eventually. Okay,  
old entries will have bad dates, but at least new ones will have good  
ones. That's better than having bad dates on both old and new entries,  
imho.

> produce a date that is generally referred to as "published date" or
> "pubdate".

Movable Type's date is initially 'created' (it gets set the first time you  
change the entry), but can be updated by the user to be anything.

> This is the all-important date that defines how entries are sorted by
> default.

If the prime goal of dates was sorting, RSS wouldn't have an RFC-822 date.

> (2) This date can and will change.

The current vague date will, of course. But the dates in Atom should be  
treated as Atom defines. Why shouldn't Atom define anything that somewhat  
breaks current practice?

> It sometimes be changed by a machine, sometimes by a user.

What's the use case for randomly changing a date?

> There is no reason for Atom to overstep itself and try to mandate
> the origin of the change.

Change whatever you like, but not 'issued'. Not 'created' either.  
'Display' and 'modified' can be modified all you want, though.

> (3) This date can be expressed in as 8601 by virtually all tools. One
> significant exception can produce the date, but without a timezone. That
> exception has a million users and cannot be overlooked.

That exception is afaik agreed to be a bad practice, and it has been  
proposed several solutions to it. Atom should not cater it, at least.

> (4) What we call that date ("issued", "published", "Frances McDormand")  
> is a side-issue.

Yes, I don't care what it's called as long as it gives me «the date the  
entry was (first) published to its intended audience». If people want  
re-issuance mechanisms, 'issued' is not the date to hack on.

> It is the only date that Atom *must* support on a practical level.

If the date can be just about anything, I don't understand why having it  
at all is useful. What will you do with it, if you don't know if it's  
«first-issued», «last-issued», «when the author thought the entry was  
going to be issued» or «when the author was going to issue the entry»?

> If this definition conflicts with dc:issued and people actually care,
> then by all means, another name should be picked out of a hat.

The point, and problem, is not what it's called. The problem is partly the  
current practice and that the date is of great importance in any  
publishing process. Current practice shoots a big hole in the publishing  
process bubble, at least if we model Atom after it. Why would we ever  
choose to model Atom after an imho bad practice, when century old  
publishing processes have proven to work for all mediums?

> (5) For Atom to differentiate itself from RSS, it must support one other
> date: modified. This is the one that aggregator authors are most  
> interested in, and most (if not all) tools can produce it.

Absolutely all tools can produce 'issued' as well. If not, they are not  
capable of publishing the entry onto the web. And if they're not, I  
wouldn't put much money on them being used at all.

> (6) This date can and will change. The change will usually be made by a
> machine, but might be user-defined in certain edge-casey scenarios.

What edge-cases are these, exactly? Are they based on current practice  
(where only one date is available)? Why are these practices something Atom  
should cater and be modeled after?

-- 
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 Jul 21 19:38: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 TAA01873
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 19:38:14 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LNTSYM041724;
	Wed, 21 Jul 2004 16:29: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 i6LNTSBr041723;
	Wed, 21 Jul 2004 16:29: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 (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LNTRZq041713
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 16:29: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 6FF587C115; Thu, 22 Jul 2004 02:26:10 +0200 (CEST)
Date: Thu, 22 Jul 2004 01:32:58 +0200
To: "Eric Scheid" <eric.scheid@ironclad.net.au>
Subject: Re: feed of versions - solves the missing middle entry problem?
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <BD241299.21482%eric.scheid@ironclad.net.au>
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: <opsbig08a5uvpchu@quark>
In-Reply-To: <BD241299.21482%eric.scheid@ironclad.net.au>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Wed, 21 Jul 2004 12:31:21 +1000, Eric Scheid  
<eric.scheid@ironclad.net.au> wrote:

> Someone (Sam? Danny?) noted the problem that if you have entries that  
> link in a chain to their prior versions, the chain could be broken if
> some entry in the middle was not retrieved during the time it was
> available.

Yes, but as I've mentioned earlier, this problem is actually _worse_ for  
non-versioned entries. To be more explicit: Entries are lost today as  
well. If you don't poll a feed for a week, you've surely missed several  
entries. Maybe even hundreds. Today, most (all?) lost entries are unique.  
With a versioning mechanism, lost entries are a version of an entry you've  
already seen somewhere.

At least you'll have the entry, even without its history. The history is,  
nonetheless, _completely_ missing from non-versioned entries. How is it  
worse to loose version-of entry than a unique one? I just don't get it.

>     #6 --> #5 --> #4 --> ???? --> #2 --> #1
>
> If entries #1-6 included a link to a feed which was all those entries,
> including the missing #3, then a publisher only ever needs to publish the
> current entry version at any point in time.

It's a nice solution which at least gives me something to think about in  
regard to the supersede mechanism. Great thinking. Let's have more of  
that, please. :-)

-- 
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 Jul 21 19:49:02 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03703
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 19:49:01 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LNctmP042408;
	Wed, 21 Jul 2004 16:38: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 i6LNctmh042407;
	Wed, 21 Jul 2004 16:38: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 i6LNcsXr042397
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 16:38: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 B432B7C115; Thu, 22 Jul 2004 02:35:38 +0200 (CEST)
To: "Ken MacLeod" <ken@bitsko.slc.ut.us>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceLinkParent updated, tightened
References: <m3vfgjdctl.fsf@bitsko.slc.ut.us> <opsbgjy3uouvpchu@quark> <m3zn5u9m96.fsf@bitsko.slc.ut.us>
Message-ID: <opsbihg2jtuvpchu@quark>
Date: Thu, 22 Jul 2004 01:42:28 +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: <m3zn5u9m96.fsf@bitsko.slc.ut.us>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 20 Jul 2004 20:34:13 -0500, Ken MacLeod <ken@bitsko.slc.ut.us> wrote:

> Logically,
>
>     atom:in-reply-to
>         the atom:id URI of the entry to which this one is a reply (the
>         "parent entry")
>
> is a refinement of
>
>     dct:references
>         The described resource references, cites, or otherwise points
>         to the referenced resource.
>
> which in turn is a refinement of
>
>     dc:relation
>         A reference to a related resource.

True, +1, I agree and so on.

> I think it would be bad practice to use a general term for a very
> specific meaning.

Maybe. It wouldn't hurt to introduce more of the <relation> terms into  
Atom, 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  Wed Jul 21 19:50: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 TAA04161
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 19:50: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 i6LNgOmG042733;
	Wed, 21 Jul 2004 16:42:24 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6LNgOYb042732;
	Wed, 21 Jul 2004 16:42:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LNgO3N042726
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 16:42:24 -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 esmtp (Exim 4.34)
	id 1BnQjB-00083G-J3; Wed, 21 Jul 2004 23:42:25 +0000
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Wed, 21 Jul 2004 19:42:24 -0400
Subject: Re: Propose partial consensus on dates
From: Robert Sayre <mint@franklinmint.fm>
To: Asbj=?ISO-8859-1?B?+A==?=rn Ulsberg <asbjorn@tigerstaden.no>,
        Dare Obasanjo <kpako@yahoo.com>
CC: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD2477A0.142BD%mint@franklinmint.fm>
In-Reply-To: <opsbieyottuvpchu@quark>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
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
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6LNgO3N042727
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 7/21/04 6:48 PM, "Asbjørn Ulsberg" <asbjorn@tigerstaden.no> wrote:

> 
>> Specifically the ability for a user to specify that a significantly
>> edited article should somehow be highlighted as rewritten which
>> differs from tracking if any modification such as fixed typos have
>> occured isn't something I've seen in any blog tool nor have I heard
>> anyone requesting this functionality before until the Atom date debate
>> began.
> 
> True, but it doesn't need to be like that either. It's a hypothetical use
> case. The advantages of re-issuing entries as new entries (with new ID's)
> instead of infinately updating the same entry still outweighs any
> drawbacks (which I think are itsy bitsy) with not supporting the supersede
> mechanism.

NewsML[0] uses an <update> content element rather than a timestamp. Reuters'
old school wire format does the same thing, I think.

<!ELEMENT Update (InsertBefore | InsertAfter | Replace | Delete )*>

Something like this is an option for us, how many times have you seen blog
entries that say things like "<b>Update:</b> I was wrong..."?

I like this because the changes are visible in the document structure. A
timestamp just encourages more frequent polling.

This feels like the right way to do it, IMHO. If it's too complex, let's
just push it out of core.

Robert Sayre

[0] 
http://www.newsml.org/IPTC/NewsML/1.2/specification/NewsML_1.2-spec-function
alspec_7.html#Struct






From owner-atom-syntax@mail.imc.org  Wed Jul 21 19:59:30 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05904
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 19:59: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 i6LNqRXH043478;
	Wed, 21 Jul 2004 16:52: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 i6LNqRRu043477;
	Wed, 21 Jul 2004 16:52: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 (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6LNqQfC043465
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 16:52: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 9EAA07C115; Thu, 22 Jul 2004 02:49:09 +0200 (CEST)
To: "Dare Obasanjo" <kpako@yahoo.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <20040721213626.51427.qmail@web41209.mail.yahoo.com>
Message-ID: <opsbih3okpuvpchu@quark>
Date: Thu, 22 Jul 2004 01:56:02 +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: <20040721213626.51427.qmail@web41209.mail.yahoo.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Wed, 21 Jul 2004 14:36:26 -0700 (PDT), Dare Obasanjo <kpako@yahoo.com>  
wrote:

> I haven't been paying much attention but I definitely
> would add my voice to those who'd point out that SOAP
> support should be a part of Atom to encourage wide
> spread development on many popular development
> platforms.

+1. I'd also like to note that it's more important for me that Atom has  
_one_ mechanism to do specific things, than what that specific solution  
is. In cases like this, I don't think «the more, the merrier» applies very  
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  Wed Jul 21 20:46:52 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13609
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 20:46: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 i6M0crrN047208;
	Wed, 21 Jul 2004 17: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 i6M0crxt047204;
	Wed, 21 Jul 2004 17:38: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 i6M0cmnf046923
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 17:38:51 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 22 Jul 2004 10:43:34 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Thu, 22 Jul 2004 10:18:14 +1000
Subject: Re: Propose partial consensus on dates
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD2544E6.21773%eric.scheid@ironclad.net.au>
In-Reply-To: <200407212101.i6LL19i4029123@above.proper.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


regarding atom:modified and the like...

Are we only considering changes to the atom:content, or would changes in
other elements trigger a change in atom:modified? What if an entry gets some
extra name-spaced extensions larded in after the fact ... is that considered
a modification of the entry?

I suggest that it is. Tools can then rely on atom:modified as a signal to
dump and reload. Tools don't need to necessarily understand the extra
elements, or even do anything with them, but they should replace their
locally held data with the new data.

e.



From owner-atom-syntax@mail.imc.org  Wed Jul 21 20: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 UAA13876
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 20:47: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 i6M0crNq047207;
	Wed, 21 Jul 2004 17: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 i6M0cr1t047203;
	Wed, 21 Jul 2004 17:38: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 i6M0cmWS046921
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 17:38:51 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 22 Jul 2004 10:43:25 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Thu, 22 Jul 2004 10:37:47 +1000
Subject: Re: Propose partial consensus on dates
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD25497B.21783%eric.scheid@ironclad.net.au>
In-Reply-To: <20040721220041.95499.qmail@web41210.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 22/7/04 8:00 AM, "Dare Obasanjo" <kpako@yahoo.com> wrote:

> Specifically the ability for a user to specify that a
> significantly edited article should somehow be
> highlighted as rewritten which differs from tracking
> if any modification such as fixed typos have occured
> isn't something I've seen in any blog tool nor have I
> heard anyone requesting this functionality before
> until the Atom date debate began.

It's common in wikis (but not the atom wiki, ironically)

There's even a mod-wiki extension for RSS which includes a field for
signifying major/minor update.

e.



From owner-atom-syntax@mail.imc.org  Wed Jul 21 20: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 UAA13937
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 20: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 i6M0crFk047209;
	Wed, 21 Jul 2004 17: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 i6M0crjM047205;
	Wed, 21 Jul 2004 17:38: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 i6M0cm20046922
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 17:38:51 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 22 Jul 2004 10:43:27 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Thu, 22 Jul 2004 10:37:52 +1000
Subject: Re: Propose partial consensus on dates
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD254980.21783%eric.scheid@ironclad.net.au>
In-Reply-To: <200407212300.i6LN0oFL039004@above.proper.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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 22/7/04 9:00 AM, "Arve Bersvendsen" <arve@virtuelvis.com> wrote:

> Disregarding "atom as feed format", and looking at the "atom as archive
> format": How is one going to represent a complete history of revisions with
> this model, when multiple, and differing entry:id's are disallowed?

perhaps in the same way that an archive format could encapsulate an archive
of the comments on entries ... as a separate feed specific to that entry.

    <link rel="versions" type="application/atom+xml" ... />

this also has the side effect of only having the current version in the
archive ... handy if you want to import that archive into an environment
that doesn't support entry versions without it having to understand any
'supercedes/obsolete' meta-tagging.

If a tool wants to import all versions, it can still do so.

e.



From owner-atom-syntax@mail.imc.org  Wed Jul 21 21:00: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 VAA16365
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 21:00: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 i6M0pZFo048151;
	Wed, 21 Jul 2004 17:51: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 i6M0pZOf048150;
	Wed, 21 Jul 2004 17:51:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-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 i6M0pYOA048144
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 17:51:34 -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 i6M0nR53013797
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 18:49:27 -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 <0I1800JMYAE3WQ@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Wed, 21 Jul 2004 18:51:40 -0600 (MDT)
Received: from [192.168.1.24] ([216.113.203.45])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTPSA id <0I1800KPRAE23Q@mail.sun.net> for atom-syntax@imc.org; Wed,
 21 Jul 2004 18:51:39 -0600 (MDT)
Date: Wed, 21 Jul 2004 17:51:48 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
In-reply-to: <opsbih3okpuvpchu@quark>
To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
Cc: Dare Obasanjo <kpako@yahoo.com>, Atom-Syntax <atom-syntax@imc.org>
Message-id: <4FF32F05-DB79-11D8-AC8C-000A95A51C9E@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.618)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
References: <20040721213626.51427.qmail@web41209.mail.yahoo.com>
 <opsbih3okpuvpchu@quark>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6M0pYOA048145
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 Jul 21, 2004, at 4:56 PM, Asbjørn Ulsberg wrote:

>> I haven't been paying much attention but I definitely
>> would add my voice to those who'd point out that SOAP
>> support should be a part of Atom to encourage wide
>> spread development on many popular development
>> platforms.

> +1. I'd also like to note that it's more important for me that Atom 
> has _one_ mechanism to do specific things, than what that specific 
> solution is.

I am pretty sure that there is *overwhelming* community demand for a 
REST API.  I think it very unlikely that we would agree to do SOAP but 
not REST.  So I think probably you can have _one_ *or* you can have 
SOAP.  -Tim




From owner-atom-syntax@mail.imc.org  Wed Jul 21 22:57: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 WAA26645
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 22:57: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 i6M2mJSI058291;
	Wed, 21 Jul 2004 19:48: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 i6M2mJX0058290;
	Wed, 21 Jul 2004 19:48:19 -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.45])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6M2mJA8058284
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 19:48:19 -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 i6M2mPAv004287;
	Wed, 21 Jul 2004 19:48:25 -0700 (PDT)
Received: from [192.168.1.101] (66-108-153-170.nyc.rr.com [66.108.153.170])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id i6M2mOVd008483;
	Wed, 21 Jul 2004 19:48:24 -0700 (PDT)
In-Reply-To: <opsbieyottuvpchu@quark>
References: <20040721220041.95499.qmail@web41210.mail.yahoo.com> <opsbieyottuvpchu@quark>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <987794AA-DB88-11D8-B3AB-000A95DC3D90@mac.com>
Cc: Atom-Syntax Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: Propose partial consensus on dates
Date: Wed, 21 Jul 2004 22:41:12 -0400
To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
X-Mailer: Apple Mail (2.618)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6M2mJA8058285
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 21 Jul 2004, at 6:48 pm, Asbjørn Ulsberg wrote:

> What's funny is, however, that any «supersede» mechanism I and Arve 
> have proposed is _already_ supported in _all_ aggregators. Okay, they 
> don't do anything smart with the reference to the previous version of 
> the entry, but they display it as a new entry. Just as they should.

The wrongness of this suggestion is beyond words. The aggregator is not 
working "just as it should". The aggregator is being confused and 
manipulated by a second-rate hack. I read the specs, I see that <guid> 
never changes even when the entry does. I decide I want my aggregator 
to only display the latest version of each entry, and I write it to use 
<guid> that way. You disagree, you come up with a hack that will mean 
it shows two versions of the same entry (all good aggregators keep 
archives). Yes, your <supercedes> tag would clear up the mess, but to 
suggest that aggregators today will work "just at it should" is 
nonsense - it's being borked by the corrupt data you're deliberately 
sending it.
Graham



From owner-atom-syntax@mail.imc.org  Wed Jul 21 23: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 XAA00183
	for <atompub-archive@lists.ietf.org>; Wed, 21 Jul 2004 23: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 i6M3kRDO062712;
	Wed, 21 Jul 2004 20: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 i6M3kROG062711;
	Wed, 21 Jul 2004 20:46:27 -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 i6M3kQLa062696
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 20:46:26 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040722034628.73524.qmail@web41204.mail.yahoo.com>
Received: from [207.46.238.143] by web41204.mail.yahoo.com via HTTP; Wed, 21 Jul 2004 20:46:28 PDT
Date: Wed, 21 Jul 2004 20:46:28 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Propose partial consensus on dates
To: Graham <dtcd@mac.com>, "Asbjørn_Ulsberg" <asbjorn@tigerstaden.no>
Cc: Atom-Syntax Syntax <atom-syntax@imc.org>
In-Reply-To: <987794AA-DB88-11D8-B3AB-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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


--- Graham <dtcd@mac.com> wrote:
> 
> On 21 Jul 2004, at 6:48 pm, Asbjørn Ulsberg wrote:
> 
> > What's funny is, however, that any «supersede»
> mechanism I and Arve 
> > have proposed is _already_ supported in _all_
> aggregators. Okay, they 
> > don't do anything smart with the reference to the
> previous version of 
> > the entry, but they display it as a new entry.
> Just as they should.
> 
> The wrongness of this suggestion is beyond words.
> The aggregator is not 
> working "just as it should". The aggregator is being
> confused and 
> manipulated by a second-rate hack. I read the specs,
> I see that <guid> 
> never changes even when the entry does. I decide I
> want my aggregator 
> to only display the latest version of each entry,
> and I write it to use 
> <guid> that way. You disagree, you come up with a
> hack that will mean 
> it shows two versions of the same entry (all good
> aggregators keep 
> archives). Yes, your <supercedes> tag would clear up
> the mess, but to 
> suggest that aggregators today will work "just at it
> should" is 
> nonsense - it's being borked by the corrupt data
> you're deliberately 
> sending it.

+1 

I was about to make the same comment myself about how
RSS Bandit works. 

=====
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!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/



From owner-atom-syntax@mail.imc.org  Thu Jul 22 03:05: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 DAA25425
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 03:05: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 i6M6qWM3013491;
	Wed, 21 Jul 2004 23:52: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 i6M6qW7D013490;
	Wed, 21 Jul 2004 23:52: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 i6M6qV89013425
	for <atom-syntax@imc.org>; Wed, 21 Jul 2004 23:52:31 -0700 (PDT)
	(envelope-from julian.reschke@gmx.de)
Received: (qmail 18358 invoked by uid 65534); 22 Jul 2004 06:52:20 -0000
Received: from pD95359BC.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.89.188)
  by mail.gmx.net (mp027) with SMTP; 22 Jul 2004 08:52:20 +0200
X-Authenticated: #1915285
Message-ID: <40FF641D.6080502@gmx.de>
Date: Thu, 22 Jul 2004 08:52:13 +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: Tim Bray <Tim.Bray@Sun.COM>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <20040721213626.51427.qmail@web41209.mail.yahoo.com> <opsbih3okpuvpchu@quark> <4FF32F05-DB79-11D8-AC8C-000A95A51C9E@sun.com>
In-Reply-To: <4FF32F05-DB79-11D8-AC8C-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:

> I am pretty sure that there is *overwhelming* community demand for a 
> REST API.  I think it very unlikely that we would agree to do SOAP but 
> not REST.  So I think probably you can have _one_ *or* you can have 
> SOAP.  -Tim

+1.


-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From owner-atom-syntax@mail.imc.org  Thu Jul 22 03: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 DAA26878
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 03:42: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 i6M7ZdtI028760;
	Thu, 22 Jul 2004 00:35: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 i6M7ZdiB028759;
	Thu, 22 Jul 2004 00:35: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 i6M7ZcIk028667
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 00:35: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 456207C115; Thu, 22 Jul 2004 10:32:04 +0200 (CEST)
Date: Thu, 22 Jul 2004 09:39:32 +0200
To: Graham <dtcd@mac.com>
Subject: Re: Propose partial consensus on dates
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <20040721220041.95499.qmail@web41210.mail.yahoo.com> <opsbieyottuvpchu@quark> <987794AA-DB88-11D8-B3AB-000A95DC3D90@mac.com>
From: =?utf-8?Q?Asbj=C3=B8rn_Ulsberg?= <asbjorn@tigerstaden.no>
Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-ID: <opsbi3j6lzkdsr4o@quark>
In-Reply-To: <987794AA-DB88-11D8-B3AB-000A95DC3D90@mac.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Wed, 21 Jul 2004 22:41:12 -0400, Graham <dtcd@mac.com> wrote:

> The wrongness of this suggestion is beyond words. The aggregator is not  
> working "just as it should". The aggregator is being confused and  
> manipulated by a second-rate hack.

You consider this method a «hack», although all institutions,  
organizations and companies in the world that has anything resembling a  
publishing process, does superseding as the only way to change (everything  
but small typographical erratas) the content of a document (both in analog  
and digital form). As I wrote in my entry[1] about this:

See W3C’s specifications, for instance. The HTML specification[2] exists  
in a pack of different versions, where each newer version supersedes an  
old one. The latest HTML 4.01 specification[3] is a supersede of the April  
24th 1998 version[4] which again is a supersede of another version of the  
April 24th 1998 version[5] which in turn is a supersede of the the  
November 7th 1997 version[6] and so on.

So, what W3C does, if I understand your comments correctly, is a  
«second-rate hack». Correct?

> I read the specs, I see that <guid> never changes even when the entry
> does.

The ID doesn't _change_, because the superseding entry is a new entry that  
relates to the old one. This isn't about changing ID's. This is about  
_not_ changig 'issued' to achieve almost the same result as a superseding  
mechanism gives you. This is about realising that a «major update» of an  
entry isn't really an update of that particular entry, but a brand new one.

____
[1] <url: http://www.virtuelvis.com/quark/archives/188.html>
[2] <url: http://www.w3.org/TR/html/>
[3] <url: http://www.w3.org/TR/1999/REC-html401-19991224/>
[4] <url: http://www.w3.org/TR/1999/PR-html40-19990824/>
[5] <url: http://www.w3.org/TR/1998/REC-html40-19980424/>
[6] <url: http://www.w3.org/TR/REC-html40-971218/>

-- 
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 Jul 22 04:42:52 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00571
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 04:42:52 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6M8TD25047936;
	Thu, 22 Jul 2004 01:29: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 i6M8TDP4047935;
	Thu, 22 Jul 2004 01:29:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from dumle.webhuset.no (dumle.webhuset.no [81.27.32.66])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6M8TB82047900
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 01:29:12 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Message-Id: <200407220829.i6M8TB82047900@above.proper.com>
Received: (qmail 32281 invoked from network); 22 Jul 2004 08:27:34 -0000
Received: from unknown (HELO localhost.localdomain) (81.27.34.19)
  by 0 with SMTP; 22 Jul 2004 08:27:34 -0000
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
MIME-Version: 1.0
From: "Arve Bersvendsen" <arve@virtuelvis.com>
To: Eric Scheid <eric.scheid@ironclad.net.au>, atom-syntax@imc.org
Subject: Re: Propose partial consensus on dates
Date: Thu, 22 Jul 2004 10:29:06 +0200
X-Mailer: WHMail 1.0 (http://www.webhuset.no)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6M8TD82047930
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


* Eric Scheid 
> every page edit "supercedes" the prior version of the page, but does not
> cause a new URI to be created for the new version... the page retains the
> same canonical URI.

Note that the resolvable URI need not change. Any supersede mechanism would
carry a reference to an entry:id, not a refereence to <link rel="alternate"
/>

-- 
Arve Bersvendsen



From owner-atom-syntax@mail.imc.org  Thu Jul 22 05: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 FAA01735
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 05:00:50 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6M8pCRQ055695;
	Thu, 22 Jul 2004 01:51: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 i6M8pC8f055694;
	Thu, 22 Jul 2004 01:51:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from dumle.webhuset.no (dumle.webhuset.no [81.27.32.66])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6M8pA3E055656
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 01:51:11 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Message-Id: <200407220851.i6M8pA3E055656@above.proper.com>
Received: (qmail 32382 invoked from network); 22 Jul 2004 08:49:34 -0000
Received: from unknown (HELO localhost.localdomain) (81.27.34.17)
  by 0 with SMTP; 22 Jul 2004 08:49:34 -0000
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
MIME-Version: 1.0
From: "Arve Bersvendsen" <arve@virtuelvis.com>
To: Robert Sayre <mint@franklinmint.fm>, atom-syntax@imc.org
Subject: Re: Propose partial consensus on dates
Date: Thu, 22 Jul 2004 10:51:06 +0200
X-Mailer: WHMail 1.0 (http://www.webhuset.no)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6M8pC3E055688
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


* Robert Sayre
> Something like this is an option for us, how many times have you seen blog
> entries that say things like "<b>Update:</b> I was wrong..."?
> 
> I like this because the changes are visible in the document structure. A
> timestamp just encourages more frequent polling.

This can be handled both in case of the revisioning CMS, and in the
non-revisioning one.

In the (current) non-revisioning one, you would simply contiue your current
practice.  In the case of the revisioning one, you could also write your
'<strong>update</strong>, and in addition ticking a "major edit" box.

-- 
Arve Bersvendsen



From owner-atom-syntax@mail.imc.org  Thu Jul 22 05:14: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 FAA02481
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 05: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 i6M96pYK061848;
	Thu, 22 Jul 2004 02:06: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 i6M96pTl061847;
	Thu, 22 Jul 2004 02:06:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6M96oaV061828
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 02:06:51 -0700 (PDT)
	(envelope-from Janne.Jalkanen@nokia.com)
Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121])
	by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6M96mx15235
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 12:06:48 +0300 (EET DST)
X-Scanned: Thu, 22 Jul 2004 12:06:31 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost)
	by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i6M96VX8018845
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 12:06:31 +0300
Received: from mgw-int1.ntc.nokia.com (172.21.143.96)
	by esdks002.ntc.nokia.com 00Ehvmfo; Thu, 22 Jul 2004 12:06:30 EEST
Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82])
	by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6M96Tn19280
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 12:06:29 +0300 (EET DST)
Received: from [172.21.60.114] ([172.21.60.114]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Thu, 22 Jul 2004 12:06:22 +0300
Message-ID: <40FF838D.3060208@nokia.com>
Date: Thu, 22 Jul 2004 12:06:21 +0300
From: Janne Jalkanen <Janne.Jalkanen@nokia.com>
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 <atom-syntax@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <40FE62E5.6030707@nokia.com> <40FE79D6.9070301@dehora.net>
In-Reply-To: <40FE79D6.9070301@dehora.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 22 Jul 2004 09:06:22.0094 (UTC) FILETIME=[2873D2E0:01C46FCB]
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



> Here's a plausible counter argument. There'll be 10 times that many 
> HTTP enabled devices in 3 years. In 3 years most of those 100M devices 
> will have been thrown away. So this approach will be baking in a 
> subset of HTTP for the short/medium term for what will be a miniority 
> of phones. It's the next 900M phones running HTTP that need to be 
> thought about.

At the moment there's no guarantee that they will be running anything 
else then MIDP 2.0, which does not support PUT/DELETE.

Not even within three years.  The first MIDP 1.0 phone was released in 
2001.  The first MIDP 2.0 phone was in the shops in 2004 (I think, 
could've been very late 2003.)  I don't know how the next generation 
JSRs are moving along, and when they will be deployed.

In fact, the largest growing markets are in Russia, China and India, 
where MIDP (or Brew, for that matter) will be the most commonly deployed 
platform.  Symbian and other smartphones will continue to be more 
expensive, and thus less available on those markets.

To me, supporting MIDP makes sense.

/Janne



From owner-atom-syntax@mail.imc.org  Thu Jul 22 05:20: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 FAA02930
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 05:20: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 i6M9CBBr064012;
	Thu, 22 Jul 2004 02:12: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 i6M9CB7E064011;
	Thu, 22 Jul 2004 02:12:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from dumle.webhuset.no (dumle.webhuset.no [81.27.32.66])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6M9C9qk063959
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 02:12:10 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Message-Id: <200407220912.i6M9C9qk063959@above.proper.com>
Received: (qmail 32503 invoked from network); 22 Jul 2004 09:10:31 -0000
Received: from unknown (HELO localhost.localdomain) (81.27.34.19)
  by 0 with SMTP; 22 Jul 2004 09:10:31 -0000
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
MIME-Version: 1.0
From: "Arve Bersvendsen" <arve@virtuelvis.com>
To: <bob@wyman.us>, atom-syntax@imc.org
Subject: Re: Propose partial consensus on dates
Date: Thu, 22 Jul 2004 11:12:03 +0200
X-Mailer: WHMail 1.0 (http://www.webhuset.no)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6M9CBqk064006
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:

> Arve Bersvendsen wrote:
> > Disregarding "atom as feed format", and looking at the "atom as
> > archive format": How is one going to represent a complete history
> > of revisions with this model, when multiple, and differing
> > entry:id's are disallowed?
>	Your database key would have to be a compound key built from
> "atom:id + atom:updated". Of course, to be really precise you should make
> the key "atom:id + atom:modified", but, it doesn't look like folk are
> supporting atom:modified...

I was not refering to what my database scheme should look like, I already
know how to do that.

I was asking: How can I keep several distinctly different posts, all with the
same ID in the same (archive/edit) feed? I'm going to answer: With today's
wording for ID as "globally unique", the validator pukes on this. Example:

<URL:http://www.virtuelvis.com/temp/dupe-id.xml>
<URL:http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fwww.virtuelvis.com%2
Ftemp%2Fdupe-id.xml>

-- 
Arve Bersvendsen



From owner-atom-syntax@mail.imc.org  Thu Jul 22 05: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 FAA03595
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 05:24: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 i6M9CacU064165;
	Thu, 22 Jul 2004 02:12: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 i6M9CYPi064164;
	Thu, 22 Jul 2004 02:12:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6M9CXZi064130
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 02:12:34 -0700 (PDT)
	(envelope-from Janne.Jalkanen@nokia.com)
Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121])
	by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6M9CXx21237
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 12:12:33 +0300 (EET DST)
X-Scanned: Thu, 22 Jul 2004 12:12:24 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost)
	by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i6M9CORC001252
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 12:12:24 +0300
Received: from mgw-int1.ntc.nokia.com (172.21.143.96)
	by esdks002.ntc.nokia.com 00pUwbpE; Thu, 22 Jul 2004 12:12:23 EEST
Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77])
	by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6M9CMn23752
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 12:12:22 +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);
	 Thu, 22 Jul 2004 12:12:12 +0300
Message-ID: <40FF84EB.7090504@nokia.com>
Date: Thu, 22 Jul 2004 12:12:11 +0300
From: Janne Jalkanen <Janne.Jalkanen@nokia.com>
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
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <40FE62E5.6030707@nokia.com> <40FE79D6.9070301@dehora.net> <40FE7EB3.5090002@intertwingly.net>
In-Reply-To: <40FE7EB3.5090002@intertwingly.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 22 Jul 2004 09:12:12.0092 (UTC) FILETIME=[F91147C0:01C46FCB]
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



> You are both right... to a point.  There is a chicken and egg problem. 
> People won't produce new phones with full support for HTTP until there 
> are applications that demonstrate the value.

True.  And WebDAV is far more interesting in this sense than Atom, I'm 
sorry to say.

> If we decide to go for least common denominator, we need to determine 
> if we can rely on HTTP methods like DELETE and Atom specific HTTP 
> headers.

Nobody has yet mentioned any gateways that eat custom headers (except 
for one, which was not widely deployed).  I'd really like to hear these 
cries against Atom-Action header now; please mail me privately and I'll 
collect them in PaceAtomActionHeader, or post to the list.

>
> The reality is that if we go for least common denominator now, there 
> will be less motivation for cell phones to update, and even if they 
> do, it will be hard to change the deployed base of Atom applications.

WebDAV will take care of the push for updates.

>
> Even if we provide both a primary and fallback mechanism (with the 
> primary having clear benefits in terms of bandwidth, etc), then there 
> will be a period of time where it takes for Atom to get adopted 
> widely, marketing to get the message, product designers to make the 
> product, and for the new products to get widely deployed.

Yup.  And my worst case fear is that people will look at Atom, realize 
that it takes less time to define a new format for their own use than to 
convince the product department to change their own implementation, and 
a new de-facto standard is formed.  Especially the telecom industry has 
been traditionally really bad at this; they are not used to swift 
movements like the internet industry.

> The option of ignoring a large class of existing cell phones entirely 
> would severely affect the adoption of Atom and prevent this feedback 
> loop from happening.

Yup.

/Janne



From owner-atom-syntax@mail.imc.org  Thu Jul 22 05:43:32 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04603
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 05:43: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 i6M9XDrm071508;
	Thu, 22 Jul 2004 02:33: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 i6M9XDII071507;
	Thu, 22 Jul 2004 02:33:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6M9XCGF071493
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 02:33:12 -0700 (PDT)
	(envelope-from Janne.Jalkanen@nokia.com)
Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121])
	by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6M9XCv19912
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 12:33:12 +0300 (EET DST)
X-Scanned: Thu, 22 Jul 2004 12:33:06 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost)
	by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i6M9X6Eu018223
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 12:33:06 +0300
Received: from mgw-int2.ntc.nokia.com (172.21.143.97)
	by esdks002.ntc.nokia.com 003rDgpI; Thu, 22 Jul 2004 12:33:06 EEST
Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28])
	by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6M9Wtu09229
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 12:32:55 +0300 (EET DST)
Received: from [172.21.60.114] ([172.21.60.114]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881);
	 Thu, 22 Jul 2004 12:32:53 +0300
Message-ID: <40FF89C4.9010901@nokia.com>
Date: Thu, 22 Jul 2004 12:32:52 +0300
From: Janne Jalkanen <Janne.Jalkanen@nokia.com>
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@imc.org
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <40FE62E5.6030707@nokia.com> <40FE79D6.9070301@dehora.net> <40FE7EB3.5090002@intertwingly.net> <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <40FE62E5.6030707@nokia.com> <40FE79D6.9070301@dehora.net> <40FE7EB3.5090002@intertwingly.net> <40FE80AA.600@dehora.net> <p06110447bd243f1e99c2@10.20.30.249> <14be96d3040721100379e0ffe5@mail.gmail.com>
In-Reply-To: <14be96d3040721100379e0ffe5@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 22 Jul 2004 09:32:53.0643 (UTC) FILETIME=[DD16EDB0:01C46FCE]
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 on going with the protocol we really want.  I'm not convinced that
>any of the vendors of "differently abled" clients are paying attention
>to us in the short term anyway.
>  
>
*cough*

I think you should be.

Seriously, the telecom world moves in general a lot slower than the 
internet world.  Mobile blogging has thus far been mostly just a game 
for a bunch of people who happen to be technically savvy.  We are seeing 
some amounts of email/sms/im publishing, but that's really only for 
"publishing".  You can't really read blogs very efficiently on your 
mobile phone either (no widespread RSS aggregators, bandwidth issues 
[think how much it would cost to check 20x20 kB RSS feeds every hour, 
not everyone supports ETags]; bloglines.com/mobile being the prime 
example I've seen on web-based aggregation, and even that borks on 
things like UTF-8 feeds).  It's all still just beginning.

Java and MIDP are going to be still in the phones for a long time (and 
we'll have to live with those limitations).  There already is a custom 
image upload API in some camera phones, but there is obvious value in 
trying to use open and public APIs for these kinds of things.  That's 
why I'm here.

-- 
Janne Jalkanen
Senior Specialist
Insight & Foresight
Corporate Strategy
Nokia Corporation



From owner-atom-syntax@mail.imc.org  Thu Jul 22 05: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 FAA05055
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 05:53: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 i6M9fww3074629;
	Thu, 22 Jul 2004 02:41:58 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6M9fwkh074628;
	Thu, 22 Jul 2004 02:41:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from dumle.webhuset.no (dumle.webhuset.no [81.27.32.66])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6M9fuMP074565
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 02:41:57 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Message-Id: <200407220941.i6M9fuMP074565@above.proper.com>
Received: (qmail 32625 invoked from network); 22 Jul 2004 09:40:18 -0000
Received: from unknown (HELO localhost.localdomain) (81.27.34.19)
  by 0 with SMTP; 22 Jul 2004 09:40:18 -0000
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
MIME-Version: 1.0
From: "Arve Bersvendsen" <arve@virtuelvis.com>
To: Graham <dtcd@mac.com>, atom-syntax@imc.org
Subject: Re: Propose partial consensus on dates
Date: Thu, 22 Jul 2004 11:41:50 +0200
X-Mailer: WHMail 1.0 (http://www.webhuset.no)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6M9fwMP074622
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


* Graham wrote:
> > Disregarding "atom as feed format", and looking at the "atom as archive
> > format": How is one going to represent a complete history of revisions 
> > with
> > this model, when multiple, and differing entry:id's are disallowed?
> 
> The spec doesn't say that anywhere. It's technically not an error 
> (currently) to have several entries with the same id in a feed if they 
> are different versions of the same entry. If we mean it to be 
> allowable, this might even provide a valid use case for <modified>.

I've interpreted "globally unique" as "may not appear twice". The feed
validator, and it's authors seem to agree with me:

<URL:http://www.virtuelvis.com/temp/dupe-id.xml>
<URL:http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fwww.virtuelvis.com%2
Ftemp%2Fdupe-id.xml>



From owner-atom-syntax@mail.imc.org  Thu Jul 22 06:13:57 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06254
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 06:13:57 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MA3Zni083569;
	Thu, 22 Jul 2004 03:03: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 i6MA3ZZ5083566;
	Thu, 22 Jul 2004 03:03:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from dumle.webhuset.no (dumle.webhuset.no [81.27.32.66])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6MA3WWG083339
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 03:03:33 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Message-Id: <200407221003.i6MA3WWG083339@above.proper.com>
Received: (qmail 315 invoked from network); 22 Jul 2004 10:01:54 -0000
Received: from unknown (HELO localhost.localdomain) (81.27.34.17)
  by 0 with SMTP; 22 Jul 2004 10:01:54 -0000
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
MIME-Version: 1.0
From: "Arve Bersvendsen" <arve@virtuelvis.com>
To: bob@wyman.us, atom-syntax@imc.org
Subject: Re: Propose partial consensus on dates
Date: Thu, 22 Jul 2004 12:03:26 +0200
X-Mailer: WHMail 1.0 (http://www.webhuset.no)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6MA3YWG083523
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:

>	Your database key would have to be a compound key built from
> "atom:id + atom:updated". Of course, to be really precise you should make
> the key "atom:id + atom:modified", but, it doesn't look like folk are
> supporting atom:modified...

Replying twice, because I need to explain why "modified" is terrible for
recognizing revisions:

1. Joe Blogger writes an entry in his BlogToolGT.  BlogToolGT has a complete
revisioning mechanism, which only not does let him issue new revisions, it
also lets him roll back to previous versions. This entry is last modified on
2005-01-01T00:00:01Z

2. Joe Blogger writes a new entry.

3. Joe Blogger rewrites his entire entry (a Major revision), which is last
modified on 2005-01-01T12:00:01Z

4. Jane Bloggers aggregator pulls Joe Bloggers feed and sees the entry for
the first time.

5. Joe Blogger decides that his Major revision was no good after all, and he
performs a rollback to the 2005-01-01T00:00:01Z-version. In essence: the
revision he rolls back to hasn't been modified since that date, and that's
what goes into "modified".

6. Jane Blogger pulls Joes feed again. Her aggregator now has two entries
with the same id. One written right after midnight, and one written at noon. 


7. At this time, Jane starts reading her newsfeeds. Which of Joes entries is
Jane going to see? 



From owner-atom-syntax@mail.imc.org  Thu Jul 22 08: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 IAA14006
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 08:16:07 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MC32dh005759;
	Thu, 22 Jul 2004 05: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 i6MC32d7005758;
	Thu, 22 Jul 2004 05:03:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MC30B5005752
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 05:03:01 -0700 (PDT)
	(envelope-from Janne.Jalkanen@nokia.com)
Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121])
	by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6MC31722988
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 15:03:01 +0300 (EET DST)
X-Scanned: Thu, 22 Jul 2004 15:02:54 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost)
	by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i6MC2sSB010614
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 15:02:54 +0300
Received: from mgw-int1.ntc.nokia.com (172.21.143.96)
	by esdks002.ntc.nokia.com 000WRaEs; Thu, 22 Jul 2004 15:02:53 EEST
Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77])
	by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6MC2mn19510
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 15:02:48 +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);
	 Thu, 22 Jul 2004 15:02:45 +0300
Message-ID: <40FFACE5.1060805@nokia.com>
Date: Thu, 22 Jul 2004 15:02:45 +0300
From: Janne Jalkanen <Janne.Jalkanen@nokia.com>
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 WG <atom-syntax@imc.org>
Subject: Re: Summary of Put/Delete problems (PacePutDelete Withdrawn)
References: <BD1DDB85.13D53%mint@franklinmint.fm> <40FAA6D3.30701@aol.net> <40FD2033.5040907@nokia.com> <40FD2EA6.9020903@intertwingly.net> <40FD376D.8080407@franklinmint.fm> <40FE62E5.6030707@nokia.com> <40FE79D6.9070301@dehora.net> <E79CB9C2-DB4B-11D8-B3AB-000A95DC3D90@mac.com> <p06110450bd247f63d889@[10.20.30.249]>
In-Reply-To: <p06110450bd247f63d889@[10.20.30.249]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 22 Jul 2004 12:02:45.0779 (UTC) FILETIME=[CCD1FE30:01C46FE3]
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 for the same reason. If the future market demands Atom, J2ME 
> devices (or whatever doesn't handle our protocol) will change to 
> handle Atom. If the future market doesn't demand Atom, there is no 
> reason for us to tailor Atom for a market that doesn't care.

Except that the market may change according to whether Atom works or not.

If Atom is really simple to run on MIDP devices => developers will do 
stuff on it => there will be a market for Atom
If Atom is really difficult to run on MIDP devices => developers shake 
their head and go for proprietary solutions => there is no market for Atom.

We have to make that decision here, too.

> We're not talking about purity here. Things that are "purely" RESTy or 
> "purely" SOAPy are good starting points. However, if we can step away 
> from the purity in order to embrace more current platforms at no 
> significant *technical* cost, we should. Doing so is not only good for 
> current stuff: it helps future platforms as well.

Hear, hear!  This is exactly why I like the PaceAtomActionHeader so 
much; the technical impact is very low on implementations, and it 
assumes nothing of the payload format, yet it allows many 
PutDeleteBorked platforms to function :)

/Janne



From owner-atom-syntax@mail.imc.org  Thu Jul 22 08:43:49 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15674
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 08:43:49 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MCW9QR009115;
	Thu, 22 Jul 2004 05:32: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 i6MCW9Sk009114;
	Thu, 22 Jul 2004 05:32: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.206])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6MCW8uR009106
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 05:32:08 -0700 (PDT)
	(envelope-from eliast@gmail.com)
Received: by mproxy.gmail.com with SMTP id 72so37726rne
        for <atom-syntax@imc.org>; Thu, 22 Jul 2004 05:32:09 -0700 (PDT)
Received: by 10.38.90.2 with SMTP id n2mr83177rnb;
        Thu, 22 Jul 2004 05:32:09 -0700 (PDT)
Message-ID: <905f7c91040722053278962348@mail.gmail.com>
Date: Thu, 22 Jul 2004 08:32:09 -0400
From: Elias Torres <eliast@gmail.com>
Reply-To: elias@torrez.us
To: Arve Bersvendsen <arve@virtuelvis.com>
Subject: Re: Propose partial consensus on dates
Cc: bob@wyman.us, atom-syntax@imc.org
In-Reply-To: <200407221003.i6MA3WWG083339@above.proper.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <200407221003.i6MA3WWG083339@above.proper.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


I'm glad people are bringing up this point relating to ids. I have a
proposition maybe we can change the subject of this email.

Currently the norm has been to use tag URIs like this:

tag:www.virtuelvis.com,2003:1192312312

Here at IBM, my dept was one of the creators of a new standard called
LSID. (LS) we still thinking of it's meaning, but it started as "Life
Sciences", but ID is for identifier :-) This standard was started
because there was a need for a naming specification of biological
entities, but we are finding its applications to be broader than that.
Let me show you an example LSID.

urn:lsid:yourdomain.com:namespace:uniqueID[:version]

urn:lsid:www.virtuelvis.com:myblog-entries-2003:1192312312
urn:lsid:www.virtuelvis.com:myblog-entries-2003:1192312312:1
urn:lsid:www.virtuelvis.com:myblog-entries-2003:1192312312:3

This scheme has many advantages:

- We've registered lsid for resolution (I'll double check, opposed to tag). 
- There's standard scheme for the URI, which is much more unclear of
the usage for tag URIs.
- This LSID urls are resolvable, mainly by pure DNS lookups. 
- NS, UNIQUEID and VERSION are completely freeform for anyone to use
anyway they want to. You may use versions as 1.1, 1.2 or AA, BB, etc.
for example.

The most important function of the spec is that from now til eternity
when you resolve a LSID and fetch the data behind it, you will ALWAYS
get returned the same exact bytes. That's was the standard was meant
to address, because when you go to an HTTP url, you always end up
getting different data. If you pass the optional version attribute you
may get that, if you don't it's up to the resolving authority to
decide whether returning the first or the latest (need to double check
this). Anyways, I'm extremely interested in people being aware of this
because I think it will of great value to Atom spec.

Remember, you are only using ID tags as a string, if we recommend it
we don't have to implement anything related to LSID, it's just a way
to guide people creating a URI that's consistent and that has been
carefully thought out. It's completely optional if people wanted to
host a resolver to LSID-aware apps could resolve their posts that way
as well.

Let me know what you think,

Elias Torres (eliast at us.ibm.com)

On Thu, 22 Jul 2004 12:03:26 +0200, Arve Bersvendsen
<arve@virtuelvis.com> wrote:
> 
> * Bob Wyman:
> 
> >       Your database key would have to be a compound key built from
> > "atom:id + atom:updated". Of course, to be really precise you should make
> > the key "atom:id + atom:modified", but, it doesn't look like folk are
> > supporting atom:modified...
> 
> Replying twice, because I need to explain why "modified" is terrible for
> recognizing revisions:
> 
> 1. Joe Blogger writes an entry in his BlogToolGT.  BlogToolGT has a complete
> revisioning mechanism, which only not does let him issue new revisions, it
> also lets him roll back to previous versions. This entry is last modified on
> 2005-01-01T00:00:01Z
> 
> 2. Joe Blogger writes a new entry.
> 
> 3. Joe Blogger rewrites his entire entry (a Major revision), which is last
> modified on 2005-01-01T12:00:01Z
> 
> 4. Jane Bloggers aggregator pulls Joe Bloggers feed and sees the entry for
> the first time.
> 
> 5. Joe Blogger decides that his Major revision was no good after all, and he
> performs a rollback to the 2005-01-01T00:00:01Z-version. In essence: the
> revision he rolls back to hasn't been modified since that date, and that's
> what goes into "modified".
> 
> 6. Jane Blogger pulls Joes feed again. Her aggregator now has two entries
> with the same id. One written right after midnight, and one written at noon.
> 
> 7. At this time, Jane starts reading her newsfeeds. Which of Joes entries is
> Jane going to see?
> 
>



From owner-atom-syntax@mail.imc.org  Thu Jul 22 08:53: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 IAA16110
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 08:53: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 i6MCjXa9009877;
	Thu, 22 Jul 2004 05:45: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 i6MCjXZe009876;
	Thu, 22 Jul 2004 05:45:33 -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 i6MCjWgo009869
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 05:45:33 -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 i6MCkT49027934;
	Thu, 22 Jul 2004 08:46:30 -0400
Message-ID: <40FFB6EA.7010601@intertwingly.net>
Date: Thu, 22 Jul 2004 08:45:30 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: =?UTF-8?B?QXNiasO4cm4gVWxzYmVyZw==?= <asbjorn@tigerstaden.no>
CC: Graham <dtcd@mac.com>, Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Propose partial consensus on dates
References: <20040721220041.95499.qmail@web41210.mail.yahoo.com> <opsbieyottuvpchu@quark> <987794AA-DB88-11D8-B3AB-000A95DC3D90@mac.com> <opsbi3j6lzkdsr4o@quark>
In-Reply-To: <opsbi3j6lzkdsr4o@quark>
Content-Type: text/plain; charset=UTF-8; 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:
> 
> So, what W3C does, if I understand your comments correctly, is a  
> «second-rate hack». Correct?

Many, many times I wish that Graham would refrain from using such 
emotionally charged language because many times I find myself agreeing 
with what he said, but not with the way in which he said it.

This is one of those times.

Between friends, playing chess, "do overs" may be permitted.

"Do overs" (taking back a move made in error) are not permitted in 
professional chess tournaments.

The W3C is professional.  They don't revise specifications in place. 
Instead, they issue new ones that supercede old ones.

If you wish to run your blog that way, that's fine.

Imposing that level of professionalism on all casual usages of blogs, 
however, is inappropriate.

Graham doesn't want to outlaw updating in place, he merely wants to be 
able to deal with it.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Thu Jul 22 09:43: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 JAA19885
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 09:43: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 i6MDT6EH013305;
	Thu, 22 Jul 2004 06:29: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 i6MDT639013304;
	Thu, 22 Jul 2004 06:29:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from garland.duramedia.net (garland.duramdedia.net [209.51.131.138] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MDT6JB013294
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 06:29:06 -0700 (PDT)
	(envelope-from jg@jonasgalvez.com)
Received: from 200-206-135-201.dsl.telesp.net.br ([200.206.135.201])
	by garland.duramedia.net with esmtp (Exim 4.34)
	id 1BnddC-0000Yr-MX
	for atom-syntax@imc.org; Thu, 22 Jul 2004 09:29:07 -0400
Message-ID: <40FFC0DE.7010101@jonasgalvez.com>
Date: Thu, 22 Jul 2004 10:27:58 -0300
From: Jonas Galvez <jg@jonasgalvez.com>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: AtomSyntax <atom-syntax@imc.org>
Subject: Re: PacePutDelete Withdrawn
References: <20040715142548.9823.qmail@web41501.mail.yahoo.com>	<40F69CFF.6080802@franklinmint.fm> <m3iscpjn09.fsf@bitsko.slc.ut.us> <40F6AB6A.7030100@franklinmint.fm>
In-Reply-To: <40F6AB6A.7030100@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 - garland.duramedia.net
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - jonasgalvez.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


Robert Sayre wrote:
> OK. I always forget about the alternate X-Atom-Method approach
> mentioned there. Is it alleged that shipping J2ME HTTP classes allow
> setting of request headers, but not HTTP methods other than GET and
> POST? Are there any other clients that can set headers but not
> methods?

I haven't finished reading the whole thread yet, but I'd like point out
that I'm strongly in favor of the custom HTTP Header alternative, since
the Flash Player now includes a 'addRequestHeader()' method to the
LoadVars and XML classes. I think it'd be the cleanest approach.



\\ jonas galvez
// jonasgalvez.com



From owner-atom-syntax@mail.imc.org  Thu Jul 22 10:18:23 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24318
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 10:18: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 i6ME0uoK015982;
	Thu, 22 Jul 2004 07:00:56 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6ME0uGM015981;
	Thu, 22 Jul 2004 07:00:56 -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 i6ME0u5N015974
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 07:00:56 -0700 (PDT)
	(envelope-from distobj@acm.org)
Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian))
	id 1Bne8h-00072F-00
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 10:01:39 -0400
Date: Thu, 22 Jul 2004 10:01:39 -0400
To: Atom-Syntax <atom-syntax@imc.org>
Subject: SOAP support
Message-ID: <20040722140139.GE30868@markbaker.ca>
References: <20040721213626.51427.qmail@web41209.mail.yahoo.com> <opsbih3okpuvpchu@quark> <4FF32F05-DB79-11D8-AC8C-000A95A51C9E@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4FF32F05-DB79-11D8-AC8C-000A95A51C9E@sun.com>
User-Agent: Mutt/1.3.28i
From: Mark Baker <distobj@acm.org>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


On Wed, Jul 21, 2004 at 05:51:48PM -0700, Tim Bray wrote:
> I am pretty sure that there is *overwhelming* community demand for a 
> REST API.  I think it very unlikely that we would agree to do SOAP but 
> not REST.  So I think probably you can have _one_ *or* you can have 
> SOAP.  -Tim

Actually, I think my previous suggestion[1] is a way to get both;
only require the use of SOAP when mandatory extensions are used since
HTTP 1.1 can't do them (at least not without some other long-forgotten
spec like PEP or RFC 2774).

 [1] http://www.imc.org/atom-syntax/mail-archive/msg07433.html

Mark.



From owner-atom-syntax@mail.imc.org  Thu Jul 22 10: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 KAA25110
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 10:26: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 i6MEG4lR016841;
	Thu, 22 Jul 2004 07: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 i6MEG4jB016840;
	Thu, 22 Jul 2004 07:16:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from garland.duramedia.net (garland.duramdedia.net [209.51.131.138] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MEG4cH016833
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 07:16:04 -0700 (PDT)
	(envelope-from jg@jonasgalvez.com)
Received: from 200-206-135-201.dsl.telesp.net.br ([200.206.135.201])
	by garland.duramedia.net with esmtp (Exim 4.34)
	id 1BneMh-0002KQ-5n
	for atom-syntax@imc.org; Thu, 22 Jul 2004 10:16:07 -0400
Message-ID: <40FFCBE2.7050901@jonasgalvez.com>
Date: Thu, 22 Jul 2004 11:14:58 -0300
From: Jonas Galvez <jg@jonasgalvez.com>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: AtomSyntax <atom-syntax@imc.org>
Subject: Re: PacePutDelete Withdrawn
References: <20040715142548.9823.qmail@web41501.mail.yahoo.com>	<40F69CFF.6080802@franklinmint.fm> <m3iscpjn09.fsf@bitsko.slc.ut.us> <40F6AB6A.7030100@franklinmint.fm> <40FFC0DE.7010101@jonasgalvez.com>
In-Reply-To: <40FFC0DE.7010101@jonasgalvez.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 - garland.duramedia.net
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - jonasgalvez.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


Jonas Galvez wrote:
> I haven't finished reading the whole thread yet, but I'd like point
> out that I'm strongly in favor of the custom HTTP Header alternative,
> since the Flash Player now includes a 'addRequestHeader()' method to
> the LoadVars and XML classes. I think it'd be the cleanest approach.

If any of you have Flash MX 2004 (or Flash MX with the latest Flash
Player in the authoring environment), try this:

     x = new XML("<test><request method=\"PUT\" /></test>");
     x.onData = function(response) {
         trace(response);
     };
     x.addRequestHeader("X-Atom-Action", "PUT");
     x.sendAndLoad("http://jonasgalvez.com/lab/http-header-test.py", x);

http-header-test.py contains:

     #!/usr/bin/python

     import os

     print "Content-type: application/xml\n"

     if os.environ["HTTP_X_ATOM_ACTION"] == "PUT":
	print '<test><response method="PUT" /></test>'

This is really exciting. I could implement a Atom client in Flash using
this technique right away, and would avoid the pain of SOAP (parsing
complex XML is also a concern in Flash Player - I've worked with - and
supported SOAP in the past - and I could clearly see the performance
issues on the thin client that is the Flash Player).

XML.addRequestHeader() is avaible on Flash Player 6 r65 and above.


\\ jonas galvez
// jonasgalvez.com



From owner-atom-syntax@mail.imc.org  Thu Jul 22 10: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 KAA25359
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 10: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 i6MEBMXa016543;
	Thu, 22 Jul 2004 07: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 i6MEBM7J016542;
	Thu, 22 Jul 2004 07:11:22 -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 i6MEBJiu016530
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 07:11:20 -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 i6MEBF53031819
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 09:11:16 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6MEBFm8031815;
	Thu, 22 Jul 2004 09:11:15 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: atom-syntax@imc.org
Subject: Re: Propose partial consensus on dates
References: <200407212300.i6LN0oFL039004@above.proper.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 22 Jul 2004 09:11:15 -0500
In-Reply-To: <200407212300.i6LN0oFL039004@above.proper.com>
Message-ID: <m3hds09loc.fsf@bitsko.slc.ut.us>
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


"Arve Bersvendsen" <arve@virtuelvis.com> writes:

> Disregarding "atom as feed format", and looking at the "atom as
> archive format": How is one going to represent a complete history of
> revisions with this model, when multiple, and differing entry:id's
> are disallowed?

We can say "atom as an archive format" can have multiple entry
instances with the same atom:entry/atom:id (while also having, say,
different atom:entry/formalpub:version-id URIs).

However, disregarding whether a formal publishing model should be in
the core of Atom, if we recognized a formal publishing model as a
first class application of Atom (of course, why wouldn't we?) we
should consider the issue of duplicate atom:entry/atom:id's in the
same dynamic feed as well and propose a solution for informal Atom
clients to disregard all but the most-recently modified/updated entry.

  -- Ken



From owner-atom-syntax@mail.imc.org  Thu Jul 22 10:49: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 KAA26592
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 10:49: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 i6MEa8C1018829;
	Thu, 22 Jul 2004 07:36: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 i6MEa822018828;
	Thu, 22 Jul 2004 07:36:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MEa8xR018820
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 07:36:08 -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 1Bneg2-0001Ww-A9; Thu, 22 Jul 2004 14:36:06 +0000
Message-ID: <40FFD0D4.4060005@franklinmint.fm>
Date: Thu, 22 Jul 2004 10:36:04 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonas Galvez <jg@jonasgalvez.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PacePutDelete Withdrawn
References: <20040715142548.9823.qmail@web41501.mail.yahoo.com>	<40F69CFF.6080802@franklinmint.fm> <m3iscpjn09.fsf@bitsko.slc.ut.us> <40F6AB6A.7030100@franklinmint.fm> <40FFC0DE.7010101@jonasgalvez.com> <40FFCBE2.7050901@jonasgalvez.com>
In-Reply-To: <40FFCBE2.7050901@jonasgalvez.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


Jonas Galvez wrote:
> 
> Jonas Galvez wrote:
> 
>> I haven't finished reading the whole thread yet, but I'd like point
>> out that I'm strongly in favor of the custom HTTP Header alternative,
>> since the Flash Player now includes a 'addRequestHeader()' method to
>> the LoadVars and XML classes. I think it'd be the cleanest approach.
> 
> 
> If any of you have Flash MX 2004 (or Flash MX with the latest Flash
> Player in the authoring environment), try this:
> 

Or you could try dropping a WSDL file into Flash MX 2004's built-in "Web 
Services" component:

http://www.franklinmint.fm/blog/archives/images/atom_wsdl_in_flash.gif


> 
> This is really exciting. I could implement a Atom client in Flash using
> this technique right away, and would avoid the pain of SOAP (parsing
> complex XML is also a concern in Flash Player - I've worked with - and
> supported SOAP in the past - and I could clearly see the performance
> issues on the thin client that is the Flash Player).
> 

Which player version? I could see having problems on Flash 5, when the 
XML Parser was written in interpreted code, but not with current 
versions. Besides, the SOAP envelope for a given entry wouldn't be much 
bigger than the entry itself.

Robert Sayre



From owner-atom-syntax@mail.imc.org  Thu Jul 22 10:54: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 KAA26915
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 10:54: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 i6MEebUo019182;
	Thu, 22 Jul 2004 07:40: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 i6MEebxQ019181;
	Thu, 22 Jul 2004 07:40: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 i6MEeaDt019175
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 07:40:36 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from phys-bur-1 ([129.148.9.72])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6MEeXil004085
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 08:40:39 -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 <0I1900M01CJNM7@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com)
 for atom-syntax@imc.org; Thu, 22 Jul 2004 10:40:33 -0400 (EDT)
Received: from mercury (vpn-129-150-33-88.Central.Sun.COM [129.150.33.88])
 by bur-mail1.east.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
 with ESMTP id <0I1900MOBCRGL7@bur-mail1.east.sun.com> for atom-syntax@imc.org;
 Thu, 22 Jul 2004 10:40:33 -0400 (EDT)
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1BnekA-0001tv-00	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 10:40:22 -0400
X-URL: http://nwalsh.com/
Date: Thu, 22 Jul 2004 10:40:22 -0400
From: Norman Walsh <ndw@nwalsh.com>
Subject: Re: PaceLinkConstruct issues & next steps
In-reply-to: <3733B5B6-DA9B-11D8-BFCB-000A95A51C9E@sun.com>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <877jsww1ex.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: <3733B5B6-DA9B-11D8-BFCB-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-Type: text/plain

/ Tim Bray <Tim.Bray@Sun.COM> was heard to say:
| I'll wait for a day or two to give people a chance to shout one of:
| (a) give up and go to distinct elements now
| (b) yes, push it on the queue and give us a chance to work something up
| (c) hey, there is too consensus on XXXX, you just didn't notice

(b) is fine, though I'd be happy with (a) because that's my personal
favorite.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Everything the same; everything
http://nwalsh.com/            | distinct.

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA/9HWOyltUcwYWjsRArMGAJ0WrfrWqfXjAp+25BPDScxYTHmOvACfaSaW
Z5u9Yq3b0LpTYX20Ng1fy+8=
=Y0JK
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Thu Jul 22 11:00: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 LAA27318
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 11:00: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 i6MEkOC1020660;
	Thu, 22 Jul 2004 07: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 i6MEkOY2020659;
	Thu, 22 Jul 2004 07:46:24 -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 i6MEkNx4020648
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 07:46:23 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040722144616.30739.qmail@web41208.mail.yahoo.com>
Received: from [67.170.36.166] by web41208.mail.yahoo.com via HTTP; Thu, 22 Jul 2004 07:46:16 PDT
Date: Thu, 22 Jul 2004 07:46:16 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Propose partial consensus on dates
To: "Asbjørn_Ulsberg" <asbjorn@tigerstaden.no>, Graham <dtcd@mac.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <opsbi3j6lzkdsr4o@quark>
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>


--- Asbjørn_Ulsberg <asbjorn@tigerstaden.no> wrote:
> 
> > I read the specs, I see that <guid> never changes
> even when the entry
> > does.
> 
> The ID doesn't _change_, because the superseding
> entry is a new entry that  
> relates to the old one. This isn't about changing
> ID's. This is about  
> _not_ changig 'issued' to achieve almost the same
> result as a superseding  
> mechanism gives you. This is about realising that a
> «major update» of an  
> entry isn't really an update of that particular
> entry, but a brand new one

I love the ambiguity of this stuff. What the heck is a
major update? So you're saying that users will see the
same post twice in their aggregator but that's OK
because a 'major' update has been done but there is no
way to explain to users what exactly is meant by
'major update'. 

Hmmmm. Sounds very user unfriendly 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!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/



From owner-atom-syntax@mail.imc.org  Thu Jul 22 11:13: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 LAA28247
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 11:13: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 i6MEx9L9022648;
	Thu, 22 Jul 2004 07:59: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 i6MEx9x7022647;
	Thu, 22 Jul 2004 07:59:09 -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 i6MEx9lm022636
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 07:59:09 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040722145906.27272.qmail@web41203.mail.yahoo.com>
Received: from [67.170.36.166] by web41203.mail.yahoo.com via HTTP; Thu, 22 Jul 2004 07:59:06 PDT
Date: Thu, 22 Jul 2004 07:59:06 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Propose partial consensus on dates
To: Arve Bersvendsen <arve@virtuelvis.com>, bob@wyman.us, atom-syntax@imc.org
In-Reply-To: <200407221003.i6MA3WWG083339@above.proper.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


--- Arve Bersvendsen <arve@virtuelvis.com> wrote:
> 
> 
> Replying twice, because I need to explain why
> "modified" is terrible for
> recognizing revisions:
> 
> 1. Joe Blogger writes an entry in his BlogToolGT. 
> BlogToolGT has a complete
> revisioning mechanism, which only not does let him
> issue new revisions, it
> also lets him roll back to previous versions. This
> entry is last modified on
> 2005-01-01T00:00:01Z
> 
> 2. Joe Blogger writes a new entry.
> 
> 3. Joe Blogger rewrites his entire entry (a Major
> revision), which is last
> modified on 2005-01-01T12:00:01Z
> 
> 4. Jane Bloggers aggregator pulls Joe Bloggers feed
> and sees the entry for
> the first time.
> 
> 5. Joe Blogger decides that his Major revision was
> no good after all, and he
> performs a rollback to the
> 2005-01-01T00:00:01Z-version. In essence: the
> revision he rolls back to hasn't been modified since
> that date, and that's
> what goes into "modified".

That sounds like a pretty dumb tool. Too external
entities the entry has been modified. Ignore feeds and
imagine you were visiting a website. If the first
entry a user sees on the website was the one written
at midnight and then they show up a few days later
only to see a different one, do you really think it
makes sense to tell the user the last modified date of
the entry was BEFORE the last modified date they saw
previously even though the entry has obviously been
modified AFTER that date from the user's perspective? 

=====
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 Jul 22 11:38: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 LAA29987
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 11:38: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 i6MFTFsv026330;
	Thu, 22 Jul 2004 08:29: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 i6MFTF4s026329;
	Thu, 22 Jul 2004 08:29:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MFTD2q026322
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 08:29:14 -0700 (PDT)
	(envelope-from Janne.Jalkanen@nokia.com)
Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120])
	by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6MFTF705129;
	Thu, 22 Jul 2004 18:29:15 +0300 (EET DST)
X-Scanned: Thu, 22 Jul 2004 18:27:35 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost)
	by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i6MFRZab026060;
	Thu, 22 Jul 2004 18:27:35 +0300
Received: from mgw-int2.ntc.nokia.com (172.21.143.97)
	by esdks001.ntc.nokia.com 00iogi8A; Thu, 22 Jul 2004 18:27:34 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 i6MFRYu28667;
	Thu, 22 Jul 2004 18:27:34 +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);
	 Thu, 22 Jul 2004 18:27:34 +0300
Message-ID: <40FFDCE6.7070701@nokia.com>
Date: Thu, 22 Jul 2004 18:27:34 +0300
From: Janne Jalkanen <Janne.Jalkanen@nokia.com>
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: ext Jonas Galvez <jg@jonasgalvez.com>
CC: AtomSyntax <atom-syntax@imc.org>
Subject: Re: PacePutDelete Withdrawn
References: <20040715142548.9823.qmail@web41501.mail.yahoo.com>	<40F69CFF.6080802@franklinmint.fm> <m3iscpjn09.fsf@bitsko.slc.ut.us> <40F6AB6A.7030100@franklinmint.fm> <40FFC0DE.7010101@jonasgalvez.com> <40FFCBE2.7050901@jonasgalvez.com>
In-Reply-To: <40FFCBE2.7050901@jonasgalvez.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-OriginalArrivalTime: 22 Jul 2004 15:27:34.0139 (UTC) FILETIME=[6940ECB0:01C47000]
X-MIME-Autoconverted: from 8bit to quoted-printable by mgw-int2.ntc.nokia.com id i6MFRYu28667
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6MFTE2q026323
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



> This is really exciting. I could implement a Atom client in Flash using
> this technique right away, and would avoid the pain of SOAP (parsing
> complex XML is also a concern in Flash Player - I've worked with - and
> supported SOAP in the past - and I could clearly see the performance
> issues on the thin client that is the Flash Player).

Yup.  I just hacked together an Atom API client for MIDP using the 
Atom-Action header.  Relatively trivial to do for a proof-of-concept.  
Of course, there are no servers that support it yet (I don't have the 
time to hack JSPWiki today), but it should give you an idea how it works.

(And again, this would work perfectly with binary objects as well, 
without having to bring in SOAP into the actual client.  The client jar 
seems big at 48 kB, but that's because it includes kxml2 in its 
entirety, which is completely unnecessary.  It also includes a 
rudimentary Atom feed parser.)

(Excuse my lame code, I didn't think at all while coding.  Pure 
instinct.  No WSSE support here either. And probably the <entry> written 
is not even valid. If Russ or some of the other Java überhackers on this 
list want to pick it up, that'd be cool by me.  I'm going to a four-week 
holiday starting tomorrow afternoon, so not a lot will be happening from 
my side regarding Atom :)

http://www.ecyrd.com/~jalkanen/Jello.zip

/Janne



From owner-atom-syntax@mail.imc.org  Thu Jul 22 11:51:56 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00943
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 11: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 i6MFaj04026932;
	Thu, 22 Jul 2004 08: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 i6MFajee026931;
	Thu, 22 Jul 2004 08:36:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from garland.duramedia.net (garland.duramdedia.net [209.51.131.138] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MFaibZ026920
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 08:36:45 -0700 (PDT)
	(envelope-from jg@jonasgalvez.com)
Received: from 200-206-135-201.dsl.telesp.net.br ([200.206.135.201] ident=jgalvez)
	by garland.duramedia.net with esmtp (Exim 4.34)
	id 1Bnfci-0006JG-HP
	for atom-syntax@imc.org; Thu, 22 Jul 2004 11:36:45 -0400
Message-ID: <40FFDEC8.3060902@jonasgalvez.com>
Date: Thu, 22 Jul 2004 12:35:36 -0300
From: Jonas Galvez <jg@jonasgalvez.com>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: AtomSyntax <atom-syntax@imc.org>
Subject: Re: PacePutDelete Withdrawn
References: <20040715142548.9823.qmail@web41501.mail.yahoo.com>	<40F69CFF.6080802@franklinmint.fm> <m3iscpjn09.fsf@bitsko.slc.ut.us> <40F6AB6A.7030100@franklinmint.fm> <40FFC0DE.7010101@jonasgalvez.com> <40FFCBE2.7050901@jonasgalvez.com> <40FFD0D4.4060005@franklinmint.fm>
In-Reply-To: <40FFD0D4.4060005@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 - garland.duramedia.net
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - jonasgalvez.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


Robert Sayre wrote:
> Or you could try dropping a WSDL file into Flash MX 2004's built-in 
> "Web Services" component:
> 
> http://www.franklinmint.fm/blog/archives/images/atom_wsdl_in_flash.gif
> 
> Which player version? I could see having problems on Flash 5, when 
> the XML Parser was written in interpreted code, but not with current 
> versions. Besides, the SOAP envelope for a given entry wouldn't be 
> much bigger than the entry itself.

That component is not built into the Player. It is interpreted code as
well. XML parsing is now very fast in the Flash Player (especially in FP
7), but it is still a concern with big files. Might not be noticeable on
a high-performance machine, but on a.. say, 500Mhz computer (which a lot
of potential users of rich web apps still use), these problems become
very evident. That's not limited to XML parsing, the "built-in" (not
available in the player, must be embeded within your application) UI
components also show unsatisfactory performance. The point is: any
second of CPU processing I can save in a Flash application is worth for
me (and lots of other developer too, I believe).

I tried to elaborate about this before:
http://www.imc.org/atom-syntax/mail-archive/msg05030.html

But yes, SOAP in Flash wouldn't represent much of a problem. The Web
Service component is very convenient, but if we can do it a simpler and
faster manner, I wouldn't mind giving up on SOAP. However, I agree that
this a very tough decision. SOAP has a wide market acceptance, for
instance, Macromedia's own ColdFusion MX has a built-in mechanism for
generating WSDL files etc. Same with .NET. So SOAP would make Atom
server software development quite easy with a particular set of tools.
Anyway, I'd still stick to the X-Atom-Method approach. I like Atom's
simplicity. I like light-weight server software. SOAP is a bloated
protocol, IMHO. But that's just me. (And I know I am not being very
helpful by not providing solid technical arguments, but I believe others
already did their best showing these points and will continue to
rephrase them if necessary).

By the way, I would happily develop a FMX2004 Atom client component.



\\ jonas galvez
// jonasgalvez.com



From owner-atom-syntax@mail.imc.org  Thu Jul 22 12:10:49 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02071
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 12:10:48 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MFuWTp028155;
	Thu, 22 Jul 2004 08:56: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 i6MFuW2M028154;
	Thu, 22 Jul 2004 08:56: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 i6MFuWQb028139
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 08:56:32 -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 <2004072215562901100drp3ae>; Thu, 22 Jul 2004 15:56:29 +0000
Date: Thu, 22 Jul 2004 09:56:28 -0600
Subject: Re: Propose partial consensus on dates
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: <20040722144616.30739.qmail@web41208.mail.yahoo.com>
Message-Id: <B1606B79-DBF7-11D8-B36F-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 Thursday, July 22, 2004, at 08:46  AM, Dare Obasanjo wrote:
> I love the ambiguity of this stuff. What the heck is a
> major update? So you're saying that users will see the
> same post twice in their aggregator but that's OK
> because a 'major' update has been done but there is no
> way to explain to users what exactly is meant by
> 'major update'.
>
> Hmmmm. Sounds very user unfriendly to me.

Let's apply this approach to some more elements:

* What the heck is a title?  Well, it's a few words to give people an 
idea of what appears in the content.  But are they the right words?  Or 
did the author chose them badly?  Is the title element user unfriendly 
because authors write bad titles?  Should we drop it from the format?  
Is there a way to explain to users exactly what should go in the title?

* What the heck is a summary?  Well, it's something longer than the 
title, but it serves a similar purpose--giving the reader a quick 
preview of what's in the content.  But if, as will probably not be 
uncommon, the author just puts the first paragraph of the content into 
the summary, is it a good summary?  Is it a summary at all?  If the 
content is well written, then it may very well be, but not all content 
is well written--some first paragraphs don't even come close to 
summarizing what follows them. Perhaps we should nuke the summary.

* While we're at it, lets nuke content, and just have links to content 
appearing elsewhere on the internet.  That way, we won't have to 
explain what to put in any of those troublesome elements, and no one 
will have to suffer from feed publishers' bad choices.

I'm sure the above sounds utterly absurd to you.  Understand that your 
assertions that publishers can't make intelligent decisions about 
whether an entry has changed enough to warrant them checking a box that 
says "this entry has changed significantly--make it appear in people's 
feed readers again" sound equally absurd to some of us.  Will some 
people make that decision badly?  Sure.  And some people will 
unsubscribe from their feeds because of it.  Just as they'll lose 
subscribers if they write bad headlines, summaries and content.  Will 
others make the decision judiciously?  Yes.  Will that add value to 
their feeds?  Yes.



From owner-atom-syntax@mail.imc.org  Thu Jul 22 12:29: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 MAA03619
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 12:29: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 i6MGFHYe030256;
	Thu, 22 Jul 2004 09:15: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 i6MGFHVR030255;
	Thu, 22 Jul 2004 09:15:17 -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 i6MGFFh4030225
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 09:15:16 -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 i6MGFC53001116
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 11:15:12 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6MGFB0j001111;
	Thu, 22 Jul 2004 11:15:11 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: atom-syntax@imc.org
Subject: Re: Propose partial consensus on dates
References: <200407212101.i6LL19i4029123@above.proper.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 22 Jul 2004 11:15:11 -0500
In-Reply-To: <200407212101.i6LL19i4029123@above.proper.com>
Message-ID: <m3acxs9fxs.fsf@bitsko.slc.ut.us>
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


"Arve Bersvendsen" <arve@virtuelvis.com> writes:

> The biggest issue with dates, however, seems to be 'issued', and
> that issue is heavily bound to the notion of re-issuance and
> entry:id:
> 
> - My view is that if a major modification is made to an entry, it is
> no longer the same entry, but a new entry, with a new entry:id.
> - This new entry MUST contain explicit information about which entry
> it "supersedes" [1].
> - Hence: an issued date becomes immutable, and as "objective" as the
> authoring tool makes it.
> This view of issued, together with "display" solves the Samuel Pepys
> Use Case, since the display date is then not bound to anything
> specific, except the original author's perceptual timeline [2].

For the sake of discussion, what happens if concensus is not to adopt
this view (model) in the core.  What would it look like for this model
(view) to be mapped into or layered over the Atom model?

In the [current] Atom model, the resource being identified is the one
that "has multiple versions".  It's not [currently] specified whether
atom:issued date is the "re-issued" of the most recent version or
"first issued" of the multiple versions.

We could relax the restriction that atom:entry/atom:id be unique by
saying that they *are* in fact the same entry, but different versions
(with the version identifier in an extension), and clients should use
the last-modified entry.  Clients can ignore missing versions because,
as in practice today, they don't need them as long as the
atom:entry/atom:id is the same as any previous version.

We could also specify that atom:issued is the date of the version, and
the "first issued" date can either be in an extensions or tracking
down the first published version of the "resource that has many
versions".

Would that work?

  -- Ken



From owner-atom-syntax@mail.imc.org  Thu Jul 22 12:45: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 MAA04811
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 12:45: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 i6MGUvQF031652;
	Thu, 22 Jul 2004 09:30:57 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6MGUvbS031651;
	Thu, 22 Jul 2004 09:30:57 -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 i6MGUuXn031645
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 09:30:56 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p0611046ebd259afd0f60@[10.20.30.249]>
Date: Thu, 22 Jul 2004 09:31:37 -0700
To: Atom WG <atom-syntax@imc.org>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: WG meeting in San Diego CANCELLED
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>


Greetings again. Following up on the thread from the other day, Tim 
and I have decided to cancel the WG meeting in San Diego. There were 
just too few expected participants to make it worth having everyone 
come from around the world, and the mailing list is doing quite well 
without a face-to-face meeting at this time.

If you already paid to register for the IETF meeting, and you were 
only coming for the Atom WG, you should cancel your reservation *by 
Monday the 26th*. You will get a refund (minus a $50 service charge). 
See the bottom of <http://www.ietf.org/meetings/rsvp_closed.html> for 
more information. We apologize to anyone for whom this is a financial 
burden.

If you are coming to the IETF meeting for other reasons, please try 
to make it to the Apps Area meeting on Monday morning. Tim and I will 
give a presentation on Atompub in order to get more interest from 
IETF regulars who have experience in the fields we are dealing with. 
It is likely that there will be questions, and having folks other 
than Tim and I help answer them would be great.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Thu Jul 22 12:45:24 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04831
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 12:45: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 i6MGU8Zr031580;
	Thu, 22 Jul 2004 09:30: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 i6MGU8YZ031579;
	Thu, 22 Jul 2004 09:30:08 -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 i6MGU8GG031571
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 09:30:08 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040722163001.4274.qmail@web41206.mail.yahoo.com>
Received: from [67.160.85.226] by web41206.mail.yahoo.com via HTTP; Thu, 22 Jul 2004 09:30:01 PDT
Date: Thu, 22 Jul 2004 09:30:01 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Propose partial consensus on dates
To: Antone Roundy <antone@geckotribe.com>, atom-syntax@imc.org
In-Reply-To: <B1606B79-DBF7-11D8-B36F-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 Thursday, July 22, 2004, at 08:46  AM, Dare
> Obasanjo wrote:
> > I love the ambiguity of this stuff. What the heck
> is a
> > major update? So you're saying that users will see
> the
> > same post twice in their aggregator but that's OK
> > because a 'major' update has been done but there
> is no
> > way to explain to users what exactly is meant by
> > 'major update'.
> >
> > Hmmmm. Sounds very user unfriendly to me.
> 
> Let's apply this approach to some more elements:
> 
> * What the heck is a title?  Well, it's a few words
> to give people an 
> idea of what appears in the content.  But are they
> the right words?  Or 
> did the author chose them badly?  Is the title
> element user unfriendly 
> because authors write bad titles?  Should we drop it
> from the format?  
> Is there a way to explain to users exactly what
> should go in the title?
> 
> * What the heck is a summary?  Well, it's something
> longer than the 
> title, but it serves a similar purpose--giving the
> reader a quick 
> preview of what's in the content.  But if, as will
> probably not be 
> uncommon, the author just puts the first paragraph
> of the content into 
> the summary, is it a good summary?  Is it a summary
> at all?  If the 
> content is well written, then it may very well be,
> but not all content 
> is well written--some first paragraphs don't even
> come close to 
> summarizing what follows them. Perhaps we should
> nuke the summary.
> 
> * While we're at it, lets nuke content, and just
> have links to content 
> appearing elsewhere on the internet.  That way, we
> won't have to 
> explain what to put in any of those troublesome
> elements, and no one 
> will have to suffer from feed publishers' bad
> choices.
> 
> I'm sure the above sounds utterly absurd to you. 

Nope they don't. Every feature added is added
complexity. Design is all about hitting the right
cost/benefit balance of complexity to features. I
think the distinction between summary and content is
unnecessary complexity but many seem to like it. Many
blog tools allow titles to be optional and I've met
users of such tools who'd rather not use titles.
However the benefit of such features is much more than
the added complexity of having these features in the
format that may either go unused by some or misused by
others. 

Having some date that is tied to an amorphous concept
like 'significant update' will be a usability problem
for aggregators. Any aggregator author with a decent
user base will tell you that one of the most
irritating problems for users are when duplicate items
show up in their aggregator.  This misfeature you are
proposing is actually enshrining this into the Atom
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!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/



From owner-atom-syntax@mail.imc.org  Thu Jul 22 12: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 MAA05670
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 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 i6MGYXUK031871;
	Thu, 22 Jul 2004 09:34: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 i6MGYXBj031870;
	Thu, 22 Jul 2004 09:34:33 -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.45])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MGYW6q031864
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 09:34:32 -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 i6MGYZAv016209;
	Thu, 22 Jul 2004 09:34:35 -0700 (PDT)
Received: from [192.168.1.103] (66-108-152-101.nyc.rr.com [66.108.152.101])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id i6MGY4Vd028377;
	Thu, 22 Jul 2004 09:34:17 -0700 (PDT)
In-Reply-To: <opsbi3j6lzkdsr4o@quark>
References: <20040721220041.95499.qmail@web41210.mail.yahoo.com> <opsbieyottuvpchu@quark> <987794AA-DB88-11D8-B3AB-000A95DC3D90@mac.com> <opsbi3j6lzkdsr4o@quark>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <BBC082CE-DBFC-11D8-B3AB-000A95DC3D90@mac.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: Propose partial consensus on dates
Date: Thu, 22 Jul 2004 12:32:33 -0400
To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
X-Mailer: Apple Mail (2.618)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6MGYW6q031865
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 22 Jul 2004, at 3:39 am, Asbjørn Ulsberg wrote:

> You consider this method a «hack», although all institutions, 
> organizations and companies in the world that has anything resembling 
> a publishing process, does superseding as the only way to change 
> (everything but small typographical erratas) the content of a document 
> (both in analog and digital form).

It doesn't matter if the EU, the MFI and the Moonies organize their 
documents that way. RSS doesn't. Atom 0.3 doesn't. They don't have a 
<supercedes> element, and no aggregator supports one.

> This is about realising that a «major update» of an entry isn't really 
> an update of that particular entry, but a brand new one.

If you say so, Asjborn.

Graham



From owner-atom-syntax@mail.imc.org  Thu Jul 22 13:42: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 NAA08901
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 13:42: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 i6MHMmcQ036253;
	Thu, 22 Jul 2004 10: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 i6MHMm6Y036252;
	Thu, 22 Jul 2004 10:22:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MHMmFj036221
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 10: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 (rwcrmhc13) with SMTP
          id <20040722172246015003hot1e>; Thu, 22 Jul 2004 17:22:46 +0000
Date: Thu, 22 Jul 2004 11:22:45 -0600
Subject: Re: Propose partial consensus on dates
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: <20040722163001.4274.qmail@web41206.mail.yahoo.com>
Message-Id: <BEC99C0E-DC03-11D8-B36F-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 Thursday, July 22, 2004, at 10:30  AM, Dare Obasanjo wrote:
> --- Antone Roundy <antone@geckotribe.com> wrote:
>> I'm sure the above sounds utterly absurd to you.
>
> Nope they don't. Every feature added is added
> complexity. Design is all about hitting the right
> cost/benefit balance of complexity to features. I
> think the distinction between summary and content is
> unnecessary complexity but many seem to like it. Many
> blog tools allow titles to be optional and I've met
> users of such tools who'd rather not use titles.
> However the benefit of such features is much more than
> the added complexity of having these features in the
> format that may either go unused by some or misused by
> others.

Okay, there was some sense behind the arguments, but certainly not 
nearly enough to support nuking title and content--which is what I 
meant to say would be absurd.  (Less absurd for summary, but still, I 
think the benefit outweighs the cost).

> Having some date that is tied to an amorphous concept
> like 'significant update' will be a usability problem
> for aggregators. Any aggregator author with a decent
> user base will tell you that one of the most
> irritating problems for users are when duplicate items
> show up in their aggregator.  This misfeature you are
> proposing is actually enshrining this into the Atom
> spec.

To clarify my position, my comments were not meant to be taken entirely 
within the context of the thread--I'm not in favor of issuing major (or 
minor) changes to an entry as a new entry.  What I favor is enabling 
publishers to make a distinction between little adjustments and 
"significant updates".  I don't see it being too much of a headache for 
aggregator authors, because they can give the user an option to 
redisplay updated entries or not.  They can give their users even finer 
grained control by enabling them to redisplay only updates that the 
publisher considered "significant".  Enabling the user to override 
their global setting for particular feeds where the publisher thinks 
every change is major would be the icing on the cake in my view.

A question then to be sure that I understand your position.  In 
http://www.imc.org/atom-syntax/mail-archive/msg06958.html when you said 
+1 to:

 > Date 1: Updated
 >
 > This date is meant to be a machine generated
 > timestamp indicating when
 > the most recent substantive change has been made to
 > the entry.

were you supporting updated as defined by Sam (including the word 
"substantive") or were you intending to say +1 to an updated date when 
the last change of ANY kind was made (removing the word "substantive")?

One other question: if the modified date (whether limited to 
"substantive" changes or not) is not to be used in conjunction with 
redisplay of altered entries, would you have any use for it at all?

Antone



From owner-atom-syntax@mail.imc.org  Thu Jul 22 13: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 NAA08919
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 13: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 i6MHPvod036461;
	Thu, 22 Jul 2004 10:25: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 i6MHPvHr036460;
	Thu, 22 Jul 2004 10:25:57 -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 i6MHPvAD036448
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 10:25:57 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040722172547.46805.qmail@web41209.mail.yahoo.com>
Received: from [67.160.85.226] by web41209.mail.yahoo.com via HTTP; Thu, 22 Jul 2004 10:25:47 PDT
Date: Thu, 22 Jul 2004 10:25:47 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Propose partial consensus on dates
To: Graham <dtcd@mac.com>, "Asbjørn_Ulsberg" <asbjorn@tigerstaden.no>
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <BBC082CE-DBFC-11D8-B3AB-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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


--- Graham <dtcd@mac.com> wrote:
> 
> On 22 Jul 2004, at 3:39 am, Asbjørn Ulsberg wrote:
> 
> > You consider this method a «hack», although all
> institutions, 
> > organizations and companies in the world that has
> anything resembling 
> > a publishing process, does superseding as the only
> way to change 
> > (everything but small typographical erratas) the
> content of a document 
> > (both in analog and digital form).
> 
> It doesn't matter if the EU, the MFI and the Moonies
> organize their 
> documents that way. RSS doesn't. Atom 0.3 doesn't.
> They don't have a 
> <supercedes> element, and no aggregator supports
> one.

No aggregator supports Atom 1.0 either so the fact
that something hasn't been supported in the past is no
argument that it can't be supported in the future. 

I'd rather debate the feature on its merits than
whether it has been supported by tools in the past or
not. 

By the way I dispute that the W3C supercedes
documents. A spec has two URIs, the URI that
identifies a version of a technology (e.g.
http://www.w3.org/TR/REC-xml) and one that identifies
the actual iteration of that document (e.g.
http://www.w3.org/TR/2004/REC-xml-20040204). If I only
go to the main URI for a W3C document then to me the
changes happened in place. In fact, this caused a
problem for SOAP when the W3C changed
http://www.w3.org/TR/soap/ to point to the SOAP 1.2
spec instead of the SOAP 1.1 spec since many people
use that URI to identify SOAP 1.1 since it was teh
only version that existed. The eventually backpedalled
and made the URI point to a landing page. 

=====
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 Jul 22 14: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 OAA14612
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 14:47: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 i6MIZIOJ042020;
	Thu, 22 Jul 2004 11:35: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 i6MIZIUZ042019;
	Thu, 22 Jul 2004 11:35:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MIZDJh042009
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 11:35:14 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6MIZFil006098
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 12:35:15 -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 <0I1900HJSNMRP8@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Thu, 22 Jul 2004 12:35:15 -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 <0I1900CRUNMQE1@mail.sun.net> for atom-syntax@imc.org; Thu,
 22 Jul 2004 12:35:15 -0600 (MDT)
Date: Thu, 22 Jul 2004 09:56:21 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: URI scheme delusions
In-reply-to: <905f7c91040722053278962348@mail.gmail.com>
To: elias@torrez.us
Cc: bob@wyman.us, atom-syntax@imc.org, Arve Bersvendsen <arve@virtuelvis.com>
Message-id: <0ED5D262-DC00-11D8-AC8C-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: <200407221003.i6MA3WWG083339@above.proper.com>
 <905f7c91040722053278962348@mail.gmail.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 Jul 22, 2004, at 5:32 AM, Elias Torres wrote:

> Currently the norm has been to use tag URIs like this:
> tag:www.virtuelvis.com,2003:1192312312

On which planet?

> urn:lsid:www.virtuelvis.com:myblog-entries-2003:1192312312
...
> - This LSID urls are resolvable, mainly by pure DNS lookups.

Not by any software on my computer.

> The most important function of the spec is that from now til eternity
> when you resolve a LSID and fetch the data behind it, you will ALWAYS
> get returned the same exact bytes. That's was the standard was meant
> to address, because when you go to an HTTP url, you always end up
> getting different data.

There seems to a recurrent persistent mania that infects otherwise 
reasonable people with the belief that by registering a URI scheme they 
are going to impose changes on fundamental human nature or management 
practice.  Whether nor not the contents of whatever a URI points at 
change is a matter of policy and management, not of technology.

So... you have repealed the second law of thermodynamics and the basic 
propensity of humans to screw up such that you can be sure that the 
bytes will never change?  I congratulate you.  I know using "http:..." 
is nowhere near as glamorous as inventing your own coolio neato URI 
scheme, but you know, if you have a management policy that the 
representation of some resource will never change, and if you enforce 
that policy, then it doesn't make a damn bit of difference what the 
characters before the colon are.  Oh, unless of course you actually 
want to use the URI to retrieve data or bookmark it or expose it to a 
search engine or any of the other things that "http:" URIs are useful 
for.  -Tim


- Tim Bray, Director of Web Technologies, Sun Microsystems
   +1-877-305-0889 Sun ext. 60561
   http://www.tbray.org/ongoing/  AIM: MarkupPedant



From owner-atom-syntax@mail.imc.org  Thu Jul 22 15:36: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 PAA19367
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 15:36: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 i6MJQYtR045475;
	Thu, 22 Jul 2004 12:26:34 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6MJQYSk045474;
	Thu, 22 Jul 2004 12:26: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 i6MJQXPS045465
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 12:26: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 MAA06768
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 12:26: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 MAA04867
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 12:26: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); Thu, 22 Jul 2004 12:26:29 -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 <0I19001J5Q03LM@shazam.verity.com> for atom-syntax@imc.org; Thu,
 22 Jul 2004 12:26:29 -0700 (PDT)
Date: Thu, 22 Jul 2004 12:26:29 -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: Propose partial consensus on dates
In-reply-to: <593B9E26-DB42-11D8-AC8C-000A95A51C9E@sun.com>
To: Atom-Syntax Syntax <atom-syntax@imc.org>
Message-id: 
 <CE28A43EFA3774A5EFDAF7C5@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: <593B9E26-DB42-11D8-AC8C-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 Wednesday, July 21, 2004 11:18 AM -0700 Tim Bray <Tim.Bray@Sun.COM> wrote:
>
> So, we need proposals for:
> - a better name than "display".  <just-tim-not-cochair>I</just-tim-not-cochair> hereby propose "dateline"

"dateline" might be confusing, because of preexisting newspaper usage.
In newspaper usage, a dateline may include a location. From XMLNews:

  <dateline>
  <location><city>Bangkok</city></location>
  <story.date>May 31, 1999</story.date>
  </dateline>
  see: <http://www.xmlnews.org/docs/story-spec.html#element.dateline>

NewsML defines it as:

  DateLine  A natural-language statement of the date and/or place of creation.
  see: <http://www.newsml.org/IPTC/NewsML/1.0/specification/NewsML_1.0-spec-functionalspec_4.html#DateLine>

I like that definition for Atom, but we would need to lose the
"and/or place" part.

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Thu Jul 22 15:45: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 PAA20335
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 15: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 i6MJUheA045736;
	Thu, 22 Jul 2004 12:30: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 i6MJUhpr045735;
	Thu, 22 Jul 2004 12:30:43 -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 i6MJTgnq045642
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 12:30:42 -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 PAA18882;
	Thu, 22 Jul 2004 15:29:44 -0400 (EDT)
Message-Id: <200407221929.PAA18882@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: i-d-announce@ietf.org
Cc: atom-syntax@imc.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-atompub-protocol-01.txt
Date: Thu, 22 Jul 2004 15:29:44 -0400
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>


--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Atom Publishing Format and Protocol Working Group of the IETF.

	Title		: The Atom Publishing Protocol
	Author(s)	: J. Gregorio, R. Sayre
	Filename	: draft-ietf-atompub-protocol-01.txt
	Pages		: 20
	Date		: 2004-7-22
	
This memo presents a protocol for using XML (Extensible Markup
   Language) and HTTP (HyperText Transport Protocol) to edit content.


   The Atom Publishing Protocol is an application-level protocol for
   publishing and editing Web resources belonging to periodically
   updated websites.  The protocol at its core is the HTTP transport of
   Atom-formatted representations.  The Atom format is documented in the
   Atom Syndication Format (draft-ietf-atompub-format-00.txt).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-01.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-atompub-protocol-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-atompub-protocol-01.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-7-22145113.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-atompub-protocol-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-atompub-protocol-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2004-7-22145113.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-atom-syntax@mail.imc.org  Thu Jul 22 16:09: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 QAA24129
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 16:09: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 i6MJojvO047491;
	Thu, 22 Jul 2004 12:50: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 i6MJojsR047490;
	Thu, 22 Jul 2004 12:50:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-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 i6MJoda3047478
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 12:50:39 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6MJohil011848
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 13:50:43 -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 <0I1900LSMR4I6T@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Thu, 22 Jul 2004 13:50:43 -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 <0I1900KQRR4H3N@mail.sun.net> for atom-syntax@imc.org; Thu,
 22 Jul 2004 13:50:42 -0600 (MDT)
Date: Thu, 22 Jul 2004 12:50:53 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: URI scheme delusions
In-reply-to: <0ED5D262-DC00-11D8-AC8C-000A95A51C9E@sun.com>
To: Tim Bray <Tim.Bray@Sun.COM>
Cc: bob@wyman.us, elias@torrez.us, atom-syntax@imc.org,
        Arve Bersvendsen <arve@virtuelvis.com>
Message-id: <709AF709-DC18-11D8-AC8C-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: <200407221003.i6MA3WWG083339@above.proper.com>
 <905f7c91040722053278962348@mail.gmail.com>
 <0ED5D262-DC00-11D8-AC8C-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 Jul 22, 2004, at 9:56 AM, Tim Bray wrote:

>> Currently the norm has been to use tag URIs like this:
>> tag:www.virtuelvis.com,2003:1192312312
>
> On which planet?

Sigh, that was rude, sorry.  Also, it was entirely off-topic for Atom.  
-Tim



From owner-atom-syntax@mail.imc.org  Thu Jul 22 16: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 QAA25024
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 16: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 i6MK97Wb048967;
	Thu, 22 Jul 2004 13:09: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 i6MK97bO048966;
	Thu, 22 Jul 2004 13:09:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.201])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6MK96T5048953
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 13:09:07 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id d78so114086rnf
        for <atom-syntax@imc.org>; Thu, 22 Jul 2004 13:09:08 -0700 (PDT)
Received: by 10.38.81.69 with SMTP id e69mr81754rnb;
        Thu, 22 Jul 2004 13:09:08 -0700 (PDT)
Message-ID: <3f1451f50407221309323e5063@mail.gmail.com>
Date: Thu, 22 Jul 2004 16:09:08 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
Subject: Re: I-D ACTION:draft-ietf-atompub-protocol-01.txt
Cc: atom-syntax@imc.org
In-Reply-To: <200407221929.PAA18882@ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <200407221929.PAA18882@ietf.org>
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 Thu, 22 Jul 2004 15:29:44 -0400, internet-drafts@ietf.org
<internet-drafts@ietf.org> wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Atom Publishing Format and Protocol Working Group of the IETF.
> 
>         Title           : The Atom Publishing Protocol
>         Author(s)       : J. Gregorio, R. Sayre
>         Filename        : draft-ietf-atompub-protocol-01.txt
>         Pages           : 20
>         Date            : 2004-7-22
> 

As usual the HTML version and side-by-side diffs 
can be found at: http://bitworking.org/projects/atom/

    -joe
  
-- 
Joe Gregorio        http://bitworking.org



From owner-atom-syntax@mail.imc.org  Thu Jul 22 16:26: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 QAA26548
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 16: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 i6MK9ngn049015;
	Thu, 22 Jul 2004 13: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 i6MK9nsW049014;
	Thu, 22 Jul 2004 13:09: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 i6MK9mJY049007
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 13:09:48 -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 i6MK7c53023019
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 14:07:38 -0600 (MDT)
Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0I1900HP8S0GP8@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Thu, 22 Jul 2004 14:09:52 -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 <0I1900KM4S0F3K@mail.sun.net> for atom-syntax@imc.org; Thu,
 22 Jul 2004 14:09:52 -0600 (MDT)
Date: Thu, 22 Jul 2004 13:09:59 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: I-D ACTION:draft-ietf-atompub-protocol-01.txt
In-reply-to: <200407221929.PAA18882@ietf.org>
To: "Atom-Syntax Syntax'" <atom-syntax@imc.org>
Message-id: <1BAE70D6-DC1B-11D8-AC8C-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: <200407221929.PAA18882@ietf.org>
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 Jul 22, 2004, at 12:29 PM, Internet-Drafts@ietf.org wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Atom Publishing Format and Protocol 
> Working Group of the IETF.

And about time too, a tip 'o the hat to Paul for jarring this loose 
from the process.

But really, I just wanted to say "thanks" on behalf of the whole 
community to Mnot, Joe, and Rob for getting these things polished up 
and out the door.  We've got an active group, competent editors, and a 
tractable problem, there's no reason why this shouldn't go down in the 
books as an example of a standard done right.  Assuming of course we 
can shake out consensus on the "dates" issue :) -Tim



From owner-atom-syntax@mail.imc.org  Thu Jul 22 19:03: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 TAA25886
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 19:03: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 i6MMoFuK062939;
	Thu, 22 Jul 2004 15:50: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 i6MMoFk1062938;
	Thu, 22 Jul 2004 15:50:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from cat-proof.de (cat.cat-proof.de [213.239.198.176])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6MMoE8R062917
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 15:50:15 -0700 (PDT)
	(envelope-from sc@itst.net)
Received: from [192.168.1.10] (p508178CE.dip0.t-ipconnect.de [80.129.120.206])
	by cat-proof.de (Postfix) with ESMTP id 15CB03410386
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 00:48:43 +0200 (CEST)
Message-ID: <4100451B.4080304@itst.net>
Date: Fri, 23 Jul 2004 00:52:11 +0200
From: Sascha Carlin <sc@itst.net>
User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707)
X-Accept-Language: de, en
MIME-Version: 1.0
To: atom-syntax@imc.org
Subject: Re: Propose partial consensus on dates
References: <593B9E26-DB42-11D8-AC8C-000A95A51C9E@sun.com>
In-Reply-To: <593B9E26-DB42-11D8-AC8C-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:

> 1. Each entry must have a "modified" which is an assertion from the 
> publisher as to when the resource was last changed.  This should be in 
> RFC3339 format.  Example: a travel journal, the entry for the 8th was 
> <atom:modified> on the 17th.

BTW, I am not sure if I got that right: "modified" should also indicate
the time the entry was published? If yes, -1, see below.


> 2. Each entry may have a "display" date - you can think of it as part of 

+1


> 3. Each entry may have a "created" date - the date on which it came to 
> be.  For example, the travel-journal entry for the 8th was 
> <atom:created> on the 11th.  RFC3339.

+1


> - the name "display" is not that great.  I've seen suggestions of "base" 
> and "described".  It occurs to me that in North American journalistic 
> lingo, the word "dateline" *exactly* describes the semantics.

Isn't that "deadline"? Err, forget it ;)


> - there are a variety of incompatible requirements (some of them quite 
> strong) for another date called "issued" which doesn't seem to be any of 
> these.

Should be optional, +1


> - what the right format is for "display"

If it's a date, it should be formated as dates are in Atom...


> - are there any must-have missing dates (I wonder if "created" could be 
> defined in a way that would meet at least some of the needs around 
> "issued").

"created" != "issued".

Issued should be a requirement, indicating the time the entry was
published for the first time.

And finally, "updated" should be there - optionally.

That would make the following list:

REQ "issued"   - the time the entry was published for the first time

OPT "created"  - the time the entry was created i. e. was saved (inside
                  the publishing system) for the first time

OPT "modified" - the last time the entry was modified without changing
                  the semantical informtion given in the entry
If the entry is modified, this should be REQ

OPT "display"  - an accompanying pointing out an semantically important
                  date to/of the entry

OPT "updated"  - the last time the entry was semantically changed
If the entry is updated, this should be REQ

Regards, Sascha




From owner-atom-syntax@mail.imc.org  Thu Jul 22 19:47: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 TAA01134
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 19:47: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 i6MNZWGF066917;
	Thu, 22 Jul 2004 16:35: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 i6MNZWls066916;
	Thu, 22 Jul 2004 16:35:32 -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 i6MNZVj7066897
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 16:35:31 -0700 (PDT)
	(envelope-from roger@agincourtmedia.com)
Received: from biggreen ([216.63.148.42]) by journurl.com with MailEnable ESMTP; Thu, 22 Jul 2004 18:35:41 -0500
From: "Roger B." <roger@agincourtmedia.com>
To: <atom-syntax@imc.org>
Subject: RE: Propose partial consensus on dates
Date: Thu, 22 Jul 2004 18:40:45 -0500
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: <4100451B.4080304@itst.net>
Thread-Index: AcRwPqV+/xQDEdgdQk62L+1LQ6E1+AAAnq2w
Message-ID: <CB11033A97134EDBA75A9D48599CA.MAI@journurl.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


> That would make the following list:
> 
> REQ "issued"   - the time the entry was published for the first time

Sascha: If a date element with that definition is a MUST in the Atom spec,
then one of two things happen:

(1) Millions of Atom feeds will be turned off as everyone goes back to RSS
en masse.

...or...

(2) Millions of Atom feeds will violate the spec by stuffing the display
date into the required issued element.

My money's on (2), since that's the path of least resistance for publishers.


Whether or not such an outcome is a problem is a matter of opinion... after
all, it'll be undetectable by the validator, and many consuming apps simply
won't care. So unless you're passionate about the sanctity of
specifications, it might be of little concern. Of course, folks in the Atom
community tend to be precisely the kind of folks who are passionate about
the sanctity of specifications, so who knows?

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/ 







From owner-atom-syntax@mail.imc.org  Thu Jul 22 20:14: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 UAA02777
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 20:14: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 i6N03cXX069126;
	Thu, 22 Jul 2004 17:03: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 i6N03cAc069124;
	Thu, 22 Jul 2004 17:03:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6N03Sh4069033
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 17:03:34 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 23 Jul 2004 10:08:31 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Fri, 23 Jul 2004 09:44:03 +1000
Subject: Re: Propose partial consensus on dates
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD268E63.21B87%eric.scheid@ironclad.net.au>
In-Reply-To: <20040722145906.27272.qmail@web41203.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 23/7/04 12:59 AM, "Dare Obasanjo" <kpako@yahoo.com> wrote:

> That sounds like a pretty dumb tool. Too external
> entities the entry has been modified. Ignore feeds and
> imagine you were visiting a website. If the first
> entry a user sees on the website was the one written
> at midnight and then they show up a few days later
> only to see a different one, do you really think it
> makes sense to tell the user the last modified date of
> the entry was BEFORE the last modified date they saw
> previously even though the entry has obviously been
> modified AFTER that date from the user's perspective?

I'm seeing a use case for almost that exact behaviour ... wikis are getting
hammered by wiki spam, and by their nature pretty much always will be. Some
wikis already have built in capability for "one click revert", and I'm
working on some code for my wiki to do exactly that. In this situation I
would want to re-set the updated date back to what it was, but set the
modified date to now().

How would RSS Bandit react to that?

e.



From owner-atom-syntax@mail.imc.org  Thu Jul 22 20:16: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 UAA02915
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 20:16: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 i6N03cPb069125;
	Thu, 22 Jul 2004 17:03: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 i6N03cY1069123;
	Thu, 22 Jul 2004 17:03:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6N03SbO069001
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 17:03:34 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 23 Jul 2004 10:08:19 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Fri, 23 Jul 2004 09:28:33 +1000
Subject: Re: Propose partial consensus on dates
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD268AC1.21B82%eric.scheid@ironclad.net.au>
In-Reply-To: <200407212300.i6LN0oFL039004@above.proper.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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 22/7/04 9:00 AM, "Arve Bersvendsen" <arve@virtuelvis.com> wrote:

> Disregarding "atom as feed format", and looking at the "atom as archive
> format": How is one going to represent a complete history of revisions with
> this model, when multiple, and differing entry:id's are disallowed?

Would you want to though? Yes, you would want all versions available to a
thing that can handle all versions, but what happens if you try importing
that all-versions-archive into a thing that doesn't keep multiple revisions
of the same entry? It's going to get messy.

A diversion for a moment ... how would you import an archive of entries and
all the comments on those entries? The simplest model would be to have a
link in every entry which leads to an archive feed of comments for that
entry. This way an importer doesn't have to try disambiguating comment
entries from top level entries, it doesn't even have to process comments if
it doesn't want them.

Back to entry revisions... consider putting only the latest data for an
entry in the archive feed, and putting a link in each archive entry which
leads to a new archive feed specific to that entry which holds all the
previous versions of that entry. Viola! A dumb environment would import just
the latest entries, while a smarter environment has the option of importing
the archive of versions too.

Only one hiccup - would every entry in a feed-versions-archive have the same
id? The way I would write the code would be such that archive-versions get a
versioned id - the original id plus some versioning suffix. Anything
pointing to the original version would still work, and nothing should be
pointing to the specific version as yet anyhow. You could of course point to
the specific version if it was revealed somehow (diveintomark has a glimmer
of this), and in that case you'd want to use the id specific to that
specific version. 

e.



From owner-atom-syntax@mail.imc.org  Thu Jul 22 20: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 UAA04486
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 20:43:22 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6N0VqTj071608;
	Thu, 22 Jul 2004 17: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 i6N0VqHv071607;
	Thu, 22 Jul 2004 17:31:52 -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 i6N0VpWo071592
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 17:31:51 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040723003152.38089.qmail@web41203.mail.yahoo.com>
Received: from [207.46.228.98] by web41203.mail.yahoo.com via HTTP; Thu, 22 Jul 2004 17:31:52 PDT
Date: Thu, 22 Jul 2004 17:31:52 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Propose partial consensus on dates
To: Antone Roundy <antone@geckotribe.com>, atom-syntax@imc.org
In-Reply-To: <BEC99C0E-DC03-11D8-B36F-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:
> 
> 
> A question then to be sure that I understand your
> position.  In 
>
http://www.imc.org/atom-syntax/mail-archive/msg06958.html
> when you said 
> +1 to:
> 
>  > Date 1: Updated
>  >
>  > This date is meant to be a machine generated
>  > timestamp indicating when
>  > the most recent substantive change has been made
> to
>  > the entry.
> 
> were you supporting updated as defined by Sam
> (including the word 
> "substantive") or were you intending to say +1 to an
> updated date when 
> the last change of ANY kind was made (removing the
> word "substantive")?

I was saying +1 to having a single date field for
indicating the last time an item was changed. I doubt
aggregators or content producers will try to
differentiate between last-time-a-type-was-fixed and
last-time-a-major-revision-was-made when displaying
content to the user. 

In RSS Bandit, I don't prompt the user when it is
discovered that the content of an item is changed but
if I did I wouldn't differentiate between either date
since this distinction would seem arbitrary to users.
Because it would be since it would vary from feed to
feed and entry to entry. 

=====
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 Jul 22 20:58: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 UAA05182
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 20:58:30 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6N0lx67073917;
	Thu, 22 Jul 2004 17:47: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 i6N0lx2I073916;
	Thu, 22 Jul 2004 17:47:59 -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 i6N0lw6q073903
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 17:47:58 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040723004757.40808.qmail@web41203.mail.yahoo.com>
Received: from [207.46.238.137] by web41203.mail.yahoo.com via HTTP; Thu, 22 Jul 2004 17:47:57 PDT
Date: Thu, 22 Jul 2004 17:47:57 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Propose partial consensus on dates
To: Eric Scheid <eric.scheid@ironclad.net.au>,
        Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <BD268E63.21B87%eric.scheid@ironclad.net.au>
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>


--- Eric Scheid <eric.scheid@ironclad.net.au> wrote:
> 
> 
> I'm seeing a use case for almost that exact
> behaviour ... wikis are getting
> hammered by wiki spam, and by their nature pretty
> much always will be. Some
> wikis already have built in capability for "one
> click revert", and I'm
> working on some code for my wiki to do exactly that.
> In this situation I
> would want to re-set the updated date back to what
> it was, but set the
> modified date to now().
> 
> How would RSS Bandit react to that?

RSS Bandit always replaces the stored content with the
most recent content from the RSS feed. However it
doesn't indicate to the user that any changes have
occured to the feed. 

If Atom shipped with date fields to indicate every
time a typo was fixed in the content I still don't
think RSS Bandit would do anything different. At best
I'd consider moving to a model like NetNewsWire that
shows the differences using an HTML diff. 



=====
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 Jul 22 21:14:17 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06411
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 21:14: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 i6N0vW0x075150;
	Thu, 22 Jul 2004 17:57: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 i6N0vWK4075149;
	Thu, 22 Jul 2004 17:57: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 i6N0vVan075138
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 17:57:31 -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 RAA00556
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 17:57: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 RAA26559
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 17:57:31 -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); Thu, 22 Jul 2004 17:57:31 -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 <0I1A00CNA5BSHM@shazam.verity.com> for atom-syntax@imc.org; Thu,
 22 Jul 2004 17:57:30 -0700 (PDT)
Date: Thu, 22 Jul 2004 17:57:27 -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: Propose partial consensus on dates
In-reply-to: <40FFB6EA.7010601@intertwingly.net>
To: Atom-Syntax <atom-syntax@imc.org>
Message-id: 
 <12A2A65A07D81C0B6BD5FB0A@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: <20040721220041.95499.qmail@web41210.mail.yahoo.com>
 <opsbieyottuvpchu@quark> <987794AA-DB88-11D8-B3AB-000A95DC3D90@mac.com>
 <opsbi3j6lzkdsr4o@quark> <40FFB6EA.7010601@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 Thursday, July 22, 2004 8:45 AM -0400 Sam Ruby <rubys@intertwingly.net> wrote:
>
> Between friends, playing chess, "do overs" may be permitted.
>
> "Do overs" (taking back a move made in error) are not permitted
> in professional chess tournaments.
>
> [...]
>
> Imposing that level of professionalism on all casual usages of blogs,
> however, is inappropriate.

I was thinking along the same lines. Different publications have
different policies for issuance and modification. This is normal
and reasonable.

Atom should specify a base semantic for these dates and let the
publications refine that.

The same holds for author, title, etc. All these things have
local policies.

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Thu Jul 22 21:23: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 VAA06857
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 21:23: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 i6N1BvpF076397;
	Thu, 22 Jul 2004 18:11: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 i6N1Bvcm076396;
	Thu, 22 Jul 2004 18:11:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from cat-proof.de (cat.cat-proof.de [213.239.198.176])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6N1Buil076389
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 18:11:57 -0700 (PDT)
	(envelope-from sc@itst.net)
Received: from [192.168.1.10] (p508178CE.dip0.t-ipconnect.de [80.129.120.206])
	by cat-proof.de (Postfix) with ESMTP id 0B60C3410385
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 03:10:31 +0200 (CEST)
Message-ID: <41006657.8000106@itst.net>
Date: Fri, 23 Jul 2004 03:13:59 +0200
From: Sascha Carlin <sc@itst.net>
User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707)
X-Accept-Language: de, en
MIME-Version: 1.0
To: atom-syntax@imc.org
Subject: Re: Propose partial consensus on dates
References: <CB11033A97134EDBA75A9D48599CA.MAI@journurl.com>
In-Reply-To: <CB11033A97134EDBA75A9D48599CA.MAI@journurl.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


Roger B. wrote:

>>That would make the following list:
>>
>>REQ "issued"   - the time the entry was published for the first time
> 
> 
> Sascha: If a date element with that definition is a MUST in the Atom spec,
> then one of two things happen:
[snip]

As I said:
>> BTW, I am not sure if I got that right: "modified" should also indicate
>> the time the entry was published? If yes, -1, see below.

I know (now, just checked with the drafts) the current drafts consider 
"modified" to be required and indicating many things: first of all, the 
time the entry was published. Since it is the only required date to an 
entry, it is the element current application use to sort entries by and 
display it as the entries' creation date.

Sure I am riding on it, as we say in German, but to me things (in the 
real World) seems to be like this:

(In brackets the elements holding timestamps outlining the described 
tasks. Tasks can be done in any timly order, alone the creation is 
always the first thing to do.)

Someone creates content ("created"). She adds a date to the content to 
outline a tight relation between the information and this date 
("display", could be used to store the date of a talk, if the content is 
an announcement of this talk, for instance). At some point she 
proof-reads it and corrects some errors, typos and alike ("modified"). 
At some point she - because of new information or to correct semantical 
errors - she changes (parts of) the information ("updated"). At some 
point she decides to publish the content ("issued").

Lets asume all these dates make it into an atom feed and into an 
aggregator of some sort (let's asume it's Bloglines and we use it as a 
usual feed consumer to check with our favorite blogs). This aggregator 
uses the dates in the feed to do the following things:

Sort the entries by "issued" to show the user whats new and whats old. 
(We don't want old information, we want the new stuff. For us new stuff 
is what we can read now, but could not 5 minutes ago.)

Well, here is an entry from yesterday which was "modified". Nothing new 
here, just fixed a few typos and glitches in the list code. Bloglines 
marks it as "modified", but keeps sorting it using "issued".

OK, there is an entry issued the day before yesterday, but 
"updated">"issued" -> new information. Let's see this. Bloglines uses 
"updated", if set, to check whether there is new information worth 
reading it. Since "updated" means there is new information and not just 
'a byte changed', we want this entry to be sorted by "updated" so that 
it comes up in the list.

One of our favorite bloggers is on holiday and keeps a journal. Since 
she can't access the internet, she blogs every other day or so. 
Sometimes she forgets to bring all her notes to the internet cafe and 
thus she posts day 6 before day 4. But she is a nice guy and has 
"display" set up correctly, so we can tell Bloglines to sort ascending 
by "display". Automagically, Day 1, Day 2, Day 3, ... appear in the 
semantically correct order.

Perhaps we are curious and want to see how fast Joe blogs his thoughts. 
Bloglines show the date Joe "created" his entry on how to build a better 
syndication format. Wow, 7 month before he "issued" this lenghty paper. 
Must have put much brain power into this.

Of course, these use cases are trivial. I just use them to make it 
easier to get what I mean. Hope that worked ;)

My point is, that there are different times, having different meanings. 
Atom should use the correct term for each date (btw, shouldn't it be 
published instead of issued? Or is publishing refering to the technical 
task of publishing? My English is not that good.) and give users the 
chance to use all these, if they like to. Meta data is good and 
important, but needs to be described as clearly as possible to be of 
real use.

May I draw your attention to this article: "The five purposes of 
metadata: David Haynes.": 
http://www.cilip.org.uk/update/issues/julyaug04/article3julyaug.html
It is somehow like an executive summary, but brings it to the point. And 
forget about this "Metadata is the future."... It _is_ an executive 
summary ;)

> Whether or not such an outcome is a problem is a matter of opinion... after
> all, it'll be undetectable by the validator, and many consuming apps simply
> won't care. So unless you're passionate about the sanctity of
> specifications, it might be of little concern. Of course, folks in the Atom
> community tend to be precisely the kind of folks who are passionate about
> the sanctity of specifications, so who knows?

This is a political question, too. I am not much of a politician, I am 
just a student of information and library science interested in 
experiencing the creation of a new standard and taking part in some of 
the discussion around it. My goal is to learn and to share - and to help 
to make IT as easy as it can be. Breaking current applications is a 
unpleasant thing to do, sure. But it is not bad nor evil, if it helps to 
make something better.

Wow, this got bigger as intended, and it'S later than I hoped. Going to 
bed and wishing you all good night, Sascha

-- 
Sascha Carlin * Heinrich-Heine-Str. 1 * 64319 Pfungstadt
http://www.itst.org/         **         +49 6157 157 205



From owner-atom-syntax@mail.imc.org  Thu Jul 22 21:48:44 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08284
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 21:48:44 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6N1bPLQ079090;
	Thu, 22 Jul 2004 18:37:25 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6N1bPE4079089;
	Thu, 22 Jul 2004 18:37:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6N1bMgS079078
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 18:37:24 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 23 Jul 2004 11:42:46 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Fri, 23 Jul 2004 11:37:05 +1000
Subject: Re: Propose partial consensus on dates
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD26A8E1.21CAD%eric.scheid@ironclad.net.au>
In-Reply-To: <4100451B.4080304@itst.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: <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 23/7/04 8:52 AM, "Sascha Carlin" <sc@itst.net> wrote:

> REQ "issued"   - the time the entry was published for the first time
> 
> OPT "created"  - the time the entry was created i. e. was saved (inside
>                  the publishing system) for the first time
> 
> OPT "modified" - the last time the entry was modified without changing
>                  the semantical informtion given in the entry
>                  If the entry is modified, this should be REQ
> 
> OPT "display"  - an accompanying pointing out an semantically important
>                  date to/of the entry
> 
> OPT "updated"  - the last time the entry was semantically changed
>                  If the entry is updated, this should be REQ

+1, mostly. 

I'd prefer "dateline" to "display" as it's more indicative of the
content-nature of the date as opposed to a meta-data-presentational nature
of the word "display".

I agree with Roger B that we can't make "issued" required because the vast
unwashed masses don't have tools that support it in the sense of *first*
published and this will simply result in a million blogs breaking the spec.

I don't see a huge problem in making "dateline" the one required date. This
models very closely to how blogging tools currently work, and I'd be
surprised if the vaunted professional publishing tools don't have the
capability for a dateline.

I'd want "updated" to include semantic changes to non-content parts of the
entry too. Similarly "modified". I wouldn't want "modified" to be munged if
the entry was simply re-written at the XML level (eg. re-ordering of
elements or variations of xmlns:prefixes).

Note that the last "updated" value should be carried forward even when a
particular instance isn't "updated" per se ... thus edition C of {A,B,C} can
be seen as an update of A even if edition B was never retrieved (while
briefly available). On the backend this would probably be implemented by not
forcing a default value into the date field, and then omitting the updated
element if the date field is empty (aka null).

e.



From owner-atom-syntax@mail.imc.org  Thu Jul 22 22:04: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 WAA09128
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 22:04: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 i6N1rCLg080889;
	Thu, 22 Jul 2004 18:53: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 i6N1rC8q080888;
	Thu, 22 Jul 2004 18:53:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.207])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6N1rA70080878
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 18:53:11 -0700 (PDT)
	(envelope-from eliast@gmail.com)
Received: by mproxy.gmail.com with SMTP id 76so1010rnl
        for <atom-syntax@imc.org>; Thu, 22 Jul 2004 18:53:16 -0700 (PDT)
Received: by 10.38.90.69 with SMTP id n69mr103930rnb;
        Thu, 22 Jul 2004 18:53:16 -0700 (PDT)
Message-ID: <905f7c9104072218534925b919@mail.gmail.com>
Date: Thu, 22 Jul 2004 21:53:16 -0400
From: Elias Torres <eliast@gmail.com>
Reply-To: elias@torrez.us
To: Tim Bray <tim.bray@sun.com>
Subject: Re: URI scheme delusions
Cc: bob@wyman.us, elias@torrez.us, atom-syntax@imc.org,
        Arve Bersvendsen <arve@virtuelvis.com>
In-Reply-To: <709AF709-DC18-11D8-AC8C-000A95A51C9E@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <200407221003.i6MA3WWG083339@above.proper.com>
 <905f7c91040722053278962348@mail.gmail.com>
 <0ED5D262-DC00-11D8-AC8C-000A95A51C9E@sun.com> <709AF709-DC18-11D8-AC8C-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


Tim,

How would you suggest people use IDs in Atom? What about the case when
multiple feeds display the same entry (categories, site-aggregators,
etc) and multiple versions of the same entry as well?

I have a personal blog but I've already switched from MT to Wordpress
once and I already have to deal with all of the headaches of creating
enough Rewrite rules to support my old and future urls. I'm not sure
how many applications I will have to go through by the time I'm >= 50.
But if I start using lsid for example, my entries would be as follow:

urn:lsid:torrez.us:blog:4871231:2.4

First of all, this is a unique identifier to a specific entry and I
have the option to install a resolver (which could be self-hosted or a
service in the future) that I can adjust to fetch the data from
whatever CMS system I could be using at the time.

Again, all I proposed was a suggestion for URI scheme (purely as a
string) in the ID attribute, which at this point our spec does not
give much to people except for another "scheme" to come up with when
setting up their blog: an ID and a URI.

I guess with blogs maybe we won't have as many versions per entry, but
I sure think we will in Wikis. Wikis already have a way for pointing
to the specific version of a page. Will we tell them to add several
link tags that we will then have to process to figure out what entry
this page is a version of according to Atom?

Anyways, I guess I must have struck a nerve or something, but I'll be
more careful when suggesting anything from now on. Instead I'll let
people discuss more important things like "display" date and so forth.

Elias


On Thu, 22 Jul 2004 12:50:53 -0700, Tim Bray <tim.bray@sun.com> wrote:
> On Jul 22, 2004, at 9:56 AM, Tim Bray wrote:
> 
> >> Currently the norm has been to use tag URIs like this:
> >> tag:www.virtuelvis.com,2003:1192312312
> >
> > On which planet?
> 
> Sigh, that was rude, sorry.  Also, it was entirely off-topic for Atom.
> -Tim
> 
>



From owner-atom-syntax@mail.imc.org  Thu Jul 22 22:44: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 WAA22583
	for <atompub-archive@lists.ietf.org>; Thu, 22 Jul 2004 22:44: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 i6N2YJ4I085019;
	Thu, 22 Jul 2004 19:34: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 i6N2YJuo085018;
	Thu, 22 Jul 2004 19:34:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from dumle.webhuset.no (dumle.webhuset.no [81.27.32.66])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6N2YH3L085006
	for <atom-syntax@imc.org>; Thu, 22 Jul 2004 19:34:18 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Message-Id: <200407230234.i6N2YH3L085006@above.proper.com>
Received: (qmail 5156 invoked from network); 23 Jul 2004 02:32:43 -0000
Received: from unknown (HELO localhost.localdomain) (81.27.34.17)
  by 0 with SMTP; 23 Jul 2004 02:32:43 -0000
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
MIME-Version: 1.0
From: "Arve Bersvendsen" <arve@virtuelvis.com>
To: Sascha Carlin <sc@itst.net>, atom-syntax@imc.org
Subject: Re: Propose partial consensus on dates
Date: Fri, 23 Jul 2004 04:34:14 +0200
X-Mailer: WHMail 1.0 (http://www.webhuset.no)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6N2YJ3L085013
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


* Sascha Carlin

> (btw, shouldn't it be 
> published instead of issued? Or is publishing refering to the technical 
> task of publishing? My English is not that good.) 

The Merriam-Webster Online dictionary [1] has the following definitions for
the verb "issue", which applies to the way 'issued' is suggested used:

'5 : to appear or become available through being officially put forth or
distributed'

and the transitive sense:

'2 a : to put forth or distribute usually officially <government issued a new
airmail stamp> <issue orders> b : to send out for sale or circulation :
PUBLISH c British : PROVIDE 2b, SUPPLY'

___
[1] Curse them for using POST for searches. http://www.m-w.com/ is the
closest I can send you



From owner-atom-syntax@mail.imc.org  Fri Jul 23 07:49: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 HAA14101
	for <atompub-archive@lists.ietf.org>; Fri, 23 Jul 2004 07:49: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 i6NBcNIr025128;
	Fri, 23 Jul 2004 04: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 i6NBcNE9025127;
	Fri, 23 Jul 2004 04:38: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 i6NBcMdw025117
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 04:38: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 i6NBdK95024607;
	Fri, 23 Jul 2004 07:39:20 -0400
Message-ID: <4100F8AB.5010206@intertwingly.net>
Date: Fri, 23 Jul 2004 07:38:19 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Eric Scheid <eric.scheid@ironclad.net.au>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Propose partial consensus on dates
References: <BD268E63.21B87%eric.scheid@ironclad.net.au>
In-Reply-To: <BD268E63.21B87%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:

> On 23/7/04 12:59 AM, "Dare Obasanjo" <kpako@yahoo.com> wrote:
> 
>>That sounds like a pretty dumb tool. Too external
>>entities the entry has been modified. Ignore feeds and
>>imagine you were visiting a website. If the first
>>entry a user sees on the website was the one written
>>at midnight and then they show up a few days later
>>only to see a different one, do you really think it
>>makes sense to tell the user the last modified date of
>>the entry was BEFORE the last modified date they saw
>>previously even though the entry has obviously been
>>modified AFTER that date from the user's perspective?
> 
> I'm seeing a use case for almost that exact behaviour ... wikis are getting
> hammered by wiki spam, and by their nature pretty much always will be. Some
> wikis already have built in capability for "one click revert", and I'm
> working on some code for my wiki to do exactly that. In this situation I
> would want to re-set the updated date back to what it was, but set the
> modified date to now().

Clearly we have to nail down some definitions, because my initial 
instincts would have been the reverse of yours.

As I see it,

<updated> == "hey, if you last fetched this feed before this date, you 
probably have missed something important"

<modified> == "the time this particular sequence of bytes became this 
entry's content."

As I see it, modified is probably only something of interest to an 
obsessive pedant.  Something a content management system may (and 
perhaps even should) track, but not something that routinely needs to be 
shared with others.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Fri Jul 23 07: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 HAA14849
	for <atompub-archive@lists.ietf.org>; Fri, 23 Jul 2004 07: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 i6NBjGMd025557;
	Fri, 23 Jul 2004 04:45:16 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6NBjG4w025556;
	Fri, 23 Jul 2004 04:45:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6NBij5A025501
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 04:44: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 i6NBdK95024607;
	Fri, 23 Jul 2004 07:39:20 -0400
Message-ID: <4100F8AB.5010206@intertwingly.net>
Date: Fri, 23 Jul 2004 07:38:19 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Eric Scheid <eric.scheid@ironclad.net.au>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Propose partial consensus on dates
References: <BD268E63.21B87%eric.scheid@ironclad.net.au>
In-Reply-To: <BD268E63.21B87%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:

> On 23/7/04 12:59 AM, "Dare Obasanjo" <kpako@yahoo.com> wrote:
> 
>>That sounds like a pretty dumb tool. Too external
>>entities the entry has been modified. Ignore feeds and
>>imagine you were visiting a website. If the first
>>entry a user sees on the website was the one written
>>at midnight and then they show up a few days later
>>only to see a different one, do you really think it
>>makes sense to tell the user the last modified date of
>>the entry was BEFORE the last modified date they saw
>>previously even though the entry has obviously been
>>modified AFTER that date from the user's perspective?
> 
> I'm seeing a use case for almost that exact behaviour ... wikis are getting
> hammered by wiki spam, and by their nature pretty much always will be. Some
> wikis already have built in capability for "one click revert", and I'm
> working on some code for my wiki to do exactly that. In this situation I
> would want to re-set the updated date back to what it was, but set the
> modified date to now().

Clearly we have to nail down some definitions, because my initial 
instincts would have been the reverse of yours.

As I see it,

<updated> == "hey, if you last fetched this feed before this date, you 
probably have missed something important"

<modified> == "the time this particular sequence of bytes became this 
entry's content."

As I see it, modified is probably only something of interest to an 
obsessive pedant.  Something a content management system may (and 
perhaps even should) track, but not something that routinely needs to be 
shared with others.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Fri Jul 23 08: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 IAA16341
	for <atompub-archive@lists.ietf.org>; Fri, 23 Jul 2004 08: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 i6NBvIWb026416;
	Fri, 23 Jul 2004 04:57:18 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6NBvIZc026415;
	Fri, 23 Jul 2004 04:57: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 i6NBvHgg026408
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 04:57:17 -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 i6NBwFji025462;
	Fri, 23 Jul 2004 07:58:16 -0400
Message-ID: <4100FD1A.4090100@intertwingly.net>
Date: Fri, 23 Jul 2004 07:57:14 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Dare Obasanjo <kpako@yahoo.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Propose partial consensus on dates
References: <20040723004757.40808.qmail@web41203.mail.yahoo.com>
In-Reply-To: <20040723004757.40808.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:

> --- Eric Scheid <eric.scheid@ironclad.net.au> wrote:
> 
>>
>>I'm seeing a use case for almost that exact
>>behaviour ... wikis are getting
>>hammered by wiki spam, and by their nature pretty
>>much always will be. Some
>>wikis already have built in capability for "one
>>click revert", and I'm
>>working on some code for my wiki to do exactly that.
>>In this situation I
>>would want to re-set the updated date back to what
>>it was, but set the
>>modified date to now().
>>
>>How would RSS Bandit react to that?
> 
> RSS Bandit always replaces the stored content with the
> most recent content from the RSS feed. However it
> doesn't indicate to the user that any changes have
> occured to the feed. 
> 
> If Atom shipped with date fields to indicate every
> time a typo was fixed in the content I still don't
> think RSS Bandit would do anything different. At best
> I'd consider moving to a model like NetNewsWire that
> shows the differences using an HTML diff. 

Consider:

http://www.tbray.org/ongoing/When/200x/2004/02/20/GenxStatus

Since this feed does not contain guids, I presume that RSS Bandit users 
would see every update as a new entry.

If this feed were updated to contain guids, I presume that RSS Bandit 
would quietly update the stored content, but would not otherwise 
highlight to the user that this entry had been modified.  For typos, I 
think this is appropriate.  For significant updates, like the ones that 
Tim had made, less so.

I want a way to distinguish between these two case.  I want that even 
though I know that some people who produce feeds will get this wrong.  I 
want this even though I know that some aggregators will ignore this 
information.

I want aggregator authors to be able to answer the question "but why 
did/did not you show my this change" with something other than "I 
guessed wrong".

And I want to do it in a way that you, Dave Obasanjo, don't go around 
telling everybody that "see, I told them that this was a bad idea".

Suggestions welcome.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Fri Jul 23 08:28: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 IAA17285
	for <atompub-archive@lists.ietf.org>; Fri, 23 Jul 2004 08:28: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 i6NC9xeb027365;
	Fri, 23 Jul 2004 05:09: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 i6NC9xqZ027364;
	Fri, 23 Jul 2004 05:09:59 -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 i6NC9w2E027355
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 05:09:59 -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 <20040723121011.FQGO13859.mta07-svc.ntlworld.com@cpc1-stke1-5-0-cust6.bagu.cable.ntl.com>;
          Fri, 23 Jul 2004 13:10:11 +0100
Date: Fri, 23 Jul 2004 13:09:52 +0100
From: David Powell <djpowell@djpowell.net>
X-Mailer: The Bat! (v2.12 RC/4) Business
Reply-To: David Powell <djpowell@djpowell.net>
X-Priority: 3 (Normal)
Message-ID: <326027223.20040723130952@djpowell.net>
To: Sam Ruby <rubys@intertwingly.net>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Propose partial consensus on dates
In-Reply-To: <4100F8AB.5010206@intertwingly.net>
References: <BD268E63.21B87%eric.scheid@ironclad.net.au>
 <4100F8AB.5010206@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: <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



Friday, July 23, 2004, 12:38:19 PM, rubys@intertwingly.net wrote:

> <updated> == "hey, if you last fetched this feed before this date, you
> probably have missed something important"

> <modified> == "the time this particular sequence of bytes became this
> entry's content."

> As I see it, modified is probably only something of interest to an 
> obsessive pedant.

I agree that "modified" is of little interest to humans, but it is of
interest to machines.

For example, a web-based aggregator, could
preformat Atom entries using XSLT, but only recalculate this
transformation if the underlying entry had been modified.

Also search engines only need reindex an entry if it has been
modified.

I have used this aggregator for the Pocket PC:
http://www.viksoe.dk/code/rsssync.htm It does the XML processing on
the PC and then synchronizes the entries to the Pocket PC. I'm not
sure exactly how it works, but I'd imagine it would be a lot easier if
it could tell whether an entry had changed by looking at its modified
date.

Any application that does any kind of synchronization benefits from
"modified" dates.

-- 
Dave



From owner-atom-syntax@mail.imc.org  Fri Jul 23 08:47: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 IAA18625
	for <atompub-archive@lists.ietf.org>; Fri, 23 Jul 2004 08: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 i6NCWEs8028780;
	Fri, 23 Jul 2004 05:32:14 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6NCWEg5028779;
	Fri, 23 Jul 2004 05:32:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6NCWC0a028771
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 05:32:13 -0700 (PDT)
	(envelope-from Janne.Jalkanen@nokia.com)
Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121])
	by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6NCV8S09009;
	Fri, 23 Jul 2004 15:31:08 +0300 (EET DST)
X-Scanned: Fri, 23 Jul 2004 15:29:55 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost)
	by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i6NCTtAU026845;
	Fri, 23 Jul 2004 15:29:55 +0300
Received: from mgw-int1.ntc.nokia.com (172.21.143.96)
	by esdks002.ntc.nokia.com 00SjAD3b; Fri, 23 Jul 2004 15:29:54 EEST
Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77])
	by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6NCTmn02376;
	Fri, 23 Jul 2004 15:29:48 +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, 23 Jul 2004 15:29:47 +0300
Message-ID: <410104BB.1050104@nokia.com>
Date: Fri, 23 Jul 2004 15:29:47 +0300
From: Janne Jalkanen <Janne.Jalkanen@nokia.com>
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: ext Sam Ruby <rubys@intertwingly.net>
CC: Eric Scheid <eric.scheid@ironclad.net.au>,
        Atom Syntax <atom-syntax@imc.org>
Subject: Re: Propose partial consensus on dates
References: <BD268E63.21B87%eric.scheid@ironclad.net.au> <4100F8AB.5010206@intertwingly.net>
In-Reply-To: <4100F8AB.5010206@intertwingly.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 23 Jul 2004 12:29:47.0788 (UTC) FILETIME=[BE06ACC0:01C470B0]
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



> <updated> == "hey, if you last fetched this feed before this date, you 
> probably have missed something important"

>
> <modified> == "the time this particular sequence of bytes became this 
> entry's content."

A wiki would probably change the <modified> -date each time someone made 
an edit, but the <updated> -date only if it was not marked as a "minor 
edit", which is a very common wiki functionality.

Just my 2c, noting that this would fit well in a wiki model.

/Janne, who goes now off to holidays :-D



From owner-atom-syntax@mail.imc.org  Fri Jul 23 08:47: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 IAA18629
	for <atompub-archive@lists.ietf.org>; Fri, 23 Jul 2004 08:47: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 i6NCZoeh028947;
	Fri, 23 Jul 2004 05:35:50 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6NCZoGY028946;
	Fri, 23 Jul 2004 05:35: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 i6NCZn57028940
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 05:35: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 i6NCakJq027180;
	Fri, 23 Jul 2004 08:36:46 -0400
Message-ID: <41010625.4090005@intertwingly.net>
Date: Fri, 23 Jul 2004 08:35:49 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <djpowell@djpowell.net>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Propose partial consensus on dates
References: <BD268E63.21B87%eric.scheid@ironclad.net.au> <4100F8AB.5010206@intertwingly.net> <326027223.20040723130952@djpowell.net>
In-Reply-To: <326027223.20040723130952@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: <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


David Powell wrote:
> 
> I agree that "modified" is of little interest to humans, but it is of
> interest to machines.
> 
> [snip]
> 
> Any application that does any kind of synchronization benefits from
> "modified" dates.

That makes sense to me.

- Sam Ruby




From owner-atom-syntax@mail.imc.org  Fri Jul 23 09:17: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 JAA20379
	for <atompub-archive@lists.ietf.org>; Fri, 23 Jul 2004 09:17: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 i6ND5jXk030939;
	Fri, 23 Jul 2004 06:05: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 i6ND5jDR030938;
	Fri, 23 Jul 2004 06:05:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail4.speakeasy.net (mail4.speakeasy.net [216.254.0.204])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ND5iWO030929
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 06:05:44 -0700 (PDT)
	(envelope-from wkearney@syndic8.com)
Received: (qmail 25498 invoked from network); 23 Jul 2004 13:05:44 -0000
Received: from xbox.wkearney.com (HELO media) ([66.92.145.79])
          (envelope-sender <wkearney@syndic8.com>)
          by mail4.speakeasy.net (qmail-ldap-1.03) with SMTP
          for <elias@torrez.us>; 23 Jul 2004 13:05:44 -0000
Message-ID: <002401c470b5$c3671240$200ca8c0@wkearney.com>
From: "Bill Kearney" <wkearney@syndic8.com>
To: <elias@torrez.us>, <atom-syntax@imc.org>
References: <200407221003.i6MA3WWG083339@above.proper.com> <905f7c91040722053278962348@mail.gmail.com> <0ED5D262-DC00-11D8-AC8C-000A95A51C9E@sun.com> <709AF709-DC18-11D8-AC8C-000A95A51C9E@sun.com> <905f7c9104072218534925b919@mail.gmail.com>
Subject: Re: URI scheme delusions
Date: Fri, 23 Jul 2004 09:04:57 -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.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
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


> Anyways, I guess I must have struck a nerve or something, but I'll be
> more careful when suggesting anything from now on. Instead I'll let
> people discuss more important things like "display" date and so forth.

It seems several people have a grave aversion to URN usage.  It's a shame really
as there are potentially a number of handy things that could be done with them.

Meanwhile, what's the name of the law to invoke when a URL vs URI permathread is
about to erupt?



From owner-atom-syntax@mail.imc.org  Fri Jul 23 09:32:41 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21707
	for <atompub-archive@lists.ietf.org>; Fri, 23 Jul 2004 09:32:40 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6NDKvDY032109;
	Fri, 23 Jul 2004 06:20: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 i6NDKv62032108;
	Fri, 23 Jul 2004 06:20:57 -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 i6NDKuqj032098
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 06:20:56 -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 <20040723132112.LCHE13859.mta07-svc.ntlworld.com@cpc1-stke1-5-0-cust6.bagu.cable.ntl.com>;
          Fri, 23 Jul 2004 14:21:13 +0100
Date: Fri, 23 Jul 2004 14:20:45 +0100
From: David Powell <djpowell@djpowell.net>
X-Mailer: The Bat! (v2.12 RC/4) Business
Reply-To: David Powell <djpowell@djpowell.net>
X-Priority: 3 (Normal)
Message-ID: <242334247.20040723142045@djpowell.net>
To: Eric Scheid <eric.scheid@ironclad.net.au>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Propose partial consensus on dates
In-Reply-To: <BD26A8E1.21CAD%eric.scheid@ironclad.net.au>
References: <4100451B.4080304@itst.net>
 <BD26A8E1.21CAD%eric.scheid@ironclad.net.au>
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


Friday, July 23, 2004, 2:37:05 AM, eric.scheid@ironclad.net.au wrote:

> On 23/7/04 8:52 AM, "Sascha Carlin" <sc@itst.net> wrote:

>> REQ "issued"   - the time the entry was published for the first time
>> 
>> OPT "created"  - the time the entry was created i. e. was saved (inside
>>                  the publishing system) for the first time
>> 
>> OPT "modified" - the last time the entry was modified without changing
>>                  the semantical informtion given in the entry
>>                  If the entry is modified, this should be REQ
>> 
>> OPT "display"  - an accompanying pointing out an semantically important
>>                  date to/of the entry
>> 
>> OPT "updated"  - the last time the entry was semantically changed
>>                  If the entry is updated, this should be REQ

> ...

> I agree with Roger B that we can't make "issued" required because the vast
> unwashed masses don't have tools that support it in the sense of *first*
> published and this will simply result in a million blogs breaking the spec.

If "issued" is to be made optional, then we need to make some more
fixes, because we would have a situation where once an entry is
modified it is guaranteed to have an objective date - "modified", but
new entries wouldn't be guaranteed an objective date.

The solution, if "issued" is made OPT, is to either:

a) make "modified" REQ even for new entries

b) require either "created" (for new entries), or "modified" (for
modified entries), or both.


I prefer a) - it matches how "modified" dates work in file systems.

-- 
Dave



From owner-atom-syntax@mail.imc.org  Fri Jul 23 09:37: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 JAA22263
	for <atompub-archive@lists.ietf.org>; Fri, 23 Jul 2004 09:37: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 i6NDQjCJ032558;
	Fri, 23 Jul 2004 06:26: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 i6NDQj2a032557;
	Fri, 23 Jul 2004 06:26:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from dumle.webhuset.no (dumle.webhuset.no [81.27.32.66])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6NDQixT032547
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 06:26:44 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Message-Id: <200407231326.i6NDQixT032547@above.proper.com>
Received: (qmail 8263 invoked from network); 23 Jul 2004 13:25:05 -0000
Received: from unknown (HELO localhost.localdomain) (81.27.34.17)
  by 0 with SMTP; 23 Jul 2004 13:25:05 -0000
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
MIME-Version: 1.0
From: "Arve Bersvendsen" <arve@virtuelvis.com>
To: Janne Jalkanen <Janne.Jalkanen@nokia.com>, atom-syntax@imc.org
Subject: Re: Propose partial consensus on dates
Date: Fri, 23 Jul 2004 15:26:39 +0200
X-Mailer: WHMail 1.0 (http://www.webhuset.no)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6NDQjxT032552
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


* Janne Jalkanen
> A wiki would probably change the <modified> -date each time someone made 
> an edit, but the <updated> -date only if it was not marked as a "minor 
> edit", which is a very common wiki functionality.

This model gives a way to distinguish between minor and major updates, but I
am afraid an 'updated' alone cannot solve the revisioning problem for
anything but non-revisioning aggregators. 

I would like to hear people's ideas/suggestions on how to make Atom handle
all of the following:

How can a revisioning mechanism be built into Atom that allows:
- For tools to import and export entries, including their entire editing
history.
- Non-revisioning tools to ignore the revision history, and still avoid
duplicates in their history (read: how can we ensure that these
non-revisioning tools will treat a "major revision" the same way it would
treat a "minor revision".
- Organizations/tools/people to support the use case that an entry may only
be issued exactly once, with an immutable 'issued' date.

-- 
Arve Bersvendsen



From owner-atom-syntax@mail.imc.org  Fri Jul 23 11: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 LAA01845
	for <atompub-archive@lists.ietf.org>; Fri, 23 Jul 2004 11: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 i6NFEWdv041410;
	Fri, 23 Jul 2004 08:14: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 i6NFEWN9041409;
	Fri, 23 Jul 2004 08:14: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 i6NFEV54041402
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 08:14:31 -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 esmtp (Exim 4.34)
	id 1Bo1kg-0000u3-Sb; Fri, 23 Jul 2004 15:14:27 +0000
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Fri, 23 Jul 2004 11:14:26 -0400
Subject: Re: Propose partial consensus on dates
From: Robert Sayre <mint@franklinmint.fm>
To: Arve Bersvendsen <arve@virtuelvis.com>,
        Janne Jalkanen <Janne.Jalkanen@nokia.com>,
        Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD26A392.143C8%mint@franklinmint.fm>
In-Reply-To: <200407231326.i6NDQixT032547@above.proper.com>
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: <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 7/23/04 9:26 AM, "Arve Bersvendsen" <arve@virtuelvis.com> wrote:

> 
> * Janne Jalkanen
>> A wiki would probably change the <modified> -date each time someone made
>> an edit, but the <updated> -date only if it was not marked as a "minor
>> edit", which is a very common wiki functionality.
> 
> This model gives a way to distinguish between minor and major updates, but I
> am afraid an 'updated' alone cannot solve the revisioning problem for
> anything but non-revisioning aggregators.
> 
> I would like to hear people's ideas/suggestions on how to make Atom handle
> all of the following:
> 
> How can a revisioning mechanism be built into Atom that allows:
> - For tools to import and export entries, including their entire editing
> history.

Extension content elements. Version control is not in the charter.

> - Non-revisioning tools to ignore the revision history, and still avoid
> duplicates in their history (read: how can we ensure that these
> non-revisioning tools will treat a "major revision" the same way it would
> treat a "minor revision".

They will. Just send them the same atom:id

> - Organizations/tools/people to support the use case that an entry may only
> be issued exactly once, with an immutable 'issued' date.

Make sure there isn't a one-to-one ratio between resources and entries. Tag
your atom:ids with an accumulator. You can do this today.

Robert Sayre



From owner-atom-syntax@mail.imc.org  Fri Jul 23 11:49:45 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04173
	for <atompub-archive@lists.ietf.org>; Fri, 23 Jul 2004 11: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 i6NFgar2043561;
	Fri, 23 Jul 2004 08: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 i6NFgaZZ043560;
	Fri, 23 Jul 2004 08:42:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6NFgXqn043554
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 08:42:35 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 24 Jul 2004 01:48:08 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sat, 24 Jul 2004 01:42:29 +1000
Subject: Re: Propose partial consensus on dates
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD276F05.21F2F%eric.scheid@ironclad.net.au>
In-Reply-To: <BD26A392.143C8%mint@franklinmint.fm>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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 would like to hear people's ideas/suggestions on how to make Atom handle
>> all of the following:
>> 
>> How can a revisioning mechanism be built into Atom that allows:
>> - For tools to import and export entries, including their entire editing
>> history.

see and action this element in the entry...
    <link rel="history" type="application/atom+xml" href="..." />

>> - Non-revisioning tools to ignore the revision history, and still avoid
>> duplicates in their history (read: how can we ensure that these
>> non-revisioning tools will treat a "major revision" the same way it would
>> treat a "minor revision".

ignore this element in the entry ...
    <link rel="history" type="application/atom+xml" href="..." />

e.



From owner-atom-syntax@mail.imc.org  Fri Jul 23 13:00:30 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09125
	for <atompub-archive@lists.ietf.org>; Fri, 23 Jul 2004 13:00: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 i6NGnTb0048218;
	Fri, 23 Jul 2004 09:49:29 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6NGnTu9048217;
	Fri, 23 Jul 2004 09:49:29 -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 i6NGnRWr048210
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 09:49:27 -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 i6NGoR4d006329;
	Fri, 23 Jul 2004 12:50:28 -0400
Message-ID: <4101419A.4090800@intertwingly.net>
Date: Fri, 23 Jul 2004 12:49:30 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Arve Bersvendsen <arve@virtuelvis.com>
CC: atom-syntax@imc.org
Subject: Re: Propose partial consensus on dates
References: <200407231326.i6NDQixT032547@above.proper.com>
In-Reply-To: <200407231326.i6NDQixT032547@above.proper.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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:

> * Janne Jalkanen
> 
>>A wiki would probably change the <modified> -date each time someone made 
>>an edit, but the <updated> -date only if it was not marked as a "minor 
>>edit", which is a very common wiki functionality.
> 
> This model gives a way to distinguish between minor and major updates, but I
> am afraid an 'updated' alone cannot solve the revisioning problem for
> anything but non-revisioning aggregators. 
> 
> I would like to hear people's ideas/suggestions on how to make Atom handle
> all of the following:
> 
> How can a revisioning mechanism be built into Atom that allows:
> - For tools to import and export entries, including their entire editing
> history.
> - Non-revisioning tools to ignore the revision history, and still avoid
> duplicates in their history (read: how can we ensure that these
> non-revisioning tools will treat a "major revision" the same way it would
> treat a "minor revision".
> - Organizations/tools/people to support the use case that an entry may only
> be issued exactly once, with an immutable 'issued' date.

I think that there is more than simply "major" and "minor".

There is "typo", there is "update", and there is "revised".

There are people out there who obsessively update their entries through 
the course of the day.

There are people who occasionally issue Updates, often several days 
after the original item was posted.

And then there is the formal model where XML 1.1 is issued based on XML 
1.0, but both have separate URIs and identities.

As I see it, being able to capture the relationship between XML 1.1 and 
XML 1.0 is desirable.  Also desirable is for non-revisioning aggregators 
to recognize these links.

  - - -

Brainstorming: can't all of these be done using the dcterms namespace? 
I don't mean copying these elements into the atom namespace, but 
actually use them in the dcterms namespace.

- Sam Ruby

- Sam Ruby




From owner-atom-syntax@mail.imc.org  Fri Jul 23 14:33: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 OAA16752
	for <atompub-archive@lists.ietf.org>; Fri, 23 Jul 2004 14:33: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 i6NIMQAQ055484;
	Fri, 23 Jul 2004 11:22: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 i6NIMQof055483;
	Fri, 23 Jul 2004 11:22: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 i6NIMQK5055475
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 11:22:26 -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 i6NIMTOo006044;
	Fri, 23 Jul 2004 11:22:29 -0700 (PDT)
Received: from [149.123.192.13] ([149.123.192.13])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id i6NIMSVd007486;
	Fri, 23 Jul 2004 11:22:29 -0700 (PDT)
In-Reply-To: <200407231326.i6NDQixT032547@above.proper.com>
References: <200407231326.i6NDQixT032547@above.proper.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <3F7C3EB6-DCD5-11D8-9170-000A95DC3D90@mac.com>
Content-Transfer-Encoding: 7bit
Cc: Atom-Syntax Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: Propose partial consensus on dates
Date: Fri, 23 Jul 2004 14:22:25 -0400
To: Arve Bersvendsen <arve@virtuelvis.com>
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>
Content-Transfer-Encoding: 7bit


On 23 Jul 2004, at 9:26 am, Arve Bersvendsen wrote:

> How can a revisioning mechanism be built into Atom that allows:
> - For tools to import and export entries, including their entire 
> editing
> history.

Allow multiple revisions of the same entry in the same feed, with the 
same id, with different modified or updated dates. Obviously this 
should be discouraged, or not allowed at all, in syndication.

> - Non-revisioning tools to ignore the revision history, and still avoid
> duplicates in their history (read: how can we ensure that these
> non-revisioning tools will treat a "major revision" the same way it 
> would
> treat a "minor revision".

Immutable id's for all revisions, as are already in the spec.

> - Organizations/tools/people to support the use case that an entry may 
> only
> be issued exactly once, with an immutable 'issued' date.

Can you fill us in why this case might need to be handled differently 
from entries that change?

Graham



From owner-atom-syntax@mail.imc.org  Fri Jul 23 14:38: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 OAA17150
	for <atompub-archive@lists.ietf.org>; Fri, 23 Jul 2004 14:38: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 i6NIU4Yl056120;
	Fri, 23 Jul 2004 11:30: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 i6NIU4Q0056119;
	Fri, 23 Jul 2004 11:30:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6NIU4mP056113
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 11:30:04 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from phys-bur-1 ([129.148.9.72])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6NIU7il009559
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 12:30:07 -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 <0I1B00A01HZ62R@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com)
 for atom-syntax@imc.org; Fri, 23 Jul 2004 14:30:07 -0400 (EDT)
Received: from mercury (vpn-129-150-33-253.Central.Sun.COM [129.150.33.253])
 by bur-mail1.east.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
 with ESMTP id <0I1B00J3GI1YUJ@bur-mail1.east.sun.com> for atom-syntax@imc.org;
 Fri, 23 Jul 2004 14:30:07 -0400 (EDT)
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1Bo4ni-000666-00	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 14:29:46 -0400
X-URL: http://nwalsh.com/
Date: Fri, 23 Jul 2004 14:29:44 -0400
From: Norman Walsh <ndw@nwalsh.com>
Subject: Re: atom:origin?
In-reply-to: <70F318DF-DB58-11D8-B3AB-000A95DC3D90@mac.com>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <87k6wutw4n.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: <200407191919.PAA17914@ietf.org> <87hds3slp8.fsf@nwalsh.com>
 <40FC4B18.7020400@dehora.net> <40FC5E56.90505@intertwingly.net>
 <40FD154A.2090706@dehora.net> <40FD1FCB.7010803@intertwingly.net>
 <40FD4133.4040206@dehora.net> <527D65FB-DA93-11D8-B3AB-000A95DC3D90@mac.com>
 <40FD9780.4020102@dehora.net> <70F318DF-DB58-11D8-B3AB-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-Type: text/plain

/ Graham <dtcd@mac.com> was heard to say:
|> With URIs, not neccessarily, but that's a different matter.
|
| Well OK. What's wrong with it being the same address made out of
| different characters?

There's no easy, reliable way for software to tell that it's the same.

Consider "http://norman.walsh.name/atom/whatsnew.xml" on the one hand and

(1) "http://norman.walsh.name/atom/whatsnew.xml" on the other. They're the same.
    There isn't going to be any disagreement about that.

(2) "http://Norman.Walsh.name/atom/whatsnew.xml" on the other. In order to know
    that they're the same, you have to understand the spec for the 'http' scheme,
    parse the domain component, normalize it, etc. Some folks are going to do
    strncmp() and some aren't so there will be disagreement.

(3) "http://norman.walsh.name/atom/wh%61tsnew.xml" on the other. This is probably
    the same, but that depends on which character(s) are percent escaped. And
    on the scheme. We don't want to go there.

(4) "http://norman.walsh.name/atom%2fwhatsnew.xml" on the other. I believe that
    this is really different, but I might be wrong.

And I haven't even opened the I18N can of worms yet.

If we're going to have semantics that depend on comparing URIs, I do
want the spec to say explicitly that comparison is by comparing the
characters exactly as they are writ.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | The trip doesn't exist that can set you
http://nwalsh.com/            | beyond the reach of cravings, fits of
                              | temper, or fears. If it did, the human
                              | race would be off there in a body.--
                              | Seneca

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBBAVkaOyltUcwYWjsRAssvAJ9U5eNla0Ywcu41u0XbYfDTs+WaEACbBLsw
QnqE96a4yNNSqiEsspYPtbI=
=7l/M
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Fri Jul 23 14: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 OAA17269
	for <atompub-archive@lists.ietf.org>; Fri, 23 Jul 2004 14:40: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 i6NIVxju056228;
	Fri, 23 Jul 2004 11:31: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 i6NIVxDR056227;
	Fri, 23 Jul 2004 11:31:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6NIVxPW056218
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 11:31:59 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from phys-bur-1 ([129.148.9.72])
	by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i6NIVt0R024130
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 11:31:56 -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 <0I1B00A01HZ62R@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com)
 for atom-syntax@imc.org; Fri, 23 Jul 2004 14:31:55 -0400 (EDT)
Received: from mercury (vpn-129-150-33-253.Central.Sun.COM [129.150.33.253])
 by bur-mail1.east.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
 with ESMTP id <0I1B00JK2I52UJ@bur-mail1.east.sun.com> for atom-syntax@imc.org;
 Fri, 23 Jul 2004 14:31:55 -0400 (EDT)
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1Bo4pb-00067C-00	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 14:31:43 -0400
X-URL: http://nwalsh.com/
Date: Fri, 23 Jul 2004 14:31:43 -0400
From: Norman Walsh <ndw@nwalsh.com>
Subject: Re: Unstructured text
In-reply-to: 
 <605A99DE882CEC36E3B093C1@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <87fz7itw1c.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: <BD22B042.21030%eric.scheid@ironclad.net.au>
 <605A99DE882CEC36E3B093C1@adsl-64-166-133-244.dsl.snfc21.pacbell.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-Type: text/plain

/ Walter Underwood <wunder@verity.com> was heard to say:
| If we want structured names, we start with the X.500 name system
| (above) and also look at AACR2 (library cataloguing rules).
| Anything short of that is US-centric hacks.

That sounds like an argument for unstructured names to me :-)

(Not the US-centric bit, just the fact that getting the markup right
is very, very hard and will add significantly to the complexity of our
spec for very little payoff. IMHO.)

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Nothing ever becomes real till it is
http://nwalsh.com/            | experienced--even a proverb is no
                              | proverb to you until your life has
                              | illustrated it.-- Keats

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBBAVmPOyltUcwYWjsRAuppAJ4qI3ARz5LLs8/6pSAdTB6n5RuHawCfavIL
e487pRC4Nyc9Td4Mq4jHSAU=
=YESm
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Fri Jul 23 14: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 OAA17696
	for <atompub-archive@lists.ietf.org>; Fri, 23 Jul 2004 14:45: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 i6NIbWoH056625;
	Fri, 23 Jul 2004 11:37: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 i6NIbWh5056624;
	Fri, 23 Jul 2004 11:37:32 -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 i6NIbVUk056618
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 11:37:31 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from phys-bur-1 ([129.148.9.72])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i6NIZK53012040
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 12:35:20 -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 <0I1B00B01I77G2@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com)
 for atom-syntax@imc.org; Fri, 23 Jul 2004 14:37:34 -0400 (EDT)
Received: from mercury (vpn-129-150-33-253.Central.Sun.COM [129.150.33.253])
 by bur-mail1.east.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
 with ESMTP id <0I1B00JH2IEHUJ@bur-mail1.east.sun.com> for atom-syntax@imc.org;
 Fri, 23 Jul 2004 14:37:34 -0400 (EDT)
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1Bo4uv-0006A6-00	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 14:37:13 -0400
X-URL: http://nwalsh.com/
Date: Fri, 23 Jul 2004 14:37:06 -0400
From: Norman Walsh <ndw@nwalsh.com>
Subject: Re: URI scheme delusions
In-reply-to: <905f7c9104072218534925b919@mail.gmail.com>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <87bri6tvsd.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: <200407221003.i6MA3WWG083339@above.proper.com>
 <905f7c91040722053278962348@mail.gmail.com>
 <0ED5D262-DC00-11D8-AC8C-000A95A51C9E@sun.com>
 <709AF709-DC18-11D8-AC8C-000A95A51C9E@sun.com>
 <905f7c9104072218534925b919@mail.gmail.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-Type: text/plain

/ Elias Torres <eliast@gmail.com> was heard to say:
| How would you suggest people use IDs in Atom?

I think the suggestion would be http[1].

| What about the case when
| multiple feeds display the same entry (categories, site-aggregators,

As long as the ID is unique, you'll get the properties you want in
these cases.

| etc) and multiple versions of the same entry as well?

When does this occur? What are "multiple versions" of an entry?

To my mind, if two entries have the same ID, they're the same thing.
If there are differences, the fact that they have the same ID is an
assertion from the author that those differences are not significant
(and you can pick one at random, though I suggest you pick the one
with the most recent atom:modified date, if you can).

                                        Be seeing you,
                                          norm

[1] http://norman.walsh.name/2004/03/03/266NorthPleasant

-- 
Norman Walsh <ndw@nwalsh.com> | A great deal may be done by severity,
http://nwalsh.com/            | more by love, but most by clear
                              | discernment and impartial
                              | justice.--Goethe

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBBAVrUOyltUcwYWjsRAmDmAJ40vSCJJ5bp/tQO814Qo0S6JC/nUgCfcfov
ZtUlQniGVXSVJp7j9fXXIv4=
=C9xf
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Fri Jul 23 15: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 PAA18654
	for <atompub-archive@lists.ietf.org>; Fri, 23 Jul 2004 15:01: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 i6NIr0og057999;
	Fri, 23 Jul 2004 11:53: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 i6NIr0hX057998;
	Fri, 23 Jul 2004 11:53:00 -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 i6NIqx7u057989
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 11:52:59 -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 i6NIs0Pt011910;
	Fri, 23 Jul 2004 14:54:00 -0400
Message-ID: <41015F3D.9020704@intertwingly.net>
Date: Fri, 23 Jul 2004 14:55:57 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Norman Walsh <ndw@nwalsh.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: atom:origin?
References: <200407191919.PAA17914@ietf.org> <87hds3slp8.fsf@nwalsh.com> <40FC4B18.7020400@dehora.net> <40FC5E56.90505@intertwingly.net> <40FD154A.2090706@dehora.net> <40FD1FCB.7010803@intertwingly.net> <40FD4133.4040206@dehora.net> <527D65FB-DA93-11D8-B3AB-000A95DC3D90@mac.com> <40FD9780.4020102@dehora.net> <70F318DF-DB58-11D8-B3AB-000A95DC3D90@mac.com> <87k6wutw4n.fsf@nwalsh.com>
In-Reply-To: <87k6wutw4n.fsf@nwalsh.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


Norman Walsh wrote:

  > If we're going to have semantics that depend on comparing URIs, I do
> want the spec to say explicitly that comparison is by comparing the
> characters exactly as they are writ.

Norman, can you take a look at:

    http://www.intertwingly.net/wiki/pie/PaceFeedEquivalence

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Fri Jul 23 15:23: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 PAA20962
	for <atompub-archive@lists.ietf.org>; Fri, 23 Jul 2004 15:23: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 i6NJCxkr059112;
	Fri, 23 Jul 2004 12:12: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 i6NJCxTu059111;
	Fri, 23 Jul 2004 12:12: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.206])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6NJCtBW059104
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 12:12:58 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id 76so25411rnk
        for <atom-syntax@imc.org>; Fri, 23 Jul 2004 12:12:59 -0700 (PDT)
Received: by 10.38.24.8 with SMTP id 8mr64005rnx;
        Fri, 23 Jul 2004 12:12:59 -0700 (PDT)
Message-ID: <14be96d30407231212b9c81b4@mail.gmail.com>
Date: Fri, 23 Jul 2004 15:12:59 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: URI scheme delusions
In-Reply-To: <87bri6tvsd.fsf@nwalsh.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <200407221003.i6MA3WWG083339@above.proper.com>
 <905f7c91040722053278962348@mail.gmail.com>
 <0ED5D262-DC00-11D8-AC8C-000A95A51C9E@sun.com>
 <709AF709-DC18-11D8-AC8C-000A95A51C9E@sun.com>
 <905f7c9104072218534925b919@mail.gmail.com> <87bri6tvsd.fsf@nwalsh.com>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


On Fri, 23 Jul 2004 14:37:06 -0400, Norman Walsh <ndw@nwalsh.com> wrote:
> / Elias Torres <eliast@gmail.com> was heard to say:
> | How would you suggest people use IDs in Atom?
> 
> I think the suggestion would be http[1].

There are things you can do, and things that people expect to be able
to do, with HTTP URIs that you can not in fact do with IDs.  For
example, http://fishbowl.pastiche.org/2004/05/31/jroller_does_it_again

> 
> | What about the case when
> | multiple feeds display the same entry (categories, site-aggregators,
> 
> As long as the ID is unique, you'll get the properties you want in
> these cases.

No, as long as the ID is unique and unchanging, you'll get the
properties you want.

> 
> | etc) and multiple versions of the same entry as well?
> 
> When does this occur? What are "multiple versions" of an entry?
> 
> To my mind, if two entries have the same ID, they're the same thing.

Paging Mr. Theseus, your ship is ready...

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Fri Jul 23 16:04: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 QAA24185
	for <atompub-archive@lists.ietf.org>; Fri, 23 Jul 2004 16:04: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 i6NJum7l062294;
	Fri, 23 Jul 2004 12: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 i6NJumao062293;
	Fri, 23 Jul 2004 12:56:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6NJulmE062286
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 12:56:47 -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 i6NJsb53016242
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 13:54:37 -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 <0I1B004Q9M2RUN@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Fri, 23 Jul 2004 13:56:51 -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 <0I1B00LI7M2QXL@mail.sun.net> for atom-syntax@imc.org; Fri,
 23 Jul 2004 13:56:51 -0600 (MDT)
Date: Fri, 23 Jul 2004 12:57:01 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: URI scheme delusions
In-reply-to: <14be96d30407231212b9c81b4@mail.gmail.com>
To: Mark Pilgrim <pilgrim@gmail.com>
Cc: Atom Syntax <atom-syntax@imc.org>
Message-id: <7627EF82-DCE2-11D8-AFAD-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: <200407221003.i6MA3WWG083339@above.proper.com>
 <905f7c91040722053278962348@mail.gmail.com>
 <0ED5D262-DC00-11D8-AC8C-000A95A51C9E@sun.com>
 <709AF709-DC18-11D8-AC8C-000A95A51C9E@sun.com>
 <905f7c9104072218534925b919@mail.gmail.com> <87bri6tvsd.fsf@nwalsh.com>
 <14be96d30407231212b9c81b4@mail.gmail.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 Jul 23, 2004, at 12:12 PM, Mark Pilgrim wrote:

> There are things you can do, and things that people expect to be able
> to do, with HTTP URIs that you can not in fact do with IDs.  For
> example, http://fishbowl.pastiche.org/2004/05/31/jroller_does_it_again

"Doctor, it hurts when I do this!"

> Paging Mr. Theseus, your ship is ready...

Good point.  There will be no black sails used on board any 
Atom-powered ship.  -Tim



From owner-atom-syntax@mail.imc.org  Fri Jul 23 16: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 QAA24204
	for <atompub-archive@lists.ietf.org>; Fri, 23 Jul 2004 16:04: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 i6NJs7it062170;
	Fri, 23 Jul 2004 12:54:07 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6NJs7Qq062169;
	Fri, 23 Jul 2004 12:54:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6NJs6wW062162
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 12:54:07 -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 esmtp (Exim 4.34)
	id 1Bo67G-0002VT-87; Fri, 23 Jul 2004 19:54:02 +0000
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Fri, 23 Jul 2004 15:54:02 -0400
Subject: Re: atom:origin?
From: Robert Sayre <mint@franklinmint.fm>
To: Norman Walsh <ndw@nwalsh.com>, Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD26E51A.143E9%mint@franklinmint.fm>
In-Reply-To: <87k6wutw4n.fsf@nwalsh.com>
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: <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 7/23/04 2:29 PM, "Norman Walsh" <ndw@nwalsh.com> wrote:

> 
> If we're going to have semantics that depend on comparing URIs, I do
> want the spec to say explicitly that comparison is by comparing the
> characters exactly as they are writ.

+1

Something like this:

"URI[RFC2396] strings in Atom documents appear as attribute values. URIs can
be tested for equivalence by comparing the normalized values[0] of the
attributes they appear in. URIs MUST NOT be considered equivalent if they
appear in attributes with differing normalized value properties. [1]"

[0] http://www.w3.org/TR/REC-xml/#AVNormalize
[1] http://www.w3.org/TR/xml-infoset/#infoitem.attribute


Robert Sayre



From owner-atom-syntax@mail.imc.org  Fri Jul 23 16:19: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 QAA24894
	for <atompub-archive@lists.ietf.org>; Fri, 23 Jul 2004 16: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 i6NK80xo062862;
	Fri, 23 Jul 2004 13:08:00 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6NK80X5062861;
	Fri, 23 Jul 2004 13:08: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 i6NK7xA0062855
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 13:07:59 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from phys-bur-1 ([129.148.9.72])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6NK83il021937
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 14:08:03 -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 <0I1B00B01MJSC2@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com)
 for atom-syntax@imc.org; Fri, 23 Jul 2004 16:08:03 -0400 (EDT)
Received: from mercury (vpn-129-150-33-253.Central.Sun.COM [129.150.33.253])
 by bur-mail1.east.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
 with ESMTP id <0I1B00AE9ML5XD@bur-mail1.east.sun.com> for atom-syntax@imc.org;
 Fri, 23 Jul 2004 16:08:03 -0400 (EDT)
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1Bo6KY-0007C8-00	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 16:07:46 -0400
X-URL: http://nwalsh.com/
Date: Fri, 23 Jul 2004 16:07:44 -0400
From: Norman Walsh <ndw@nwalsh.com>
Subject: Re: URI scheme delusions
In-reply-to: <14be96d30407231212b9c81b4@mail.gmail.com>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <87u0vysd0v.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: <200407221003.i6MA3WWG083339@above.proper.com>
 <905f7c91040722053278962348@mail.gmail.com>
 <0ED5D262-DC00-11D8-AC8C-000A95A51C9E@sun.com>
 <709AF709-DC18-11D8-AC8C-000A95A51C9E@sun.com>
 <905f7c9104072218534925b919@mail.gmail.com> <87bri6tvsd.fsf@nwalsh.com>
 <14be96d30407231212b9c81b4@mail.gmail.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-Type: text/plain

/ Mark Pilgrim <pilgrim@gmail.com> was heard to say:
| On Fri, 23 Jul 2004 14:37:06 -0400, Norman Walsh <ndw@nwalsh.com> wrote:
|> / Elias Torres <eliast@gmail.com> was heard to say:
|> | How would you suggest people use IDs in Atom?
|> 
|> I think the suggestion would be http[1].
|
| There are things you can do, and things that people expect to be able
| to do, with HTTP URIs that you can not in fact do with IDs.  For
| example, http://fishbowl.pastiche.org/2004/05/31/jroller_does_it_again

I did say it was a suggestion. I'm not happy about it, I just decided
to admit defeat on names and addresses and move on.

In the case of the jroller example, I don't think the use of http is
the problem, dynamically generating the ID values from the web server
name is the problem.

|> | What about the case when
|> | multiple feeds display the same entry (categories, site-aggregators,
|> 
|> As long as the ID is unique, you'll get the properties you want in
|> these cases.
|
| No, as long as the ID is unique and unchanging, you'll get the
| properties you want.

Unchanging, yes. Unless, of course, you hold the view that IDs cannot
change, their one defining characteristic is that they provide
identity. An entry with a "changed" ID is a different entry, by
definition.

|> When does this occur? What are "multiple versions" of an entry?
|> 
|> To my mind, if two entries have the same ID, they're the same thing.
|
| Paging Mr. Theseus, your ship is ready...

Yes. And the one that has the same ID painted on its bow is the same
one, irrespective of what it's composed of. And if two ships sail into
the harbor and they both have the same ID painted on their bow, then
there is only one ship. And there are no spoons on any of them.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | We dance around in a ring and suppose,
http://nwalsh.com/            | but the Secret sits in the middle and
                              | knows.--Robert Frost

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBBAXASOyltUcwYWjsRAoT2AJ92xL4+p28qxPX/kE/lV7Dsyo/otACgo9SB
+Gn4fqYIDBTfzqxbMsmUXw8=
=EQjT
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Fri Jul 23 16:26: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 QAA25294
	for <atompub-archive@lists.ietf.org>; Fri, 23 Jul 2004 16:26: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 i6NKFXB4063243;
	Fri, 23 Jul 2004 13:15: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 i6NKFXOa063242;
	Fri, 23 Jul 2004 13:15:33 -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 i6NKFXq8063236
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 13:15:33 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from phys-bur-1 ([129.148.9.72])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6NKFbil024943
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 14:15:37 -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 <0I1B00C01MSWOI@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com)
 for atom-syntax@imc.org; Fri, 23 Jul 2004 16:15:37 -0400 (EDT)
Received: from mercury (vpn-129-150-33-253.Central.Sun.COM [129.150.33.253])
 by bur-mail1.east.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
 with ESMTP id <0I1B00AO9MXSXD@bur-mail1.east.sun.com> for atom-syntax@imc.org;
 Fri, 23 Jul 2004 16:15:37 -0400 (EDT)
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1Bo6Ro-0007I1-00	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 16:15:16 -0400
X-URL: http://nwalsh.com/
Date: Fri, 23 Jul 2004 16:15:14 -0400
From: Norman Walsh <ndw@nwalsh.com>
Subject: Re: atom:origin?
In-reply-to: <41015F3D.9020704@intertwingly.net>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <87pt6mscod.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: <200407191919.PAA17914@ietf.org> <87hds3slp8.fsf@nwalsh.com>
 <40FC4B18.7020400@dehora.net> <40FC5E56.90505@intertwingly.net>
 <40FD154A.2090706@dehora.net> <40FD1FCB.7010803@intertwingly.net>
 <40FD4133.4040206@dehora.net> <527D65FB-DA93-11D8-B3AB-000A95DC3D90@mac.com>
 <40FD9780.4020102@dehora.net> <70F318DF-DB58-11D8-B3AB-000A95DC3D90@mac.com>
 <87k6wutw4n.fsf@nwalsh.com> <41015F3D.9020704@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-Type: text/plain

/ Sam Ruby <rubys@intertwingly.net> was heard to say:
| Norman Walsh wrote:
|
|   > If we're going to have semantics that depend on comparing URIs, I do
|> want the spec to say explicitly that comparison is by comparing the
|> characters exactly as they are writ.
|
| Norman, can you take a look at:
|
|     http://www.intertwingly.net/wiki/pie/PaceFeedEquivalence

Yes, that's what I had in mind, assuming we get consensus on the
clarification that I added to that page :-)

  NormanWalsh suggests that "matches" and "matching" be more
  specifically defined as per Section 6.2.1 "Simple String Comparison"
  of 2396bis.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | 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.4 (GNU/Linux)

iD8DBQBBAXHUOyltUcwYWjsRAigBAJ0X3fb+Pk2PivEUvVIxPYaZcMiFLACfT0eX
FN0pYostx8tjslVo9cGbbew=
=9mt9
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Fri Jul 23 16:33: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 QAA25801
	for <atompub-archive@lists.ietf.org>; Fri, 23 Jul 2004 16:33: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 i6NKLtgZ063474;
	Fri, 23 Jul 2004 13:21: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 i6NKLtkj063473;
	Fri, 23 Jul 2004 13:21:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from dumle.webhuset.no (dumle.webhuset.no [81.27.32.66])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6NKLrQl063465
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 13:21:54 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Message-Id: <200407232021.i6NKLrQl063465@above.proper.com>
Received: (qmail 10284 invoked from network); 23 Jul 2004 20:20:17 -0000
Received: from unknown (HELO localhost.localdomain) (81.27.34.19)
  by 0 with SMTP; 23 Jul 2004 20:20:17 -0000
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
MIME-Version: 1.0
From: "Arve Bersvendsen" <arve@virtuelvis.com>
To: Graham <dtcd@mac.com>, atom-syntax@imc.org
Subject: Re: Propose partial consensus on dates
Date: Fri, 23 Jul 2004 22:21:49 +0200
X-Mailer: WHMail 1.0 (http://www.webhuset.no)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6NKLtQl063468
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


> > - Organizations/tools/people to support the use case that an entry may 
> > only be issued exactly once, with an immutable 'issued' date.
> 
> Can you fill us in why this case might need to be handled differently 
> from entries that change?

Because there are organizations out there that issue something _exactly
once_. If they, for some unknown reason, need to change the content of what
they have already released, they cannot simply change the content of what
they have written, they have to release a new entry that supersedes the old
one.

One such notable process is medical journals here in Norway.  If the treating
part or the patient want an entry in the journal changed, they cannot simply
go back and change that entry. They have to issue a new entry in the journal,
and state that this entry supersedes a given previous entry.  This is a legal
requirement.

The blogging model of dated, and often linked, entries is a good fit for the
typical medical journal. The "feed" notion of a journal also fits pretty well
with the (again, Norwegian) legal requirement that a patient has a legal
right to access his jorunal.



From owner-atom-syntax@mail.imc.org  Fri Jul 23 16:47: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 QAA26547
	for <atompub-archive@lists.ietf.org>; Fri, 23 Jul 2004 16:47: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 i6NKaPAQ064117;
	Fri, 23 Jul 2004 13:36: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 i6NKaPIE064116;
	Fri, 23 Jul 2004 13:36: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 i6NKaPDC064107
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 13:36:25 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040723203624.5503.qmail@web41206.mail.yahoo.com>
Received: from [207.46.228.16] by web41206.mail.yahoo.com via HTTP; Fri, 23 Jul 2004 13:36:24 PDT
Date: Fri, 23 Jul 2004 13:36:24 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Propose partial consensus on dates
To: Sam Ruby <rubys@intertwingly.net>
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <4100FD1A.4090100@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:
> 
> Consider:
> 
>
http://www.tbray.org/ongoing/When/200x/2004/02/20/GenxStatus
> 
> Since this feed does not contain guids, I presume
> that RSS Bandit users 
> would see every update as a new entry.

No. The most recent version of RSS Bandit uses the
combination of link + title to act as identifiers for
feeds without guids. We did this because some feeds
such as the one at http://www.ibiblio.org/xml/ use the
same link for different items. This turns out to have
been a mistake since every time a typo is fixed in a
title our users see a new item in their feed that is a
duplicate. 

In the next version, we'll go back to using links as
guids in RSS feeds without guids. 

> If this feed were updated to contain guids, I
> presume that RSS Bandit 
> would quietly update the stored content, but would
> not otherwise 
> highlight to the user that this entry had been
> modified.  For typos, I 
> think this is appropriate.  For significant updates,
> like the ones that 
> Tim had made, less so.

Sure. My worry is that the difference between
significant update and minor update will differ to
widely from site to site for us to give users a
consistent user experience. You could argue that the
benefit of being able to make the distinction is worth
the added complexity it brings to the format and the
potential user irritation when <updated> is misused. 


> 
> I want aggregator authors to be able to answer the
> question "but why 
> did/did not you show my this change" with something
> other than "I 
> guessed wrong".

That's a worthy goal. 

> And I want to do it in a way that you, Dave
> Obasanjo, don't go around 
> telling everybody that "see, I told them that this
> was a bad idea".

My name isn't Dave. :)

=====
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  Fri Jul 23 17: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 RAA27995
	for <atompub-archive@lists.ietf.org>; Fri, 23 Jul 2004 17:18: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 i6NL4rjg065745;
	Fri, 23 Jul 2004 14: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 i6NL4rif065744;
	Fri, 23 Jul 2004 14:04: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 i6NL4qZS065737
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 14:04: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 esmtp (Exim 4.34)
	id 1Bo7Dn-0000HJ-Vp; Fri, 23 Jul 2004 21:04:52 +0000
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Fri, 23 Jul 2004 17:04:52 -0400
Subject: Re: Propose partial consensus on dates
From: Robert Sayre <mint@franklinmint.fm>
To: Dare Obasanjo <kpako@yahoo.com>, Sam Ruby <rubys@intertwingly.net>
CC: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD26F5B4.143F7%mint@franklinmint.fm>
In-Reply-To: <20040723203624.5503.qmail@web41206.mail.yahoo.com>
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: <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 7/23/04 4:36 PM, "Dare Obasanjo" <kpako@yahoo.com> wrote:

> 
>> If this feed were updated to contain guids, I
>> presume that RSS Bandit
>> would quietly update the stored content, but would
>> not otherwise 
>> highlight to the user that this entry had been
>> modified.  For typos, I
>> think this is appropriate.  For significant updates,
>> like the ones that
>> Tim had made, less so.
> 
> Sure. My worry is that the difference between
> significant update and minor update will differ to
> widely from site to site for us to give users a
> consistent user experience. You could argue that the
> benefit of being able to make the distinction is worth
> the added complexity it brings to the format and the
> potential user irritation when <updated> is misused.
> 

My worry is that we're inventing this practice. What's the precedent here?
Other formats seem to tackle this problem with changes to content structure
and/or distinct but related resources.

Robert Sayre



From owner-atom-syntax@mail.imc.org  Fri Jul 23 18:08: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 SAA00259
	for <atompub-archive@lists.ietf.org>; Fri, 23 Jul 2004 18: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 i6NLv924068763;
	Fri, 23 Jul 2004 14: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 i6NLv9hC068762;
	Fri, 23 Jul 2004 14:57: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 i6NLv8kf068755
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 14:57:08 -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 i6NLvDil004880
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 15:57:13 -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 <0I1B00H1SRNDMS@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Fri, 23 Jul 2004 15:57:13 -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 <0I1B00C41RNCE4@mail.sun.net> for atom-syntax@imc.org; Fri,
 23 Jul 2004 15:57:13 -0600 (MDT)
Date: Fri, 23 Jul 2004 14:57:23 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Date Options Survey
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <475BB4D1-DCF3-11D8-AFAD-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: <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


Is up for WG input at http://intertwingly.net/wiki/pie/DateSurvey

Please at this time do *not* argue about the definitions or 
classifications, this is meant as a blunt-edged data gathering 
exercise.  -Tim



From owner-atom-syntax@mail.imc.org  Fri Jul 23 18: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 SAA02195
	for <atompub-archive@lists.ietf.org>; Fri, 23 Jul 2004 18:33: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 i6NMNOwu070003;
	Fri, 23 Jul 2004 15:23: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 i6NMNOX6070002;
	Fri, 23 Jul 2004 15:23:24 -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 i6NMNNII069995
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 15:23:24 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 13519 messnum 2823492 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 23 Jul 2004 22:23:20 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail07.svc.cra.dublin.eircom.net (qp 13519) with SMTP; 23 Jul 2004 22:23:20 -0000
Message-ID: <41018FD8.1040603@dehora.net>
Date: Fri, 23 Jul 2004 23:23: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
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: URI scheme delusions
References: <200407221003.i6MA3WWG083339@above.proper.com> <905f7c91040722053278962348@mail.gmail.com> <0ED5D262-DC00-11D8-AC8C-000A95A51C9E@sun.com> <709AF709-DC18-11D8-AC8C-000A95A51C9E@sun.com> <905f7c9104072218534925b919@mail.gmail.com> <87bri6tvsd.fsf@nwalsh.com> <14be96d30407231212b9c81b4@mail.gmail.com> <7627EF82-DCE2-11D8-AFAD-000A95A51C9E@sun.com>
In-Reply-To: <7627EF82-DCE2-11D8-AFAD-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 Jul 23, 2004, at 12:12 PM, Mark Pilgrim wrote:
> 
>> There are things you can do, and things that people expect to be able
>> to do, with HTTP URIs that you can not in fact do with IDs.  For
>> example, http://fishbowl.pastiche.org/2004/05/31/jroller_does_it_again
> 
> 
> "Doctor, it hurts when I do this!"

See a psychiatarist, not a doctor. The web has naming and name 
distribution policies that are clearly delusional. As are all the 
others.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Fri Jul 23 18:35: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 SAA02326
	for <atompub-archive@lists.ietf.org>; Fri, 23 Jul 2004 18:35: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 i6NMPo9x070066;
	Fri, 23 Jul 2004 15: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 i6NMPoUS070065;
	Fri, 23 Jul 2004 15:25: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.202])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6NMPnXQ070058
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 15:25:50 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id 73so30441rnl
        for <atom-syntax@imc.org>; Fri, 23 Jul 2004 15:25:52 -0700 (PDT)
Received: by 10.38.206.62 with SMTP id d62mr5463rng;
        Fri, 23 Jul 2004 15:25:52 -0700 (PDT)
Message-ID: <14be96d30407231525194c45b1@mail.gmail.com>
Date: Fri, 23 Jul 2004 18:25:52 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Tim Bray <tim.bray@sun.com>
Subject: Re: URI scheme delusions
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <7627EF82-DCE2-11D8-AFAD-000A95A51C9E@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <200407221003.i6MA3WWG083339@above.proper.com>
 <905f7c91040722053278962348@mail.gmail.com>
 <0ED5D262-DC00-11D8-AC8C-000A95A51C9E@sun.com>
 <709AF709-DC18-11D8-AC8C-000A95A51C9E@sun.com>
 <905f7c9104072218534925b919@mail.gmail.com> <87bri6tvsd.fsf@nwalsh.com>
 <14be96d30407231212b9c81b4@mail.gmail.com> <7627EF82-DCE2-11D8-AFAD-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 Fri, 23 Jul 2004 12:57:01 -0700, Tim Bray <tim.bray@sun.com> wrote:
> On Jul 23, 2004, at 12:12 PM, Mark Pilgrim wrote:
> 
> > There are things you can do, and things that people expect to be able
> > to do, with HTTP URIs that you can not in fact do with IDs.  For
> > example, http://fishbowl.pastiche.org/2004/05/31/jroller_does_it_again
> 
> "Doctor, it hurts when I do this!"

"Doctor, it hurts when I miss the point."  There are things you can do
with "http://" URIs when they're URLs served up over HTTP, that you
can't do when they're in an <id> element.  One of them is HTTP-level
redirects.  Another is actually doing an HTTP GET and expecting
something useful.  (See also: permathreads on using "http://" URIs for
namespaces, RDF predicates, etc.)

You and I have battled over this before, and I'm still right, and you
still don't have any response except "Doctor, it hurts when I do
this."  Stop fighting long enough to acknowledge the consensus around
you.

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Fri Jul 23 19:36: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 TAA04223
	for <atompub-archive@lists.ietf.org>; Fri, 23 Jul 2004 19:36: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 i6NNO6t7073770;
	Fri, 23 Jul 2004 16: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 i6NNO69g073769;
	Fri, 23 Jul 2004 16:24:06 -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 i6NNO5AM073762
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 16:24:05 -0700 (PDT)
	(envelope-from roger@agincourtmedia.com)
Received: from biggreen ([216.63.148.42]) by journurl.com with MailEnable ESMTP; Fri, 23 Jul 2004 18:23:53 -0500
From: "Roger B." <roger@agincourtmedia.com>
To: "'Tim Bray'" <Tim.Bray@sun.com>, "'Atom Syntax'" <atom-syntax@imc.org>
Subject: RE: Date Options Survey
Date: Fri, 23 Jul 2004 18:29:17 -0500
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: <475BB4D1-DCF3-11D8-AFAD-000A95A51C9E@sun.com>
Thread-Index: AcRxADcBmMW16tkIRoGV6zOuXsQQQwAC4D6g
Message-ID: <A044DED38F4B4693B39B02C3826EA.MAI@journurl.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


> Please at this time do *not* argue about the definitions or
> classifications, this is meant as a blunt-edged data gathering
> exercise. 

Tim: That made it tough, because I had to -1 some things that would have
been better described as -1R, or "Atom would suffer from having this as a
required element". While I personally think four core date elements probably
amounts to two too many from a view-source POV, I'm not actually opposed to
any of them as long as they're optional.

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/ 






From owner-atom-syntax@mail.imc.org  Fri Jul 23 19:37:34 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04283
	for <atompub-archive@lists.ietf.org>; Fri, 23 Jul 2004 19: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 i6NNSdVU073933;
	Fri, 23 Jul 2004 16:28:39 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6NNSdTp073932;
	Fri, 23 Jul 2004 16:28:39 -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 i6NNSce8073919
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 16:28:39 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6NNSiil007142
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 17:28:44 -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 <0I1B005BYVVVZ0@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Fri, 23 Jul 2004 17:28: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 <0I1B00KX7VVV3Q@mail.sun.net> for atom-syntax@imc.org; Fri,
 23 Jul 2004 17:28:43 -0600 (MDT)
Date: Fri, 23 Jul 2004 16:28:54 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Date Options Survey
In-reply-to: <A044DED38F4B4693B39B02C3826EA.MAI@journurl.com>
To: "Roger B." <roger@agincourtmedia.com>
Cc: "'Atom Syntax'" <atom-syntax@imc.org>
Message-id: <0FFB1980-DD00-11D8-AFAD-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: <A044DED38F4B4693B39B02C3826EA.MAI@journurl.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 Jul 23, 2004, at 4:29 PM, Roger B. wrote:

> Tim: That made it tough, because I had to -1 some things that would 
> have
> been better described as -1R, or "Atom would suffer from having this 
> as a
> required element". While I personally think four core date elements 
> probably
> amounts to two too many from a view-source POV, I'm not actually 
> opposed to
> any of them as long as they're optional.

Roger, why don't you add a section for commentary at the bottom of the 
page below the table and drop that in.  It's useful info. -Tim



From owner-atom-syntax@mail.imc.org  Fri Jul 23 20:50:26 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06846
	for <atompub-archive@lists.ietf.org>; Fri, 23 Jul 2004 20:50:23 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6O0brGC077255;
	Fri, 23 Jul 2004 17:37: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 i6O0brHB077254;
	Fri, 23 Jul 2004 17:37:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from dumle.webhuset.no (dumle.webhuset.no [81.27.32.66])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6O0bpDw077246
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 17:37:52 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Message-Id: <200407240037.i6O0bpDw077246@above.proper.com>
Received: (qmail 11106 invoked from network); 24 Jul 2004 00:36:15 -0000
Received: from unknown (HELO localhost.localdomain) (81.27.34.17)
  by 0 with SMTP; 24 Jul 2004 00:36:15 -0000
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
MIME-Version: 1.0
From: "Arve Bersvendsen" <arve@virtuelvis.com>
To: Tim Bray <Tim.Bray@Sun.COM>, atom-syntax@imc.org
Subject: Re: Date Options Survey
Date: Sat, 24 Jul 2004 02:37:49 +0200
X-Mailer: WHMail 1.0 (http://www.webhuset.no)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6O0bqDw077249
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
> Please at this time do *not* argue about the definitions or 
> classifications, this is meant as a blunt-edged data gathering 
> exercise.  -Tim

While I have answered the survey, I would like to state that I think this
survey is premature and incomplete as long as we don't agree on the specific
meaning of some of the dates - we really need to have consensus on "What does
X mean" before we can actually form an opinion on X.

-- 
Arve Bersvendsen



From owner-atom-syntax@mail.imc.org  Fri Jul 23 21:20: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 VAA08440
	for <atompub-archive@lists.ietf.org>; Fri, 23 Jul 2004 21:20: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 i6O19FH2078900;
	Fri, 23 Jul 2004 18:09: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 i6O19FrS078899;
	Fri, 23 Jul 2004 18:09:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6O19F1X078887
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 18:09:15 -0700 (PDT)
	(envelope-from gstein@google.com)
Received: from buu.corp.google.com (buu.corp.google.com [172.24.67.34])
	by 216-239-45-4.google.com (8.12.11/8.12.9) with ESMTP id i6O19Csj027257
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 18:09:12 -0700
Received: from gstein by buu.corp.google.com with local (Exim 4.14 #4)
	id 1BoB2F-0004Zo-IA by authid <gstein>
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 18:09:11 -0700
Date: Fri, 23 Jul 2004 18:09:11 -0700
From: Greg Stein <gstein@google.com>
To: atom-syntax@imc.org
Subject: Re: URI scheme delusions
Message-ID: <20040724010911.GB11643@google.com>
References: <200407221003.i6MA3WWG083339@above.proper.com> <905f7c91040722053278962348@mail.gmail.com> <0ED5D262-DC00-11D8-AC8C-000A95A51C9E@sun.com> <709AF709-DC18-11D8-AC8C-000A95A51C9E@sun.com> <905f7c9104072218534925b919@mail.gmail.com> <87bri6tvsd.fsf@nwalsh.com> <14be96d30407231212b9c81b4@mail.gmail.com> <7627EF82-DCE2-11D8-AFAD-000A95A51C9E@sun.com> <14be96d30407231525194c45b1@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <14be96d30407231525194c45b1@mail.gmail.com>
User-Agent: Mutt/1.4.1i
X-URL: http://www.lyra.org/greg/
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'm agreeing with Mark on this one. His example:

    http://fishbowl.pastiche.org/2004/05/31/jroller_does_it_again

That URI is fixed and unchanging. It is JUST FINE as an identifier.

The fact that you can feed it into a HTTP client, have it run off and
fetch content for you, and the fact that the content might change... has
NOTHING to do with the fact that that URI is a constant. And, thus, more
than suitable as an identifier.

My ID is "Greg Stein". That's awfully constant. I'm always changing, but
my identifier is not.

In short, people are conflating two concepts, and using that as an
argument that an HTTP URI is unusable as an identifier. Whoops. Keep 'em
separate, people...

Cheers,
-g

On Fri, Jul 23, 2004 at 06:25:52PM -0400, Mark Pilgrim wrote:
> 
> On Fri, 23 Jul 2004 12:57:01 -0700, Tim Bray <tim.bray@sun.com> wrote:
> > On Jul 23, 2004, at 12:12 PM, Mark Pilgrim wrote:
> > 
> > > There are things you can do, and things that people expect to be able
> > > to do, with HTTP URIs that you can not in fact do with IDs.  For
> > > example, http://fishbowl.pastiche.org/2004/05/31/jroller_does_it_again
> > 
> > "Doctor, it hurts when I do this!"
> 
> "Doctor, it hurts when I miss the point."  There are things you can do
> with "http://" URIs when they're URLs served up over HTTP, that you
> can't do when they're in an <id> element.  One of them is HTTP-level
> redirects.  Another is actually doing an HTTP GET and expecting
> something useful.  (See also: permathreads on using "http://" URIs for
> namespaces, RDF predicates, etc.)
> 
> You and I have battled over this before, and I'm still right, and you
> still don't have any response except "Doctor, it hurts when I do
> this."  Stop fighting long enough to acknowledge the consensus around
> you.
> 
> -- 
> Cheers,
> -Mark
> 



From owner-atom-syntax@mail.imc.org  Fri Jul 23 21:44: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 VAA09179
	for <atompub-archive@lists.ietf.org>; Fri, 23 Jul 2004 21:44: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 i6O1W2It081757;
	Fri, 23 Jul 2004 18: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 i6O1W2Bk081756;
	Fri, 23 Jul 2004 18: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-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 i6O1Vup2081744
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 18: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 i6O1Tm53016956
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 19:29:48 -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 <0I1C00HHS1LDMS@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Fri, 23 Jul 2004 19:32:02 -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 <0I1C00CPE1LDE1@mail.sun.net> for atom-syntax@imc.org; Fri,
 23 Jul 2004 19:32:01 -0600 (MDT)
Date: Fri, 23 Jul 2004 18:32:12 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Date Options Survey
In-reply-to: <200407240037.i6O0bpDw077246@above.proper.com>
To: Arve Bersvendsen <arve@virtuelvis.com>
Cc: atom-syntax@imc.org
Message-id: <49A1D676-DD11-11D8-AFAD-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: <200407240037.i6O0bpDw077246@above.proper.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 Jul 23, 2004, at 5:37 PM, Arve Bersvendsen wrote:

> While I have answered the survey, I would like to state that I think 
> this
> survey is premature and incomplete as long as we don't agree on the 
> specific
> meaning of some of the dates - we really need to have consensus on 
> "What does
> X mean" before we can actually form an opinion on X.

You're entitled to that opinion, but I talked it over with Paul and 
Sam, and we agreed that we had a good-enough shared understanding to do 
some information gathering.  As co-chair, my job is to help move this 
process along and it's our judgment that this will help.  Mind you, I 
could have launched it at a better time than late afternoon on a Summer 
Friday. -Tim



From owner-atom-syntax@mail.imc.org  Fri Jul 23 21: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 VAA09373
	for <atompub-archive@lists.ietf.org>; Fri, 23 Jul 2004 21:52: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 i6O1dEo4082270;
	Fri, 23 Jul 2004 18:39: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 i6O1dEMe082269;
	Fri, 23 Jul 2004 18:39:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6O1dDbD082257;
	Fri, 23 Jul 2004 18:39:13 -0700 (PDT)
	(envelope-from jasnell@us.ibm.com)
Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32])
	by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i6O1dADb422746;
	Fri, 23 Jul 2004 21:39:10 -0400
Received: from d03nm122.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168])
	by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6O1cobx178656;
	Fri, 23 Jul 2004 19:39:00 -0600
In-Reply-To: <20040724010911.GB11643@google.com>
To: Greg Stein <gstein@google.com>
Cc: atom-syntax@imc.org, owner-atom-syntax@mail.imc.org
MIME-Version: 1.0
Subject: Re: URI scheme delusions
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
From: James M Snell <jasnell@us.ibm.com>
X-MIMETrack: S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/23/2004 06:33:22 PM,
	Serialize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/23/2004 06:33:22 PM,
	Serialize complete at 07/23/2004 06:33:23 PM,
	Itemize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/23/2004 06:33:23 PM,
	S/MIME Sign complete at 07/23/2004 06:33:23 PM,
	S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/23/2004 06:38:47 PM,
	S/MIME Sign complete at 07/23/2004 06:38:47 PM,
	Serialize by Router on D03NM122/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at
 07/23/2004 19:39:05,
	Serialize complete at 07/23/2004 19:39:05
Message-ID: <OF031774D8.BEC98F6C-ON88256EDB.00084992-88256EDB.00090B2C@us.ibm.com>
Date: Fri, 23 Jul 2004 19:38:47 -0600
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z35910_boundary_sign
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>


This is an S/MIME signed message.

---------z35910_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 00088C9B88256EDB_="

This is a multipart message in MIME format.
--=_alternative 00088C9B88256EDB_=
Content-Type: text/plain; charset="US-ASCII"

owner-atom-syntax@mail.imc.org wrote on 07/23/2004 06:09:11 PM:

> 
> I'm agreeing with Mark on this one. His example:
> 
>     http://fishbowl.pastiche.org/2004/05/31/jroller_does_it_again
> 
> That URI is fixed and unchanging. It is JUST FINE as an identifier.
> 
> The fact that you can feed it into a HTTP client, have it run off and
> fetch content for you, and the fact that the content might change... has
> NOTHING to do with the fact that that URI is a constant. And, thus, more
> than suitable as an identifier.
> 
> My ID is "Greg Stein". That's awfully constant. I'm always changing, but
> my identifier is not.
> 
> In short, people are conflating two concepts, and using that as an
> argument that an HTTP URI is unusable as an identifier. Whoops. Keep 'em
> separate, people...
> 

I personally feel that ID should be allowed to be ANY type of URI, 
independent of scheme.  It simply does not matter if you can DO anything 
with it, it just has to be unique.  If you can actually DO something with 
the URI that is used as the ID, then great, wonderful, bonus... but that's 
not a requirement. HTTP URI's work great to meet this requirement, LSID's 
could also... the scheme used in the URI simply doesn't matter.

> Cheers,
> -g
> 
> On Fri, Jul 23, 2004 at 06:25:52PM -0400, Mark Pilgrim wrote:
> > 
> > On Fri, 23 Jul 2004 12:57:01 -0700, Tim Bray <tim.bray@sun.com> wrote:
> > > On Jul 23, 2004, at 12:12 PM, Mark Pilgrim wrote:
> > > 
> > > > There are things you can do, and things that people expect to be 
able
> > > > to do, with HTTP URIs that you can not in fact do with IDs.  For
> > > > example, 
http://fishbowl.pastiche.org/2004/05/31/jroller_does_it_again
> > > 
> > > "Doctor, it hurts when I do this!"
> > 
> > "Doctor, it hurts when I miss the point."  There are things you can do
> > with "http://" URIs when they're URLs served up over HTTP, that you
> > can't do when they're in an <id> element.  One of them is HTTP-level
> > redirects.  Another is actually doing an HTTP GET and expecting
> > something useful.  (See also: permathreads on using "http://" URIs for
> > namespaces, RDF predicates, etc.)
> > 
> > You and I have battled over this before, and I'm still right, and you
> > still don't have any response except "Doctor, it hurts when I do
> > this."  Stop fighting long enough to acknowledge the consensus around
> > you.
> > 
> > -- 
> > Cheers,
> > -Mark
> > 
> 


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

--=_alternative 00088C9B88256EDB_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>owner-atom-syntax@mail.imc.org wrote on 07/23/2004
06:09:11 PM:<br>
<br>
&gt; <br>
&gt; I'm agreeing with Mark on this one. His example:<br>
&gt; <br>
&gt; &nbsp; &nbsp; http://fishbowl.pastiche.org/2004/05/31/jroller_does_it_again<br>
&gt; <br>
&gt; That URI is fixed and unchanging. It is JUST FINE as an identifier.<br>
&gt; <br>
&gt; The fact that you can feed it into a HTTP client, have it run off
and<br>
&gt; fetch content for you, and the fact that the content might change...
has<br>
&gt; NOTHING to do with the fact that that URI is a constant. And, thus,
more<br>
&gt; than suitable as an identifier.<br>
&gt; <br>
&gt; My ID is &quot;Greg Stein&quot;. That's awfully constant. I'm always
changing, but<br>
&gt; my identifier is not.<br>
&gt; <br>
&gt; In short, people are conflating two concepts, and using that as an<br>
&gt; argument that an HTTP URI is unusable as an identifier. Whoops. Keep
'em<br>
&gt; separate, people...<br>
&gt; </tt></font>
<br>
<br><font size=2><tt>I personally feel that ID should be allowed to be
ANY type of URI, independent of scheme. &nbsp;It simply does not matter
if you can DO anything with it, it just has to be unique. &nbsp;If you
can actually DO something with the URI that is used as the ID, then great,
wonderful, bonus... but that's not a requirement. HTTP URI's work great
to meet this requirement, LSID's could also... the scheme used in the URI
simply doesn't matter.</tt></font>
<br><font size=2><tt><br>
&gt; Cheers,<br>
&gt; -g<br>
&gt; <br>
&gt; On Fri, Jul 23, 2004 at 06:25:52PM -0400, Mark Pilgrim wrote:<br>
&gt; &gt; <br>
&gt; &gt; On Fri, 23 Jul 2004 12:57:01 -0700, Tim Bray &lt;tim.bray@sun.com&gt;
wrote:<br>
&gt; &gt; &gt; On Jul 23, 2004, at 12:12 PM, Mark Pilgrim wrote:<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; &gt; There are things you can do, and things that people
expect to be able<br>
&gt; &gt; &gt; &gt; to do, with HTTP URIs that you can not in fact do with
IDs. &nbsp;For<br>
&gt; &gt; &gt; &gt; example, http://fishbowl.pastiche.org/2004/05/31/jroller_does_it_again<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; &quot;Doctor, it hurts when I do this!&quot;<br>
&gt; &gt; <br>
&gt; &gt; &quot;Doctor, it hurts when I miss the point.&quot; &nbsp;There
are things you can do<br>
&gt; &gt; with &quot;http://&quot; URIs when they're URLs served up over
HTTP, that you<br>
&gt; &gt; can't do when they're in an &lt;id&gt; element. &nbsp;One of
them is HTTP-level<br>
&gt; &gt; redirects. &nbsp;Another is actually doing an HTTP GET and expecting<br>
&gt; &gt; something useful. &nbsp;(See also: permathreads on using &quot;http://&quot;
URIs for<br>
&gt; &gt; namespaces, RDF predicates, etc.)<br>
&gt; &gt; <br>
&gt; &gt; You and I have battled over this before, and I'm still right,
and you<br>
&gt; &gt; still don't have any response except &quot;Doctor, it hurts when
I do<br>
&gt; &gt; this.&quot; &nbsp;Stop fighting long enough to acknowledge the
consensus around<br>
&gt; &gt; you.<br>
&gt; &gt; <br>
&gt; &gt; -- <br>
&gt; &gt; Cheers,<br>
&gt; &gt; -Mark<br>
&gt; &gt; <br>
&gt; <br>
</tt></font>
<br>
<br><font size=2 face="sans-serif">- James M Snell<br>
 &nbsp;jasnell@us.ibm.com<br>
 &nbsp;http://www.ibm.com<br>
 &nbsp;(877) 511-5082 / Office<br>
 &nbsp;930-1979 / Tie Line</font>
<br>
--=_alternative 00088C9B88256EDB_=--

---------z35910_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIIUOAIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIISWDCCAtow
ggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1
aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAy
MDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA629xc49NpAPz
cAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7glzJKgPkPzlTZZfznznGbmAWVnNBQ
lyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnwNclOnnP2sKufuPzbTImQTTi5c8JZNZcM
J0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEEBAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1Ud
DgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAPBgNVHRMBAf8EBTADAQH/MDEGA1UdJQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUH
AwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvu
jQupk2oCScMd3FIHLE7hOfu8YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14ke
McF9ViNdewEoBGiAycUq8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIC2jCCAkOgAwIB
AgIDAxS2MA0GCSqGSIb3DQEBBAUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwMTE0MjIw
NzExWhcNMTExMjMxMjIwNzExWjBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25h
bCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrb3Fzj02kA/NwCy5KFMiY
tFgyTJ6kMSQLVSs9uwVHIAVkqy/enDQwZ9b/7uCXMkqA+Q/OVNll/OfOcZuYBZWc0FCXI9qw60KO
J/rTd65FdF4dwp8cw8si0qjOJtYg8cm46fA1yU6ec/awq5+4/NtMiZBNOLlzwlk1lwwnRgXNNwID
AQABo4GqMIGnMBEGCWCGSAGG+EIBAQQEAwIAhzAOBgNVHQ8BAf8EBAMCAcYwHQYDVR0OBBYEFK5U
DpLqqDOpKyQtx8hvMNze80pAMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMA8GA1Ud
EwEB/wQFMAMBAf8wMQYDVR0lBCowKAYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYB
BQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAMnJ7c2YLyrY/PKlFl+7sm8NENfWtFxqdm+6NC6mTagJJ
wx3cUgcsTuE5+7xh9+/G0tTfLzA1qZAQ5GNMPXvmoB9+vJfKnC2JWMFQpIOUEJDXiR4xwX1WI117
ASgEaIDJxSrxHcuuV/hMIO9bgZ6C41MUVmdLTKBgBOImTuIPK8QwggMgMIICiaADAgECAgQ13vTP
MA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQL
EyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0MTUxWhcN
MTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMk
RXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKKlQRkrPFr
U18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkwrFEeO68r
1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOgYaRfMF0x
CzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBD
ZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAxODA4MjIx
NjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAdBgNV
HQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0HQQAEDTAL
GwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwlMQ0AppJu
f7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn00DbOyZY
sih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMgMIICiaADAgEC
AgQ13vTPMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0
MTUxWhcNMTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsG
A1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKK
lQRkrPFrU18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkw
rFEeO68r1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOg
YaRfMF0xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNl
Y3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAx
ODA4MjIxNjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAdBgNVHQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0H
QQAEDTALGwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwl
MQ0AppJuf7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn
00DbOyZYsih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMmMIIC
j6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIxNjM2NTRaMIGFMQsw
CQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEXMBUGA1UEAxMOSmFt
ZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkqhkiG9w0BCQEWEmph
c25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwKpbDG3zMatEuuOT
FYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSyd+7nwqAvbBfPj+0S
vcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7tBJlLrwDRCMoNlPuQ
Kg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQW
BBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOgFAwSamFzbmVs
bEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pAMCcGA1UdJQQgMB4G
CCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAZMKevB7dFfb9
23OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY8BjwVHxiYgG4xkxf
B1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOIzj3lz3xd+uOzqRFg
/Wsg/VMwggMmMIICj6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAy
BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNV
BAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIx
NjM2NTRaMIGFMQswCQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEX
MBUGA1UEAxMOSmFtZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkq
hkiG9w0BCQEWEmphc25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
wKpbDG3zMatEuuOTFYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSy
d+7nwqAvbBfPj+0SvcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7t
BJlLrwDRCMoNlPuQKg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQD
AgXgMB0GA1UdDgQWBBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcU
AgOgFAwSamFzbmVsbEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA
MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQAD
gYEAZMKevB7dFfb923OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY
8BjwVHxiYgG4xkxfB1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOI
zj3lz3xd+uOzqRFg/Wsg/VMxggG7MIIBtwIBATBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJ
bnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0g
Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwF+kzAJBgUrDgMCGgUAoIGiMBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDcyNDAxMzMyM1owIwYJKoZIhvcNAQkEMRYE
FFfZp8jOCED3KbyqImTDEnAw4ZJTMEMGCSqGSIb3DQEJDzE2MDQwBwYFKw4DAh0wDgYIKoZIhvcN
AwICAgCAMAoGCCqGSIb3DQMHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGACY+34hpJ
oxXoYFoO7PKDfkUcbODFkMnTvORKmKMLfZ74N7DYe1p7WwIiy67c1EHFn7AzvFcXkINBQN5jvWQd
53SgbBQmEpDKmtysLqVbOtLyi4++p/pmVOR8bRuMN4/5JtjEHTJRA24A44oIF8Kykk7YQmyo8Ok1
godcpn5ZP6oAAAAA

---------z35910_boundary_sign--



From owner-atom-syntax@mail.imc.org  Fri Jul 23 22:28: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 WAA10549
	for <atompub-archive@lists.ietf.org>; Fri, 23 Jul 2004 22: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 i6O2K1oM085717;
	Fri, 23 Jul 2004 19: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 i6O2K1el085716;
	Fri, 23 Jul 2004 19:20:01 -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 i6O2K1q7085707
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 19:20:01 -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 <2004072402200101400dk6hne>; Sat, 24 Jul 2004 02:20:02 +0000
Date: Fri, 23 Jul 2004 20:20:00 -0600
Subject: Re: Date Options Survey
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: <0FFB1980-DD00-11D8-AFAD-000A95A51C9E@sun.com>
Message-Id: <F72C928A-DD17-11D8-889A-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 Jul 23, 2004, at 4:29 PM, Roger B. wrote:
> Tim: That made it tough, because I had to -1 some things that would 
> have
> been better described as -1R, or "Atom would suffer from having this 
> as a
> required element". While I personally think four core date elements 
> probably
> amounts to two too many from a view-source POV, I'm not actually 
> opposed to
> any of them as long as they're optional.
Perhaps the following list of choices could be used to express that:

-2: I won't be able to use Atom if this is included
-1: Atom would suffer from having this included
0: I don't care.
0NR: I don't care if it's in Atom or not, but if it is, it should NOT 
be REQUIRED in every Entry
+1: Atom would benefit from having this included, and I don't care 
whether it's REQUIRED in every Entry
+1NR: Atom would benefit from having this included, but it should NOT 
be REQUIRED in every Entry
+1R: Atom would benefit from having this included, and it should be 
REQUIRED in every Entry
+2: I won't be able to use Atom if this isn't available, and I don't 
care whether it's REQUIRED in every Entry
+2NR: I won't be able to use Atom if this isn't available, but it 
should NOT be REQUIRED in every Entry
+2R: I won't be able to use Atom if this isn't available, and it should 
be REQUIRED in every Entry



From owner-atom-syntax@mail.imc.org  Fri Jul 23 23:15:14 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12043
	for <atompub-archive@lists.ietf.org>; Fri, 23 Jul 2004 23:15:13 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6O2wuM1087451;
	Fri, 23 Jul 2004 19:58: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 i6O2wubb087450;
	Fri, 23 Jul 2004 19:58: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] (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 i6O2wtXB087444
	for <atom-syntax@imc.org>; Fri, 23 Jul 2004 19:58:55 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p06110419bd277f8460c8@[10.20.30.249]>
In-Reply-To: <F72C928A-DD17-11D8-889A-003065EA6144@geckotribe.com>
References: <F72C928A-DD17-11D8-889A-003065EA6144@geckotribe.com>
Date: Fri, 23 Jul 2004 19:59:01 -0700
To: atom-syntax@imc.org
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: Date Options Survey
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>


>Perhaps the following list of choices could be used to express that:

Folks:

Could we *please* just let the poll happen without trying to tweak it 
do death while it is running? It's a poll, nothing more. It gives 
folks a visual way of saying "oh, this seems to be going that way". 
We can have different ones later, if we want. We can re-run this one 
in light of new material if we want. We can run away screaming, if we 
want.

Tim's purpose is a good one: see how folks are thinking without 
having to wade through the messages, which are less than clear at 
times.

It's the weekend. Let's give it a few days and see what it ends up 
looking like. It might be a big waste of time, but that's no big deal.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Sat Jul 24 03:51: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 DAA04168
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 03: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 i6O7eUBb055350;
	Sat, 24 Jul 2004 00:40:30 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6O7eUca055349;
	Sat, 24 Jul 2004 00:40:30 -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 i6O7eTlv055289;
	Sat, 24 Jul 2004 00:40:30 -0700 (PDT)
	(envelope-from roger@agincourtmedia.com)
Received: from biggreen ([216.63.148.42]) by journurl.com with MailEnable ESMTP; Sat, 24 Jul 2004 02:40:07 -0500
From: "Roger B." <roger@agincourtmedia.com>
To: "'Paul Hoffman / IMC'" <phoffman@imc.org>, <atom-syntax@imc.org>
Subject: RE: Date Options Survey
Date: Sat, 24 Jul 2004 02:45:44 -0500
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: <p06110419bd277f8460c8@[10.20.30.249]>
Thread-Index: AcRxKmPKIWpQefFVROGwPAZqnYmkYAAJ5ugg
Message-ID: <C90C61A5E3744FA8804F25D6AF531.MAI@journurl.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


> Could we *please* just let the poll happen without trying to tweak it
> do death while it is running?

Paul: It would be pointless to tweak it now anyway... adding/changing items
would warp the results. So yeah, it's better to finish an untweaked poll,
and if things still look muddled, try a tweaked one later.

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/ 






From owner-atom-syntax@mail.imc.org  Sat Jul 24 04: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 EAA04959
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 04: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 i6O86KwE063228;
	Sat, 24 Jul 2004 01:06: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 i6O86KxS063226;
	Sat, 24 Jul 2004 01:06:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from dumle.webhuset.no (dumle.webhuset.no [81.27.32.66])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6O86JUa063201
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 01:06:19 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Message-Id: <200407240806.i6O86JUa063201@above.proper.com>
Received: (qmail 12670 invoked from network); 24 Jul 2004 08:04:39 -0000
Received: from unknown (HELO localhost.localdomain) (81.27.34.19)
  by 0 with SMTP; 24 Jul 2004 08:04:39 -0000
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
MIME-Version: 1.0
From: "Arve Bersvendsen" <arve@virtuelvis.com>
To: Tim Bray <Tim.Bray@Sun.COM>, atom-syntax@imc.org
Subject: Re: Date Options Survey
Date: Sat, 24 Jul 2004 10:06:14 +0200
X-Mailer: WHMail 1.0 (http://www.webhuset.no)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6O86KUa063221
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:
> You're entitled to that opinion, but I talked it over with Paul and 
> Sam, and we agreed that we had a good-enough shared understanding to do 
> some information gathering.  

Ok, to be clear: I have answered the survey with MY understanding of one
specific date: issued.

My specific understanding is: "issued" == "first-issued" == does not change,
even if the entry changes. A date that essentially would be a timestamp for
when an entry's state was set to "publish".  I am +1R on that.

Another understanding of "issued" is what Movable Type thinks the "issued"
date is now: The user-changable date that is attached to an entry. In Movable
Type, this date is always equal to "created".  I am, at the very least, a -1
on that. 


-- 
Arve Bersvendsen



From owner-atom-syntax@mail.imc.org  Sat Jul 24 05:26: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 FAA08363
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 05:26: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 i6O9HlLh086242;
	Sat, 24 Jul 2004 02:17: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 i6O9Hl02086241;
	Sat, 24 Jul 2004 02:17:47 -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 i6O9HkPk086203
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 02:17:46 -0700 (PDT)
	(envelope-from roger@agincourtmedia.com)
Received: from biggreen ([216.63.148.42]) by journurl.com with MailEnable ESMTP; Sat, 24 Jul 2004 04:17:25 -0500
From: "Roger B." <roger@agincourtmedia.com>
To: <atom-syntax@imc.org>
Subject: Date Options Analysis: Issued
Date: Sat, 24 Jul 2004 04:22:14 -0500
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: <200407240806.i6O86JUa063201@above.proper.com>
Thread-Index: AcRxVTZHB+qVLnnRShG2GUUyvPrxhwABYWvQ
Message-ID: <8897C0DC42844B8A518EAF30843.MAI@journurl.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


> My specific understanding is: "issued" == "first-issued" == does not
change,
> even if the entry changes. A date that essentially would be a timestamp
for
> when an entry's state was set to "publish".  I am +1R on that.

Arve: Let me see if we can make some practical progress on this front.
Here's a scenario:

Let's say it's next year, and Atom 1.0 is released into the wild. And let's
say your argument has carried the day, and the spec ships with a required,
static atom:issued element.

When I put a potentially dynamic date in that element, how will you know?
How will Sam and Mark validate the nature of my dates? In concrete,
user-facing terms, how will your publishing app break if/when one of my
dates changes? In concrete, user-facing terms, how will your aggregator
break if/when one of my dates changes?

(My guesses: You won't, they won't, it won't, and it won't.)

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/ 







From owner-atom-syntax@mail.imc.org  Sat Jul 24 05: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 FAA10161
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 05: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 i6O9kTLX095310;
	Sat, 24 Jul 2004 02:46: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 i6O9kTFp095309;
	Sat, 24 Jul 2004 02:46:29 -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 i6O9kSRg095273
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 02:46:28 -0700 (PDT)
	(envelope-from davep@dpawson.co.uk)
Received: (qmail 12685 invoked from network); 24 Jul 2004 10:08:08 -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 Jul 2004 10:08:08 -0000
Subject: Re: Date Options Survey
From: Dave Pawson <davep@dpawson.co.uk>
Reply-To: davep@dpawson.co.uk
To: Atom syntax <atom-syntax@imc.org>
In-Reply-To: <200407240806.i6O86JUa063201@above.proper.com>
References: <200407240806.i6O86JUa063201@above.proper.com>
Content-Type: text/plain
Message-Id: <1090662382.2037.38.camel@homer>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) 
Date: Sat, 24 Jul 2004 10:46:22 +0100
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 Sat, 2004-07-24 at 09:06, Arve Bersvendsen wrote:
> * Tim Bray:
> > You're entitled to that opinion, but I talked it over with Paul and 
> > Sam, and we agreed that we had a good-enough shared understanding to do 
> > some information gathering.  
> 
> Ok, to be clear: I have answered the survey with MY understanding of one
> specific date: issued.
> 
> My specific understanding is: "issued" == "first-issued" == does not change,
> even if the entry changes. A date that essentially would be a timestamp for
> when an entry's state was set to "publish".  I am +1R on that.
> 
> Another understanding of "issued" is what Movable Type thinks the "issued"
> date is now: The user-changable date that is attached to an entry. In Movable
> Type, this date is always equal to "created".  I am, at the very least, a -1
> on that. 

And mine are different again from these.
I guess that's what's happening with the survey? Trying to find out if
there is support for the ideas there? If they come down one way or
another, clarity can be sought prior to wordsmithing the spec?


-- 
Regards DaveP.
XSLT&Docbook  FAQ
http://www.dpawson.co.uk/xsl




From owner-atom-syntax@mail.imc.org  Sat Jul 24 06:16: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 GAA11046
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 06:16: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 i6OA7nBr003027;
	Sat, 24 Jul 2004 03:07: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 i6OA7ngj003026;
	Sat, 24 Jul 2004 03:07:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from dumle.webhuset.no (dumle.webhuset.no [81.27.32.66])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6OA7m93002984
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 03:07:48 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Message-Id: <200407241007.i6OA7m93002984@above.proper.com>
Received: (qmail 13058 invoked from network); 24 Jul 2004 10:06:09 -0000
Received: from unknown (HELO localhost.localdomain) (81.27.34.19)
  by 0 with SMTP; 24 Jul 2004 10:06:09 -0000
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
MIME-Version: 1.0
From: "Arve Bersvendsen" <arve@virtuelvis.com>
To: "Roger B." <roger@agincourtmedia.com>, atom-syntax@imc.org
Subject: Re: Date Options Analysis: Issued
Date: Sat, 24 Jul 2004 12:07:44 +0200
X-Mailer: WHMail 1.0 (http://www.webhuset.no)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6OA7n93003019
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


* Roger Benningfield
>> My specific understanding is: "issued" == "first-issued" == does not
>> change, even if the entry changes. A date that essentially would be a
timestamp
>> for when an entry's state was set to "publish".  I am +1R on that.
> 
> Arve: Let me see if we can make some practical progress on this front.
> Here's a scenario:
>
> When I put a potentially dynamic date in that element, how will you know?
> How will Sam and Mark validate the nature of my dates? In concrete,
> user-facing terms, how will your publishing app break if/when one of my
> dates changes? In concrete, user-facing terms, how will your aggregator
> break if/when one of my dates changes?

Roger: I cannot enforce what you or others put in their feeds. The validator
cant enforce what someone puts in their feed - as long as it is syntactically
valid, it _is_ syntactically valid. I can't stop you from putting
1337-01-01T13:37:00Z as a permanent constant in all of your dates, if that is
what you wish.

Similarily, the W3C can't force web authors to create semantically sane
documents. They can't stop someone from using tables from layout. They can't
stop SEO spammers from putting pargraph content into heading elements.

What the W3C can do, however, is to provide a clear wording on what an
element means, and how it is to be used.

What we can do, is to provide clear wordings on what the different elements
within the atom namespace means, and how they SHOULD and SHOULD NOT be used.
If neccesary, we can even say how an element MUST and MUST NOT be used.

A clear wording on what an element really does _mean_ is a tool for
application vendors to facilitate reliable interoperability.  

-- 
Arve Bersvendsen



From owner-atom-syntax@mail.imc.org  Sat Jul 24 06:58: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 GAA12820
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 06:58: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 i6OAmd9D012489;
	Sat, 24 Jul 2004 03: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 i6OAmdh8012488;
	Sat, 24 Jul 2004 03:48:39 -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 i6OAmcZP012480
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 03:48:38 -0700 (PDT)
	(envelope-from roger@agincourtmedia.com)
Received: from biggreen ([216.63.148.42]) by journurl.com with MailEnable ESMTP; Sat, 24 Jul 2004 05:48:16 -0500
From: "Roger B." <roger@agincourtmedia.com>
To: "'Arve Bersvendsen'" <arve@virtuelvis.com>, <atom-syntax@imc.org>
Subject: RE: Date Options Analysis: Issued
Date: Sat, 24 Jul 2004 05:53:17 -0500
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: <200407241007.i6OA7m93002984@above.proper.com>
Thread-Index: AcRxZiaDvGpv8lmgTq+G3QK19nRuBgAAh7pw
Message-ID: <83E29738DFB84F29AE4652D298591.MAI@journurl.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


> A clear wording on what an element really does _mean_ is a tool for
> application vendors to facilitate reliable interoperability.

Arve: Perhaps I should be happy with half my questions answered, but
consider me greedy... I want the whole enchilada.

For the sake of argument, we can agree that a static date can be neither
mandated nor effectively validated. So what are the real-world repercussions
of using a dynamic date? How will your publishing app and/or aggregator
break when I change a date in my feed? What unintended consequence will I
face?

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/ 







From owner-atom-syntax@mail.imc.org  Sat Jul 24 07:45: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 HAA14818
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 07:45: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 i6OBaVtg018943;
	Sat, 24 Jul 2004 04:36: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 i6OBaVUh018942;
	Sat, 24 Jul 2004 04:36: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 i6OBaUPc018933
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 04:36: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 CCC357C0F3; Sat, 24 Jul 2004 14:32:36 +0200 (CEST)
To: "Roger B." <roger@agincourtmedia.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Propose partial consensus on dates
References: <CB11033A97134EDBA75A9D48599CA.MAI@journurl.com>
Message-ID: <opsbm30stduvpchu@quark>
Date: Sat, 24 Jul 2004 13:39:54 +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: <CB11033A97134EDBA75A9D48599CA.MAI@journurl.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Thu, 22 Jul 2004 18:40:45 -0500, Roger B. <roger@agincourtmedia.com>  
wrote:

>> REQ "issued"   - the time the entry was published for the first time
>
> Sascha: If a date element with that definition is a MUST in the Atom  
> spec, then one of two things happen:
>
> (1) Millions of Atom feeds will be turned off as everyone goes back to  
> RSS en masse.

I doubt that. If so, it will (hopefully) only be transitional.

> (2) Millions of Atom feeds will violate the spec by stuffing the display
> date into the required issued element.

That will also be transitional. Tools will already need to enhance their  
functionality to be Atom-conformant. Atom is _not_ RSS backward  
compatible. It has never been. And that's why Atom will be _better_ than  
RSS, and not just alternative syntax.

> after all, it'll be undetectable by the validator, and many consuming
> apps simply won't care.

Many consuming apps won't care. Sure. Many consuming apps will care, 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  Sat Jul 24 07:45: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 HAA14849
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 07: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 i6OBaEMh018929;
	Sat, 24 Jul 2004 04:36: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 i6OBaEJu018928;
	Sat, 24 Jul 2004 04:36:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from dumle.webhuset.no (dumle.webhuset.no [81.27.32.66])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6OBaDKP018917
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 04:36:13 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Message-Id: <200407241136.i6OBaDKP018917@above.proper.com>
Received: (qmail 13350 invoked from network); 24 Jul 2004 11:34:32 -0000
Received: from unknown (HELO localhost.localdomain) (81.27.34.17)
  by 0 with SMTP; 24 Jul 2004 11:34:32 -0000
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
MIME-Version: 1.0
From: "Arve Bersvendsen" <arve@virtuelvis.com>
To: "Roger B." <roger@agincourtmedia.com>, atom-syntax@imc.org
Subject: Re: Date Options Analysis: Issued
Date: Sat, 24 Jul 2004 13:36:07 +0200
X-Mailer: WHMail 1.0 (http://www.webhuset.no)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6OBaEKP018923
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


>> A clear wording on what an element really does _mean_ is a tool for
>> application vendors to facilitate reliable interoperability.
> 
> Arve: Perhaps I should be happy with half my questions answered, but
> consider me greedy... I want the whole enchilada.
> 
> For the sake of argument, we can agree that a static date can be neither
> mandated nor effectively validated. So what are the real-world
repercussions
> of using a dynamic date? How will your publishing app and/or aggregator
> break when I change a date in my feed? What unintended consequence will I
> face?

Please note that I was deliberately not answering what "issued" should mean
at this point. I was arguing that we should have a common understanding of
which question we were answering, when filling in DateSurvey.

If you were curious as to why I am -1 on mutable, and +1 on immutable, you
can first look a partial answer here:
<URL:http://imc.org/atom-syntax/mail-archive/msg07672.html>

When something is issued, it is out there, and issued, forever.  If you
change the content of what is out there, it is no longer the same entity: it
is a new entity, and SHOULD carry the metadata saying it is a new entity,
with some specifically named relation to the old one. 

If you are the creator of a non-revisioning CMS, my guess is that the desire
to change the "issued" date, is that you want it to bump back on to the front
page, or back into a feed where it normally would have rolled off. Sorting
this front page, or the feed by 'modified' is then, IMHO, a more suitable
option.

-- 
Arve Bersvendsen



From owner-atom-syntax@mail.imc.org  Sat Jul 24 08: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 IAA15896
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 08:04: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 i6OBq5lE019909;
	Sat, 24 Jul 2004 04: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 i6OBq51x019908;
	Sat, 24 Jul 2004 04:52: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 i6OBq4aV019895
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 04:52: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 693D27C0F3; Sat, 24 Jul 2004 14:48:18 +0200 (CEST)
To: "Eric Scheid" <eric.scheid@ironclad.net.au>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Propose partial consensus on dates
References: <BD26A8E1.21CAD%eric.scheid@ironclad.net.au>
Message-ID: <opsbm4q1fhuvpchu@quark>
Date: Sat, 24 Jul 2004 13:55:39 +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: <BD26A8E1.21CAD%eric.scheid@ironclad.net.au>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 23 Jul 2004 11:37:05 +1000, Eric Scheid  
<eric.scheid@ironclad.net.au> wrote:

> I agree with Roger B that we can't make "issued" required because the  
> vast unwashed masses don't have tools that support it in the sense of
> *first* published and this will simply result in a million blogs
> breaking the spec.

Transitionally, yes. This has been brought up on so many occasions now,  
that I need to ask: Is the current consensus that Atom should be backwards  
compatible with RSS and that no tools should change in order to conform to  
the Atom 1.0 specification?

> I don't see a huge problem in making "dateline" the one required date.

It's basically just an alternative, more subjective way to express  
'issued', so I see absolutely no reason to require it.

> This models very closely to how blogging tools currently work

Why is the current practice in the blogging world of such major  
significance, while current practice other (more professional) areas of  
minor or no interest? This doesn't model how the publishing industry  
currently work, and the model will be very difficult to implement outside  
the world of Movable Type and LiveJournal et al, because it doesn't make  
sense anywhere else.

> and I'd be surprised if the vaunted professional publishing tools don't
> have the capability for a dateline.

Some do, some don't.

-- 
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 Jul 24 08:35: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 IAA17214
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 08:35:13 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OCOtpm021548;
	Sat, 24 Jul 2004 05:24: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 i6OCOtHB021547;
	Sat, 24 Jul 2004 05:24:55 -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 i6OCOs5P021541
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 05:24:54 -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 i6OCPs5h028348;
	Sat, 24 Jul 2004 08:25:55 -0400
Message-ID: <410255C5.107@intertwingly.net>
Date: Sat, 24 Jul 2004 08:27:49 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Propose partial consensus on dates
References: <BD26A8E1.21CAD%eric.scheid@ironclad.net.au> <opsbm4q1fhuvpchu@quark>
In-Reply-To: <opsbm4q1fhuvpchu@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 Fri, 23 Jul 2004 11:37:05 +1000, Eric Scheid  
> <eric.scheid@ironclad.net.au> wrote:
> 
>> I agree with Roger B that we can't make "issued" required because the  
>> vast unwashed masses don't have tools that support it in the sense of
>> *first* published and this will simply result in a million blogs
>> breaking the spec.
> 
> Transitionally, yes. This has been brought up on so many occasions now,  
> that I need to ask: Is the current consensus that Atom should be 
> backwards  compatible with RSS and that no tools should change in order 
> to conform to  the Atom 1.0 specification?

The question about backwards compatibility with RSS is a red herring.

  - - -

RSS 0.91 had no item level date.

RSS 1.0 had something simply called "date" and if you follow the 
definition of this date, you find "Typically, Date will be associated 
with the creation or availability of the resource."

RSS 0.93 introduced a date named "pubDate", defined as "Its value is a 
date, indicating when the item will become available".  In 2.0, this 
changed to "indicating when the item was published. If it's a date in 
the future, aggregators may choose to not display the item until that date".

  - - -

At some point in this discussion, a myth was created that RSS dates were 
correspond to "dc:issued" ("dc:available" is a better match, IMHO), and 
that "dc:issued" is mutable.

The one thing that can be observed, based on experience with RSS, is 
that if a slot for a mutable date is not provided, people will use the 
slot provided anyway.

The charter says "The working group will use experience gained with 
RSS...".  We have experience with how people have misused RSS.  And we 
can observe the results: they blame the aggregators.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Sat Jul 24 08: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 IAA17757
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 08: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 i6OCaJ6R022224;
	Sat, 24 Jul 2004 05:36: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 i6OCaJ1L022223;
	Sat, 24 Jul 2004 05:36: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 i6OCaIX2022136
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 05:36:19 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 24 Jul 2004 22:41:20 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sat, 24 Jul 2004 22:35:38 +1000
Subject: Re: Propose partial consensus on dates
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD2894BA.2216A%eric.scheid@ironclad.net.au>
In-Reply-To: <opsbm4q1fhuvpchu@quark>
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 i6OCaJX2022218
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 24/7/04 9:55 PM, "Asbjørn Ulsberg" <asbjorn@tigerstaden.no> wrote:
> Transitionally, yes. This has been brought up on so many occasions now,
> that I need to ask: Is the current consensus that Atom should be backwards
> compatible with RSS and that no tools should change in order to conform to
> the Atom 1.0 specification?

The more change needed for adoption the slower the adoption will be. Both
'issued' and 'updated' will require changes to blogging tools. With
'updated', there will be an immediate payoff to implementing that change,
with aggregators being able to discern the changes of interest amongst the
noise of minor modifications.

The same *cannot* be said for 'issued'. For the major active constituency
for which atom is being developed for, they simply haven't recognised any
value or utility to know the first-published date. There would be no payoff
for the pain.

>> I don't see a huge problem in making "dateline" the one required date.
> 
> It's basically just an alternative, more subjective way to express
> 'issued', so I see absolutely no reason to require it.

My point is simple: it's better to have only one date be required rather
than a plethora, and if we have to choose just one I pick 'dateline',
because it will deliver the most bang for the buck for the most users who
are already in the community. Extra fields which will only be used by a
minority, no matter how much they jump up and down about the importance of
the BDS&M of their policies and procesures, should be optional as required.

e.




From owner-atom-syntax@mail.imc.org  Sat Jul 24 08:57:24 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17857
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 08:57:23 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OClIq6022660;
	Sat, 24 Jul 2004 05: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 i6OClIOx022659;
	Sat, 24 Jul 2004 05:47: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 i6OClHFD022647
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 05:47: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 AE7B07C11E; Sat, 24 Jul 2004 15:43:30 +0200 (CEST)
Date: Sat, 24 Jul 2004 14:51:04 +0200
To: "Greg Stein" <gstein@google.com>
Subject: Re: URI scheme delusions
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <200407221003.i6MA3WWG083339@above.proper.com> <905f7c91040722053278962348@mail.gmail.com> <0ED5D262-DC00-11D8-AC8C-000A95A51C9E@sun.com> <709AF709-DC18-11D8-AC8C-000A95A51C9E@sun.com> <905f7c9104072218534925b919@mail.gmail.com> <87bri6tvsd.fsf@nwalsh.com> <14be96d30407231212b9c81b4@mail.gmail.com> <7627EF82-DCE2-11D8-AFAD-000A95A51C9E@sun.com> <14be96d30407231525194c45b1@mail.gmail.com> <20040724010911.GB11643@google.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: <opsbm7ber2uvpchu@quark>
In-Reply-To: <20040724010911.GB11643@google.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 23 Jul 2004 18:09:11 -0700, Greg Stein <gstein@google.com> wrote:

> That URI is fixed and unchanging. It is JUST FINE as an identifier.

That exact URL is probably just fine, yes. But many other URL's are not.  
E.g.:

   http://home.example.com/~bob/blog/012231.html

Is _not_ a good «URL as ID». What can and will happen with such a URL is  
that this Bob Z will move to another location, and thus change the ID of  
his entries. What may also happen is that Bob X registers at example.com  
and receives the same account as Bob Z. Bob X can then publish entries  
with the exact same ID as Bob Z did. Then we're in a situation where:

   - The original 'http://home.example.com/~bob/blog/012231.html' entry
     is unretrievable, because it has changed location _and_ ID.

   - The new 'http://home.example.com/~bob/blog/012231.html' has nothing
     to do with the first one, and people retrieving it will be very
     confused.

   - If 'http://home.example.com/~bob/blog/012231.html' isn't ever
     overwritten by a new entry, it will still be impossible to force Bob
     X to always do an HTTP redirect Bob Z's entry location.

This is not an edge case. It is extremely common that people don't have  
their own domains to set up blogs on. And the URI they are expected to  
choose for their entry ID's is the one their blog resides on. And that  
blog both can and will move. That's when we have problems, by the single  
fact that URL's are expected to be _directly_ resolvable.

If we, however, have a URI scheme that isn't expected to be directly  
retrievable, we will mitigate or kill the scenarios where ID's are changed  
when entries move. If this scheme also contains good ways to create an ID  
that will stay unique over time, by e.g. containing the date of when the  
entry was published at that domain, it will mitigate or kill scenarios  
where ID's are reused by different authors.

> The fact that you can feed it into a HTTP client, have it run off and
> fetch content for you, and the fact that the content might change... has
> NOTHING to do with the fact that that URI is a constant.

People expect it to be. HTTP URI's is per def directly resolvable. It is  
impossible to change that perception. Also, not all Atom entries may be  
directly retrievable over HTTP, and thus will an HTTP URI scheme for ID's  
be very awkward for some publishers.

I don't mind people using URL's as identifiers when they know what they're  
doing (e.g. will never change the ID of their entries), and when they know  
that the URL's they create won't ever be reused if they somehow loose  
their domain in the future. But for everyone else, LSID's or tag URI's  
should be the recommended ID scheme.

-- 
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 Jul 24 09:04: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 JAA18113
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 09:04: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 i6OCqFOS022871;
	Sat, 24 Jul 2004 05:52: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 i6OCqFa4022870;
	Sat, 24 Jul 2004 05:52: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 i6OCqDn1022862
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 05:52:14 -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 F12B37C0F3; Sat, 24 Jul 2004 15:48:24 +0200 (CEST)
Date: Sat, 24 Jul 2004 14:55:54 +0200
To: "James M Snell" <jasnell@us.ibm.com>
Subject: Re: URI scheme delusions
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <OF031774D8.BEC98F6C-ON88256EDB.00084992-88256EDB.00090B2C@us.ibm.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: <opsbm7jgwuuvpchu@quark>
In-Reply-To: <OF031774D8.BEC98F6C-ON88256EDB.00084992-88256EDB.00090B2C@us.ibm.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 23 Jul 2004 19:38:47 -0600, James M Snell <jasnell@us.ibm.com>  
wrote:

> I personally feel that ID should be allowed to be ANY type of URI,
> independent of scheme.

+1. The recommended scheme should, however, be one that we are almost 100%  
certain won't make people want to change the ID's of their entries in the  
future, and that stays unique over time as well (e.g. isn't reused). The  
ID MUST be universally unique[1], no matter what scheme it is based on.

> It simply does not matter if you can DO anything with it, it just
> has to be unique.

+1.

____
[1] From <url: http://intertwingly.net/wiki/pie/AtomTerminology>: «An  
identifier that is unique across all time, by use of data/time in addition  
to any other global naming system or registration, in contrast to a  
globally unique identifier which is only known to be unique when it is  
created.»

-- 
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 Jul 24 09:10: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 JAA18517
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 09:10: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 i6OD0JaG023308;
	Sat, 24 Jul 2004 06:00: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 i6OD0JnV023307;
	Sat, 24 Jul 2004 06:00: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 i6OD0HZu023285
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 06:00: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 33C877C0F3; Sat, 24 Jul 2004 15:56:31 +0200 (CEST)
To: "Robert Sayre" <mint@franklinmint.fm>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Propose partial consensus on dates
References: <BD26F5B4.143F7%mint@franklinmint.fm>
Message-ID: <opsbm7w4sxuvpchu@quark>
Date: Sat, 24 Jul 2004 15:04:06 +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: <BD26F5B4.143F7%mint@franklinmint.fm>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 23 Jul 2004 17:04:52 -0400, Robert Sayre <mint@franklinmint.fm>  
wrote:

> My worry is that we're inventing this practice.

We are. 'updated' will, if it makes its way into Atom, be 100%  
Atom-specific.

> What's the precedent here?

In other areas and formats, superseding is the number one way to deal with  
this.

> Other formats seem to tackle this problem with changes to content  
> structure and/or distinct but related resources.

Yep. Of some reason I'm not familiar with, that is too complex for Atom to  
adopt, even if it is the most widespread solution to this problem. :-\

I'd be perfectly fine with an optional superseding mechanism. But Atom  
should not propose two alternative ways to signify major modifications.  
Therefore should Atom core only contain an 'modified' element that doesn't  
say anything about what the modification was, and a superseding extension  
to the core that allows for versioning.

If people want to ignore supersedings, they can, both on the consumer and  
producer side. If they want a way to separate minor from major changes,  
they must use the superseding mechanism, which is an extension to the  
core. Atom core will then have a required, immutable 'issued', and will  
not have 'updated'.

-- 
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 Jul 24 09:15: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 JAA18780
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 09:15: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 i6OD4UJo023427;
	Sat, 24 Jul 2004 06:04: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 i6OD4UZ3023426;
	Sat, 24 Jul 2004 06:04:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OD4TuG023419
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 06:04: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 8CD0B7C0F3; Sat, 24 Jul 2004 16:00:43 +0200 (CEST)
Date: Sat, 24 Jul 2004 15:08:19 +0200
To: "Janne Jalkanen" <Janne.Jalkanen@nokia.com>
Subject: Re: Propose partial consensus on dates
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <BD268E63.21B87%eric.scheid@ironclad.net.au> <4100F8AB.5010206@intertwingly.net> <410104BB.1050104@nokia.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: <opsbm735weuvpchu@quark>
In-Reply-To: <410104BB.1050104@nokia.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 23 Jul 2004 15:29:47 +0300, Janne Jalkanen  
<Janne.Jalkanen@nokia.com> wrote:

> A wiki would probably change the <modified> -date each time someone made  
> an edit, but the <updated> -date only if it was not marked as a "minor  
> edit", which is a very common wiki functionality.

Since most Wikis do versioning, I think it would be pretty bad not to  
reflect this in Atom. An extension to Atom core that allowed for  
superseding would easilly fix this.

Eric Scheid's proposal of having feeds of revisions is also a great way to  
follow up on changes on one particular Wiki page. That would also make it  
easy to revert changes whenever spam or such occurs, because the revision  
feed would contain all changes to the Wiki page.

> /Janne, who goes now off to holidays :-D

See you in Helsinki in a couple of weeks, hopefully! :-)

-- 
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 Jul 24 09: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 JAA19338
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 09: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 i6ODGJaN024706;
	Sat, 24 Jul 2004 06: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 i6ODGIb0024701;
	Sat, 24 Jul 2004 06:16: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 i6ODGH2E024680
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 06:16: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 7BF8A7C0F3; Sat, 24 Jul 2004 16:12:31 +0200 (CEST)
Date: Sat, 24 Jul 2004 15:20:11 +0200
To: "Sam Ruby" <rubys@intertwingly.net>
Subject: Re: Propose partial consensus on dates
Cc: Atom-Syntax <atom-syntax@imc.org>, Graham <dtcd@mac.com>
References: <20040721220041.95499.qmail@web41210.mail.yahoo.com> <opsbieyottuvpchu@quark> <987794AA-DB88-11D8-B3AB-000A95DC3D90@mac.com> <opsbi3j6lzkdsr4o@quark> <40FFB6EA.7010601@intertwingly.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: <opsbm8nxk4uvpchu@quark>
In-Reply-To: <40FFB6EA.7010601@intertwingly.net>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Thu, 22 Jul 2004 08:45:30 -0400, Sam Ruby <rubys@intertwingly.net>  
wrote:

> The W3C is professional.  They don't revise specifications in place.  
> Instead, they issue new ones that supercede old ones.

Yes. Just a note; W3C is not at all alone in performing this practice.

> Imposing that level of professionalism on all casual usages of blogs,  
> however, is inappropriate.

We wouldn't. A supersede mechanism would be highly optional. It would  
probably best fit in an extension to the core. But if Atom wants to  
provide a way for publishers to separate minor from major modifications, I  
feel that the current practice in other (more professional) publishing  
areas should be adopted, instead of creating a new mechanism unique for  
Atom.

I (and the publishing industry) could probably live with an 'updated'  
element that signify major modifications. I think, however, that this  
should be plucked out of the core and put into an extension, and that the  
extension should be a bit more advanced to also be usable for more  
advanced use cases like Wiki's, revision supportive publishing tools, etc.

What's important to me (and much of the publishing industry I've spoken  
with), is that 'issued' never change. In practice, it will be  
'first-issued', and if we need to call the element 'first-issued' to do  
that, that's fine. That will, however, be of no real use since each entry,  
in my model, can only be issued once.

If you want to re-issue an entry, you supersede it with another. And the  
mechanism for that practice would be defined in an extension to the core.

> Graham doesn't want to outlaw updating in place, he merely wants to be  
> able to deal with it.

I'm not sure what «deal with it» means. I haven't seen a solid use case  
for when modification of 'issued' is useful, either. I know that the  
current practice in the blogging community is that the one date associated  
with an entry can be changed whenever the author feels like it, but I  
thought we had come to agreement that this date isn't 'issued'. Infact, it  
is 'created', 'modified', 'issued' and 'dateline' at 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  Sat Jul 24 09:29: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 JAA19360
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 09:29: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 i6ODI9nh025077;
	Sat, 24 Jul 2004 06: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 i6ODI9F6025076;
	Sat, 24 Jul 2004 06:18: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 i6ODI8uR025070
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 06:18: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 i6ODJ9Nt031037;
	Sat, 24 Jul 2004 09:19:09 -0400
Message-ID: <41026240.8020009@intertwingly.net>
Date: Sat, 24 Jul 2004 09:21:04 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: URI scheme delusions
References: <OF031774D8.BEC98F6C-ON88256EDB.00084992-88256EDB.00090B2C@us.ibm.com> <opsbm7jgwuuvpchu@quark>
In-Reply-To: <opsbm7jgwuuvpchu@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 Fri, 23 Jul 2004 19:38:47 -0600, James M Snell <jasnell@us.ibm.com>  
> wrote:
> 
>> I personally feel that ID should be allowed to be ANY type of URI,
>> independent of scheme.
> 
> +1. The recommended scheme should, however, be one that we are almost 
> 100%  certain won't make people want to change the ID's of their entries 
> in the  future, and that stays unique over time as well (e.g. isn't 
> reused). The  ID MUST be universally unique[1], no matter what scheme it 
> is based on.
> 
>> It simply does not matter if you can DO anything with it, it just
>> has to be unique.
>
> +1.

I agree with this, except for the word "The" in front of the word 
"recommended" above.

My belief is that if, and only if, you own your own domain name, then 
making the id match the permalink is a good idea.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Sat Jul 24 09: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 JAA19450
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 09:32:04 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ODKVoj025202;
	Sat, 24 Jul 2004 06:20:31 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6ODKVAx025201;
	Sat, 24 Jul 2004 06:20: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 i6ODKUk2025193
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 06:20: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 430117C0F3; Sat, 24 Jul 2004 16:16:44 +0200 (CEST)
Date: Sat, 24 Jul 2004 15:24:24 +0200
To: "Dare Obasanjo" <kpako@yahoo.com>
Subject: Re: Propose partial consensus on dates
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <20040722144616.30739.qmail@web41208.mail.yahoo.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: <opsbm8uyfxuvpchu@quark>
In-Reply-To: <20040722144616.30739.qmail@web41208.mail.yahoo.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Thu, 22 Jul 2004 07:46:16 -0700 (PDT), Dare Obasanjo <kpako@yahoo.com>  
wrote:

> I love the ambiguity of this stuff. What the heck is a major update?

Whatever makes the author think that the user should read the entry again.  
E.g. not a typo-fix, but pretty much everything else.

> So you're saying that users will see the same post twice in their
> aggregator but that's OK because a 'major' update has been done but
> there is no way to explain to users what exactly is meant by 'major
> update'.

There is a way. It is called «superseding». But if your aggregator doesn't  
support the superseding mechanism, then it will appear as a new entry. Can  
you tell me how RSS Bandit deals with modifications to an entry today,  
when most entries don't even have ID'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  Sat Jul 24 09:39: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 JAA19724
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 09: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 i6ODQF8T025480;
	Sat, 24 Jul 2004 06:26: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 i6ODQFic025479;
	Sat, 24 Jul 2004 06:26: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 i6ODQEV6025471
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 06:26: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 595EA7C0F3; Sat, 24 Jul 2004 16:22:28 +0200 (CEST)
To: "Ken MacLeod" <ken@bitsko.slc.ut.us>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Propose partial consensus on dates
References: <200407212101.i6LL19i4029123@above.proper.com> <m3acxs9fxs.fsf@bitsko.slc.ut.us>
Message-ID: <opsbm84ksxuvpchu@quark>
Date: Sat, 24 Jul 2004 15:30:10 +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: <m3acxs9fxs.fsf@bitsko.slc.ut.us>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 22 Jul 2004 11:15:11 -0500, Ken MacLeod <ken@bitsko.slc.ut.us> wrote:

> For the sake of discussion, what happens if concensus is not to adopt
> this view (model) in the core.  What would it look like for this model
> (view) to be mapped into or layered over the Atom model?

A superseding mechanism _should_ probably be placed outside the core.  
What's important then, imho, is that the core doesn't have a mechanism  
that «competes» with this extension. E.g. drop «updated» and make «issued»  
immutable.

> In the [current] Atom model, the resource being identified is the one
> that "has multiple versions".  It's not [currently] specified whether
> atom:issued date is the "re-issued" of the most recent version or
> "first issued" of the multiple versions.

True.

> We could relax the restriction that atom:entry/atom:id be unique by
> saying that they *are* in fact the same entry, but different versions
> (with the version identifier in an extension), and clients should use
> the last-modified entry.  Clients can ignore missing versions because,
> as in practice today, they don't need them as long as the
> atom:entry/atom:id is the same as any previous version.

I'm sorry, but I don't follow. How would this work for an immutable  
'issued'?

> We could also specify that atom:issued is the date of the version, and
> the "first issued" date can either be in an extensions or tracking
> down the first published version of the "resource that has many
> versions".
>
> Would that work?

Hm, not really. The most important date for the publishing industry is  
'first-issued'. If Atom core doesn't support a required 'first-issued' or  
an immutable 'issued' (whatever the element is called), an extension that  
supports it will be of no particular interest.

-- 
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 Jul 24 09:45:58 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19934
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 09:45:57 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ODVpRD025671;
	Sat, 24 Jul 2004 06:31: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 i6ODVptI025670;
	Sat, 24 Jul 2004 06:31: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 i6ODVnsU025662
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 06:31: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 7D7D67C0F3; Sat, 24 Jul 2004 16:28:03 +0200 (CEST)
To: Graham <dtcd@mac.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Propose partial consensus on dates
References: <20040721220041.95499.qmail@web41210.mail.yahoo.com> <opsbieyottuvpchu@quark> <987794AA-DB88-11D8-B3AB-000A95DC3D90@mac.com> <opsbi3j6lzkdsr4o@quark> <BBC082CE-DBFC-11D8-B3AB-000A95DC3D90@mac.com>
Message-ID: <opsbm9dvfxuvpchu@quark>
Date: Sat, 24 Jul 2004 15:35:45 +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: <BBC082CE-DBFC-11D8-B3AB-000A95DC3D90@mac.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Thu, 22 Jul 2004 12:32:33 -0400, Graham <dtcd@mac.com> wrote:

> It doesn't matter if the EU, the MFI and the Moonies organize their  
> documents that way.

Why not?

> RSS doesn't.

So? Is it a goal that Atom 1.0 is 100% backwards compatible with RSS?

> Atom 0.3 doesn't.

Atom 0.3 is bound to change in many other areas than this, so that doesn't  
matter either.

> They don't have a <supercedes> element, and no aggregator supports one.

No aggregator needs to, either. A supersede mechanism would be optional.  
What's important is that we don't put a half-way supersede mechanism in  
the core that competes with a more «correct» and advanced supersede  
mechanism.

>> This is about realising that a «major update» of an entry isn't really  
>> an update of that particular entry, but a brand new one.
>
> If you say so, Asjborn.

I don't say so. Who says so, is the publishing industry, and everyone else  
that publishes stuff that are a bit more professional than a personal  
weblog. And I hope that Atom, in the end, can cater for those needs as  
well as the personal weblog author'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  Sat Jul 24 09:52: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 JAA20158
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 09: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 i6ODexOV026583;
	Sat, 24 Jul 2004 06:40: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 i6ODexjO026582;
	Sat, 24 Jul 2004 06:40:59 -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 i6ODewFV026575
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 06:40:58 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 50096 messnum 6514433 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 24 Jul 2004 13:40:54 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail12.svc.cra.dublin.eircom.net (qp 50096) with SMTP; 24 Jul 2004 13:40:54 -0000
Message-ID: <410266E4.6040304@dehora.net>
Date: Sat, 24 Jul 2004 14:40:52 +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: Sam Ruby <rubys@intertwingly.net>
CC: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>,
        Atom-Syntax <atom-syntax@imc.org>
Subject: Re: URI scheme delusions
References: <OF031774D8.BEC98F6C-ON88256EDB.00084992-88256EDB.00090B2C@us.ibm.com> <opsbm7jgwuuvpchu@quark> <41026240.8020009@intertwingly.net>
In-Reply-To: <41026240.8020009@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: <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


Sam Ruby wrote:

> 
> Asbjørn Ulsberg wrote:
>
>>
>> +1. The recommended scheme should, however, be one that we are almost 
>> 100%  certain won't make people want to change the ID's of their 
>> entries in the  future, and that stays unique over time as well (e.g. 
>> isn't reused). The  ID MUST be universally unique[1], no matter what 
>> scheme it is based on.
>>
>>> It simply does not matter if you can DO anything with it, it just
>>> has to be unique.
>>
>>
>> +1.
> 
> 
> I agree with this, except for the word "The" in front of the word 
> "recommended" above.
> 
> My belief is that if, and only if, you own your own domain name, then 
> making the id match the permalink is a good idea.

And I agree with that except for the word "own" - "lease" is more 
accurate wrt such issues.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Sat Jul 24 09:55: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 JAA20208
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 09:55: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 i6ODhmuI026690;
	Sat, 24 Jul 2004 06:43: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 i6ODhmYH026684;
	Sat, 24 Jul 2004 06:43: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 i6ODhlaL026672
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 06:43: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 E305D7C0F3; Sat, 24 Jul 2004 16:40:00 +0200 (CEST)
Date: Sat, 24 Jul 2004 15:47:45 +0200
To: "Dare Obasanjo" <kpako@yahoo.com>
Subject: Re: Propose partial consensus on dates
References: <20040722172547.46805.qmail@web41209.mail.yahoo.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
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: <opsbm9xve1uvpchu@quark>
In-Reply-To: <20040722172547.46805.qmail@web41209.mail.yahoo.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Thu, 22 Jul 2004 10:25:47 -0700 (PDT), Dare Obasanjo <kpako@yahoo.com>  
wrote:

> By the way I dispute that the W3C supercedes documents.

That's okay, but I disagree with you. Whatever you place in the word  
«supersede»; what W3C does, is to replace an older specification with a  
new one. And this practice is commonly known as «superseding». W3C even  
uses the word «supersede» themselves: «Other documents may supersede this  
document»[1].

> A spec has two URIs, the URI that identifies a version of a technology
> (e.g. http://www.w3.org/TR/REC-xml) and one that identifies the actual
> iteration of that document (e.g.  
> http://www.w3.org/TR/2004/REC-xml-20040204).

These URI's are orthogonal. The problem with Atom is that the current view  
is only to cater for the first of those URI's you mention. Each version of  
an entry doesn't need to be represented in HTML. The HTML document can be  
the latest version at all times, while the older versions of it can be  
retrievable as Atom entries, represented through a superseding mechanism.

> If I only go to the main URI for a W3C document then to me the changes
> happened in place.

Yes, but that is how it appears to you, as a reader. What actually  
happened «under the table», is that each newer version of a specification  
superseded an older one. This is very common practice, not only in W3C.

____
[1] The first paragraph in the section «Status of this document» in <url:  
http://www.w3.org/TR/html40/>.

-- 
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 Jul 24 10:09: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 KAA21025
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 10:09: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 i6ODwl0Y027351;
	Sat, 24 Jul 2004 06:58: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 i6ODwl7K027350;
	Sat, 24 Jul 2004 06:58:47 -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 i6ODwkUd027343
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 06:58:46 -0700 (PDT)
	(envelope-from davep@dpawson.co.uk)
Received: (qmail 23880 invoked from network); 24 Jul 2004 14:20:33 -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 Jul 2004 14:20:33 -0000
Subject: Re: Propose partial consensus on dates
From: Dave Pawson <davep@dpawson.co.uk>
Reply-To: davep@dpawson.co.uk
To: Atom syntax <atom-syntax@imc.org>
In-Reply-To: <opsbm9dvfxuvpchu@quark>
References: <20040721220041.95499.qmail@web41210.mail.yahoo.com>
	 <opsbieyottuvpchu@quark> <987794AA-DB88-11D8-B3AB-000A95DC3D90@mac.com>
	 <opsbi3j6lzkdsr4o@quark> <BBC082CE-DBFC-11D8-B3AB-000A95DC3D90@mac.com>
	 <opsbm9dvfxuvpchu@quark>
Content-Type: text/plain; charset=
Message-Id: <1090677528.2037.85.camel@homer>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) 
Date: Sat, 24 Jul 2004 14:58:48 +0100
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


On Sat, 2004-07-24 at 14:35, AsbjÞrn Ulsberg wrote:

> >> This is about realising that a «major update» of an entry isn't really  
> >> an update of that particular entry, but a brand new one.
> >
> > If you say so, Asjborn.
> 
> I don't say so. Who says so, is the publishing industry, and everyone else  
> that publishes stuff that are a bit more professional than a personal  
> weblog. And I hope that Atom, in the end, can cater for those needs as  
> well as the personal weblog author's.

>From which, logically, a major update to a book creates a new title?
No.


Regards DaveP.
XSLT&Docbook  FAQ
http://www.dpawson.co.uk/xsl




From owner-atom-syntax@mail.imc.org  Sat Jul 24 10:34: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 KAA23096
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 10:34: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 i6OEN2bm028471;
	Sat, 24 Jul 2004 07:23: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 i6OEN27B028470;
	Sat, 24 Jul 2004 07:23: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 i6OEN0Pn028464
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 07:23: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 BA70C7C0F3; Sat, 24 Jul 2004 17:19:12 +0200 (CEST)
To: "Arve Bersvendsen" <arve@virtuelvis.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Date Options Survey
References: <200407240806.i6O86JUa063201@above.proper.com>
Message-ID: <opsbnbrcqruvpchu@quark>
Date: Sat, 24 Jul 2004 16:27:02 +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: <200407240806.i6O86JUa063201@above.proper.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 24 Jul 2004 10:06:14 +0200, Arve Bersvendsen <arve@virtuelvis.com>  
wrote:

> Ok, to be clear: I have answered the survey with MY understanding of one
> specific date: issued.
>
> My specific understanding is: "issued" == "first-issued" == does not  
> change, even if the entry changes. A date that essentially would be a
> timestamp for when an entry's state was set to "publish".  I am +1R on
> that.

This is my understanding as well, so +2R on that one from me.

> Another understanding of "issued" is what Movable Type thinks the  
> "issued" date is now: The user-changable date that is attached to an  
> entry.
> In  Movable Type, this date is always equal to "created".  I am, at the
> very least, a -1 on that.

I'm -2 on it. I would actually rather not have an 'issued' at all, than  
having the issued Movable Type currently employs.

-- 
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 Jul 24 10:41: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 KAA23433
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 10:41: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 i6OEVow0028834;
	Sat, 24 Jul 2004 07:31:50 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6OEVok5028833;
	Sat, 24 Jul 2004 07:31:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OEVnfu028826
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 07:31: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 1125D7C0F3; Sat, 24 Jul 2004 17:28:03 +0200 (CEST)
To: "Roger B." <roger@agincourtmedia.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Date Options Analysis: Issued
References: <8897C0DC42844B8A518EAF30843.MAI@journurl.com>
Message-ID: <opsbnb58bkuvpchu@quark>
Date: Sat, 24 Jul 2004 16:35:58 +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: <8897C0DC42844B8A518EAF30843.MAI@journurl.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 24 Jul 2004 04:22:14 -0500, Roger B. <roger@agincourtmedia.com>  
wrote:

> When I put a potentially dynamic date in that element, how will you know?

No one but you will, but then; you're abusing the element. That's like  
using <table> for layout in HTML today. Machines will (or at least should)  
expect that you put tabular data in it (because that's what W3C says it  
should contain), but the data you have in it isn't tabular. Hence, you're  
abusing the <table> element.

> How will Sam and Mark validate the nature of my dates?

There is oceans of things the validator can't spot. How can the HTML  
validator spot abuse of the <table> element, or the <h1> element for that  
matter? «The data inside <table> is not tabular!» or «The text inside the  
<h1> tag is not a heading!» is very unlikely to ever be seen, because it  
is impossible to spot by a program.

> In concrete, user-facing terms, how will your publishing app break  
> if/when
> one of my dates changes?

No other publishing application will know about your dates other than your  
own. I don't understand this scenario.

> In concrete, user-facing terms, how will your aggregator break if/when  
> one of my dates changes?

Firstly, the context of when you first wrote and published the entry will  
be unknown. Secondly, any order of the entries on the assumption that  
'issued' equals 'first-issued' will break.

-- 
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 Jul 24 10:46:52 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23760
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 10:46: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 i6OEZIfI029915;
	Sat, 24 Jul 2004 07:35: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 i6OEZIY1029914;
	Sat, 24 Jul 2004 07:35: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 i6OEZH55029907
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 07:35:18 -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 i6OEaJNf002668
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 10:36:19 -0400
Message-ID: <41027456.5040109@intertwingly.net>
Date: Sat, 24 Jul 2004 10:38:14 -0400
From: Sam Ruby <rubys@intertwingly.net>
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@imc.org
Subject: PaceDateline
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


http://www.intertwingly.net/wiki/pie/PaceDateline

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Sat Jul 24 10:47: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 KAA23794
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 10:47: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 i6OEXaEa029270;
	Sat, 24 Jul 2004 07:33: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 i6OEXaqC029269;
	Sat, 24 Jul 2004 07:33:36 -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 i6OEXZDC029260
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 07:33:35 -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 1B5977C0F3; Sat, 24 Jul 2004 17:29:49 +0200 (CEST)
To: "Roger B." <roger@agincourtmedia.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Date Options Analysis: Issued
References: <83E29738DFB84F29AE4652D298591.MAI@journurl.com>
Message-ID: <opsbnb86y0uvpchu@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, 24 Jul 2004 16:37:44 +0200
In-Reply-To: <83E29738DFB84F29AE4652D298591.MAI@journurl.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 24 Jul 2004 05:53:17 -0500, Roger B. <roger@agincourtmedia.com>  
wrote:

> So what are the real-world repercussions of using a dynamic date?

Since I've answered your questions regarding this, what is the solid use  
case for ever changing 'issued'?

-- 
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 Jul 24 10:59:31 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24308
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 10:59: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 i6OElEns031615;
	Sat, 24 Jul 2004 07:47: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 i6OElEU6031614;
	Sat, 24 Jul 2004 07:47:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OElAJm031606
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 07:47:12 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 25 Jul 2004 00:52:50 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sun, 25 Jul 2004 00:47:09 +1000
Subject: Re: Date Options Analysis: Issued
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD28B38D.22253%eric.scheid@ironclad.net.au>
In-Reply-To: <opsbnb58bkuvpchu@quark>
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 i6OElEJm031609
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 25/7/04 12:35 AM, "Asbjørn Ulsberg" <asbjorn@tigerstaden.no> wrote:

> 
>> In concrete, user-facing terms, how will your publishing app break
>> if/when
>> one of my dates changes?
> 
> No other publishing application will know about your dates other than your
> own. I don't understand this scenario.

I think Roger is referring to a situation not unlike the following:

09:00 - your publishing application retrieves the feed,
        finds an entry id=#1 with 'issued'=2004-07-24T08:00Z
09:30 - some edits are made, new entries created, etc
10:00 - your publishing application again retrieves the feed
        finds an entry id=#1 with 'issued'=2004-07-24T08:00Z
10:01 - techs run screaming as the publishing application
        erupts in a fiery blaze of sparks?

e.




From owner-atom-syntax@mail.imc.org  Sat Jul 24 11:05: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 LAA24569
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 11:05: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 i6OEiTQu030631;
	Sat, 24 Jul 2004 07:44:29 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6OEiT4Q030630;
	Sat, 24 Jul 2004 07:44:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from dumle.webhuset.no (dumle.webhuset.no [81.27.32.66])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6OEiSrF030598
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 07:44:29 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Message-Id: <200407241444.i6OEiSrF030598@above.proper.com>
Received: (qmail 13963 invoked from network); 24 Jul 2004 14:42:48 -0000
Received: from unknown (HELO localhost.localdomain) (81.27.34.17)
  by 0 with SMTP; 24 Jul 2004 14:42:48 -0000
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
MIME-Version: 1.0
From: "Arve Bersvendsen" <arve@virtuelvis.com>
To: davep@dpawson.co.uk, atom-syntax@imc.org
Subject: Re: Propose partial consensus on dates
Date: Sat, 24 Jul 2004 16:44:24 +0200
X-Mailer: WHMail 1.0 (http://www.webhuset.no)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6OEiTrF030625
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


* Dave Pawson

>> From which, logically, a major update to a book creates a new title?
> No.

Regardless of what happens to the title:
<URL:http://www.imc.org/atom-syntax/mail-archive/msg06782.html>

-- 
Arve



From owner-atom-syntax@mail.imc.org  Sat Jul 24 11: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 LAA24673
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 11: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 i6OEtupg032190;
	Sat, 24 Jul 2004 07: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 i6OEtunN032189;
	Sat, 24 Jul 2004 07:55: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] (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 i6OEtsEJ032182
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 07:55:55 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p0611041fbd282844015a@[10.20.30.249]>
In-Reply-To: <410266E4.6040304@dehora.net>
References: 
 <OF031774D8.BEC98F6C-ON88256EDB.00084992-88256EDB.00090B2C@us.ibm.com>
 <opsbm7jgwuuvpchu@quark> <41026240.8020009@intertwingly.net>
 <410266E4.6040304@dehora.net>
Date: Sat, 24 Jul 2004 07:55:56 -0700
To: Atom WG <atom-syntax@imc.org>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: URI scheme delusions
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


At 2:40 PM +0100 7/24/04, Bill de hÓra wrote:
>Sam Ruby wrote:
>
>>
>>Asbjørn Ulsberg wrote:
>>
>>>
>>>+1. The recommended scheme should, however, be one that we are 
>>>almost 100%  certain won't make people want to change the ID's of 
>>>their entries in the  future, and that stays unique over time as 
>>>well (e.g. isn't reused). The  ID MUST be universally unique[1], 
>>>no matter what scheme it is based on.
>>>
>>>>It simply does not matter if you can DO anything with it, it just
>>>>has to be unique.
>>>
>>>
>>>+1.
>>
>>
>>I agree with this, except for the word "The" in front of the word 
>>"recommended" above.
>>
>>My belief is that if, and only if, you own your own domain name, 
>>then making the id match the permalink is a good idea.
>
>And I agree with that except for the word "own" - "lease" is more 
>accurate wrt such issues.

And I agree with that chain of agrees. (Does that make it a +4?)

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Sat Jul 24 11:18: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 LAA25094
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 11:18: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 i6OF20Yw032891;
	Sat, 24 Jul 2004 08:02: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 i6OF20B0032890;
	Sat, 24 Jul 2004 08:02:00 -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 i6OF1xbW032878
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 08:01: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 B87AD7C0F3; Sat, 24 Jul 2004 17:58:12 +0200 (CEST)
Date: Sat, 24 Jul 2004 17:06:13 +0200
To: "Sam Ruby" <rubys@intertwingly.net>
Subject: Re: PaceDateline
References: <41027456.5040109@intertwingly.net>
Cc: Atom-Syntax <atom-syntax@imc.org>
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: <opsbndknqruvpchu@quark>
In-Reply-To: <41027456.5040109@intertwingly.net>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 24 Jul 2004 10:38:14 -0400, Sam Ruby <rubys@intertwingly.net>  
wrote:

> http://www.intertwingly.net/wiki/pie/PaceDateline

I'm +1 on the 'dateline' element itself, but very -1 on that this element  
should replace 'modified', 'issued' and 'created'. Hence -1 on the pace.

Btw, what format should 'dateline' have? An arbitrary string?

-- 
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 Jul 24 11:21: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 LAA25169
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 11:21: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 i6OFBLAe034369;
	Sat, 24 Jul 2004 08: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 i6OFBLQe034368;
	Sat, 24 Jul 2004 08:11: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 i6OFBJ9I034361
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 08:11:20 -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 i6OFCLq4004428;
	Sat, 24 Jul 2004 11:12:22 -0400
Message-ID: <41027CC9.5060202@intertwingly.net>
Date: Sat, 24 Jul 2004 11:14:17 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceDateline
References: <41027456.5040109@intertwingly.net> <opsbndknqruvpchu@quark>
In-Reply-To: <opsbndknqruvpchu@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, 24 Jul 2004 10:38:14 -0400, Sam Ruby <rubys@intertwingly.net>  
> wrote:
> 
>> http://www.intertwingly.net/wiki/pie/PaceDateline
> 
> I'm +1 on the 'dateline' element itself, but very -1 on that this 
> element  should replace 'modified', 'issued' and 'created'. Hence -1 on 
> the pace.
> 
> Btw, what format should 'dateline' have? An arbitrary string?

Please read the entire Pace, it is not that long.

modified, issued, and created are still present, and default to the 
specified dateline.

The presumption is that dateline will be defined as a profile of ISO 8601.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Sat Jul 24 11:23: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 LAA25350
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 11:23: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 i6OFD3o6034470;
	Sat, 24 Jul 2004 08: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 i6OFD33k034469;
	Sat, 24 Jul 2004 08:13:03 -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 i6OFD2Dg034460
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 08:13:02 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 25 Jul 2004 01:18:42 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sun, 25 Jul 2004 01:13:01 +1000
Subject: Re: Date Options Analysis: Issued
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD28B99D.22262%eric.scheid@ironclad.net.au>
In-Reply-To: <opsbnb86y0uvpchu@quark>
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 i6OFD3Dg034463
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 25/7/04 12:37 AM, "Asbjørn Ulsberg" <asbjorn@tigerstaden.no> wrote:

> what is [a] solid use case for ever changing 'issued'?

my computer clock is wrong and has been publishing everything with the year
1901. whoops. I fix it, fix the data, and republish.

e.




From owner-atom-syntax@mail.imc.org  Sat Jul 24 11:24: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 LAA25393
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 11:24: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 i6OFF0Wg034657;
	Sat, 24 Jul 2004 08:15: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 i6OFF0YS034656;
	Sat, 24 Jul 2004 08:15:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OFEv7v034647
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 08:15:00 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 25 Jul 2004 01:20:37 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sun, 25 Jul 2004 01:14:56 +1000
Subject: Re: Date Options Analysis: Issued
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD28BA10.22265%eric.scheid@ironclad.net.au>
In-Reply-To: <opsbnb58bkuvpchu@quark>
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



oops! sloppy copy/paste.

this one has the entry retrieved at 10:00 with a different 'issued' value.


>> In concrete, user-facing terms, how will your publishing app break
>> if/when
>> one of my dates changes?
> 
> No other publishing application will know about your dates other than your
> own. I don't understand this scenario.

I think Roger is referring to a situation not unlike the following:

09:00 - your publishing application retrieves the feed,
        finds an entry id=#1 with 'issued'=2004-07-24T08:00Z
09:30 - some edits are made, new entries created, etc
10:00 - your publishing application again retrieves the feed
        finds an entry id=#1 with 'issued'=2004-07-24T08:15Z
10:01 - techs run screaming as the publishing application
        erupts in a fiery blaze of sparks?

e.



From owner-atom-syntax@mail.imc.org  Sat Jul 24 11: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 LAA25601
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 11: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 i6OFFLtN034700;
	Sat, 24 Jul 2004 08:15:21 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6OFFLKU034698;
	Sat, 24 Jul 2004 08:15:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OFFJCg034687
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 08:15:20 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 25 Jul 2004 01:20:56 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sun, 25 Jul 2004 01:11:12 +1000
Subject: Re: URI scheme delusions
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD28B930.22260%eric.scheid@ironclad.net.au>
In-Reply-To: <41026240.8020009@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: <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 24/7/04 11:21 PM, "Sam Ruby" <rubys@intertwingly.net> wrote:

> My belief is that if, and only if, you own your own domain name, then
> making the id match the permalink is a good idea.

assuming they're wise enough to avoid having the URL polluted with
implementation specific bits, like ".php" or "blog.cgi?..." and such.

e.



From owner-atom-syntax@mail.imc.org  Sat Jul 24 11: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 LAA26523
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 11: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 i6OFZGLg035803;
	Sat, 24 Jul 2004 08:35: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 i6OFZG38035802;
	Sat, 24 Jul 2004 08:35:16 -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 i6OFZEAh035794
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 08:35: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 (rwcrmhc13) with SMTP
          id <2004072415351001500iq5gme>; Sat, 24 Jul 2004 15:35:10 +0000
Date: Sat, 24 Jul 2004 09:35:09 -0600
Subject: Re: Propose partial consensus on dates
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: <BD2894BA.2216A%eric.scheid@ironclad.net.au>
Message-Id: <0BC52492-DD87-11D8-9941-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, July 24, 2004, at 06:35  AM, Eric Scheid wrote:
> Both
> 'issued' and 'updated' will require changes to blogging tools. With
> 'updated', there will be an immediate payoff to implementing that 
> change,
> with aggregators being able to discern the changes of interest amongst 
> the
> noise of minor modifications.
>
> The same *cannot* be said for 'issued'. For the major active 
> constituency
> for which atom is being developed for, they simply haven't recognised 
> any
> value or utility to know the first-published date. There would be no 
> payoff
> for the pain.
>
Given that the major active constituency for which Atom is being 
developed has never had the option of having both an issued date and an 
updated date, I don't know that we can make definitive statements about 
how useful they'll (we'll) find the one versus the other. In my first 
pass at Date Options Survey, I said "0" for Issued, but then I got 
thinking about how I'd used Updated, and changed to +1.  Here's my 
thinking:

Some users will want to see each entry only once, whether it gets 
Updated or not.  Other users will want to see it again every time it's 
Updated.  Each is likely to want the date ordering to be based on the 
date that interests them.  The reason for the person wanting to see 
Updates wanting to sort by Updated is obvious enough--to them, an 
update is new news.  But a person who only wants to see it once is 
likely to consider it new news only as of the time it was first issued. 
  Thus, knowing when it was first issued is important for their sorting 
order.

A concrete example: Let's say I'm syndicating somebody else's newsfeed 
on my website. On Monday, shocking revelations come out about 
government corruption, and a story about it appears in the feed.  It 
gets displayed on my site.  On Wednesday, the publisher notices a 
significant factual error and fixes it.  They bump the Updated date to 
bring it to the top of the feed for people who care about updates.  
That's the right thing to do, but that doesn't make the news story 
fresh.  It's two days old, and I'd rather have my site showing the 
fresh news story about how the stock market is crashing today.  As an 
individual reader, I may have the same preference.  I've been away from 
my feed reader for 3 days.  I've already heard the government 
corruption story from five different sources, so I don't need it to 
come to the top.  It's still a new Entry for me, since I've been away 
from the feed reader, but it's not fresh news, so I want it to fall to 
the bottom of the list.



From owner-atom-syntax@mail.imc.org  Sat Jul 24 12:03: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 MAA26927
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 12:03:05 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OFspa4037121;
	Sat, 24 Jul 2004 08:54: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 i6OFspqk037120;
	Sat, 24 Jul 2004 08:54: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 (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OFsoAd037112
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 08:54: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 D659E7C0F3; Sat, 24 Jul 2004 18:50:53 +0200 (CEST)
Date: Sat, 24 Jul 2004 17:59:05 +0200
To: "Eric Scheid" <eric.scheid@ironclad.net.au>
Subject: Re: URI scheme delusions
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <BD28B930.22260%eric.scheid@ironclad.net.au>
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: <opsbnf0rq7uvpchu@quark>
In-Reply-To: <BD28B930.22260%eric.scheid@ironclad.net.au>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 25 Jul 2004 01:11:12 +1000, Eric Scheid  
<eric.scheid@ironclad.net.au> wrote:

>> My belief is that if, and only if, you own your own domain name, then
>> making the id match the permalink is a good idea.
>
> assuming they're wise enough to avoid having the URL polluted with
> implementation specific bits, like ".php" or "blog.cgi?..." and such.

It wouldn't hurt if the specification gave some examples to how such ID's  
could look like, and not leave everything up to both interpretation and  
implementation, as I feel it does for too many issues, now.

Many other specifications are springled with examples. The Atom format  
specification has _one_. Even though this format is a simple one, and  
unarguably simpler than e.g. HTML, I see no reason to not have more  
examples in it.

Would it be too much to require, that future (and existing) paces should  
have at least one example in them, which will be included as a  
non-normative example in the 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  Sat Jul 24 12:03:56 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26969
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 12:03:56 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OFqbqq036987;
	Sat, 24 Jul 2004 08: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 i6OFqbLH036986;
	Sat, 24 Jul 2004 08:52:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.192])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OFqatt036975
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 08:52:36 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id 74so41553rnl
        for <atom-syntax@imc.org>; Sat, 24 Jul 2004 08:52:39 -0700 (PDT)
Received: by 10.38.207.22 with SMTP id e22mr69087rng;
        Sat, 24 Jul 2004 08:52:39 -0700 (PDT)
Message-ID: <14be96d304072408524788c699@mail.gmail.com>
Date: Sat, 24 Jul 2004 11:52:39 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: "Bill de hÓra" <bill@dehora.net>
Subject: Re: URI scheme delusions
Cc: Sam Ruby <rubys@intertwingly.net>, Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <410266E4.6040304@dehora.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
References: <OF031774D8.BEC98F6C-ON88256EDB.00084992-88256EDB.00090B2C@us.ibm.com> <opsbm7jgwuuvpchu@quark> <41026240.8020009@intertwingly.net> <410266E4.6040304@dehora.net>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6OFqbtt036979
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, 24 Jul 2004 14:40:52 +0100, Bill de hÓra <bill@dehora.net> wrote:
> Sam Ruby wrote:
> > My belief is that if, and only if, you own your own domain name, then
> > making the id match the permalink is a good idea.
> 
> And I agree with that except for the word "own" - "lease" is more
> accurate wrt such issues.

That's one problem (of many) with using "http://" URLs are unique
identifiers -- they're not guaranteed to *remain* unique over time,
because nobody owns their domain forever.

If only there were some way to create an identifier that combined a
domain name with, say, a date on which you controlled that domain.

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Sat Jul 24 12:08:15 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27087
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 12:08:15 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OFviHc037331;
	Sat, 24 Jul 2004 08:57: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 i6OFviCM037330;
	Sat, 24 Jul 2004 08:57:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.196])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OFvh2x037323
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 08:57:43 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id 73so44557rnl
        for <atom-syntax@imc.org>; Sat, 24 Jul 2004 08:57:46 -0700 (PDT)
Received: by 10.38.3.79 with SMTP id 79mr26004rnc;
        Sat, 24 Jul 2004 08:57:45 -0700 (PDT)
Message-ID: <14be96d3040724085722ca7549@mail.gmail.com>
Date: Sat, 24 Jul 2004 11:57:45 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Sam Ruby <rubys@intertwingly.net>
Subject: Re: PaceDateline
Cc: atom-syntax@imc.org
In-Reply-To: <41027456.5040109@intertwingly.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <41027456.5040109@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 Sat, 24 Jul 2004 10:38:14 -0400, Sam Ruby <rubys@intertwingly.net> wrote:
> 
> http://www.intertwingly.net/wiki/pie/PaceDateline

I edited the proposal to fix what appears to be a typo.  It read
"atom:dateline elements MUST contain an atom:dateline element".  I
changed this to "atom:entry elements MUST contain an atom:dateline
element".

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Sat Jul 24 12:26: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 MAA27790
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 12: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 i6OGGail038303;
	Sat, 24 Jul 2004 09:16: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 i6OGGaOe038302;
	Sat, 24 Jul 2004 09:16:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OGGZYP038296
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 09:16:35 -0700 (PDT)
	(envelope-from gstein@google.com)
Received: from buu.corp.google.com (buu.corp.google.com [172.24.67.34])
	by 216-239-45-4.google.com (8.12.11/8.12.9) with ESMTP id i6OGGX3A000356
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 09:16:33 -0700
Received: from gstein by buu.corp.google.com with local (Exim 4.14 #4)
	id 1BoPCK-0007jX-Jd by authid <gstein>
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 09:16:32 -0700
Date: Sat, 24 Jul 2004 09:16:32 -0700
From: Greg Stein <gstein@google.com>
To: atom-syntax@imc.org
Subject: Re: URI scheme delusions
Message-ID: <20040724161632.GA29675@google.com>
References: <OF031774D8.BEC98F6C-ON88256EDB.00084992-88256EDB.00090B2C@us.ibm.com> <opsbm7jgwuuvpchu@quark> <41026240.8020009@intertwingly.net> <410266E4.6040304@dehora.net> <14be96d304072408524788c699@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <14be96d304072408524788c699@mail.gmail.com>
User-Agent: Mutt/1.4.1i
X-URL: http://www.lyra.org/greg/
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, Jul 24, 2004 at 11:52:39AM -0400, Mark Pilgrim wrote:
> 
> On Sat, 24 Jul 2004 14:40:52 +0100, Bill de hÓra <bill@dehora.net> wrote:
> > Sam Ruby wrote:
> > > My belief is that if, and only if, you own your own domain name, then
> > > making the id match the permalink is a good idea.
> > 
> > And I agree with that except for the word "own" - "lease" is more
> > accurate wrt such issues.
> 
> That's one problem (of many) with using "http://" URLs are unique
> identifiers -- they're not guaranteed to *remain* unique over time,
> because nobody owns their domain forever.
> 
> If only there were some way to create an identifier that combined a
> domain name with, say, a date on which you controlled that domain.

What are the temporal constraints? Does it really need to be unique for
all time, or simply within a given feed?

Or maybe only as long as the entry it is matched up with? Why should an ID
outlive the entry itself?


In any case, I believe the spec should simply specify "a URI" as the
identifier. I don't think it needs to recommend any particular scheme (as
recommendations are generally non-normative), though a companion "best
practices" document certainly could.

Cheers,
-g



From owner-atom-syntax@mail.imc.org  Sat Jul 24 12:32: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 MAA27911
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 12:32:40 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OGME5S038741;
	Sat, 24 Jul 2004 09:22: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 i6OGMESb038740;
	Sat, 24 Jul 2004 09:22:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OGMDg4038732
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 09:22: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 42D7F7C0F3; Sat, 24 Jul 2004 19:18:26 +0200 (CEST)
Date: Sat, 24 Jul 2004 18:25:43 +0200
To: "Eric Scheid" <eric.scheid@ironclad.net.au>
Subject: Re: Date Options Analysis: Issued
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <BD28B99D.22262%eric.scheid@ironclad.net.au>
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: <opsbng85gcuvpchu@quark>
In-Reply-To: <BD28B99D.22262%eric.scheid@ironclad.net.au>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 25 Jul 2004 01:13:01 +1000, Eric Scheid  
<eric.scheid@ironclad.net.au> wrote:

>> what is [a] solid use case for ever changing 'issued'?
>
> my computer clock is wrong and has been publishing everything with the  
> year 1901. whoops. I fix it, fix the data, and republish.

Okay. You made an error when you first issued. A good use case which I can  
support. That should be included in the specification text in the lines of:

«The atom:issued date is immutable, and SHOULD never change. In practice,  
it reflects the entry's first date of issuance. If, however, the  
atom:issued date is erroneous due to date misconfigurations, it MUST be  
modified to reflect the correct issued date of the entry. It SHOULD NOT be  
modified to re-issue the entry. For re-issuance, see  
[extension:supersede].»

Or something like 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 Jul 24 12:35: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 MAA28006
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 12: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 i6OGQjU6038940;
	Sat, 24 Jul 2004 09:26: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 i6OGQjJ9038939;
	Sat, 24 Jul 2004 09:26: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 i6OGQh3e038925
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 09:26: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 882D97C0F3; Sat, 24 Jul 2004 19:22:56 +0200 (CEST)
To: "Arve Bersvendsen" <arve@virtuelvis.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Propose partial consensus on dates
References: <200407231326.i6NDQixT032547@above.proper.com>
Message-ID: <opsbnhgoiyuvpchu@quark>
Date: Sat, 24 Jul 2004 18:30:14 +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: <200407231326.i6NDQixT032547@above.proper.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 23 Jul 2004 15:26:39 +0200, Arve Bersvendsen <arve@virtuelvis.com>  
wrote:

> How can a revisioning mechanism be built into Atom that allows:
> - For tools to import and export entries, including their entire editing
> history.

A supersede mechanism.

> - Non-revisioning tools to ignore the revision history, and still avoid
> duplicates in their history (read: how can we ensure that these
> non-revisioning tools will treat a "major revision" the same way it would
> treat a "minor revision".

A supersede mechanism.

> - Organizations/tools/people to support the use case that an entry may  
> only be issued exactly once, with an immutable 'issued' date.

A supersede mechanism plus specification text that says that 'issued' is  
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 Jul 24 12:47: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 MAA28456
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 12:47: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 i6OGd7JZ039846;
	Sat, 24 Jul 2004 09:39:07 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6OGd79J039845;
	Sat, 24 Jul 2004 09:39: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-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 i6OGd6Fs039839
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 09:39:06 -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 i6OGat53016841
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 10:36:55 -0600 (MDT)
Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0I1D00HFD7L9MS@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sat, 24 Jul 2004 10:39:09 -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 <0I1D00KQ07L83Q@mail.sun.net> for atom-syntax@imc.org; Sat,
 24 Jul 2004 10:39:08 -0600 (MDT)
Date: Sat, 24 Jul 2004 09:39:20 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: URI scheme delusions
In-reply-to: <14be96d304072408524788c699@mail.gmail.com>
To: Mark Pilgrim <pilgrim@gmail.com>
Cc: Sam Ruby <rubys@intertwingly.net>,
        =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>,
        Atom-Syntax <atom-syntax@imc.org>
Message-id: <02F0CB0F-DD90-11D8-8C8C-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: 
 <OF031774D8.BEC98F6C-ON88256EDB.00084992-88256EDB.00090B2C@us.ibm.com>
 <opsbm7jgwuuvpchu@quark> <41026240.8020009@intertwingly.net>
 <410266E4.6040304@dehora.net> <14be96d304072408524788c699@mail.gmail.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 Jul 24, 2004, at 8:52 AM, Mark Pilgrim wrote:

> If only there were some way to create an identifier that combined a
> domain name with, say, a date on which you controlled that domain.

I assume Mark is being ironic, but whatever, he's entirely correct.  I 
am increasingly convinced of the virtue of putting dates in URIs, as in 
http://www.tbray.org/ongoing/When/200x/2004/07/24/WillYou [<== just an 
example, no Atom-related content here].

  --Tim



From owner-atom-syntax@mail.imc.org  Sat Jul 24 12: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 MAA28518
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 12: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 i6OGauEo039405;
	Sat, 24 Jul 2004 09:36:56 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6OGauK1039404;
	Sat, 24 Jul 2004 09:36:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-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 i6OGataP039398
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 09:36:55 -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 i6OGawil019071
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 10:36:58 -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 <0I1D00CCD7HMHN@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sat, 24 Jul 2004 10:36:58 -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 <0I1D00KAD7HL3N@mail.sun.net> for atom-syntax@imc.org; Sat,
 24 Jul 2004 10:36:58 -0600 (MDT)
Date: Sat, 24 Jul 2004 09:37:09 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: URI scheme delusions
In-reply-to: <opsbnf0rq7uvpchu@quark>
To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
Cc: Eric Scheid <eric.scheid@ironclad.net.au>,
        Atom-Syntax <atom-syntax@imc.org>
Message-id: <B5441647-DD8F-11D8-8C8C-000A95A51C9E@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.618)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
References: <BD28B930.22260%eric.scheid@ironclad.net.au>
 <opsbnf0rq7uvpchu@quark>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6OGauaP039399
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 Jul 24, 2004, at 8:59 AM, Asbjørn Ulsberg wrote:

> Many other specifications are springled with examples. The Atom format 
> specification has _one_. Even though this format is a simple one, and 
> unarguably simpler than e.g. HTML, I see no reason to not have more 
> examples in it.

+1.  I think it is essential that the atom RFCs-to-be have lots of 
examples, and in general should provide an example of something before 
they try to explain/specify it. -Tim




From owner-atom-syntax@mail.imc.org  Sat Jul 24 12:49:48 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28539
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 12:49:48 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OGcZX3039662;
	Sat, 24 Jul 2004 09: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 i6OGcZd5039661;
	Sat, 24 Jul 2004 09:38: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 (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OGcYPZ039649
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 09:38:35 -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 B474B7C0F3; Sat, 24 Jul 2004 19:34:46 +0200 (CEST)
Date: Sat, 24 Jul 2004 18:42:05 +0200
To: "Sam Ruby" <rubys@intertwingly.net>
Subject: Re: Propose partial consensus on dates
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <BD26A8E1.21CAD%eric.scheid@ironclad.net.au> <opsbm4q1fhuvpchu@quark> <410255C5.107@intertwingly.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: <opsbnh0f0buvpchu@quark>
In-Reply-To: <410255C5.107@intertwingly.net>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 24 Jul 2004 08:27:49 -0400, Sam Ruby <rubys@intertwingly.net>  
wrote:

> The question about backwards compatibility with RSS is a red herring.

Yes. That's why I wonder why it's brought up every time «immutable  
'issued'» is mentioned. If we were to specify Atom to be backwards  
compatible with RSS, Atom would be RSS.

> RSS 0.91 had no item level date.

So, Atom already breaks backwards compatibility with RSS 0.91.

> RSS 1.0 had something simply called "date" and if you follow the  
> definition of this date, you find "Typically, Date will be associated  
> with the creation or availability of the resource."

So, it's specified as 'issued', but used more as a combination of  
'issued', 'created' and 'dateline' in most publishing tools.

> RSS 0.93 introduced a date named "pubDate", defined as "Its value is a  
> date, indicating when the item will become available".  In 2.0, this  
> changed to "indicating when the item was published. If it's a date in  
> the future, aggregators may choose to not display the item until that  
> date".

Also specified as 'issued', but used as a combination of 'issued',  
'created' and 'dateline' in most publishing tools.

> At some point in this discussion, a myth was created that RSS dates were  
> correspond to "dc:issued" ("dc:available" is a better match, IMHO), and  
> that "dc:issued" is mutable.

Yes. I agree that this is a myth, and nothing more.

> The one thing that can be observed, based on experience with RSS, is  
> that if a slot for a mutable date is not provided, people will use the  
> slot provided anyway.

I think such a slot should be provided. I just don't understand why it  
must be 'issued'. Any other mutable date works just fine with me. Multiple  
'issued' elements even works; see:

<url: http://intertwingly.net/wiki/pie/PaceMultipleIssued>

But _one_ mutable 'issued' doesn't work at all. Why do people tend to  
squeeze the current practice of RSS' dates into 'issued', when nothing I  
know of supports that conception? The current RSS date may change whenever  
the author wants. The current RSS date is _not_ 'issued'. So, why should  
atom:issued ever change?

> The charter says "The working group will use experience gained with  
> RSS...".  We have experience with how people have misused RSS.  And we  
> can observe the results: they blame the aggregators.

Shouldn't we try to rectify this, then? And while we're in the rectifying  
process, having a look at how more professional, century old practices  
that are proven to work, functions, wouldn't hurt, imo.

-- 
Asbjørn Ulsberg         -=|=-        asbjornu@hotmail.com
«He's a loathsome offensive brute, yet I can't look away»



From owner-atom-syntax@mail.imc.org  Sat Jul 24 12:54: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 MAA28708
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 12: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 i6OGjSwk040292;
	Sat, 24 Jul 2004 09:45:28 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6OGjS72040291;
	Sat, 24 Jul 2004 09:45:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-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 i6OGjRYE040285
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 09:45:28 -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 i6OGhG53018053
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 10:43:16 -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 <0I1D00CK57VUHN@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sat, 24 Jul 2004 10:45:31 -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 <0I1D00KAL7VU3N@mail.sun.net> for atom-syntax@imc.org; Sat,
 24 Jul 2004 10:45:30 -0600 (MDT)
Date: Sat, 24 Jul 2004 09:45:43 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceDateline
In-reply-to: <41027456.5040109@intertwingly.net>
To: Sam Ruby <rubys@intertwingly.net>
Cc: atom-syntax@imc.org
Message-id: <E71F04E4-DD90-11D8-8C8C-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: <41027456.5040109@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 Jul 24, 2004, at 7:38 AM, Sam Ruby wrote:

> http://www.intertwingly.net/wiki/pie/PaceDateline

When I first read this, I considered going over to Sam's place and 
strangling him for introducing another variable to the tangle.  But 
this has the feel of a really good idea... after all, there is a few 
centuries of prior art suggesting that it's a good idea to make it easy 
for people to time/date-stamp their stories.

BTW, the Pace is a little ambiguous, it says that atom:dateline is a 
Date construct, so where does the location go?  Is it <dateline 
when="date">location here?</dateline> or what? -Tim



From owner-atom-syntax@mail.imc.org  Sat Jul 24 12:56:57 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28792
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 12:56: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 i6OGlJxs040396;
	Sat, 24 Jul 2004 09:47: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 i6OGlJrI040395;
	Sat, 24 Jul 2004 09:47: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 i6OGlHds040384
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 09:47: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 C1E1F7C0F3; Sat, 24 Jul 2004 19:43:30 +0200 (CEST)
Date: Sat, 24 Jul 2004 18:50:53 +0200
To: "Eric Scheid" <eric.scheid@ironclad.net.au>
Subject: Re: Propose partial consensus on dates
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <BD2894BA.2216A%eric.scheid@ironclad.net.au>
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: <opsbnie3xpuvpchu@quark>
In-Reply-To: <BD2894BA.2216A%eric.scheid@ironclad.net.au>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 24 Jul 2004 22:35:38 +1000, Eric Scheid  
<eric.scheid@ironclad.net.au> wrote:

> The more change needed for adoption the slower the adoption will be.

Of course. This will be a balance between «What do we want?» and «How fast  
do we want it to be supported?». I'm most concerned about «What do we  
want?» at this point, as I have strong beliefs in the adoption of Atom,  
almost no matter how much incompatible it will be with RSS.

I'm not saying we should break compatibility as much as XHTML 2 is with  
previous versions, but I don't agree that we shouldn't change anything  
either. Some things must change. Some things must break backwards  
compatibility with RSS. Regardless of these dates, that's a fact. Why  
can't 'issued' break this backward compatibility as well, then?

> Both 'issued' and 'updated' will require changes to blogging tools. With
> 'updated', there will be an immediate payoff to implementing that change,
> with aggregators being able to discern the changes of interest amongst  
> the noise of minor modifications.

With immutable 'issued' + 'supersede', this will apply as well. No one  
needs to implement support for it, even, because it's supported already.

> The same *cannot* be said for 'issued'. For the major active constituency
> for which atom is being developed for, they simply haven't recognised any
> value or utility to know the first-published date. There would be no  
> payoff for the pain.

Maybe not for the weblogging community, but I am saying that more  
professional publishing processes will have very much value from it.

>> It's basically just an alternative, more subjective way to express
>> 'issued', so I see absolutely no reason to require it.
>
> My point is simple: it's better to have only one date be required rather
> than a plethora

If only one date should be required (when was that ever made an issue?), I  
would requre 'issued', since that is the most important date in a  
publishing process.

> and if we have to choose just one I pick 'dateline', because it will
> deliver the most bang for the buck for the most users who are already
> in the community.

I will probably never even parse the 'dateline' date in the tools I'd be  
writing for Atom.

> Extra fields which will only be used by a minority

Do you see professional publishers like BBC as a minority? What defines  
«minority»? The number of publishers? The number of readers that publisher  
has?

-- 
Asbjørn Ulsberg         -=|=-        asbjornu@hotmail.com
«He's a loathsome offensive brute, yet I can't look away»



From owner-atom-syntax@mail.imc.org  Sat Jul 24 12:58:05 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28850
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 12: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 i6OGmvBB040468;
	Sat, 24 Jul 2004 09:48: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 i6OGmvpA040467;
	Sat, 24 Jul 2004 09:48:57 -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 i6OGmuKb040453
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 09:48:56 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 67532 messnum 5076793 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 24 Jul 2004 16:48:54 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail04.svc.cra.dublin.eircom.net (qp 67532) with SMTP; 24 Jul 2004 16:48:54 -0000
Message-ID: <410292F3.4010005@dehora.net>
Date: Sat, 24 Jul 2004 17:48:51 +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: PaceDateline
References: <41027456.5040109@intertwingly.net>
In-Reply-To: <41027456.5040109@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:

> 
> http://www.intertwingly.net/wiki/pie/PaceDateline
> 
> - Sam Ruby


-1 to the co-occurence constraint below:

[[[
  Unless the following elements are also present from the dcterms 
namespace, this value is to be presumed as the the date that the 
entry was created, valid, available, issued, modified, accepted, 
copyrighted, and submitted.
]]]

cheers
Bill



From owner-atom-syntax@mail.imc.org  Sat Jul 24 13:20: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 NAA00038
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 13:20: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 i6OHAAIU041686;
	Sat, 24 Jul 2004 10:10: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 i6OHAAw6041685;
	Sat, 24 Jul 2004 10:10:10 -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 i6OHA98A041678
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 10:10:09 -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 i6OHADil025130
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 11:10:13 -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 <0I1D00HP6910MS@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sat, 24 Jul 2004 11:10:13 -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 <0I1D00KQI9103Q@mail.sun.net> for atom-syntax@imc.org; Sat,
 24 Jul 2004 11:10:12 -0600 (MDT)
Date: Sat, 24 Jul 2004 10:10:24 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceDateline
In-reply-to: <410292F3.4010005@dehora.net>
To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>
Cc: atom-syntax@imc.org
Message-id: <59FFC974-DD94-11D8-8C8C-000A95A51C9E@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.618)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
References: <41027456.5040109@intertwingly.net> <410292F3.4010005@dehora.net>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6OHA98A041680
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 Jul 24, 2004, at 9:48 AM, Bill de hÓra wrote:

> -1 to the co-occurence constraint below:
>
> [[[
>  Unless the following elements are also present from the dcterms 
> namespace, this value is to be presumed as the the date that the entry 
> was created, valid, available, issued, modified, accepted, 
> copyrighted, and submitted.

Explain, Bill?  Sam's saying that dateline provides the default for the 
dates from dc:terms in the case they're not provided.  I'm not getting 
your point, I think -Tim




From owner-atom-syntax@mail.imc.org  Sat Jul 24 13:28: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 NAA00456
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 13:28: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 i6OHIA8B042055;
	Sat, 24 Jul 2004 10:18: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 i6OHIAN3042054;
	Sat, 24 Jul 2004 10:18: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 (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OHI82n042047
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 10:18: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 07ADE7C0F3; Sat, 24 Jul 2004 20:14:18 +0200 (CEST)
To: "Tim Bray" <Tim.Bray@sun.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: URI scheme delusions
References: <BD28B930.22260%eric.scheid@ironclad.net.au> <opsbnf0rq7uvpchu@quark> <B5441647-DD8F-11D8-8C8C-000A95A51C9E@sun.com>
Message-ID: <opsbnjukx5uvpchu@quark>
Date: Sat, 24 Jul 2004 19:21:46 +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: <B5441647-DD8F-11D8-8C8C-000A95A51C9E@sun.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 24 Jul 2004 09:37:09 -0700, Tim Bray <Tim.Bray@Sun.COM> wrote:

> +1.  I think it is essential that the atom RFCs-to-be have lots of  
> examples, and in general should provide an example of something before  
> they try to explain/specify it.

Would it be too much to require future and existing paces to include at  
least one example that will be a part of the specification, then? It  
wouldn't take much time to write one for each Pace's author, I think.

For future pace's, it's just to add an 'Examples' section to the pace  
template.

-- 
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 Jul 24 13:32: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 NAA00611
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 13:32: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 i6OHMb7C042624;
	Sat, 24 Jul 2004 10:22: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 i6OHMbf0042623;
	Sat, 24 Jul 2004 10:22: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 i6OHMbpi042614
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 10:22: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 77BC27C0F3; Sat, 24 Jul 2004 20:18:50 +0200 (CEST)
Date: Sat, 24 Jul 2004 19:26:20 +0200
To: "Sam Ruby" <rubys@intertwingly.net>
Subject: Re: PaceDateline
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <41027456.5040109@intertwingly.net> <opsbndknqruvpchu@quark> <41027CC9.5060202@intertwingly.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: <opsbnj16g8uvpchu@quark>
In-Reply-To: <41027CC9.5060202@intertwingly.net>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 24 Jul 2004 11:14:17 -0400, Sam Ruby <rubys@intertwingly.net>  
wrote:

> Please read the entire Pace, it is not that long.

I did.

> modified, issued, and created are still present, and default to the  
> specified dateline.

I can't live with an optional 'issued', sorry. :-\ I should probably have  
written that in my previous comment.

> The presumption is that dateline will be defined as a profile of ISO  
> 8601.

Where does the location information go, then?

-- 
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 Jul 24 13:33:57 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00671
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 13:33: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 i6OHND2N042649;
	Sat, 24 Jul 2004 10:23: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 i6OHNDfr042648;
	Sat, 24 Jul 2004 10:23: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 i6OHNBB9042641
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 10:23: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 CD7A87C0F3; Sat, 24 Jul 2004 20:19:24 +0200 (CEST)
To: =?iso-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceDateline
References: <41027456.5040109@intertwingly.net> <410292F3.4010005@dehora.net>
Message-ID: <opsbnj24o1uvpchu@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, 24 Jul 2004 19:26:54 +0200
In-Reply-To: <410292F3.4010005@dehora.net>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 24 Jul 2004 17:48:51 +0100, Bill de hÓra <bill@dehora.net> wrote:

> -1 to the co-occurence constraint below:
>
> [[[
>   Unless the following elements are also present from the dcterms  
> namespace, this value is to be presumed as the the date that the entry  
> was created, valid, available, issued, modified, accepted, copyrighted,  
> and submitted.
> ]]]

+1 to your -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  Sat Jul 24 13: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 NAA01380
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 13:54: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 i6OHhIrh043859;
	Sat, 24 Jul 2004 10:43: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 i6OHhIiA043858;
	Sat, 24 Jul 2004 10:43: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 i6OHhHV2043844
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 10:43:17 -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 i6OHiJKk011514;
	Sat, 24 Jul 2004 13:44:20 -0400
Message-ID: <4102A066.3020101@intertwingly.net>
Date: Sat, 24 Jul 2004 13:46:14 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Arve Bersvendsen <arve@virtuelvis.com>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceDateline
References: <200407241615.i6OGF0TL007188@chromium.sabren.com>
In-Reply-To: <200407241615.i6OGF0TL007188@chromium.sabren.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


Arve Bersvendsen wrote:

>>http://www.intertwingly.net/wiki/pie/PaceDateline
> 
> I'm -1 on this as the pace stands at the time of writing. This looks like
> pubDate (almost) all over again, with CMSes having to invent their own uses
> of DC dates.

I understand and appreciate this argument.  If it helps, let me retrace 
my train of thought.  From http://www.intertwingly.net/wiki/pie/DateSurvey :

     [GrahamParks]: I don't think optional core elements cause problems
     if there are clear rules about what to do when one is missing

     [RogerBenningfield]: That means throwing out the subtle bits,
     leaving them for extensions.

     [SamRuby] I prefer names that either don't already have strong
     predefined associations or have associations that match the
     definition we intend.

So, I went back to dcterms.  What I found there was a set of dates, 
*each* of which I could imagine *somebody* making a clear and compelling 
argument for.

What to do?

First, let's look at the 80% use case.  In the case of weblogs, this 
unquestionably is the case where created, valid, available, issued, 
modified, accepted, copyrighted, and submitted are all simultaneous.

Then I picked a name which does not have a strong predefined association 
with any of those "refined" elements.  I tentatively picked dateline. 
If you look at how that term is used by The Media (e.g., newspapers, 
magazines, television), and apply it to a media (the internet) where 
publishing is often accomplished without recourse to an editor, then it 
does seem to fit.

So, how is this different than pubDate?  Well, for starters, there are 
clear rules.  But, is this enough?  I thought about it a bit, and the 
worst thing I could imagine happening is for everybody to pick a 
different refined date to sort on.

So, I thought about the aggregators that I have used.  When presenting 
views of "fresh news", what they mostly care about can be summed up as 
"if I were to poll your site once a second, when would I have first seen 
this entry?"  The refined date that most closely matches this 
description is <available>, which coincidentally matches the spec 
definition (as opposed to the popular usage) of the RSS pubDate.

I figure that by drawing attention to this one date, this problem can be 
solved to the extent that it can be solved.  There always will be the 
case of people who are unwilling and unable to follow instructions. 
Those that don't will likely not place this additional element in, and 
this tend to have the effect of penalizing them (their updates won't be 
seen) without placing any blame on the aggregators.  And, even in the 
worst case (users being penalized for missing news), this is no worse 
than the current state.

I then thought about the subtle distinction between updated and 
modified.  If aggregators are sorting on available, then I'm not sure 
what they would do with another field.  Thinking about it a bit more, 
one could argue that if somebody made a change and chose NOT to update 
the value of available, then one could imply a bit of intent.

At this point, the suggestion seemed worth enough to write up, even if 
it doesn't attract consensus.  I was troubled by the definition of 
dateline also implying a place of origin, so I did a minimal amount of 
research (google rocks!) before committing the Pace.

If the event that this Pace is accepted, some form of the above text 
belongs either as an informative note, or in a separate usage guide.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Sat Jul 24 13:56: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 NAA01517
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 13: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 i6OHkjD5044037;
	Sat, 24 Jul 2004 10:46: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 i6OHkjLZ044036;
	Sat, 24 Jul 2004 10:46:45 -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 i6OHkhXL044030
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 10:46:43 -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 i6OHlkVn011731;
	Sat, 24 Jul 2004 13:47:47 -0400
Message-ID: <4102A135.7040708@intertwingly.net>
Date: Sat, 24 Jul 2004 13:49:41 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <Tim.Bray@Sun.COM>
CC: atom-syntax@imc.org
Subject: Re: PaceDateline
References: <41027456.5040109@intertwingly.net> <E71F04E4-DD90-11D8-8C8C-000A95A51C9E@sun.com>
In-Reply-To: <E71F04E4-DD90-11D8-8C8C-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:
> 
> BTW, the Pace is a little ambiguous, it says that atom:dateline is a 
> Date construct, so where does the location go?  Is it <dateline 
> when="date">location here?</dateline> or what? -Tim

I've updated the first line of the first note to read as follows:

     At this time, THE SYNTAX FOR providing location information has not
     been fleshed out.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Sat Jul 24 14:02: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 OAA01784
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 14:02:53 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OHqelJ044335;
	Sat, 24 Jul 2004 10:52: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 i6OHqetr044334;
	Sat, 24 Jul 2004 10:52:40 -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 i6OHqdJO044319
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 10:52:40 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 25 Jul 2004 03:58:18 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sun, 25 Jul 2004 03:50:41 +1000
Subject: Re: Propose partial consensus on dates
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD28DE91.222E3%eric.scheid@ironclad.net.au>
In-Reply-To: <opsbnie3xpuvpchu@quark>
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 i6OHqeJO044329
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 25/7/04 2:50 AM, "Asbjørn Ulsberg" <asbjorn@tigerstaden.no> wrote:

> With immutable 'issued' + 'supersede', this will apply as well. No one
> needs to implement support for it, even, because it's supported already.

by "supported" you mean today's aggregators will clutter up my daily feed
reading with multiple versions of the essentially same entry?

-1

e.




From owner-atom-syntax@mail.imc.org  Sat Jul 24 14:03: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 OAA01874
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 14:03: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 i6OHqefh044327;
	Sat, 24 Jul 2004 10:52: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 i6OHqekC044326;
	Sat, 24 Jul 2004 10:52:40 -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 i6OHqclt044318
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 10:52:39 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 25 Jul 2004 03:58:14 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sun, 25 Jul 2004 03:47:42 +1000
Subject: Re: Propose partial consensus on dates
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD28DDDE.222E1%eric.scheid@ironclad.net.au>
In-Reply-To: <opsbnh0f0buvpchu@quark>
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 i6OHqdlt044321
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 25/7/04 2:42 AM, "Asbjørn Ulsberg" <asbjorn@tigerstaden.no> wrote:

>> The one thing that can be observed, based on experience with RSS, is
>> that if a slot for a mutable date is not provided, people will use the
>> slot provided anyway.
> 
> I think such a slot should be provided. I just don't understand why it
> must be 'issued'.

Looking at DateSurvey, there is very strong support for 'dateline', so I
don't think anyone is saying it must be 'issued'. It has been said however
that if there is just one date field then it will get abused.

e.




From owner-atom-syntax@mail.imc.org  Sat Jul 24 14:13: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 OAA02254
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 14: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 i6OI44Nh044853;
	Sat, 24 Jul 2004 11:04: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 i6OI44bO044852;
	Sat, 24 Jul 2004 11:04:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OI43wH044846
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 11:04:03 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6OI47il005218
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 12:04:07 -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 <0I1D00HMIBIUMS@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sat, 24 Jul 2004 12:04:07 -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 <0I1D003ILBIRL2@mail.sun.net> for atom-syntax@imc.org; Sat,
 24 Jul 2004 12:04:03 -0600 (MDT)
Date: Sat, 24 Jul 2004 11:04:14 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceDateline
In-reply-to: <opsbnj16g8uvpchu@quark>
To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
Cc: Sam Ruby <rubys@intertwingly.net>, Atom-Syntax <atom-syntax@imc.org>
Message-id: <DF629C3B-DD9B-11D8-8C8C-000A95A51C9E@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.618)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
References: <41027456.5040109@intertwingly.net> <opsbndknqruvpchu@quark>
 <41027CC9.5060202@intertwingly.net> <opsbnj16g8uvpchu@quark>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6OI43wH044847
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 Jul 24, 2004, at 10:26 AM, Asbjørn Ulsberg wrote:

> I can't live with an optional 'issued', sorry. :-\ I should probably 
> have written that in my previous comment.

Given that a substantial proportion of publications are simply not 
going to adopt your favored semantic of immutable-issued+supercede, I 
think you're going to *have* to learn to live without "issued".  I 
think you would do much better to support Sam's proposal.  If dc:issued 
is present, that would be a good signal that this publication is using 
your semantics.  If your software can't run properly without your 
"issued" semantic, then it will *never* work correctly on (for example) 
my weblog, so wouldn't you rather have that signaled? -Tim



From owner-atom-syntax@mail.imc.org  Sat Jul 24 14:15: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 OAA02348
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 14:15: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 i6OI7Fbj045348;
	Sat, 24 Jul 2004 11:07: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 i6OI7F4D045347;
	Sat, 24 Jul 2004 11:07: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 i6OI7BkE045340
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 11:07:14 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 25 Jul 2004 04:12:53 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sun, 25 Jul 2004 04:07:12 +1000
Subject: Re: Propose partial consensus on dates
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD28E270.22304%eric.scheid@ironclad.net.au>
In-Reply-To: <opsbnie3xpuvpchu@quark>
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 i6OI7FkE045342
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 25/7/04 2:50 AM, "Asbjørn Ulsberg" <asbjorn@tigerstaden.no> wrote:

> With immutable 'issued' + 'supersede', this will apply as well. No one
> needs to implement support for it, even, because it's supported already.

by "supported" you mean today's aggregators will clutter up my daily feed
reading with multiple versions of the essentially same entry?

-1

"essentially same" meaning the bulk of content the same, just one extra
footnote.

just like this damnable email itself?

e.




From owner-atom-syntax@mail.imc.org  Sat Jul 24 14:17: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 OAA02536
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 14:17: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 i6OI6nSo045331;
	Sat, 24 Jul 2004 11:06: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 i6OI6naV045330;
	Sat, 24 Jul 2004 11:06: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 i6OI6jPd045323
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 11:06:48 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 25 Jul 2004 04:12:26 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sun, 25 Jul 2004 04:06:45 +1000
Subject: Re: Propose partial consensus on dates
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD28E255.22303%eric.scheid@ironclad.net.au>
In-Reply-To: <opsbnie3xpuvpchu@quark>
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 i6OI6nPd045325
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 25/7/04 2:50 AM, "Asbjørn Ulsberg" <asbjorn@tigerstaden.no> wrote:

> With immutable 'issued' + 'supersede', this will apply as well. No one
> needs to implement support for it, even, because it's supported already.

by "supported" you mean today's aggregators will clutter up my daily feed
reading with multiple versions of the essentially same entry?

-1

"essentially same" meaning the bulk of content the same, just one extra
footnote.

e.




From owner-atom-syntax@mail.imc.org  Sat Jul 24 14: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 OAA03006
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 14: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 i6OIGbSF045726;
	Sat, 24 Jul 2004 11:16: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 i6OIGbwr045725;
	Sat, 24 Jul 2004 11:16:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mta01-svc.ntlworld.com (mta01-svc.ntlworld.com [62.253.162.41])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OIGafv045716
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 11:16:36 -0700 (PDT)
	(envelope-from djpowell@djpowell.net)
Received: from cpc1-stke1-5-0-cust6.bagu.cable.ntl.com ([81.97.134.6])
          by mta01-svc.ntlworld.com
          (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP
          id <20040724181557.RTSI22902.mta01-svc.ntlworld.com@cpc1-stke1-5-0-cust6.bagu.cable.ntl.com>;
          Sat, 24 Jul 2004 19:15:57 +0100
Date: Sat, 24 Jul 2004 19:16:33 +0100
From: David Powell <djpowell@djpowell.net>
X-Mailer: The Bat! (v2.12 RC/4) Business
Reply-To: David Powell <djpowell@djpowell.net>
X-Priority: 3 (Normal)
Message-ID: <1203005908.20040724191633@djpowell.net>
To: =?ISO-8859-1?B?QXNiavhybiBVbHNiZXJn?= <asbjorn@tigerstaden.no>
CC: "Sam Ruby" <rubys@intertwingly.net>, Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceDateline
In-Reply-To: <opsbnj16g8uvpchu@quark>
References: <41027456.5040109@intertwingly.net> <opsbndknqruvpchu@quark>
 <41027CC9.5060202@intertwingly.net> <opsbnj16g8uvpchu@quark>
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


Saturday, July 24, 2004, 6:26:20 PM, asbjorn@tigerstaden.no wrote:

>> modified, issued, and created are still present, and default to the
>> specified dateline.

> I can't live with an optional 'issued', sorry. :-\ I should probably have
> written that in my previous comment.

Can you explain your +2R for atom:issued a bit more? I can understand
why an aggregator of professionally published documents might require
all of those documents to have an issued date. I can also imagine that
they may be required to have some form of formal categorization field,
such as a refinement of dc:subject (I've worked on a publishing system
that did) - but nobody is suggesting that all Atom feeds should
require these other fields that are mandatory for some applications of
Atom.

So why would you require *every* Atom publication in the world to
have an issued date. Aren't these requirements just local policies of
the publishing system, rather than requirements that apply to all Atom
publications?

Another example would be a blog's comments feed. Some comments feeds
require the author to supply an email address or URL, but this can be
enforced without requiring every Atom publication in the world to
supply an email address - this is just another local policy of that
feed.


I personally don't have a problem with issued, but it seems that where
blogs supply both issued/created and modified dates, the issued dates
tend not to be used by aggregators, so I'm not convinced that all
entries should be forced to supply it unless it has a clear benefit to
the majority of readers.

-- 
Dave



From owner-atom-syntax@mail.imc.org  Sat Jul 24 14:29: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 OAA03364
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 14: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 i6OILhIQ045968;
	Sat, 24 Jul 2004 11:21: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 i6OILhZj045967;
	Sat, 24 Jul 2004 11:21:43 -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 i6OILf9C045961
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 11:21:42 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 76638 messnum 3884094 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 24 Jul 2004 18:21:40 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail08.svc.cra.dublin.eircom.net (qp 76638) with SMTP; 24 Jul 2004 18:21:40 -0000
Message-ID: <4102A8B2.9030900@dehora.net>
Date: Sat, 24 Jul 2004 19:21:38 +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: PaceDateline
References: <41027456.5040109@intertwingly.net> <410292F3.4010005@dehora.net> <59FFC974-DD94-11D8-8C8C-000A95A51C9E@sun.com>
In-Reply-To: <59FFC974-DD94-11D8-8C8C-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:

> On Jul 24, 2004, at 9:48 AM, Bill de hÓra wrote:
> 
>> -1 to the co-occurence constraint below:
>>
>> [[[
>>  Unless the following elements are also present from the dcterms 
>> namespace, this value is to be presumed as the the date that the entry 
>> was created, valid, available, issued, modified, accepted, 
>> copyrighted, and submitted.
> 
> 
> Explain, Bill?  Sam's saying that dateline provides the default for the 
> dates from dc:terms in the case they're not provided.  I'm not getting 
> your point, I think -Tim

It's a default behaviour not worth having. I think if the dc:terms 
values are to be considered part of Atom, they should be explicitly 
present, not presumed by their absence. This Pace makes them present 
in Atom as a result of them not being there. Also, automatically 
inheriting a value from one date into another date with different 
meaning may not be desirable. It's not hard to imagine a siuation 
where a dcterms:submitted or dcterms:copyright is not written into 
an Atom entry but that the datetime value used to infer it 
downstream is not what was intended (programming through 
side-effects). The sound thing for a user to do then is to write 
these values out - so be it if they're all the same. Given the 
intense discussion around dates, it seems best that if someone wants 
to assert such terms they do so explicitly.

cheers
Bill




From owner-atom-syntax@mail.imc.org  Sat Jul 24 14: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 OAA03638
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 14: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 i6OINUm9046164;
	Sat, 24 Jul 2004 11:23: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 i6OINUKb046163;
	Sat, 24 Jul 2004 11:23:30 -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 i6OINTUh046154
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 11:23:30 -0700 (PDT)
	(envelope-from davep@dpawson.co.uk)
Received: (qmail 5836 invoked from network); 24 Jul 2004 18:45:20 -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 Jul 2004 18:45:20 -0000
Subject: Re: PaceDateline - process issue
From: Dave Pawson <davep@dpawson.co.uk>
Reply-To: davep@dpawson.co.uk
To: Atom syntax <atom-syntax@imc.org>
In-Reply-To: <E71F04E4-DD90-11D8-8C8C-000A95A51C9E@sun.com>
References: <41027456.5040109@intertwingly.net>
	 <E71F04E4-DD90-11D8-8C8C-000A95A51C9E@sun.com>
Content-Type: text/plain
Message-Id: <1090693415.2037.118.camel@homer>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) 
Date: Sat, 24 Jul 2004 19:23:35 +0100
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


> > http://www.intertwingly.net/wiki/pie/PaceDateline

Says, The "atom:dateline" element is a Date construct that indicates the
date and place of origin

In which case its not a semantic tag? Why 'place' in dateline?

Or is the place meant to be a child of date (yuk)

What's the process for comments?
Edit the wiki page?
(Thought I'd better ask first)
-- 
Regards DaveP.
XSLT&Docbook  FAQ
http://www.dpawson.co.uk/xsl




From owner-atom-syntax@mail.imc.org  Sat Jul 24 14:32: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 OAA03662
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 14:32:40 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OINrfU046216;
	Sat, 24 Jul 2004 11:23: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 i6OINrW4046215;
	Sat, 24 Jul 2004 11:23: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 i6OINphD046209
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 11:23:52 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 25 Jul 2004 04:29:34 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sun, 25 Jul 2004 04:23:52 +1000
Subject: Re: Propose partial consensus on dates
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD28E658.22314%eric.scheid@ironclad.net.au>
In-Reply-To: <opsbnie3xpuvpchu@quark>
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 i6OINrhD046210
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 25/7/04 2:50 AM, "Asbjørn Ulsberg" <asbjorn@tigerstaden.no> wrote:

> With immutable 'issued' + 'supersede', this will apply as well. No one
> needs to implement support for it, even, because it's supported already.

by "supported" you mean today's aggregators will clutter up my daily feed
reading with multiple versions of the essentially same entry?

-1

"essentially same" meaning the bulk of content the same, just one extra
footnote.

just like this damnable email itself?

have I made my point yet? apologies to everyone!

e.




From owner-atom-syntax@mail.imc.org  Sat Jul 24 14:40: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 OAA04103
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 14:40: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 i6OITsdC046845;
	Sat, 24 Jul 2004 11:29: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 i6OITsOf046844;
	Sat, 24 Jul 2004 11:29:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OITqtc046829
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 11:29:53 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 25 Jul 2004 04:35:35 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sun, 25 Jul 2004 04:29:53 +1000
Subject: Re: Propose partial consensus on dates
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD28E7C1.22319%eric.scheid@ironclad.net.au>
In-Reply-To: <0BC52492-DD87-11D8-9941-003065EA6144@geckotribe.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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 25/7/04 1:35 AM, "Antone Roundy" <antone@geckotribe.com> wrote:

> Some users will want to see each entry only once, whether it gets
> Updated or not.  Other users will want to see it again every time it's
> Updated.  Each is likely to want the date ordering to be based on the
> date that interests them.  The reason for the person wanting to see
> Updates wanting to sort by Updated is obvious enough--to them, an
> update is new news.  But a person who only wants to see it once is
> likely to consider it new news only as of the time it was first issued.
> Thus, knowing when it was first issued is important for their sorting
> order.

For me, sorting on 'updated' doesn't make much sense, and I am someone who
*does* want to see updates. I would sort on 'dateline', not 'updated', not
'issued', because this gives me the best sense of what they are writing
about.

My feed reader of choice currently marks unread items in bold, and if it
detects a change (via diffs since we don't have 'updated' yet) it marks it
in bold again. (Incidentally, this means that if I haven't got round to
reading something it doesn't matter if it has been updated or not). If I
sort by 'dateline' (or pubDate as in current practice (not spec)), then I
can see something has been updated because it's down the page, nestled
amongst a bunch of things I've already read. This positional context signals
to me that it is old, it was probably read, and it's now been updated.
Jumbling updates in with new news doesn't help me ... I'd start to read from
the top of the entry and then be confused because it looks so familiar. For
updates, I'd want to know I should probably glance/scroll to the bottom of
the entry, because that's where by custom most people write their update
footnotes.

I'd also prefer to sort on 'dateline' not 'issued', because I'd prefer to
read things in the date order that they are about (content wise), and not
the order in which someone got around to writing up their notes. Sorting by
'dateline' not 'issued' also means that any new entry with an older date
stands out ... it's down the page, nestled amongst a bunch of read things.
This is a subtle signal that it's been issued in out of date sequence, since
I normally read things as they become available, and to take that into
consideration regarding accuracy due to elapsed time effects on
recollection. Sorting by issued doesn't give me that signal.

If it's below the scroll, I will still find it because my feed-reader of
choice gives me an unread count for each feed.

So, sorting by 'dateline' makes more sense to me than sorting by 'updated'
or 'issued'. I'd still make use of 'updated'. I still don't know what I'd do
with 'issued'.

e.



From owner-atom-syntax@mail.imc.org  Sat Jul 24 14:43: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 OAA04271
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 14:43: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 i6OIYVIH047343;
	Sat, 24 Jul 2004 11: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 i6OIYVZf047342;
	Sat, 24 Jul 2004 11:34:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OIYQAs047335
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 11:34:29 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 25 Jul 2004 04:40:08 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sun, 25 Jul 2004 04:34:23 +1000
Subject: Re: PaceDateline
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD28E8CF.2231A%eric.scheid@ironclad.net.au>
In-Reply-To: <DF629C3B-DD9B-11D8-8C8C-000A95A51C9E@sun.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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 25/7/04 4:04 AM, "Tim Bray" <Tim.Bray@Sun.COM> wrote:

> If dc:issued is present, that would be a good signal that this publication is
> using your semantics.

+1

Far better to have 'issued' missing than to have it polluted, and being
unable to distinguish between well behaved 'issued's and polluted 'issued's.

This is a good design pattern we should keep in mind.

e.



From owner-atom-syntax@mail.imc.org  Sat Jul 24 14:48: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 OAA04506
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 14:48: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 i6OIdq2s047644;
	Sat, 24 Jul 2004 11:39:52 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6OIdqGo047643;
	Sat, 24 Jul 2004 11:39:52 -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 i6OIdpqg047637
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 11:39:52 -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 i6OIej7W013979;
	Sat, 24 Jul 2004 14:40:45 -0400
Message-ID: <4102ADA0.3060901@intertwingly.net>
Date: Sat, 24 Jul 2004 14:42:40 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <atom-syntax@imc.org>
Subject: Re: PaceDateline - process issue
References: <41027456.5040109@intertwingly.net>	 <E71F04E4-DD90-11D8-8C8C-000A95A51C9E@sun.com> <1090693415.2037.118.camel@homer>
In-Reply-To: <1090693415.2037.118.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: <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


Dave Pawson wrote:

>>>http://www.intertwingly.net/wiki/pie/PaceDateline
> 
> Says, The "atom:dateline" element is a Date construct that indicates the
> date and place of origin

The dictionary definition of the word dateline, explicitly linked from 
the PaceDateline page and repeated inside the page itself, is:

     A phrase at the beginning of a newspaper or magazine article that
     gives the date and place of its origin.

> In which case its not a semantic tag? Why 'place' in dateline?

I am not certain why that definition would make this tag non-semantic. 
Can you explain?  As to why 'place' in dateline, again it is because of 
the dictionary definition for the term.  Also from the Pace:

     If the WG decides not to provide a means for capturing the place of
     origin, then a different element name should be chosen.

> Or is the place meant to be a child of date (yuk)

 From the notes section:

     At this time, the syntax for providing location information has not
     been fleshed out.

> What's the process for comments?
> Edit the wiki page?
> (Thought I'd better ask first)

 From http://www.intertwingly.net/wiki/pie/CategoryProposals :

    Discussion about proposals is to take place on the mailing list.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Sat Jul 24 15:22: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 PAA06834
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 15:22: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 i6OJAoGe049018;
	Sat, 24 Jul 2004 12:10: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 i6OJAode049017;
	Sat, 24 Jul 2004 12:10: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.86])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OJAnBB049011
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 12:10:49 -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 i6OJArRG015153;
	Sat, 24 Jul 2004 12:10:53 -0700 (PDT)
Received: from [192.168.1.101] (66-108-153-170.nyc.rr.com [66.108.153.170])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id i6OJAoVd013723;
	Sat, 24 Jul 2004 12:10:51 -0700 (PDT)
In-Reply-To: <4102ADA0.3060901@intertwingly.net>
References: <41027456.5040109@intertwingly.net> <E71F04E4-DD90-11D8-8C8C-000A95A51C9E@sun.com> <1090693415.2037.118.camel@homer> <4102ADA0.3060901@intertwingly.net>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <2BDD4646-DDA5-11D8-9170-000A95DC3D90@mac.com>
Content-Transfer-Encoding: 7bit
Cc: Atom syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: PaceDateline - process issue
Date: Sat, 24 Jul 2004 15:10:48 -0400
To: Sam Ruby <rubys@intertwingly.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>
Content-Transfer-Encoding: 7bit


a) Where on earth did the dcterms idea come back from? Not discussing 
dates properly in the spec seems like a sure way to discourage 
interoperability.
b) "dateline" was offered as a name for a consensus *date* construct. 
No one said datelines themselves (ie including place information) were 
a good idea.

I really hope you're just playing devil's advocate with these two 
suggestions.

Graham



From owner-atom-syntax@mail.imc.org  Sat Jul 24 15: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 PAA06858
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 15:22:26 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OJChpk049152;
	Sat, 24 Jul 2004 12:12:43 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6OJCh75049151;
	Sat, 24 Jul 2004 12:12:43 -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 i6OJChfR049135
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 12:12:43 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040724191240.48009.qmail@web41212.mail.yahoo.com>
Received: from [67.160.87.187] by web41212.mail.yahoo.com via HTTP; Sat, 24 Jul 2004 12:12:40 PDT
Date: Sat, 24 Jul 2004 12:12:40 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Propose partial consensus on dates
To: "Asbjørn_Ulsberg" <asbjorn@tigerstaden.no>
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <opsbm9xve1uvpchu@quark>
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>


--- Asbjørn_Ulsberg <asbjorn@tigerstaden.no> wrote:
> 
> Yes, but that is how it appears to you, as a reader.
> What actually  
> happened «under the table», is that each newer
> version of a specification  
> superseded an older one. This is very common
> practice, not only in W3C.

Who cares what happens under the table? We are
discussing a syndication format used for displaying
metadata to readers not for accurately describing the
custom features of every CMS in the world.

=====
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  Sat Jul 24 15:27: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 PAA07139
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 15:27: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 i6OJJRIW049463;
	Sat, 24 Jul 2004 12:19: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 i6OJJRmL049462;
	Sat, 24 Jul 2004 12:19: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 (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OJJQ1h049450
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 12:19: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 06E2F7C0F3; Sat, 24 Jul 2004 22:15:34 +0200 (CEST)
Date: Sat, 24 Jul 2004 21:23:29 +0200
To: "Eric Scheid" <eric.scheid@ironclad.net.au>
Subject: Re: Propose partial consensus on dates
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <BD28DDDE.222E1%eric.scheid@ironclad.net.au>
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: <opsbnphfemuvpchu@quark>
In-Reply-To: <BD28DDDE.222E1%eric.scheid@ironclad.net.au>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 25 Jul 2004 03:47:42 +1000, Eric Scheid  
<eric.scheid@ironclad.net.au> wrote:

> Looking at DateSurvey, there is very strong support for 'dateline', so I
> don't think anyone is saying it must be 'issued'.

Many people on this list have argued that the current practice is so and  
so, and that's why 'issued' can't be so and so. If we agree that the  
current practice is with a date that has almost nothing in common with  
'issued', I believe that practice can't be covered by an 'issued' element,  
and thus proclaiming what current practice is, means nothing, at least not  
when talking about the 'issued' element. Right? :-)

> It has been said however that if there is just one date field then it  
> will
> get abused.

I've always said that the more dates, the merrier. Personally, I find it  
very difficult to believe that it will be problematic for any tool to  
produce both 'issued', 'modified' and 'created', seeing that absolutely  
all tools I have ever worked with (both in the weblogging world and  
outside of it) does all of these actions:

   - If a tool can create entries, it should provide a date for it.
   - If a tool can issue entries, it should provide a date for it.
   - If a tool can modify entries, it should provide a date for it.

If a tool can't provide any of these dates, I really don't understand how  
that tool can work at all. The only date of the above I really _need_, is  
'issued', though. Why is it too much to require that tools provide that  
date? Because they don't do it today?

-- 
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 Jul 24 15:31: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 PAA07322
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 15:31: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 i6OJLqaQ049546;
	Sat, 24 Jul 2004 12: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 i6OJLqg4049545;
	Sat, 24 Jul 2004 12:21:52 -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 i6OJLpLQ049538
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 12:21:52 -0700 (PDT)
	(envelope-from davep@dpawson.co.uk)
Received: (qmail 22452 invoked from network); 24 Jul 2004 19:43:43 -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 Jul 2004 19:43:43 -0000
Subject: Re: PaceDateline - process issue
From: Dave Pawson <davep@dpawson.co.uk>
Reply-To: davep@dpawson.co.uk
To: Sam Ruby <rubys@intertwingly.net>
Cc: Atom syntax <atom-syntax@imc.org>
In-Reply-To: <4102ADA0.3060901@intertwingly.net>
References: <41027456.5040109@intertwingly.net>
	 <E71F04E4-DD90-11D8-8C8C-000A95A51C9E@sun.com>
	 <1090693415.2037.118.camel@homer>  <4102ADA0.3060901@intertwingly.net>
Content-Type: text/plain
Message-Id: <1090696918.2037.124.camel@homer>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) 
Date: Sat, 24 Jul 2004 20:21:58 +0100
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 Sat, 2004-07-24 at 19:42, Sam Ruby wrote:
> Dave Pawson wrote:
> 
> >>>http://www.intertwingly.net/wiki/pie/PaceDateline
> > 
> > Says, The "atom:dateline" element is a Date construct that indicates the
> > date and place of origin
> 
> The dictionary definition of the word dateline, explicitly linked from 
> the PaceDateline page and repeated inside the page itself, is:
> 
>      A phrase at the beginning of a newspaper or magazine article that
>      gives the date and place of its origin.

sorry Sam, I'd missed that. I guess that's an Americanism. 
Certainly not familiar to me.


> I am not certain why that definition would make this tag non-semantic. 
>From my interpretation, not the reference, 'tis all.


> > What's the process for comments?
> > Edit the wiki page?
> > (Thought I'd better ask first)
> 
>  From http://www.intertwingly.net/wiki/pie/CategoryProposals :
> 
>     Discussion about proposals is to take place on the mailing list.
With recognised 'editors' amending the wiki?
Is that it?


-- 
Regards DaveP.
XSLT&Docbook  FAQ
http://www.dpawson.co.uk/xsl




From owner-atom-syntax@mail.imc.org  Sat Jul 24 15: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 PAA07521
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 15:34:32 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OJPRPB049744;
	Sat, 24 Jul 2004 12:25: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 i6OJPRSH049743;
	Sat, 24 Jul 2004 12:25: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 (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OJPQVk049735
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 12:25: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 D2EBD7C0F3; Sat, 24 Jul 2004 22:21:38 +0200 (CEST)
To: "Eric Scheid" <eric.scheid@ironclad.net.au>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Propose partial consensus on dates
References: <BD28DE91.222E3%eric.scheid@ironclad.net.au>
Message-ID: <opsbnprlcvuvpchu@quark>
Date: Sat, 24 Jul 2004 21:29:35 +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: <BD28DE91.222E3%eric.scheid@ironclad.net.au>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 25 Jul 2004 03:50:41 +1000, Eric Scheid  
<eric.scheid@ironclad.net.au> wrote:

>> With immutable 'issued' + 'supersede', this will apply as well. No one
>> needs to implement support for it, even, because it's supported already.
>
> by "supported" you mean today's aggregators will clutter up my daily feed
> reading with multiple versions of the essentially same entry?

They already do that, don't they? If not, how do current aggregators  
differentiate entries that has no ID?

-- 
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 Jul 24 15:34:49 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07552
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 15:34:48 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OJNsdp049678;
	Sat, 24 Jul 2004 12:23:54 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6OJNsJk049677;
	Sat, 24 Jul 2004 12:23:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OJNrN9049660
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 12:23: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 9D6977C0F3; Sat, 24 Jul 2004 22:20:05 +0200 (CEST)
Date: Sat, 24 Jul 2004 21:28:00 +0200
To: "Sam Ruby" <rubys@intertwingly.net>
Subject: Re: PaceDateline
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <41027456.5040109@intertwingly.net> <E71F04E4-DD90-11D8-8C8C-000A95A51C9E@sun.com> <4102A135.7040708@intertwingly.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: <opsbnpoylzuvpchu@quark>
In-Reply-To: <4102A135.7040708@intertwingly.net>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 24 Jul 2004 13:49:41 -0400, Sam Ruby <rubys@intertwingly.net>  
wrote:

>      At this time, THE SYNTAX FOR providing location information has not
>      been fleshed out.

Can't Atom use the XMLNews' <dateline>[1], as suggested by Walter  
Underwood (I think):

   <dateline>
     <location><city>Bangkok</city></location>
     <story.date>May 31, 1999</story.date>
   </dateline>

The exact syntax might need a bit tweaking, but allowing <dateline> to be  
a complexType makes it easier to express different things, at least.

____
[1] <url: http://www.xmlnews.org/docs/story-spec.html#element.dateline>

-- 
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 Jul 24 15:49:21 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08266
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 15:49: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 i6OJalTK050630;
	Sat, 24 Jul 2004 12:36: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 i6OJaluh050629;
	Sat, 24 Jul 2004 12:36: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 i6OJakoo050622
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 12:36: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 D710C7C0F3; Sat, 24 Jul 2004 22:32:58 +0200 (CEST)
Date: Sat, 24 Jul 2004 21:40:56 +0200
To: "David Powell" <djpowell@djpowell.net>
Subject: Re: PaceDateline
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <41027456.5040109@intertwingly.net> <opsbndknqruvpchu@quark> <41027CC9.5060202@intertwingly.net> <opsbnj16g8uvpchu@quark> <1203005908.20040724191633@djpowell.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: <opsbnqaiaauvpchu@quark>
In-Reply-To: <1203005908.20040724191633@djpowell.net>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 24 Jul 2004 19:16:33 +0100, David Powell <djpowell@djpowell.net>  
wrote:

> So why would you require *every* Atom publication in the world to
> have an issued date.

Because every Atom publication in the world is of interest to me, and the  
projects I'm involved in. You, David, are a probable content provider to  
ePerSpace, for instance. If ePerSpace is clueless regarding the context  
you wrote your entry in, that matters.

> Aren't these requirements just local policies of the publishing
> system, rather than requirements that apply to all Atom publications?

I wish it was, but; no.

> I personally don't have a problem with issued, but it seems that where
> blogs supply both issued/created and modified dates, the issued dates
> tend not to be used by aggregators, so I'm not convinced that all
> entries should be forced to supply it unless it has a clear benefit to
> the majority of readers.

Just a note: RSS is new. Atom is even newer. The whole syndication space  
itself is pretty fresh.

We are specifying a format and an API that will cater for current needs  
for Atom, but they will also somewhat cater for future needs. Future needs  
for Atom will by no doubt be more advanced than the current. The simpler  
we create Atom at v 1.0, the less advanced use cases can it cater for in  
the future, because existing data will be of great importance to what  
future use cases might be.

-- 
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 Jul 24 15:51: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 PAA08346
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 15:51: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 i6OJiZGU051137;
	Sat, 24 Jul 2004 12:44:35 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6OJiZKD051136;
	Sat, 24 Jul 2004 12:44: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] (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 i6OJiWWI051130;
	Sat, 24 Jul 2004 12:44:33 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p0611040cbd286c192341@[10.20.30.249]>
In-Reply-To: <4102A8B2.9030900@dehora.net>
References: <41027456.5040109@intertwingly.net>
 <410292F3.4010005@dehora.net>
 <59FFC974-DD94-11D8-8C8C-000A95A51C9E@sun.com>
 <4102A8B2.9030900@dehora.net>
Date: Sat, 24 Jul 2004 12:43:14 -0700
To: Bill de =?iso-8859-1?Q?h=D3ra?=  <bill@dehora.net>, atom-syntax@imc.org
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: PaceDateline
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


At 7:21 PM +0100 7/24/04, Bill de hÓra wrote:
>I think if the dc:terms values are to be considered part of Atom, 
>they should be explicitly present, not presumed by their absence. 
>This Pace makes them present in Atom as a result of them not being 
>there.

How do you feel about "MUST handle atom:dateline, SHOULD handle the 
dateish dc:terms"?

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Sat Jul 24 15:53: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 PAA08401
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 15:53: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 i6OJis2M051159;
	Sat, 24 Jul 2004 12:44:54 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6OJisjA051158;
	Sat, 24 Jul 2004 12:44: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 (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OJiVdh051126
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 12:44: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 434CA7C0F3; Sat, 24 Jul 2004 22:40:44 +0200 (CEST)
Date: Sat, 24 Jul 2004 21:48:42 +0200
To: "Dare Obasanjo" <kpako@yahoo.com>
Subject: Re: Propose partial consensus on dates
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <20040724191240.48009.qmail@web41212.mail.yahoo.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: <opsbnqngaauvpchu@quark>
In-Reply-To: <20040724191240.48009.qmail@web41212.mail.yahoo.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 24 Jul 2004 12:12:40 -0700 (PDT), Dare Obasanjo <kpako@yahoo.com>  
wrote:

> Who cares what happens under the table?

Even though it's under the table, it's still very visible, seeing that  
_every_ W3C specification that has a previous version, links to it. Every  
version has a unique and retrievable URI, and every newer version  
supersedes an older one.

> We are discussing a syndication format used for displaying
> metadata to readers

That's maybe what you are interested in. I'm primarily interested in how  
Atom can be used and understood by machines and programs. If that data can  
be worked like hand-in-a-glove by a program, the program can easilly  
present it to a human reader, if that's what the program's intention is.

> not for accurately describing the custom features of every CMS
> in the world.

That's not what I'm trying to do either.

-- 
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 Jul 24 16:16: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 QAA09768
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 16:16: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 i6OK4PvN053092;
	Sat, 24 Jul 2004 13:04: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 i6OK4PWh053091;
	Sat, 24 Jul 2004 13:04: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 (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OK4NNK053083
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 13:04:24 -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 256087C0F3; Sat, 24 Jul 2004 23:00:37 +0200 (CEST)
Date: Sat, 24 Jul 2004 22:08:42 +0200
To: "Eric Scheid" <eric.scheid@ironclad.net.au>
Subject: Re: Date Options Analysis: Issued
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <BD28BA10.22265%eric.scheid@ironclad.net.au>
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: <opsbnrksn6uvpchu@quark>
In-Reply-To: <BD28BA10.22265%eric.scheid@ironclad.net.au>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 25 Jul 2004 01:14:56 +1000, Eric Scheid  
<eric.scheid@ironclad.net.au> wrote:

> I think Roger is referring to a situation not unlike the following:
>
> 09:00 - your publishing application retrieves the feed,
>         finds an entry id=#1 with 'issued'=2004-07-24T08:00Z
> 09:30 - some edits are made, new entries created, etc
> 10:00 - your publishing application again retrieves the feed
>         finds an entry id=#1 with 'issued'=2004-07-24T08:15Z
> 10:01 - techs run screaming as the publishing application
>         erupts in a fiery blaze of sparks?

No. What is more probable to happen, is the following:

   09:00 - Our aggregator is offline due to upgrades

   09:00 - The owner of feed X publishes a set of new entries

   09:30 - The owner of feed X edits an entry with id=#1, and
           gives it a new 'issued' date.

   10:00 - Our aggregator retrieves feed X and finds an entry
           id=#1 with 'issued'=2004-07-24T08:15Z

   10:01 - No one will ever know that the entry was originally
           issued at 2004-07-24T08:00Z

-- 
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 Jul 24 16:20: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 QAA09878
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 16:20: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 i6OK9RZL053514;
	Sat, 24 Jul 2004 13:09: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 i6OK9RbO053513;
	Sat, 24 Jul 2004 13:09: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 (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OK9Qhh053506
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 13:09: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 0D1A17C0F3; Sat, 24 Jul 2004 23:05:39 +0200 (CEST)
To: =?iso-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceDateline
References: <41027456.5040109@intertwingly.net> <410292F3.4010005@dehora.net> <59FFC974-DD94-11D8-8C8C-000A95A51C9E@sun.com> <4102A8B2.9030900@dehora.net>
Message-ID: <opsbnrs8e1uvpchu@quark>
Date: Sat, 24 Jul 2004 22:13:46 +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: <4102A8B2.9030900@dehora.net>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 24 Jul 2004 19:21:38 +0100, Bill de hÓra <bill@dehora.net> wrote:

> It's a default behaviour not worth having. I think if the dc:terms  
> values are to be considered part of Atom, they should be explicitly  
> present, not presumed by their absence. This Pace makes them present in  
> Atom as a result of them not being there. Also, automatically inheriting  
> a value from one date into another date with different meaning may not  
> be desirable.

+2.

> Given the intense discussion around dates, it seems best that if someone
> wants to assert such terms they do so explicitly.

Yes. I don't want to assume anything. I want to know explicitly. I agree  
that optional elements in the core isn't of much value, but that is why I  
think 'issued' should be required.

If any elements are missing, they should be assumed to be missing. Their  
values are unknown. Nothing more, nothing less. Default values is  
something I thought we were moving away from, re the optional <author>  
element 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  Sat Jul 24 16:30: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 QAA10258
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 16:30: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 i6OKGuLG053803;
	Sat, 24 Jul 2004 13:16: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 i6OKGuUd053802;
	Sat, 24 Jul 2004 13:16:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from cat-proof.de (cat.cat-proof.de [213.239.198.176])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OKGsif053789
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 13:16:55 -0700 (PDT)
	(envelope-from sc@itst.net)
Received: from [192.168.1.10] (p50816F9D.dip0.t-ipconnect.de [80.129.111.157])
	by cat-proof.de (Postfix) with ESMTP id 33459340B660
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 22:15:23 +0200 (CEST)
Message-ID: <4102C42E.7020803@itst.net>
Date: Sat, 24 Jul 2004 22:18:54 +0200
From: Sascha Carlin <sc@itst.net>
User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707)
X-Accept-Language: de, en
MIME-Version: 1.0
To: atom-syntax@imc.org
Subject: Re: PaceDateline
References: <41027456.5040109@intertwingly.net> <opsbndknqruvpchu@quark> <41027CC9.5060202@intertwingly.net> <opsbnj16g8uvpchu@quark> <1203005908.20040724191633@djpowell.net> <opsbnqaiaauvpchu@quark>
In-Reply-To: <opsbnqaiaauvpchu@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:

> We are specifying a format and an API that will cater for current needs  
> for Atom, but they will also somewhat cater for future needs. Future 
> needs  for Atom will by no doubt be more advanced than the current. The 
> simpler  we create Atom at v 1.0, the less advanced use cases can it 
> cater for in  the future, because existing data will be of great 
> importance to what  future use cases might be.

+10

-- 
Sascha Carlin * Heinrich-Heine-Str. 1 * 64319 Pfungstadt
http://www.itst.org/         **         +49 6157 157 205



From owner-atom-syntax@mail.imc.org  Sat Jul 24 16:34: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 QAA10490
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 16:34: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 i6OKMrAB054058;
	Sat, 24 Jul 2004 13:22: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 i6OKMrTS054057;
	Sat, 24 Jul 2004 13:22: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 i6OKMqJU054045
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 13:22: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 D4F5B7C0F3; Sat, 24 Jul 2004 23:19:02 +0200 (CEST)
Date: Sat, 24 Jul 2004 22:27:07 +0200
To: "Tim Bray" <Tim.Bray@sun.com>
Subject: Re: PaceDateline
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <41027456.5040109@intertwingly.net> <opsbndknqruvpchu@quark> <41027CC9.5060202@intertwingly.net> <opsbnj16g8uvpchu@quark> <DF629C3B-DD9B-11D8-8C8C-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: <opsbnsfhcvuvpchu@quark>
In-Reply-To: <DF629C3B-DD9B-11D8-8C8C-000A95A51C9E@sun.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 24 Jul 2004 11:04:14 -0700, Tim Bray <Tim.Bray@Sun.COM> wrote:

> Given that a substantial proportion of publications are simply not going  
> to adopt your favored semantic of immutable-issued+supercede, I think  
> you're going to *have* to learn to live without "issued".

What is «a substantial proportion of publications», and who are  
responsible for them? Why is it impossible for weblogging tools to stamp  
the entries they issue with the instance in time they issue them?

I'd ask the same for 'created' and 'modified', but those aren't that  
important to me, so I won't.

> I think you would do much better to support Sam's proposal.

I'd live better with «missing 'issued' means missing issued» instead of  
'issued' having a default value equal to 'atom:dateline', but I still  
won't live good, since a formal 'issued' date is the most important date  
an entry can ever have in a publishing process.

> If dc:issued is present, that would be a good signal that this
> publication is using your semantics.

Yes, but why can't it always be present? Why is it such a difficult date  
to provide, and whenever someone wishes to provide it, they urge to modify  
it at a random pace? Why can't an immutable issued be required in the core?

> If your software can't run properly without your "issued" semantic,
> then it will *never* work correctly on (for example) my weblog

Why not? If Atom requires an 'issued' date, will you still not provide 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  Sat Jul 24 16:44: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 QAA10994
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 16:44: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 i6OKVool054466;
	Sat, 24 Jul 2004 13:31:50 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6OKVoFN054465;
	Sat, 24 Jul 2004 13:31:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OKVneh054459
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 13:31: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 1A4CE7C0F3; Sat, 24 Jul 2004 23:28:01 +0200 (CEST)
Date: Sat, 24 Jul 2004 22:36:11 +0200
To: "Eric Scheid" <eric.scheid@ironclad.net.au>
Subject: Re: PaceDateline
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <BD28E8CF.2231A%eric.scheid@ironclad.net.au>
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: <opsbnsulzguvpchu@quark>
In-Reply-To: <BD28E8CF.2231A%eric.scheid@ironclad.net.au>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 25 Jul 2004 04:34:23 +1000, Eric Scheid  
<eric.scheid@ironclad.net.au> wrote:

> Far better to have 'issued' missing than to have it polluted

I agree, but why would people pollute it? If it is managed 100% by the  
tool issuing the entries, how can it be polluted? And if tools have  
difficulties providing this date, why is that?

I understand that there will be cases where humans will b0rk something up,  
but if the most used tools implement and deploy a method that is  
compatible with my view on 'issued', those b0rked humans won't make much  
difference.

-- 
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 Jul 24 16:52:52 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11186
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 16:52:51 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OKfGcQ055207;
	Sat, 24 Jul 2004 13:41: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 i6OKfGVK055206;
	Sat, 24 Jul 2004 13:41: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 i6OKfFfE055199
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 13:41:15 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i6OKd353002197
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 14:39:03 -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 <0I1D00CDRISTHN@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sat, 24 Jul 2004 14:41:17 -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 <0I1D00KVEIST3Q@mail.sun.net> for atom-syntax@imc.org; Sat,
 24 Jul 2004 14:41:17 -0600 (MDT)
Date: Sat, 24 Jul 2004 13:41:28 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceDateline
In-reply-to: <4102C42E.7020803@itst.net>
To: "Atom-Syntax Syntax'" <atom-syntax@imc.org>
Message-id: <D6AAB52A-DDB1-11D8-8C8C-000A95A51C9E@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.618)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
References: <41027456.5040109@intertwingly.net> <opsbndknqruvpchu@quark>
 <41027CC9.5060202@intertwingly.net> <opsbnj16g8uvpchu@quark>
 <1203005908.20040724191633@djpowell.net> <opsbnqaiaauvpchu@quark>
 <4102C42E.7020803@itst.net>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6OKfFfE055201
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:
>
>> We are specifying a format and an API that will cater for current 
>> needs  for Atom, but they will also somewhat cater for future needs. 
>> Future needs  for Atom will by no doubt be more advanced than the 
>> current. The simpler  we create Atom at v 1.0, the less advanced use 
>> cases can it cater for in  the future, because existing data will be 
>> of great importance to what  future use cases might be.

Here is a list of technologies that, at the time of their arrival, were 
denounced as being "too simple": Unix, C, SQL, HTML, HTTP, XML, SMTP.  
Simple is good.  Simple gets adopted.  Simple wins.  -Tim



From owner-atom-syntax@mail.imc.org  Sat Jul 24 16: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 QAA11496
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 16: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 i6OKlFGY055449;
	Sat, 24 Jul 2004 13:47: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 i6OKlFSD055448;
	Sat, 24 Jul 2004 13:47:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from cat-proof.de (cat.cat-proof.de [213.239.198.176])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OKlE1h055435
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 13:47:14 -0700 (PDT)
	(envelope-from sc@itst.net)
Received: from [192.168.1.10] (p50816F9D.dip0.t-ipconnect.de [80.129.111.157])
	by cat-proof.de (Postfix) with ESMTP id 9BD88340B660
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 22:45:47 +0200 (CEST)
Message-ID: <4102CB4E.5030607@itst.net>
Date: Sat, 24 Jul 2004 22:49:18 +0200
From: Sascha Carlin <sc@itst.net>
User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707)
X-Accept-Language: de, en
MIME-Version: 1.0
To: atom-syntax@imc.org
Subject: Re: Propose partial consensus on dates
References: <BD28E7C1.22319%eric.scheid@ironclad.net.au>
In-Reply-To: <BD28E7C1.22319%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:

> I'd also prefer to sort on 'dateline' not 'issued', because I'd prefer to
> read things in the date order that they are about (content wise), and not
> the order in which someone got around to writing up their notes. Sorting by
> 'dateline' not 'issued' also means that any new entry with an older date
> stands out ... it's down the page, nestled amongst a bunch of read things.
> This is a subtle signal that it's been issued in out of date sequence, since
> I normally read things as they become available, and to take that into
> consideration regarding accuracy due to elapsed time effects on
> recollection. Sorting by issued doesn't give me that signal.
> 
> If it's below the scroll, I will still find it because my feed-reader of
> choice gives me an unread count for each feed.
> 
> So, sorting by 'dateline' makes more sense to me than sorting by 'updated'
> or 'issued'. I'd still make use of 'updated'. I still don't know what I'd do
> with 'issued'.

(I describe dates in words because there is no consensus about the 
format dateline should have.)

What exactly does the date in dateline refer to? We had the use case 
'journal', where entrys should be sorted day by day in the correct 
order, using 'dateline'.

That's a valid usecase, but what does it mean for other use cases? Take 
an entry in a department blog announcing a department meeting on this 
Tuesday, 9am localtime.

Taking the semantics from the first use case, 'dateline' should be 'this 
Tuesday, 9am localtime'. So my aggregator should display this entry on 
top of the list until either another entry comes with a dateline > 'this 
Tuesday, 9am localtime', for instance an entry about the department's 
summer party taking place at the restaurant across the street on '20th 
September 2004. Again, this entry should be displayed on top until, ... 
You get it.

So there may be situations ruled by local policies where we have entries 
with a dateline far far in the future.

Another problem with dateline - at least I feel it's a problem - is 
hidden in the the following use case: let's assume the entry about the 
summer party mentioned above. It's taking place in September, but the 
author - the dep. secretary - announces a meeting in August to plan the 
party. What would then be the 'dateline'? The meeting or the party? The 
secretary is not very into all this web-stuff and thinks that keeping a 
filofax is much more effective. So she may think, ok, it's about the 
party, right? I put the party's date inside this form field.

To make a long story short: 'dateline' is not an objective date. It 
depends on the authors view and we sure cannot believe all people around 
the world would have the same opionion about what date to put inside the 
same entry's dateline field.

'issued', 'updated', 'modified' and 'created' are objective. They define 
a clear point in time making a clear assertion about a certain step in 
the life on an entry/document (in Information Retrieval, all content 
entities are documents).

Sure 'dateline' is a neat thing to have. But it is not error prone 
enough to count on it.

-- 
Sascha Carlin * Heinrich-Heine-Str. 1 * 64319 Pfungstadt
http://www.itst.org/         **         +49 6157 157 205



From owner-atom-syntax@mail.imc.org  Sat Jul 24 17:10: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 RAA11890
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 17:10:54 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OKxwoM056571;
	Sat, 24 Jul 2004 13:59: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 i6OKxwRr056570;
	Sat, 24 Jul 2004 13:59:58 -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 i6OKxvDW056564
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 13:59:57 -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 i6OKvj53005363
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 14:57:45 -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 <0I1D00HEZJO1MS@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sat, 24 Jul 2004 15:00:02 -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 <0I1D00KFQJO03N@mail.sun.net> for atom-syntax@imc.org; Sat,
 24 Jul 2004 15:00:00 -0600 (MDT)
Date: Sat, 24 Jul 2004 14:00:11 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceDateline
In-reply-to: <opsbnsfhcvuvpchu@quark>
To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
Cc: Atom-Syntax <atom-syntax@imc.org>
Message-id: <73CB0D64-DDB4-11D8-8C8C-000A95A51C9E@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.618)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
References: <41027456.5040109@intertwingly.net> <opsbndknqruvpchu@quark>
 <41027CC9.5060202@intertwingly.net> <opsbnj16g8uvpchu@quark>
 <DF629C3B-DD9B-11D8-8C8C-000A95A51C9E@sun.com> <opsbnsfhcvuvpchu@quark>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6OKxvDW056565
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 Jul 24, 2004, at 1:27 PM, Asbjørn Ulsberg wrote:

>> Given that a substantial proportion of publications are simply not 
>> going to adopt your favored semantic of immutable-issued+supercede, I 
>> think you're going to *have* to learn to live without "issued".
>
> What is «a substantial proportion of publications», and who are 
> responsible for them? Why is it impossible for weblogging tools to 
> stamp the entries they issue with the instance in time they issue 
> them?

At 'ongoing', I frequently update entries in place.  I insist on doing 
this.  It works well.  I'm not going to stop. Thus, the only two dates 
that are meaningful for an 'ongoing' entry are its advertised date 
(what we've been calling 'dateline') and its last-modified date.  Thus 
an 'issued' that didn't change would be highly misleading, and an 
'issued' that did change would be identical to 'modified'.  I don't ask 
that you adopt my publishing semantics, but I also don't expect to 
adopt yours.  I am not the only one doing this, a huge number of 
weblogs work this way.  It's one of the good things about Web 
publishing is that you can revise/correct/amplify things in place.

I have spent some years in professional publishing technology and I 
fully, completely, totally, understand your model of publishing an 
immutable article and never revising but only superseding it.  I agree 
that it's appropriate for lots of applications.  But it isn't popular 
among a large part of the user base and it isn't going to become 
popular and you are just going to have to live with this fact.

>  a formal 'issued' date is the most important date an entry can ever 
> have in a publishing process.

In *your* publishing process.  Not mine.

> Why not? If Atom requires an 'issued' date, will you still not provide 
> it?

I'd probably stay with RSS, since it doesn't try to enforce a foreign 
publishing model on me. -Tim




From owner-atom-syntax@mail.imc.org  Sat Jul 24 17:14:07 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12090
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 17: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 i6OL3279056714;
	Sat, 24 Jul 2004 14: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 i6OL32De056713;
	Sat, 24 Jul 2004 14:03:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OL30oN056677
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 14:03:01 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 25 Jul 2004 07:08:06 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sun, 25 Jul 2004 07:02:25 +1000
Subject: Re: PaceDateline
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD290B81.22365%eric.scheid@ironclad.net.au>
In-Reply-To: <opsbnsulzguvpchu@quark>
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 i6OL32oN056708
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 25/7/04 6:36 AM, "Asbjørn Ulsberg" <asbjorn@tigerstaden.no> wrote:

>> Far better to have 'issued' missing than to have it polluted
> 
> I agree, but why would people pollute it? If it is managed 100% by the
> tool issuing the entries, how can it be polluted? And if tools have
> difficulties providing this date, why is that?

lack of capability in the tool + spec says 'issued' MUST be present
= some other date gets stuffed in there, including dates which change
= pollution

e.




From owner-atom-syntax@mail.imc.org  Sat Jul 24 17:14: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 RAA12112
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 17:14: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 i6OL40rB056744;
	Sat, 24 Jul 2004 14: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 i6OL4047056743;
	Sat, 24 Jul 2004 14:04:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OL3wOM056733
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 14:03:59 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 25 Jul 2004 07:09:37 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sun, 25 Jul 2004 07:03:55 +1000
Subject: Re: Date Options Analysis: Issued
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD290BDB.22365%eric.scheid@ironclad.net.au>
In-Reply-To: <opsbnrksn6uvpchu@quark>
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 i6OL3xOM056737
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 25/7/04 6:08 AM, "Asbjørn Ulsberg" <asbjorn@tigerstaden.no> wrote:

>> I think Roger is referring to a situation not unlike the following:
>> 
>> 09:00 - your publishing application retrieves the feed,
>>         finds an entry id=#1 with 'issued'=2004-07-24T08:00Z
>> 09:30 - some edits are made, new entries created, etc
>> 10:00 - your publishing application again retrieves the feed
>>         finds an entry id=#1 with 'issued'=2004-07-24T08:15Z
>> 10:01 - techs run screaming as the publishing application
>>         erupts in a fiery blaze of sparks?
> 
> No. What is more probable to happen, is the following:
>
> [Our aggregator misses the change]

that may well happen too.

it doesn't answer what your aggregator will do when it does come across an
entry which has a changed 'issued' date though.

remember: many blog feeds include entries covering many days, so unless your
aggregator is a real slow poke and only schedules a retrieval once a month
you are likely to see the changed 'issued'.

what does your tool then do? catch fire? dump core? reject the feed? reject
the entry? ignore the changed value?

e.




From owner-atom-syntax@mail.imc.org  Sat Jul 24 17:30: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 RAA12864
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 17: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 i6OLGAkq057659;
	Sat, 24 Jul 2004 14: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 i6OLGA3L057658;
	Sat, 24 Jul 2004 14:16:10 -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 i6OLGAvi057651
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 14:16:10 -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 i6OLGFJd016948;
	Sat, 24 Jul 2004 14:16:15 -0700 (PDT)
Received: from [192.168.1.101] (66-108-153-170.nyc.rr.com [66.108.153.170])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id i6OLGBaA020337;
	Sat, 24 Jul 2004 14:16:14 -0700 (PDT)
In-Reply-To: <4102A066.3020101@intertwingly.net>
References: <200407241615.i6OGF0TL007188@chromium.sabren.com> <4102A066.3020101@intertwingly.net>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1-727408051; protocol="application/pkcs7-signature"
Message-Id: <A7D4B42E-DDB6-11D8-9170-000A95DC3D90@mac.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: PaceDateline
Date: Sat, 24 Jul 2004 17:15:57 -0400
To: Sam Ruby <rubys@intertwingly.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-727408051
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 24 Jul 2004, at 1:46 pm, Sam Ruby wrote:

> First, let's look at the 80% use case.  In the case of weblogs, this 
> unquestionably is the case where created, valid, available, issued, 
> modified, accepted, copyrighted, and submitted are all simultaneous.

The problem here is requiring aggregators to infer something that may 
not be true. My example was <issued> could safely be used for a 
dateline in <dateline>'s absence. However it is not safe to say 
something has not been modified since creation in <modified>'s absence. 
You need to include wording in your proposal that says "you must 
include <dc:xxx> when <dc:xxx> is different from <dateline>" - 
currently it is only implied.

> So, I thought about the aggregators that I have used.  When presenting 
> views of "fresh news", what they mostly care about can be summed up as 
> "if I were to poll your site once a second, when would I have first 
> seen this entry?"  The refined date that most closely matches this 
> description is <available>, which coincidentally matches the spec 
> definition (as opposed to the popular usage) of the RSS pubDate.

Again, to ensure uniformity, the spec needs to encourage and/or mandate 
<available> (or equivalent) when it differs from dateline.

> I then thought about the subtle distinction between updated and 
> modified.  If aggregators are sorting on available, then I'm not sure 
> what they would do with another field.  Thinking about it a bit more, 
> one could argue that if somebody made a change and chose NOT to update 
> the value of available, then one could imply a bit of intent.

I don't like this line of thought. I'd probably use <updated> to flag 
an update in the listing (eg mark as unread). In fact I'd rather do 
that than sort by it (or at least have the choice of not sorting by 
it).

Graham
--Apple-Mail-1-727408051
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
9w0BCQUxDxcNMDQwNzI0MjExNTU3WjAjBgkqhkiG9w0BCQQxFgQU8XLvrzvjykcSoOjK9XasUHem
taoweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEALuJSZKNdOy/eIFI7d5Kuok79
ikSrVdeRYHDWvjkCizdyKb+bm8Z2lul9B9yaXS+5EOZp6PJtTiACpSP2Rr0c6myidnoDWHpJdNIt
lyGVpY71RP4As93W3CgQU3IKUI/ypPtm2hzhgMxzpzhvXiV0LRnJHjO/YY1zi3DL7gTWd91upSZK
sowZYUM63V0hgtHVf/vKP8l4lcCDpvJ50fhRQ17StQY1EqqQHMnFvWZ0sGo3WSWWT769wkurZZPV
OnauShIjFAaUxF1DpG9riIX9JSrotZfq6WvPv7UP7LFDhQ6E4dR4SjjK3cntN62qKMCJy2bIbNqN
VX05tyKBqSQcVAAAAAAAAA==

--Apple-Mail-1-727408051--



From owner-atom-syntax@mail.imc.org  Sat Jul 24 17: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 RAA12971
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 17:33: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 i6OLLPXt057879;
	Sat, 24 Jul 2004 14:21: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 i6OLLP6b057878;
	Sat, 24 Jul 2004 14:21:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from dumle.webhuset.no (dumle.webhuset.no [81.27.32.66])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6OLLOm6057871
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 14:21:24 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Message-Id: <200407242121.i6OLLOm6057871@above.proper.com>
Received: (qmail 15354 invoked from network); 24 Jul 2004 21:19:48 -0000
Received: from unknown (HELO localhost.localdomain) (81.27.34.17)
  by 0 with SMTP; 24 Jul 2004 21:19:48 -0000
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
MIME-Version: 1.0
From: "Arve Bersvendsen" <arve@virtuelvis.com>
To: Tim Bray <Tim.Bray@Sun.COM>, atom-syntax@imc.org
Subject: Re: PaceDateline
Date: Sat, 24 Jul 2004 23:21:23 +0200
X-Mailer: WHMail 1.0 (http://www.webhuset.no)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6OLLPm6057873
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:

> Here is a list of technologies that, at the time of their arrival, were 
> denounced as being "too simple": Unix, C, SQL, HTML, HTTP, XML, SMTP.  
> Simple is good.  Simple gets adopted.  Simple wins.  -Tim

Could we please at least _attempt_ to refrain from wilfully commiting
fallacies when making our arguments?

That Unix was claimed to be too simple, yet wins does not imply that if Atom
is claimed to be "too simple", Atom wins. 



From owner-atom-syntax@mail.imc.org  Sat Jul 24 17:41:43 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13272
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 17:41: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 i6OLUafN058339;
	Sat, 24 Jul 2004 14:30: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 i6OLUaTZ058338;
	Sat, 24 Jul 2004 14:30:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from cat-proof.de (cat.cat-proof.de [213.239.198.176])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OLUZIJ058331
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 14:30:36 -0700 (PDT)
	(envelope-from sc@itst.net)
Received: from [192.168.1.10] (p50816F9D.dip0.t-ipconnect.de [80.129.111.157])
	by cat-proof.de (Postfix) with ESMTP id EFF0C340B660
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 23:29:08 +0200 (CEST)
Message-ID: <4102D578.1060908@itst.net>
Date: Sat, 24 Jul 2004 23:32:40 +0200
From: Sascha Carlin <sc@itst.net>
User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707)
X-Accept-Language: de, en
MIME-Version: 1.0
To: "Atom-Syntax Syntax'" <atom-syntax@imc.org>
Subject: Re: PaceDateline
References: <41027456.5040109@intertwingly.net> <opsbndknqruvpchu@quark> <41027CC9.5060202@intertwingly.net> <opsbnj16g8uvpchu@quark> <1203005908.20040724191633@djpowell.net> <opsbnqaiaauvpchu@quark> <4102C42E.7020803@itst.net> <D6AAB52A-DDB1-11D8-8C8C-000A95A51C9E@sun.com>
In-Reply-To: <D6AAB52A-DDB1-11D8-8C8C-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:

>>> We are specifying a format and an API that will cater for current 
>>> needs  for Atom, but they will also somewhat cater for future needs. 
>>> Future needs  for Atom will by no doubt be more advanced than the 
>>> current. The simpler  we create Atom at v 1.0, the less advanced use 
>>> cases can it cater for in  the future, because existing data will be 
>>> of great importance to what  future use cases might be.
> 
> Here is a list of technologies that, at the time of their arrival, were 
> denounced as being "too simple": Unix, C, SQL, HTML, HTTP, XML, SMTP.  
> Simple is good.  Simple gets adopted.  Simple wins.  -Tim

And simple things are updated. Isn't that exactly what we are doing 
here? Taking 'simple' RSS and updateing it?

That's just the way it goes, old things are replaced by new ones. But 
some things are created with the future in mind. Think of SGML. It lives 
up until today. On the opposite, take the efforts the Germans made to 
build jets. They did not want to give up the single rear wheel and the 
whole thing blew up. Jets need to have a single (pair) front wheel and 
two (pairs) of rear wheels (actually these are under the middle of the 
jet, not at the rear, but what the heck ;) ).

This is a philisophical discussion and there are as many opionions as 
participants.

But can't we agree that creating something only by looking at the 
present is short-sighted? If one'd build a house one would build a roof 
so that it would be warm in winter and give shelter from autumn rain - 
even if the house would be build in summer, right?

-- 
Sascha Carlin * Heinrich-Heine-Str. 1 * 64319 Pfungstadt
http://www.itst.org/         **         +49 6157 157 205



From owner-atom-syntax@mail.imc.org  Sat Jul 24 17:48: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 RAA13451
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 17:48: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 i6OLb9dO058642;
	Sat, 24 Jul 2004 14:37: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 i6OLb9T7058641;
	Sat, 24 Jul 2004 14:37:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OLb80B058630
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 14:37: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 14CD77C0F3; Sun, 25 Jul 2004 00:33:21 +0200 (CEST)
Date: Sat, 24 Jul 2004 23:40:44 +0200
To: "Eric Scheid" <eric.scheid@ironclad.net.au>
Subject: Re: Date Options Analysis: Issued
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <BD290BDB.22365%eric.scheid@ironclad.net.au>
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: <opsbnvt6emuvpchu@quark>
In-Reply-To: <BD290BDB.22365%eric.scheid@ironclad.net.au>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 25 Jul 2004 07:03:55 +1000, Eric Scheid  
<eric.scheid@ironclad.net.au> wrote:

> it doesn't answer what your aggregator will do when it does come across  
> an entry which has a changed 'issued' date though.

Currently, it won't do anything, because it doesn't exist. We will try to  
create it after Atom's model as closely as possible, and if we face a  
mutated 'issued', I'm not sure how we should react. We might insert it as  
a supersede of the previous entry we have in our database, or at least as  
a version of the entry under the same ID, but without knowledge of its  
relation to the previous entry we have.

Nothing will catch fire, but it is loss of important data not to know when  
the entry was first issued. And that's a loss I won't swallow very easilly.

-- 
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 Jul 24 17:58: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 RAA13990
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 17:58: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 i6OLkq6s059312;
	Sat, 24 Jul 2004 14:46: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 i6OLkp2G059291;
	Sat, 24 Jul 2004 14:46:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from cat-proof.de (cat.cat-proof.de [213.239.198.176])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OLkmrs059216
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 14:46:48 -0700 (PDT)
	(envelope-from sc@itst.net)
Received: from [192.168.1.10] (p50816F9D.dip0.t-ipconnect.de [80.129.111.157])
	by cat-proof.de (Postfix) with ESMTP id 92954340B660
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 23:45:21 +0200 (CEST)
Message-ID: <4102D944.5090906@itst.net>
Date: Sat, 24 Jul 2004 23:48:52 +0200
From: Sascha Carlin <sc@itst.net>
User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707)
X-Accept-Language: de, en
MIME-Version: 1.0
To: atom-syntax@imc.org
Subject: Re: Propose partial consensus on dates
References: <BD28E7C1.22319%eric.scheid@ironclad.net.au> <4102CB4E.5030607@itst.net>
In-Reply-To: <4102CB4E.5030607@itst.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


Sorry for double posting, I forgot something to second my point.

> Sure 'dateline' is a neat thing to have. But it is not error prone 
> enough to count on it.

'dateline' and its idea to come from professional journalism/publishing. 
Can we really rely on Joe Average to do the job of a long-studied and 
trained journalist?

-- 
Sascha Carlin * Heinrich-Heine-Str. 1 * 64319 Pfungstadt
http://www.itst.org/         **         +49 6157 157 205



From owner-atom-syntax@mail.imc.org  Sat Jul 24 18:12: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 SAA15634
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 18:12: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 i6OM12lt060351;
	Sat, 24 Jul 2004 15:01:02 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6OM128R060350;
	Sat, 24 Jul 2004 15:01:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OM11U6060332
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 15:01: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 41ABE7C0F3; Sun, 25 Jul 2004 00:57:14 +0200 (CEST)
Date: Sun, 25 Jul 2004 00:04:43 +0200
To: "Tim Bray" <Tim.Bray@sun.com>
Subject: Re: PaceDateline
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <41027456.5040109@intertwingly.net> <opsbndknqruvpchu@quark> <41027CC9.5060202@intertwingly.net> <opsbnj16g8uvpchu@quark> <1203005908.20040724191633@djpowell.net> <opsbnqaiaauvpchu@quark> <4102C42E.7020803@itst.net> <D6AAB52A-DDB1-11D8-8C8C-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: <opsbnwx5gsuvpchu@quark>
In-Reply-To: <D6AAB52A-DDB1-11D8-8C8C-000A95A51C9E@sun.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 24 Jul 2004 13:41:28 -0700, Tim Bray <Tim.Bray@Sun.COM> wrote:

> Here is a list of technologies that, at the time of their arrival, were  
> denounced as being "too simple": Unix, C, SQL, HTML, HTTP, XML, SMTP.

So since calf is meat, and meat is good, rat is also good since rat is  
meat?

-- 
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 Jul 24 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 SAA15703
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 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 i6OM1RqC060379;
	Sat, 24 Jul 2004 15:01:27 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6OM1RaX060378;
	Sat, 24 Jul 2004 15:01:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from dumle.webhuset.no (dumle.webhuset.no [81.27.32.66])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6OM1PWN060371
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 15:01:26 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Message-Id: <200407242201.i6OM1PWN060371@above.proper.com>
Received: (qmail 15483 invoked from network); 24 Jul 2004 21:59:50 -0000
Received: from unknown (HELO localhost.localdomain) (81.27.34.19)
  by 0 with SMTP; 24 Jul 2004 21:59:50 -0000
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
MIME-Version: 1.0
From: "Arve Bersvendsen" <arve@virtuelvis.com>
To: Tim.Bray@Sun.COM, atom-syntax@imc.org
Subject: Re: PaceDateline
Date: Sun, 25 Jul 2004 00:01:25 +0200
X-Mailer: WHMail 1.0 (http://www.webhuset.no)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6OM1QWN060373
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

> > Here is a list of technologies that, at the time of their arrival, were 
> > denounced as being "too simple": Unix, C, SQL, HTML, HTTP, XML, SMTP.  
> > Simple is good.  Simple gets adopted.  Simple wins.  -Tim
> 
> Could we please at least _attempt_ to refrain from wilfully commiting
> fallacies when making our arguments?
> 
> That Unix was claimed to be too simple, yet wins does not imply that if
Atom
> is claimed to be "too simple", Atom wins. 

Augh. Never press send by reflex. Addendum follows:

If Unix is claimed to be 'too simple' and Unix after all is 'sufficiently
complex' does NOT in any way imply that Atom is 'sufficiently complex'
whenever someone claims that Atom is 'too simple'



From owner-atom-syntax@mail.imc.org  Sat Jul 24 18:51: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 SAA17897
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 18:51: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 i6OMeBLm062755;
	Sat, 24 Jul 2004 15:40: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 i6OMeBsf062754;
	Sat, 24 Jul 2004 15:40: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 i6OMeAaC062734
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 15:40: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 EBABD7C0F3; Sun, 25 Jul 2004 01:36:18 +0200 (CEST)
Date: Sun, 25 Jul 2004 00:43:57 +0200
To: "Tim Bray" <Tim.Bray@sun.com>
Subject: Re: URI scheme delusions
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <OF031774D8.BEC98F6C-ON88256EDB.00084992-88256EDB.00090B2C@us.ibm.com> <opsbm7jgwuuvpchu@quark> <41026240.8020009@intertwingly.net> <410266E4.6040304@dehora.net> <14be96d304072408524788c699@mail.gmail.com> <02F0CB0F-DD90-11D8-8C8C-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: <opsbnyrj06uvpchu@quark>
In-Reply-To: <02F0CB0F-DD90-11D8-8C8C-000A95A51C9E@sun.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 24 Jul 2004 09:39:20 -0700, Tim Bray <Tim.Bray@Sun.COM> wrote:

> I assume Mark is being ironic, but whatever, he's entirely correct.  I  
> am increasingly convinced of the virtue of putting dates in URIs, as in  
> http://www.tbray.org/ongoing/When/200x/2004/07/24/WillYou [<== just an  
> example, no Atom-related content here].

+1. If one uses HTTP URI's as the atom:id scheme, the template one uses  
should be just as universally unique as 'tag' and LSID URI's, yes. Thus  
must dates be a part of the URI. If one don't want dates in the publicly  
available URI's, one should probably not use that as the atom:id, or at  
least provide two; one for atom:id that does a 303 to the other, which is  
the publicly available 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  Sat Jul 24 18:58: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 SAA18250
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 18:58:06 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6OMnAEc063249;
	Sat, 24 Jul 2004 15:49:10 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6OMnAss063248;
	Sat, 24 Jul 2004 15:49: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 i6OMn9Fx063241
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 15:49: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 15EB17C0F3; Sun, 25 Jul 2004 01:45:22 +0200 (CEST)
Date: Sun, 25 Jul 2004 00:53:02 +0200
To: "Sascha Carlin" <sc@itst.net>
Subject: Re: Propose partial consensus on dates
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <BD28E7C1.22319%eric.scheid@ironclad.net.au> <4102CB4E.5030607@itst.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: <opsbny6odbuvpchu@quark>
In-Reply-To: <4102CB4E.5030607@itst.net>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 24 Jul 2004 22:49:18 +0200, Sascha Carlin <sc@itst.net> wrote:

> To make a long story short: 'dateline' is not an objective date.

No, it is highly subjective, which effectively makes it useless as a  
«stand-in» for any other dates.

> 'issued', 'updated', 'modified' and 'created' are objective.

Right on.

> Sure 'dateline' is a neat thing to have. But it is not error prone  
> enough to count on it.

Seeing that it will be provided by most blog publishers, I don't see the  
value in requiring it either. I don't understand what good it does for  
consumers, when present, that 'issued' and 'modified' can't cater for.  
Requiring 'issued' and 'modified' makes much more sense, as they can  
always work as stand-in dates for 'dateline', but it can never be the  
other way around.

-- 
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 Jul 24 19:01:06 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18403
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 19:01: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 i6OMr9aZ063397;
	Sat, 24 Jul 2004 15:53: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 i6OMr9BI063396;
	Sat, 24 Jul 2004 15:53:09 -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 i6OMr9ra063388
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 15:53:09 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040724225309.19857.qmail@web41211.mail.yahoo.com>
Received: from [67.160.87.187] by web41211.mail.yahoo.com via HTTP; Sat, 24 Jul 2004 15:53:09 PDT
Date: Sat, 24 Jul 2004 15:53:09 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Propose partial consensus on dates
To: "Asbjørn_Ulsberg" <asbjorn@tigerstaden.no>
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <opsbm8uyfxuvpchu@quark>
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>


--- Asbjørn_Ulsberg <asbjorn@tigerstaden.no> wrote:
> 
> There is a way. It is called «superseding». But if
> your aggregator doesn't  
> support the superseding mechanism, then it will
> appear as a new entry. Can  
> you tell me how RSS Bandit deals with modifications
> to an entry today,  
> when most entries don't even have ID's?

http://www.imc.org/atom-syntax/mail-archive/msg07673.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 - 100MB free storage!
http://promotions.yahoo.com/new_mail 



From owner-atom-syntax@mail.imc.org  Sat Jul 24 19:08:11 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18618
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 19:08: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 i6OMurPk063602;
	Sat, 24 Jul 2004 15:56: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 i6OMurOl063601;
	Sat, 24 Jul 2004 15:56: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 i6OMurJ1063595
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 15:56:53 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040724225653.65915.qmail@web41208.mail.yahoo.com>
Received: from [67.160.87.187] by web41208.mail.yahoo.com via HTTP; Sat, 24 Jul 2004 15:56:53 PDT
Date: Sat, 24 Jul 2004 15:56:53 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Propose partial consensus on dates
To: Arve Bersvendsen <arve@virtuelvis.com>
Cc: 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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


--- Arve Bersvendsen <arve@virtuelvis.com> wrote:
> 
> You're wrong. Atom is more than what you choose to
> expose to the user through
> RSSBandit.  Atom is a syndication format for
> reading, it is an
> editing/publishing protocol, and it is an archive
> format. Never forget that.

I haven't. Unfortunately all the people pushing pet
features that make no sense in the syndication or
editing/publishing scenario seem to have. 


=====
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  Sat Jul 24 19:19: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 TAA19160
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 19:19: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 i6ON841X064083;
	Sat, 24 Jul 2004 16: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 i6ON84Rm064082;
	Sat, 24 Jul 2004 16:08:04 -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 i6ON83LM064074
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 16:08:03 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040724230803.78902.qmail@web41210.mail.yahoo.com>
Received: from [67.160.87.187] by web41210.mail.yahoo.com via HTTP; Sat, 24 Jul 2004 16:08:03 PDT
Date: Sat, 24 Jul 2004 16:08:03 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Propose partial consensus on dates
To: "Asbjørn_Ulsberg" <asbjorn@tigerstaden.no>
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <opsbnzy9bkuvpchu@quark>
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>


--- Asbjørn_Ulsberg <asbjorn@tigerstaden.no> wrote:
>
> >
>
http://www.imc.org/atom-syntax/mail-archive/msg07673.html
> 
> Okay. How is it different, then, when an entry
> reappears in an entry  
> without an ID, and when an entry that supersedes an
> old one, does?

I have no idea what you are asking. How does an entry
reappear in an entry? What does one entry superseding
another look like in an RSS feed? 

=====
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  Sat Jul 24 19:20:58 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19202
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 19: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 i6ON6DQl064019;
	Sat, 24 Jul 2004 16: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 i6ON6DTx064018;
	Sat, 24 Jul 2004 16:06: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 i6ON6CPC064009
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 16:06: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 B54317C0F3; Sun, 25 Jul 2004 02:02:25 +0200 (CEST)
To: "Dare Obasanjo" <kpako@yahoo.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Propose partial consensus on dates
References: <20040724225309.19857.qmail@web41211.mail.yahoo.com>
Message-ID: <opsbnzy9bkuvpchu@quark>
Date: Sun, 25 Jul 2004 01:10:11 +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: <20040724225309.19857.qmail@web41211.mail.yahoo.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 24 Jul 2004 15:53:09 -0700 (PDT), Dare Obasanjo <kpako@yahoo.com>  
wrote:

>> Can you tell me how RSS Bandit deals with modifications to an entry
>> today, when most entries don't even have ID's?
>
> http://www.imc.org/atom-syntax/mail-archive/msg07673.html

Okay. How is it different, then, when an entry reappears in an entry  
without an ID, and when an entry that supersedes an old one, does?

-- 
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 Jul 24 19:29: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 TAA19628
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 19:29: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 i6ONKsKh065058;
	Sat, 24 Jul 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 i6ONKsh4065057;
	Sat, 24 Jul 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 smtpgateway.itweb.no ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ONKrnw065044
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 16:20: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 CE7157C0F3; Sun, 25 Jul 2004 02:17:03 +0200 (CEST)
Date: Sun, 25 Jul 2004 01:24:51 +0200
To: "Dare Obasanjo" <kpako@yahoo.com>
Subject: Re: Propose partial consensus on dates
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <20040724230803.78902.qmail@web41210.mail.yahoo.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: <opsbn0npiiuvpchu@quark>
In-Reply-To: <20040724230803.78902.qmail@web41210.mail.yahoo.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 24 Jul 2004 16:08:03 -0700 (PDT), Dare Obasanjo <kpako@yahoo.com>  
wrote:

> I have no idea what you are asking. How does an entry
> reappear in an entry?

Sorry, I'm tired. An entry reappears in a feed, of course. If an entry  
without an ID reapperas in a feed (due to modifications), how is that  
different from an entry that supersedes another one, shows up?

> What does one entry superseding another look like in an RSS feed?

Since RSS supports extensions via namespaces, they would semantically be  
almost the same, with different ID's and with a <publishing:relation />  
element that points to the ID they supersede.

-- 
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 Jul 24 19:59: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 TAA20472
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 19:59: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 i6ONoVqu067807;
	Sat, 24 Jul 2004 16: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 i6ONoV2O067806;
	Sat, 24 Jul 2004 16:50: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 i6ONoUju067799
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 16:50: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 i6ONpTOE028412;
	Sat, 24 Jul 2004 19:51:32 -0400
Message-ID: <4102F674.5070007@intertwingly.net>
Date: Sat, 24 Jul 2004 19:53:24 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <atom-syntax@imc.org>
Subject: Re: PaceDateline - process issue
References: <41027456.5040109@intertwingly.net>	 <E71F04E4-DD90-11D8-8C8C-000A95A51C9E@sun.com>	 <1090693415.2037.118.camel@homer>  <4102ADA0.3060901@intertwingly.net> <1090696918.2037.124.camel@homer>
In-Reply-To: <1090696918.2037.124.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: <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


Dave Pawson wrote:
>>
>> From http://www.intertwingly.net/wiki/pie/CategoryProposals :
>>
>>    Discussion about proposals is to take place on the mailing list.
> 
> With recognised 'editors' amending the wiki?
> Is that it?

Everybody can make proposals on the wiki, as a general rule, discussion 
about proposals should occur on the mailing list.

http://www.intertwingly.net/wiki/pie/HowToGetInvolved

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Sat Jul 24 20:00: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 UAA20545
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 20:00: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 i6ONne9v067778;
	Sat, 24 Jul 2004 16:49: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 i6ONne1E067777;
	Sat, 24 Jul 2004 16:49:40 -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 i6ONndJ2067767
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 16:49:39 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040724234940.43822.qmail@web41206.mail.yahoo.com>
Received: from [67.160.87.187] by web41206.mail.yahoo.com via HTTP; Sat, 24 Jul 2004 16:49:40 PDT
Date: Sat, 24 Jul 2004 16:49:40 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Propose partial consensus on dates
To: "Asbjørn_Ulsberg" <asbjorn@tigerstaden.no>
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <opsbn0npiiuvpchu@quark>
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>


--- Asbjørn_Ulsberg <asbjorn@tigerstaden.no> wrote:
> 
> Sorry, I'm tired. An entry reappears in a feed, of
> course. If an entry  
> without an ID reapperas in a feed (due to
> modifications), how is that  
> different from an entry that supersedes another one,
> shows up?

When an entry [with a link or guid which has been
previously seen] reappears in a feed then RSS Bandit
silently updates the title and content of the entry it
has stored on the local machine. If the entry appears
with a different permalink or guid then it is treated
as a brand new entry. 
 
> > What does one entry superseding another look like
> in an RSS feed?
> 
> Since RSS supports extensions via namespaces, they
> would semantically be  
> almost the same, with different ID's and with a
> <publishing:relation />  
> element that points to the ID they supersede.

Gotcha.

=====
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  Sat Jul 24 20:14: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 UAA21020
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 20:14: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 i6P04Yla068340;
	Sat, 24 Jul 2004 17: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 i6P04YHn068339;
	Sat, 24 Jul 2004 17:04:34 -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 i6P04YOJ068330
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 17:04: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 (rwcrmhc11) with SMTP
          id <200407250004310130029ucje>; Sun, 25 Jul 2004 00:04:32 +0000
Date: Sat, 24 Jul 2004 18:04:30 -0600
Subject: Re: PaceDateline
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: <opsbnwx5gsuvpchu@quark>
Message-Id: <337ACDD8-DDCE-11D8-9941-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 i6P04YOJ068334
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, July 24, 2004, at 02:41  PM, Tim Bray wrote:
>> Here is a list of technologies that, at the time of their arrival, 
>> were denounced as being "too simple": Unix, C, SQL, HTML, HTTP, XML, 
>> SMTP.

On Saturday, July 24, 2004, at 04:04  PM, Asbjørn Ulsberg wrote:
> So since calf is meat, and meat is good, rat is also good since rat is 
> meat?

On Saturday, July 24, 2004, at 04:01  PM, Arve Bersvendsen wrote:
> Augh. Never press send by reflex. Addendum follows:
>
> If Unix is claimed to be 'too simple' and Unix after all is 
> 'sufficiently
> complex' does NOT in any way imply that Atom is 'sufficiently complex'
> whenever someone claims that Atom is 'too simple'

On Saturday, July 24, 2004, at 03:21  PM, Arve Bersvendsen wrote:
> Could we please at least _attempt_ to refrain from wilfully commiting
> fallacies when making our arguments?
>
> That Unix was claimed to be too simple, yet wins does not imply that 
> if Atom
> is claimed to be "too simple", Atom wins.

Sheesh people.  I hardly think Tim was arguing that "denounced as too 
simple" == "good", and "not denounced as too simple" == "bad".  The 
point is that technologies that avoid complexity that isn't required by 
most users are more likely to succeed than technologies that have the 
ability to handle everything, even though almost nobody needs it.  
Remember "80/20".  If the Atom core requires[1] support for, for 
example, a complex system for indicating which entries supercede other 
entries, which 20% (or less) of users need, then 80% (or more) of the 
target market is going to be less receptive to Atom.  They may stick 
with RSS ("it gets the job done, even if not perfectly, and I don't 
have to deal with this 'supercedes' stuff"), or they may adopt the next 
format that someone proposes to fix RSS's problems, which doesn't carry 
the burden of complexity that they don't need.

I understand that for what some of you do, "supercedes" and such are 
important.  So build an extension.  We all need to be broad minded 
enough to consider the needs of the various stakeholders, and to be 
willing to move features out of the core if they fall on the 20 side of 
80/20 and would impose a non-trivial burden on the 80.  If it turns out 
that a mojority of people DO need something that got stuck into an 
extension, fine.  Support for the extension will become a standard 
feature.

Given that using an extension in a feed isn't significantly more 
difficult than using core elements, I think that without overdoing it, 
we should aim for simplicity in the core, and not be too put out if 
some things end up in extensions.

Antone

[1] It's been said before, but I'll say it again: you can claim that 
nothing special needs to be done to support the superceding mechanism, 
but any aggregator that doesn't implement it is going to have users 
screaming about duplicate entries and jumping ship to another 
aggregator.




From owner-atom-syntax@mail.imc.org  Sat Jul 24 20:59: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 UAA22448
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 20:59: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 i6P0lSdI070222;
	Sat, 24 Jul 2004 17:47: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 i6P0lS4K070221;
	Sat, 24 Jul 2004 17:47:28 -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 i6P0lQl1070210
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 17:47:27 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p06110415bd28b369aca5@[10.20.30.249]>
In-Reply-To: <337ACDD8-DDCE-11D8-9941-003065EA6144@geckotribe.com>
References: <337ACDD8-DDCE-11D8-9941-003065EA6144@geckotribe.com>
Date: Sat, 24 Jul 2004 17:47:29 -0700
To: atom-syntax@imc.org
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: PaceDateline
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 6:04 PM -0600 7/24/04, Antone Roundy wrote:
>I understand that for what some of you do, "supercedes" and such are 
>important.  So build an extension.

+1. 'Nuff said.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Sat Jul 24 21:19: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 VAA23222
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 21:19: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 i6P19r3D071550;
	Sat, 24 Jul 2004 18: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 i6P19rnn071549;
	Sat, 24 Jul 2004 18:09:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from beta.verity.com (beta.verity.com [192.187.143.12])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6P19r0J071531
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 18:09: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 SAA21751
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 18:09:51 -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 SAA13618
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 18:09:51 -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); Sat, 24 Jul 2004 18:09:51 -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 <0I1D00B1OV8C9N@shazam.verity.com> for atom-syntax@imc.org; Sat,
 24 Jul 2004 18:09:50 -0700 (PDT)
Date: Sat, 24 Jul 2004 18:09:48 -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: URI scheme delusions
In-reply-to: <BD28B930.22260%eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: 
 <D27F1C535244EC7D9A184F00@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: <BD28B930.22260%eric.scheid@ironclad.net.au>
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 24/7/04 11:21 PM, "Sam Ruby" <rubys@intertwingly.net> wrote:
>
> My belief is that if, and only if, you own your own domain name, then
> making the id match the permalink is a good idea.

That isn't sufficient. Infoseek owned it's own domain, but
http://software.infoseek.com/ no longer points to Ultraseek.
Disney bought Infoseek, renamed it, sold our bits to Inktomi,
who sold them to Verity. Six years, four domains.

Luckily, search engines usually don't care about IDs that
are unique for 10,000 years. They are more concerned with
keeping up with the current state of the universe. If you
want history, you have to keep your own archive.

Hmm, time to invite Brewster Kahle to chime in?

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Sat Jul 24 21:54: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 VAA24753
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 21:54: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 i6P1kFOs073519;
	Sat, 24 Jul 2004 18:46: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 i6P1kFPm073518;
	Sat, 24 Jul 2004 18:46:15 -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 i6P1kE6T073504
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 18:46:14 -0700 (PDT)
	(envelope-from wunder@verity.com)
Received: from mx-rr.verity.com ([10.3.100.59])
	by beta.verity.com (8.9.3/8.9.3) with ESMTP id SAA23182
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 18:46:16 -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 SAA16755
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 18:46:15 -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); Sat, 24 Jul 2004 18:46:15 -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 <0I1D00BI2WX19N@shazam.verity.com> for atom-syntax@imc.org; Sat,
 24 Jul 2004 18:46:15 -0700 (PDT)
Date: Sat, 24 Jul 2004 18:46:12 -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: PaceDateline
In-reply-to: <p06110415bd28b369aca5@[10.20.30.249]>
To: atom-syntax@imc.org
Message-id: 
 <A5B2DC6A7861A232B4E0ACE0@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: <337ACDD8-DDCE-11D8-9941-003065EA6144@geckotribe.com>
 <p06110415bd28b369aca5@[10.20.30.249]>
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, July 24, 2004 5:47 PM -0700 "Paul Hoffman / IMC" <phoffman@imc.org> wrote:
>
> At 6:04 PM -0600 7/24/04, Antone Roundy wrote:
>> I understand that for what some of you do, "supercedes" and such are
>> important.  So build an extension.
>
> +1. 'Nuff said.

I'm not sure that an extension is the right approach. PRISM already
exists (www.prismstandard.org), and has an aggregator DTD. These
issues sound like they belong in PRISM, not in Atom.

Is Atom designed to be the core of a publishing system or the edge?
If it is the edge, then it is a simplified view of the (very real)
issues internal to publishing.

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Sat Jul 24 21: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 VAA24947
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 21: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 i6P1mgWb073650;
	Sat, 24 Jul 2004 18:48: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 i6P1mgmr073649;
	Sat, 24 Jul 2004 18:48:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6P1mfMm073643
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 18:48:41 -0700 (PDT)
	(envelope-from murata@hokkaido.email.ne.jp)
Received: from [127.0.0.1] (g039162.ppp.asahi-net.or.jp [211.132.39.162])
	by mail.asahi-net.or.jp (Postfix) with ESMTP id 06E657EC8
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 10:48:47 +0900 (JST)
Date: Sun, 25 Jul 2004 10:48:06 +0900
From: MURATA Makoto <murata@hokkaido.email.ne.jp>
To: atom-syntax@imc.org
Subject: Fw: An I-D for text/xml, application/xml, etc.
Message-Id: <20040725104644.9C45.MURATA@hokkaido.email.ne.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.09.01 [ja]
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


Among other changes, this I-D deprecates text/xml, 
but recommends application/xml.

The mailing list for this I-D is ietf-xml-mime.imc.org. 
(http://www.imc.org/ietf-xml-mime/index.html).

Cheers,

Makoto

Forwarded by MURATA Makoto <murata@hokkaido.email.ne.jp>
----------------------- Original Message -----------------------
From:    MURATA Makoto <murata@hokkaido.email.ne.jp>
To:      ietf-xml-mime@imc.org
Date:    Sun, 25 Jul 2004 09:25:41 +0900
Subject: An I-D for text/xml, application/xml, etc.
----


Based on the discussions in this mailing list and W3C TAG, an 
I-D for XML media types has been created.  Major changes from 
RFC 3023 are as follows:

   First, text/xml and text/xml-external-parsed-entity are deprecated.
   Second, XPointer ([XPointerFramework] and [XPointerElement]) has been
   added as fragment identifiers for "application/xml".  Third, [XBase]
   has been added as a mechanism for specifying base URIs.  Fourth, many
   references are updated.

http://www.ietf.org/internet-drafts/draft-murata-kohn-lilley-xml-00.txt

Comments welcome.

Cheers,

-- 
MURATA Makoto <murata@hokkaido.email.ne.jp>


--------------------- Original Message Ends --------------------




From owner-atom-syntax@mail.imc.org  Sat Jul 24 22: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 WAA25182
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 22:02: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 i6P1rdnS073982;
	Sat, 24 Jul 2004 18:53:39 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6P1rdE2073981;
	Sat, 24 Jul 2004 18:53:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from sh163.net (mail1.sh163.net [202.96.194.132])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6P1rbSs073964
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 18:53:37 -0700 (PDT)
	(envelope-from xiaoxie@public4.sta.net.cn)
Message-Id: <200407250153.i6P1rbSs073964@above.proper.com>
Received: (rockmail 23452 invoked from network); 25 Jul 2004 01:53:34 -0000
Received: from unknown (HELO devhome) (xiaoxie@[222.64.188.133])
          (envelope-sender <xiaoxie@public4.sta.net.cn>)
          by 0 (Rockmail 2.0)
          for <atom-syntax@imc.org>; 25 Jul 2004 01:53:34 -0000
From: "Raymond Hsieh" <xiaoxie@public4.sta.net.cn>
To: "'Atom Syntax'" <atom-syntax@imc.org>, <owner-atom-syntax@mail.imc.org>
Subject: Getting feed with ATOM
Date: Sun, 25 Jul 2004 09:53:13 +0800
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:  <D27F1C535244EC7D9A184F00@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
Thread-Index: AcRx5aJxey8dB5uwQVSfxPPtw5/jwAABEKaw
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


Hi, 

I have a question regarding getting feed with Atom. 

I want to fetch all blog entries ever published on my blogspot, including
those archived. However, when I get feed with Atom, it only gave me a few,
not including the older entries (like those published in 2003). 

Any idea how I could get all the entries from my blogspot? 

Thanks, 
Raymond



From owner-atom-syntax@mail.imc.org  Sat Jul 24 22:45:02 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26958
	for <atompub-archive@lists.ietf.org>; Sat, 24 Jul 2004 22: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 i6P2S0iW075863;
	Sat, 24 Jul 2004 19:28:00 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6P2S0ro075862;
	Sat, 24 Jul 2004 19:28:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.196])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6P2RxsK075856
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 19:27:59 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id 74so51307rnl
        for <atom-syntax@imc.org>; Sat, 24 Jul 2004 19:28:05 -0700 (PDT)
Received: by 10.38.207.22 with SMTP id e22mr106080rng;
        Sat, 24 Jul 2004 19:28:05 -0700 (PDT)
Message-ID: <14be96d304072419285ec80400@mail.gmail.com>
Date: Sat, 24 Jul 2004 22:28:05 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Tim Bray <tim.bray@sun.com>
Subject: Re: URI scheme delusions
Cc: Sam Ruby <rubys@intertwingly.net>, "Bill de hÓra" <bill@dehora.net>,
        Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <02F0CB0F-DD90-11D8-8C8C-000A95A51C9E@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <OF031774D8.BEC98F6C-ON88256EDB.00084992-88256EDB.00090B2C@us.ibm.com>
 <opsbm7jgwuuvpchu@quark> <41026240.8020009@intertwingly.net>
 <410266E4.6040304@dehora.net> <14be96d304072408524788c699@mail.gmail.com> <02F0CB0F-DD90-11D8-8C8C-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 Sat, 24 Jul 2004 09:39:20 -0700, Tim Bray <tim.bray@sun.com> wrote:
> On Jul 24, 2004, at 8:52 AM, Mark Pilgrim wrote:
> 
> > If only there were some way to create an identifier that combined a
> > domain name with, say, a date on which you controlled that domain.
> 
> I assume Mark is being ironic, but whatever, he's entirely correct.  I
> am increasingly convinced of the virtue of putting dates in URIs, as in
> http://www.tbray.org/ongoing/When/200x/2004/07/24/WillYou [<== just an
> example, no Atom-related content here].

"Doctor, it hurts when I miss the point over and over."

If you lose the tbray.org domain, what then?  The new owner could
legitimately reuse this ID at any time to mean something else.  The
entire namespace belongs to them now; they can map it any way they
want without violating the http:// URI scheme.

urn: solves this by registering namespaces permanently.  (This
statement applies to informal and formal URNs.  Ad-hoc x- URNs have no
insurance against collision.)

tag: solves this by combining a domain name and a date to create a
namespace.  The date is a date on which you controlled the domain.

if http:// has a way of solving this that I'm missing, I would
appreciate being enlightened.

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Sun Jul 25 01:00:26 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02245
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 01:00:26 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6P4o91n083696;
	Sat, 24 Jul 2004 21:50: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 i6P4o9dA083695;
	Sat, 24 Jul 2004 21:50:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6P4o6lQ083688
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 21:50:07 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 25 Jul 2004 14:55:52 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sun, 25 Jul 2004 14:50:10 +1000
Subject: Re: PaceDateline
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD297922.22439%eric.scheid@ironclad.net.au>
In-Reply-To: <337ACDD8-DDCE-11D8-9941-003065EA6144@geckotribe.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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 25/7/04 10:04 AM, "Antone Roundy" <antone@geckotribe.com> wrote:

> I understand that for what some of you do, "supercedes" and such are
> important.  So build an extension.  We all need to be broad minded
> enough to consider the needs of the various stakeholders, and to be
> willing to move features out of the core if they fall on the 20 side of
> 80/20 and would impose a non-trivial burden on the 80.  If it turns out
> that a majority of people DO need something that got stuck into an
> extension, fine.  Support for the extension will become a standard
> feature.

+1



From owner-atom-syntax@mail.imc.org  Sun Jul 25 01:24: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 BAA03056
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 01: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 i6P5Ecth089076;
	Sat, 24 Jul 2004 22:14: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 i6P5EcwU089075;
	Sat, 24 Jul 2004 22:14:38 -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 i6P5EcZF089038
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 22:14:38 -0700 (PDT)
	(envelope-from distobj@acm.org)
Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian))
	id 1BobM4-0007jh-00; Sun, 25 Jul 2004 01:15:24 -0400
Date: Sun, 25 Jul 2004 01:15:24 -0400
To: Mark Pilgrim <pilgrim@gmail.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: URI scheme delusions
Message-ID: <20040725051524.GF30868@markbaker.ca>
References: <OF031774D8.BEC98F6C-ON88256EDB.00084992-88256EDB.00090B2C@us.ibm.com> <opsbm7jgwuuvpchu@quark> <41026240.8020009@intertwingly.net> <410266E4.6040304@dehora.net> <14be96d304072408524788c699@mail.gmail.com> <02F0CB0F-DD90-11D8-8C8C-000A95A51C9E@sun.com> <14be96d304072419285ec80400@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <14be96d304072419285ec80400@mail.gmail.com>
User-Agent: Mutt/1.3.28i
From: Mark Baker <distobj@acm.org>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


On Sat, Jul 24, 2004 at 10:28:05PM -0400, Mark Pilgrim wrote:
> If you lose the tbray.org domain, what then?  The new owner could
> legitimately reuse this ID at any time to mean something else.  The
> entire namespace belongs to them now; they can map it any way they
> want without violating the http:// URI scheme.
> 
> urn: solves this by registering namespaces permanently.

I don't think so.  There's nothing more permanent about URN namespace
registration than DNS name registration.  It might appear that way,
but that's illusory; should somebody register a namespace which uses
somebody else's trademark, you can guarantee that the courts would be
brought in - just as they would be with the DNS - and that there'd be a
chance that the name would be reassigned.

The problem is registries in general, not DNS in particular.

> tag: solves this by combining a domain name and a date to create a
> namespace.  The date is a date on which you controlled the domain.

Well - and this argument applies to URNs too - I suppose one way to
solve the problem of a new owner reusing the URI, is to make sure
that nobody, including the current owner, can use (read; dereference)
it.  Bah, sorry, that's not my idea of solution.  Important identifiers
should be dereferencable.

> if http:// has a way of solving this that I'm missing, I would
> appreciate being enlightened.

It doesn't solve it either.  It's just the best you can do with both a
name registry *and* dereferencability, IMO.

The fact is that persistence costs, you can't just institute it.
Registrants need to do the upfront legwork to ensure they're not using
somebody else's trademark.  They need to adopt careful policies. etc..
... which reminds me that I've written about this before;

http://www.markbaker.ca/2002/09/draft-connolly-w3c-accessible-registries-00.txt

Mark.



From owner-atom-syntax@mail.imc.org  Sun Jul 25 02:05: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 CAA10011
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 02:05: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 i6P5qikN006683;
	Sat, 24 Jul 2004 22:52: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 i6P5qiZV006682;
	Sat, 24 Jul 2004 22:52:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6P5qghK006668
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 22:52:42 -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 i6P5qoil023432
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 23:52:50 -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 <0I1E009NH8C1LU@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sat, 24 Jul 2004 23:52:50 -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 <0I1E003SW8BXL2@mail.sun.net> for atom-syntax@imc.org; Sat,
 24 Jul 2004 23:52:46 -0600 (MDT)
Date: Sat, 24 Jul 2004 22:52:58 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: URI scheme delusions
In-reply-to: <14be96d304072419285ec80400@mail.gmail.com>
To: Mark Pilgrim <pilgrim@gmail.com>
Cc: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>,
        Sam Ruby <rubys@intertwingly.net>, Atom-Syntax <atom-syntax@imc.org>
Message-id: <E162E7FC-DDFE-11D8-8C8C-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: 
 <OF031774D8.BEC98F6C-ON88256EDB.00084992-88256EDB.00090B2C@us.ibm.com>
 <opsbm7jgwuuvpchu@quark> <41026240.8020009@intertwingly.net>
 <410266E4.6040304@dehora.net> <14be96d304072408524788c699@mail.gmail.com>
 <02F0CB0F-DD90-11D8-8C8C-000A95A51C9E@sun.com>
 <14be96d304072419285ec80400@mail.gmail.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 Jul 24, 2004, at 7:28 PM, Mark Pilgrim wrote:

>>   I
>> am increasingly convinced of the virtue of putting dates in URIs, as 
>> in
>> http://www.tbray.org/ongoing/When/200x/2004/07/24/WillYou [<== just an
>> example, no Atom-related content here].
>
> If you lose the tbray.org domain, what then?  The new owner could
> legitimately reuse this ID at any time to mean something else.  The
> entire namespace belongs to them now; they can map it any way they
> want without violating the http:// URI scheme.
>
> urn: solves this by registering namespaces permanently.

It seems to me that the identifier remains valid as an identifier even 
if someone else owns the namespace, particularly if there's a lot of 
software out there that knows it.  The identifier's function as an 
identifier does not, in any protocol we're likely to design, have any 
dependency on what you might get when you dereference it.  For example, 
I'm quite sure that the character string 
"http://www.w3.org/XML/1998/namespace" (the URI for the "xml:" prefix) 
will remain widely recognized in software long after the W3C has faded 
away and w3.org is owned by Wholesale Wolves and Weasels, Inc.  It's 
just a character string and the character string need not change.  As 
long as I own the namespace, the identifier will be potentially more 
useful because you might be able to dereference it to get some 
explanatory/supporting material.  A URN or tag: or whatever removes the 
possibility of direct dereference by ubiquitous software, thus 
buying... uh, what?  I've never understood.  The most typical use case 
of an identifier is as an input to a call like strcmp(), which doesn't 
care in the slightest about URI schemes.

But can we please stop arguing?  Because it doesn't matter, I REALLY 
THINK it doesn't matter.  In Atom, there are going to be places where 
it says "this identifier should be a URI".  Those who really believe in 
a useful distinction between naming and location, or who believe that 
the URN registration process really produces longer-lived identifiers, 
can use that kind of URI.  Those of us who think that identifiers are 
made more useful by being potentially dereferencable will use HTTP 
URIs.   In a few decades we'll know who was right. -Tim



From owner-atom-syntax@mail.imc.org  Sun Jul 25 03:00: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 CAA21061
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 02:59: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 i6P6j4Ub027121;
	Sat, 24 Jul 2004 23:45: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 i6P6j4sN027120;
	Sat, 24 Jul 2004 23:45:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6P6j39P027104
	for <atom-syntax@imc.org>; Sat, 24 Jul 2004 23:45:04 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 25 Jul 2004 16:50:42 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sun, 25 Jul 2004 16:44:59 +1000
Subject: Re: URI scheme delusions
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD29940B.22526%eric.scheid@ironclad.net.au>
In-Reply-To: <20040725051524.GF30868@markbaker.ca>
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 i6P6j49P027114
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 25/7/04 3:15 PM, "Mark Baker" <distobj@acm.org> wrote:

>> tag: solves this by combining a domain name and a date to create a
>> namespace.  The date is a date on which you controlled the domain.
> 
> Well - and this argument applies to URNs too - I suppose one way to
> solve the problem of a new owner reusing the URI, is to make sure
> that nobody, including the current owner, can use (read; dereference)
> it.  Bah, sorry, that's not my idea of solution.  Important identifiers
> should be dereferencable.

A tag URI could be dereferenced, given a register with historical records.
Although tag base domains could be reassigned, they can't rewrite history
That is: stating that the domain name was under the control of some other
than the person who actually had that domain name under their control
(rightly or wrongly) at that time.

Given the rise of über-aggregators like syndic8, bloglines, technorati, etc
... it wouldn't be difficult for them to provide a dereferencing interface,
providing the last known URL for any given URI (tag, urn, LSID, etc).

e.




From owner-atom-syntax@mail.imc.org  Sun Jul 25 03: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 DAA21832
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 03:22: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 i6P77qb0035880;
	Sun, 25 Jul 2004 00: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 i6P77qnm035879;
	Sun, 25 Jul 2004 00:07:52 -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 i6P77n7T035866
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 00:07:51 -0700 (PDT)
	(envelope-from roger@agincourtmedia.com)
Received: from biggreen ([216.63.148.42]) by journurl.com with MailEnable ESMTP; Sun, 25 Jul 2004 02:07:30 -0500
From: "Roger B." <roger@agincourtmedia.com>
To: "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: RE: Date Options Analysis: Issued
Date: Sun, 25 Jul 2004 02:12:56 -0500
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: <opsbnb86y0uvpchu@quark>
Thread-Index: AcRxiyp24uXlteyYT3GjMJkhyrWRuAAhmRMw
Message-ID: <8D0C838FBFA146559761C1532C1EA4.MAI@journurl.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


> Since I've answered your questions regarding this, what is the solid use
> case for ever changing 'issued'?

Asbjorn: Happens every day. 

(1) User is on vacation and posts (via email) three messages documenting
three days of her trip. She hits "send", and all three messages get posted.
However, she has no way to specify the publish date from within her mail
client, so all three posts end up with today's date. When she gets home, she
logs in and fixes the problem.

(2) User posts via an API client that doesn't support user-specified pub
dates. Later, she has to log in and fix the problem.

(3) User keeps a rigid, daily diary, but forgets to post until 1AM the next
day. So he posts quickly before bed, and goes back in the morning to fix the
problem.

(4) User posts three entries that are meant to be read in a specific order,
but forgets to take her blog's reverse chronological order into account. She
has to login and fix the problem.

(5) User is cheating on his wife, and suddenly realizes that his blog entry
from three days ago indicates that he was playing golf, when he told her
that he was playing golf *four* days ago. She he has to login and fix the
problem.

(6) User posts "into the future" about an event or whatever, and the event
gets pushed back. He has to login and fix the problem.

(7) JournURL-specific: User posts an entry, but forgets to check the
"weblog" box on the posting page. Her entry shows up in the forum, but not
in her blog. When she spots the missing post four days later, she edits it
to make it show up in her blog, and updates the pub date so her readers
won't miss it.

I could go on like this for pages. People are people. They change their
minds. They do dumb things. Sometimes they're evil. Sometimes the world is.

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/ 







From owner-atom-syntax@mail.imc.org  Sun Jul 25 03:27: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 DAA21993
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 03:27: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 i6P7FuXE038488;
	Sun, 25 Jul 2004 00: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 i6P7FuMU038486;
	Sun, 25 Jul 2004 00:15:56 -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 i6P7Ftg8038447
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 00:15:55 -0700 (PDT)
	(envelope-from roger@agincourtmedia.com)
Received: from biggreen ([216.63.148.42]) by journurl.com with MailEnable ESMTP; Sun, 25 Jul 2004 02:15:35 -0500
From: "Roger B." <roger@agincourtmedia.com>
To: "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: RE: Date Options Analysis: Issued
Date: Sun, 25 Jul 2004 02:21:04 -0500
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: <opsbnb58bkuvpchu@quark>
Thread-Index: AcRxiutHm+V7s/2DT3ij/lGaGrN8ZwAiyQtg
Message-ID: <14AD7E53513F40CD8FD166E4CB94C3.MAI@journurl.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


Asbjorn: Okay, so as with Arve, we've established that this can't be
mandated, can't be validated, and in addition, the origin of my date has no
impact on your use of the same date element in your publishing environment.

So we're left with this:

> Firstly, the context of when you first wrote and published the entry will
> be unknown. 

It will be known to the extent that I want it known. I've given it a date of
2004-08-10, and that's all you need to know. It's my writing, and I will
decide the context. If I want to write it in 2003 and make you think I wrote
it in 2004 (or vice versa), that's my business.

> Secondly, any order of the entries on the assumption that
> 'issued' equals 'first-issued' will break.

Two questions:

(1) Define "break". What exactly will happen?

(2) If "issued" is actually "first-issued", then why would an aggregator
ever check that element for any instance of atom:id after seeing it the
first time?

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/ 







From owner-atom-syntax@mail.imc.org  Sun Jul 25 03:46: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 DAA22823
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 03:46: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 i6P7cGnG046011;
	Sun, 25 Jul 2004 00:38: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 i6P7cGnu046010;
	Sun, 25 Jul 2004 00:38:16 -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 i6P7cGp4045961
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 00:38:16 -0700 (PDT)
	(envelope-from roger@agincourtmedia.com)
Received: from biggreen ([216.63.148.42]) by journurl.com with MailEnable ESMTP; Sun, 25 Jul 2004 02:37:56 -0500
From: "Roger B." <roger@agincourtmedia.com>
To: "'Sam Ruby'" <rubys@intertwingly.net>
Cc: "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: RE: PaceDateline
Date: Sun, 25 Jul 2004 02:43: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.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
In-Reply-To: <41027CC9.5060202@intertwingly.net>
Thread-Index: AcRxkKT1M6BjL0eBT3+YBULbGdlVWgAikhdw
Message-ID: <D7E1FD6870B74A8C9F818E1E42F6BF.MAI@journurl.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


re: PaceDateline

Sam: +1

--
Roger Benningfield
 






From owner-atom-syntax@mail.imc.org  Sun Jul 25 03: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 DAA22841
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 03: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 i6P7cFVF045995;
	Sun, 25 Jul 2004 00: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 i6P7cFjH045994;
	Sun, 25 Jul 2004 00:38:15 -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 i6P7cEPe045952
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 00:38:14 -0700 (PDT)
	(envelope-from roger@agincourtmedia.com)
Received: from biggreen ([216.63.148.42]) by journurl.com with MailEnable ESMTP; Sun, 25 Jul 2004 02:37:56 -0500
From: "Roger B." <roger@agincourtmedia.com>
To: "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: RE: Date Options Survey
Date: Sun, 25 Jul 2004 02:43: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.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
In-Reply-To: <opsbnbrcqruvpchu@quark>
Thread-Index: AcRxieiYuJXWqMUDTSCntgcyqO1bUgAj+2ww
Message-ID: <249C630F374D439C9D61BEED04072.MAI@journurl.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


> I'm -2 on it. I would actually rather not have an 'issued' at all, than
> having the issued Movable Type currently employs.

Asbjorn: Yet another question, from another angle. 

If an MT user puts mutable dates in issued and you put immutable dates in
issued, how is the consumption of your feed compromised by the consumption
of the MT user's feed? 

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/ 







From owner-atom-syntax@mail.imc.org  Sun Jul 25 04:04: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 EAA23335
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 04:04:02 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6P7mtXs050274;
	Sun, 25 Jul 2004 00:48: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 i6P7mtYR050273;
	Sun, 25 Jul 2004 00:48: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 i6P7msCe050254
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 00:48:54 -0700 (PDT)
	(envelope-from davep@dpawson.co.uk)
Received: (qmail 3512 invoked from network); 25 Jul 2004 08:10:47 -0000
Received: from dpawson.gotadsl.co.uk (HELO ?192.168.2.6?) (davep@dpawson.co.uk@81.6.251.105)
  by 0 with SMTP; 25 Jul 2004 08:10:47 -0000
Subject: Re: PaceDateline
From: Dave Pawson <davep@dpawson.co.uk>
Reply-To: davep@dpawson.co.uk
To: Paul Hoffman / IMC <phoffman@imc.org>
Cc: Atom syntax <atom-syntax@imc.org>
In-Reply-To: <p0611040cbd286c192341@[10.20.30.249]>
References: <41027456.5040109@intertwingly.net>
	 <410292F3.4010005@dehora.net>
	 <59FFC974-DD94-11D8-8C8C-000A95A51C9E@sun.com>
	 <4102A8B2.9030900@dehora.net>  <p0611040cbd286c192341@[10.20.30.249]>
Content-Type: text/plain; charset=
Message-Id: <1090741737.2018.23.camel@homer>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) 
Date: Sun, 25 Jul 2004 08:48:57 +0100
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


On Sat, 2004-07-24 at 20:43, Paul Hoffman / IMC wrote:
> At 7:21 PM +0100 7/24/04, Bill de hÓra wrote:
> >I think if the dc:terms values are to be considered part of Atom, 
> >they should be explicitly present, not presumed by their absence. 
> >This Pace makes them present in Atom as a result of them not being 
> >there.
> 
> How do you feel about "MUST handle atom:dateline, SHOULD handle the 
> dateish dc:terms"?

-1 to dateline.
For newsml it seems appropriate. Unless the term is more globally
acceptable I don't find it appropriate for atom, 
preferring earlier suggested options for date. 
  And does a reader really care about 'place'?
For some it may be appropriate. For many it would be totally
inappropriate. 



Should I presume that the Dublin Core definitions have been brushed
aside as insufficiently defined?



-- 
Regards DaveP.
XSLT&Docbook  FAQ
http://www.dpawson.co.uk/xsl




From owner-atom-syntax@mail.imc.org  Sun Jul 25 04:06: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 EAA23417
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 04:06:06 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6P7mYDi050123;
	Sun, 25 Jul 2004 00: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 i6P7mY42050122;
	Sun, 25 Jul 2004 00:48:34 -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 i6P7mX78050071
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 00:48:33 -0700 (PDT)
	(envelope-from roger@agincourtmedia.com)
Received: from biggreen ([216.63.148.42]) by journurl.com with MailEnable ESMTP; Sun, 25 Jul 2004 02:48:12 -0500
From: "Roger B." <roger@agincourtmedia.com>
To: "'Sam Ruby'" <rubys@intertwingly.net>
Cc: "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: RE: PaceDateline
Date: Sun, 25 Jul 2004 02:53:51 -0500
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: <41027CC9.5060202@intertwingly.net>
Thread-Index: AcRxkKT1M6BjL0eBT3+YBULbGdlVWgAiwcWA
Message-ID: <C8AFB611CEEF45D9A6C03266102817.MAI@journurl.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


> A decision will need to be made as to whether or not this 
> element also replaces the feed level atom:modified element.

Sam: As has been pointed out in a few times, the feed-level atom:modified is
already extremely problematic for all but the most basic feeds. Once you get
into dynamic search feeds, things get potentially ugly on the publishing
end.

So when we get back to it, there's probably a lot to go over. (Unless the
consensus is "when in doubt, stuff now() in there," in which case forget I
said anything.)

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/ 







From owner-atom-syntax@mail.imc.org  Sun Jul 25 04:51: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 EAA25843
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 04:51: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 i6P8cbHw067333;
	Sun, 25 Jul 2004 01:38: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 i6P8cbW9067332;
	Sun, 25 Jul 2004 01:38:37 -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 i6P8calL067292
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 01:38:36 -0700 (PDT)
	(envelope-from roger@agincourtmedia.com)
Received: from biggreen ([216.63.148.42]) by journurl.com with MailEnable ESMTP; Sun, 25 Jul 2004 03:38:17 -0500
From: "Roger B." <roger@agincourtmedia.com>
To: "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: RE: Propose partial consensus on dates
Date: Sun, 25 Jul 2004 03:42:58 -0500
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: <opsbnphfemuvpchu@quark>
Thread-Index: AcRxs1fW/zwKTWKmScGLQTTvbd/DMQAbF2Kg
Message-ID: <1D4BBD968F1B4695817DE6F3E3DEE.MAI@journurl.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


> Many people on this list have argued that the current practice is so and
> so, and that's why 'issued' can't be so and so.

Asbjorn: That's a misunderstanding, from what I can see. I suspect most
folks would be happy adhering to a "professional publisher's" definition of
"issued"... I know I would. Just don't try to force me to provide such a
date by making it a required element, 'cause it ain't gonna happen.

I can accommodate your practice, and you can find a way to accommodate mine.

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/ 







From owner-atom-syntax@mail.imc.org  Sun Jul 25 06:09: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 GAA29660
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 06:09: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 i6P9tHBZ094850;
	Sun, 25 Jul 2004 02:55: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 i6P9tH89094849;
	Sun, 25 Jul 2004 02:55:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from cat-proof.de (cat.cat-proof.de [213.239.198.176])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6P9tGUl094835
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 02:55:17 -0700 (PDT)
	(envelope-from sc@itst.net)
Received: from [192.168.1.10] (p5081732F.dip0.t-ipconnect.de [80.129.115.47])
	by cat-proof.de (Postfix) with ESMTP id 8CDC8340B660
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 11:53:45 +0200 (CEST)
Message-ID: <410383FF.8030603@itst.net>
Date: Sun, 25 Jul 2004 11:57:19 +0200
From: Sascha Carlin <sc@itst.net>
User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707)
X-Accept-Language: de, en
MIME-Version: 1.0
To: atom-syntax@imc.org
Subject: Re: Date Options Survey
References: <475BB4D1-DCF3-11D8-AFAD-000A95A51C9E@sun.com>
In-Reply-To: <475BB4D1-DCF3-11D8-AFAD-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


Just to document the current votes.

I ignored R/NR and just summed the numbers.

Of 20 votes, with a maximum total of 40:

  - 4 for created
  - 14 for dateline
  - 13 for issued
  - 13 for modified
  - 7 for updated


Of 20 votes, with a maximum total of 20 saying it needs to be there:

  - 0 for created
  - 3 for dateline
  - 9 for issued
  - 9 for modified
  - 2 for updated

16 votes agree in 'issued' and 'modified' should be the only REQ dates, 
3 say 'dateline' should be the only REG (one includes 'updated').

I know the vote is fresh and it's weekend, but as the strongest 
participants already have voted, I just try it:

* Include 3 dates in Atom core, 'dateline, 'issued' and 'modified'.

* Make 'issued' and 'modified' REQ, 'dateline' OPT.

'dateline' defaults to 'issued', modified does for new entries, too. If 
you modify the entry, 'issued' would still have the old value and 
'modified' would be updated.

Since there are use cases where 'created' and 'updated' would be of 
great value, create a module/extension for them. If you want to use it, 
you'd inlude 'dateline, 'issued' and 'modified' as mentioned above plus 
'created' and 'updated'. This way applications using core Atom would not 
suffer and could still interpret your feeds.

If you (feed provider) don't want to use the extension, your (the 
programmers) application (using the extension) should interpret created 
= issued and updated = modified. This way you would still be able to use 
feeds with less information getting the most out of them.

Programmatically this would mean that applications need to store at 
least three dates: the date an entry is being made publically available 
(never changing), a date set by an author (changing at author's will) 
and the last date the entry was modified in any way (changing 
automagically).

For the extension to work the application needs to store two more dates. 
First the date the new entry is opened for the first time (never 
changing), second a date the author marks as bringing new/changed 
information to the entry (changing at author's will, e. g. by using a 
checkbox 'major update' as is used in some wikis).

I think this model would fit 80% of the most common use casing (using 
Atom core), leaving enough room for specialised applications (using the 
extension).

-- 
Sascha Carlin * Heinrich-Heine-Str. 1 * 64319 Pfungstadt
http://www.itst.org/         **         +49 6157 157 205



From owner-atom-syntax@mail.imc.org  Sun Jul 25 06:23: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 GAA00576
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 06:23:17 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6PABkOs002201;
	Sun, 25 Jul 2004 03: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 i6PABkPS002200;
	Sun, 25 Jul 2004 03:11:46 -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 i6PABj3E002122
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 03:11:45 -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 <20040725101157.ORGO8914.mta07-svc.ntlworld.com@cpc1-stke1-5-0-cust6.bagu.cable.ntl.com>;
          Sun, 25 Jul 2004 11:11:57 +0100
Date: Sun, 25 Jul 2004 11:11:38 +0100
From: David Powell <djpowell@djpowell.net>
X-Mailer: The Bat! (v2.12 RC/4) Business
Reply-To: David Powell <djpowell@djpowell.net>
X-Priority: 3 (Normal)
Message-ID: <1672548655.20040725111138@djpowell.net>
To: Sam Ruby <rubys@intertwingly.net>
CC: atom-syntax@imc.org
Subject: Re: PaceDateline
In-Reply-To: <41027456.5040109@intertwingly.net>
References: <41027456.5040109@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: <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



Comments on various bits of PaceDateline:

> The "atom:dateline" element is a Date construct that indicates the
> date ...

+1

I'm a fan of a machine readable dateline that is a loosely associated
date for an entry.


> and place of origin for a weblog entry.

-1

I don't think that geo-data should be part of the core. It would be a
cool extension though.

I definitely don't think it should be associated with a date element,
I don't see them as being at all related. Besides, I'd rather we nail
down these date issues before we start expanding the permathread to
discussing the format and implications of geo-data.


> atom:entry elements MUST contain an atom:dateline element, but MUST
> NOT contain more than one.

+0

Making dateline mandatory is interesting, but I'm not really
convinced.

I suppose it is a date that everyone can provide, because it is just a
date associated with the entry, so it would be valid to use the value
of modified or any other date here.


> Unless the following elements are also present from the dcterms
> namespace

+0 to using the dublin core namespaces instead of inlining the terms
into the Atom namespace.

I'm not sure why Atom 0.3 inlines terms from dublin core into the Atom
namespace. I'm not opposed to using the terms directly from the dublin
core namespace, but this is a separate issue from which dates we chose
to include.


> Remove sections 5.6 "atom:modified", 5.7 "atom:issued", and 5.8
> "atom:created" Element.

-1

Several people thought "modified" should be required, so I'd want to
see that at least in the spec (whether it goes in atom: or dcterms: )


> this value is to be presumed as the the date that the entry was
> created, valid, available, issued, modified, accepted, copyrighted,
> and submitted.

-1

If dates aren't present, then they aren't present. I don't think that
we should require that they are defaulted to other dates. Dateline
could be in the future if it was used to associate an entry with the
date of an upcoming event, it would obviously be wrong to default most
of those dates in that case.

Atom should be communicating an author's metadata, not making it up
itself.

-- 
Dave




From owner-atom-syntax@mail.imc.org  Sun Jul 25 06:40: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 GAA01621
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 06:40: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 i6PASD1e007795;
	Sun, 25 Jul 2004 03:28: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 i6PASDv2007794;
	Sun, 25 Jul 2004 03:28: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 i6PASB1g007729
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 03:28: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 D31D97C122; Sun, 25 Jul 2004 13:24:11 +0200 (CEST)
Date: Sun, 25 Jul 2004 12:32:20 +0200
To: "Antone Roundy" <antone@geckotribe.com>
Subject: Re: PaceDateline
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <337ACDD8-DDCE-11D8-9941-003065EA6144@geckotribe.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: <opsbovj6d6uvpchu@quark>
In-Reply-To: <337ACDD8-DDCE-11D8-9941-003065EA6144@geckotribe.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 24 Jul 2004 18:04:30 -0600, Antone Roundy <antone@geckotribe.com>  
wrote:

> Sheesh people.  I hardly think Tim was arguing that "denounced as too  
> simple" == "good", and "not denounced as too simple" == "bad".

Probably not.

> I understand that for what some of you do, "supercedes" and such are  
> important.  So build an extension.

Yep. I've maintained the view of having a superseding mechanism in an  
extension for a long time. I'm still maintaining that view.

> [1] It's been said before, but I'll say it again: you can claim that  
> nothing special needs to be done to support the superceding mechanism,  
> but any aggregator that doesn't implement it is going to have users  
> screaming about duplicate entries and jumping ship to another aggregator.

That's exactly what happens today if an entry reappears in a feed, isn't  
it? What's the difference?

And no one should be denied to switch aggregators, if another one supports  
more than the one someone's using. Supporting a supersede mechanism could  
be an edge some aggregators could have over others. Is that a bad thing?

-- 
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 Jul 25 08:10: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 IAA06110
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 08:10: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 i6PBwoei015406;
	Sun, 25 Jul 2004 04:58: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 i6PBwoue015405;
	Sun, 25 Jul 2004 04:58:50 -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 i6PBwnJf015392
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 04:58:50 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 21569 messnum 9271773 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 25 Jul 2004 11:58:43 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail10.svc.cra.dublin.eircom.net (qp 21569) with SMTP; 25 Jul 2004 11:58:43 -0000
Message-ID: <4103A072.8050806@dehora.net>
Date: Sun, 25 Jul 2004 12:58:42 +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: Paul Hoffman / IMC <phoffman@imc.org>
CC: atom-syntax@imc.org
Subject: Re: PaceDateline
References: <41027456.5040109@intertwingly.net> <410292F3.4010005@dehora.net> <59FFC974-DD94-11D8-8C8C-000A95A51C9E@sun.com> <4102A8B2.9030900@dehora.net> <p0611040cbd286c192341@[10.20.30.249]>
In-Reply-To: <p0611040cbd286c192341@[10.20.30.249]>
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


Paul Hoffman / IMC wrote:
> At 7:21 PM +0100 7/24/04, Bill de hÓra wrote:
> 
>> I think if the dc:terms values are to be considered part of Atom, they 
>> should be explicitly present, not presumed by their absence. This Pace 
>> makes them present in Atom as a result of them not being there.
> 
> 
> How do you feel about "MUST handle atom:dateline, SHOULD handle the 
> dateish dc:terms"?

Better, but here's a strawman that's stops me saying ok. Suppose 
Desperate Blog Writer (DBW) publishes an Atom entry and the dateline 
  element is part of that entry. DBW has unwittingly 
dcterms:copyrighted it whether or not a copyright was /intended/ and 
if so whether the copyright is intended on that date.

The other terms are almost certainly meaningful in the context of 
organizations that issue content and have some kind of workflow 
associated with that process (Dilbert: "I never 'acccepted' that"; 
PHB: "Our new enterprise blogging system says you did" ...). I have 
experience appying such terms to content to help determine roles and 
responsibilities for data and its alterations - this is not 
neccessarily stuff we should so easily entail. I appreciate the 
value of defaults to us technical types, but I doubt such abductive 
entailments are a good idea generally (principle of least surprise 
and all that).

cheers
Bill



From owner-atom-syntax@mail.imc.org  Sun Jul 25 08:15:10 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06314
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 08:15:10 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6PC4Bfr015689;
	Sun, 25 Jul 2004 05:04: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 i6PC4BNT015688;
	Sun, 25 Jul 2004 05:04:11 -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 i6PC4ANN015679
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 05:04:11 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 85520 messnum 1900950 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 25 Jul 2004 12:04:06 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail02.svc.cra.dublin.eircom.net (qp 85520) with SMTP; 25 Jul 2004 12:04:06 -0000
Message-ID: <4103A1B5.3090809@dehora.net>
Date: Sun, 25 Jul 2004 13:04:05 +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: Arve Bersvendsen <arve@virtuelvis.com>
CC: Tim Bray <Tim.Bray@Sun.COM>, atom-syntax@imc.org
Subject: Re: PaceDateline
References: <200407242121.i6OLLOm6057871@above.proper.com>
In-Reply-To: <200407242121.i6OLLOm6057871@above.proper.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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:
> * Tim Bray:
> 
> 
>>Here is a list of technologies that, at the time of their arrival, were 
>>denounced as being "too simple": Unix, C, SQL, HTML, HTTP, XML, SMTP.  
>>Simple is good.  Simple gets adopted.  Simple wins.  -Tim
> 
> 
> Could we please at least _attempt_ to refrain from wilfully commiting
> fallacies when making our arguments?
> 
> That Unix was claimed to be too simple, yet wins does not imply that if Atom
> is claimed to be "too simple", Atom wins. 

No-one said that. But the history suggests we should take simplicity 
seriously as a trade-off against completeness when it comes to 
adoption - certainly that's been my experience.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Sun Jul 25 08:21: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 IAA06449
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 08:21:19 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6PCBRdi016648;
	Sun, 25 Jul 2004 05: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 i6PCBRFq016647;
	Sun, 25 Jul 2004 05:11:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from dumle.webhuset.no (dumle.webhuset.no [81.27.32.66])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6PCBQTC016639
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 05:11:26 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Message-Id: <200407251211.i6PCBQTC016639@above.proper.com>
Received: (qmail 23498 invoked from network); 25 Jul 2004 12:09:46 -0000
Received: from unknown (HELO localhost.localdomain) (81.27.34.17)
  by 0 with SMTP; 25 Jul 2004 12:09:46 -0000
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
MIME-Version: 1.0
From: "Arve Bersvendsen" <arve@virtuelvis.com>
To: David Powell <djpowell@djpowell.net>, atom-syntax@imc.org
Subject: Re: PaceDateline
Date: Sun, 25 Jul 2004 14:11:23 +0200
X-Mailer: WHMail 1.0 (http://www.webhuset.no)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6PCBRTC016642
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


* Dave Pawson:
> I don't think that geo-data should be part of the core. It would be a
> cool extension though.
> 
> I definitely don't think it should be associated with a date element,
> I don't see them as being at all related. Besides, I'd rather we nail
> down these date issues before we start expanding the permathread to
> discussing the format and implications of geo-data.

I agree with you. Partly.

The connection between geodata and notion of time is interesting, from a
human point of view. If we reduce the connection between geodata and
date/time to numbers, information is lost.

"Mid-February, northern Norway, in the middle of a spooky winter night"
carries different information from: 

Date: 2005-02-14T03:07:32+02:00
Latitude: 69 Deg 01 Min. 21 Sec.
Longitude: 17 Deg 13 Min. 0 Sec.

The first one says this is winter. Says that it is in Norway. Says it is
spooky. This cannot be derived from the geodata, unless the reader already
has knowledge of Norway, where Norway is on the globe, and has experience
with mid-winter nights in the north of Norway.

Of course, there is data loss when going the other way as well.

In conclusion: connecting date and geo-information when this information is
only meant for machine parsing, is quite meaningless. Allowing connection of
human-provided info for humans is not. 

(Having said that, the "Mid-February ..." thing belongs somewhere in the
content. 



From owner-atom-syntax@mail.imc.org  Sun Jul 25 08:32: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 IAA06663
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 08:32: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 i6PCJOwX017045;
	Sun, 25 Jul 2004 05:19: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 i6PCJOtk017044;
	Sun, 25 Jul 2004 05:19:24 -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 i6PCJOvl017033
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 05:19:24 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 43816 messnum 2023632 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 25 Jul 2004 12:19:19 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail09.svc.cra.dublin.eircom.net (qp 43816) with SMTP; 25 Jul 2004 12:19:19 -0000
Message-ID: <4103A546.2020505@dehora.net>
Date: Sun, 25 Jul 2004 13:19:18 +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: Tim Bray <Tim.Bray@Sun.COM>
CC: Mark Pilgrim <pilgrim@gmail.com>, Sam Ruby <rubys@intertwingly.net>,
        Atom-Syntax <atom-syntax@imc.org>
Subject: Re: URI scheme delusions
References: <OF031774D8.BEC98F6C-ON88256EDB.00084992-88256EDB.00090B2C@us.ibm.com> <opsbm7jgwuuvpchu@quark> <41026240.8020009@intertwingly.net> <410266E4.6040304@dehora.net> <14be96d304072408524788c699@mail.gmail.com> <02F0CB0F-DD90-11D8-8C8C-000A95A51C9E@sun.com> <14be96d304072419285ec80400@mail.gmail.com> <E162E7FC-DDFE-11D8-8C8C-000A95A51C9E@sun.com>
In-Reply-To: <E162E7FC-DDFE-11D8-8C8C-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:

> But can we please stop arguing?  Because it doesn't matter, I REALLY 
> THINK it doesn't matter.  In Atom, there are going to be places where it 
> says "this identifier should be a URI".  Those who really believe in a 
> useful distinction between naming and location, or who believe that the 
> URN registration process really produces longer-lived identifiers, can 
> use that kind of URI.  Those of us who think that identifiers are made 
> more useful by being potentially dereferencable will use HTTP URIs.   In 
> a few decades we'll know who was right.

Yes. Aside from striking me as BCP material, the architecture [1] 
and means[2] to let everyone have their cake and eat it (modulo some 
crumbs) exists. Otherwise the philosophers are better qualified to 
deal with this problem and are approximately a century ahead of us.

cheers
Bill

[1] http://www.ietf.org/rfc/rfc3401.txt
[2] http://www.ietf.org/rfc/rfc3404.txt



From owner-atom-syntax@mail.imc.org  Sun Jul 25 08:35: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 IAA06768
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 08:35: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 i6PCNW1T017169;
	Sun, 25 Jul 2004 05:23:32 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6PCNWX8017168;
	Sun, 25 Jul 2004 05:23:32 -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 i6PCNVkX017161
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 05:23:32 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 40173 messnum 434134 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 25 Jul 2004 12:23:28 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail05.svc.cra.dublin.eircom.net (qp 40173) with SMTP; 25 Jul 2004 12:23:28 -0000
Message-ID: <4103A63E.6060309@dehora.net>
Date: Sun, 25 Jul 2004 13:23:26 +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: Dare Obasanjo <kpako@yahoo.com>
CC: Arve Bersvendsen <arve@virtuelvis.com>, atom-syntax@imc.org
Subject: Featuritis. was Re: Propose partial consensus on dates
References: <20040724225653.65915.qmail@web41208.mail.yahoo.com>
In-Reply-To: <20040724225653.65915.qmail@web41208.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:


> 
> I haven't. Unfortunately all the people pushing pet
> features that make no sense in the syndication or
> editing/publishing scenario seem to have. 

Have you a compiled a list of such features in your opinion? 
Seriously,  as a contributor to one of the better OS readers, that 
would be good to know.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Sun Jul 25 11: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 LAA13615
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 11:11: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 i6PEx7t7029680;
	Sun, 25 Jul 2004 07:59: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 i6PEx7IU029679;
	Sun, 25 Jul 2004 07:59:07 -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 i6PEx6c7029670
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 07:59:06 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p06110421bd2979d0ed16@[10.20.30.249]>
In-Reply-To: <opsboxrwu4uvpchu@quark>
References: 
 <OF031774D8.BEC98F6C-ON88256EDB.00084992-88256EDB.00090B2C@us.ibm.com>
 <opsbm7jgwuuvpchu@quark> <41026240.8020009@intertwingly.net>
 <410266E4.6040304@dehora.net> <14be96d304072408524788c699@mail.gmail.com>
 <02F0CB0F-DD90-11D8-8C8C-000A95A51C9E@sun.com>
 <14be96d304072419285ec80400@mail.gmail.com>
 <E162E7FC-DDFE-11D8-8C8C-000A95A51C9E@sun.com> <opsboxrwu4uvpchu@quark>
Date: Sun, 25 Jul 2004 07:58:40 -0700
To: Atom WG <atom-syntax@imc.org>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: URI scheme delusions
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


At 1:20 PM +0200 7/25/04, Asbjørn Ulsberg wrote:
>Wouldn't we be better off recommending Bob and his friend a scheme 
>we knew were safer against future modifications, universally 
>uniqueness, etc?

No. Trying to teach Bob and his friends why URNs are better than URLs 
is futile, and that's OK. He shouldn't have to worry about it.

>  Or do you have faith in that Bob, although he doesn't know anything 
>(he has no idea what the difference between URI, URL or URN is, and 
>he has only seen URL's «live»), will pick a scheme that is 
>universally unique «enough»?

Yes. If he is hand-coding, he has probably read enough of the RFC to 
get it right. If he is using a tool, the tool will probably get it 
right.

If we're going by the 80/20 rule (heck, the 99/1 rule), entries and 
feeds will be software-generated. It is completely trivial for 
software to generate IDs that won't get re-used except in the most 
extreme cases, such as a domain name turnover. In those very rare 
cases, there is nothing we can do. We live with it. We sleep anyway.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Sun Jul 25 12:33: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 MAA16426
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 12:33: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 i6PBECev011892;
	Sun, 25 Jul 2004 04:14:12 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6PBECKG011891;
	Sun, 25 Jul 2004 04:14:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from dumle.webhuset.no (dumle.webhuset.no [81.27.32.66])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6PBE9iZ011871
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 04:14:11 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Message-Id: <200407251114.i6PBE9iZ011871@above.proper.com>
Received: (qmail 23307 invoked from network); 25 Jul 2004 11:12:29 -0000
Received: from unknown (HELO localhost.localdomain) (81.27.34.17)
  by 0 with SMTP; 25 Jul 2004 11:12:29 -0000
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
MIME-Version: 1.0
From: "Arve Bersvendsen" <arve@virtuelvis.com>
To: "Roger B." <roger@agincourtmedia.com>, atom-syntax@imc.org
Subject: Re: Date Options Survey
Date: Sun, 25 Jul 2004 13:14:05 +0200
X-Mailer: WHMail 1.0 (http://www.webhuset.no)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6PBEBiZ011886
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


* Roger Benningfield:
> If an MT user puts mutable dates in issued and you put immutable dates in
> issued, how is the consumption of your feed compromised by the consumption
> of the MT user's feed? 

What if you track millions of feeds, and want to do something potentially
useful to them, and every generator out there assigns their own meaning to
it?  If you knew that MT assigned one meaning, where the date was only a
fancified version of 'Created'. For LJ, this date was always equal to
'modified', for JournURL, this was actually 'first-issued' (read: immutable).
Add 10 to 15 generators down the line using one of the already mentioned
dates.

You'd end up having to write a generator-sniffing mess to do anything useful
with the data.



From owner-atom-syntax@mail.imc.org  Sun Jul 25 12:34: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 MAA16455
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 12: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 i6PBFjU0012103;
	Sun, 25 Jul 2004 04:15: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 i6PBFjfS012102;
	Sun, 25 Jul 2004 04:15: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 i6PBFiYk012094
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 04:15: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 77B367C11E; Sun, 25 Jul 2004 14:11:49 +0200 (CEST)
Date: Sun, 25 Jul 2004 13:20:10 +0200
To: "Tim Bray" <Tim.Bray@Sun.COM>
Subject: Re: URI scheme delusions
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <OF031774D8.BEC98F6C-ON88256EDB.00084992-88256EDB.00090B2C@us.ibm.com> <opsbm7jgwuuvpchu@quark> <41026240.8020009@intertwingly.net> <410266E4.6040304@dehora.net> <14be96d304072408524788c699@mail.gmail.com> <02F0CB0F-DD90-11D8-8C8C-000A95A51C9E@sun.com> <14be96d304072419285ec80400@mail.gmail.com> <E162E7FC-DDFE-11D8-8C8C-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: <opsboxrwu4uvpchu@quark>
In-Reply-To: <E162E7FC-DDFE-11D8-8C8C-000A95A51C9E@sun.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 24 Jul 2004 22:52:58 -0700, Tim Bray <Tim.Bray@Sun.COM> wrote:

> Those who really believe in a useful distinction between naming and
> location, or who believe that the URN registration process really
> produces longer-lived identifiers, can use that kind of URI.  Those
> of us who think that identifiers are made more useful by being
> potentially dereferencable will use HTTP URIs.

What about those who _just_don't_know_anything_? That is, Bob and his  
friends, which thinks all HTTP URI's are resolvable from now until  
forever, that they are dynamic (if a resource move, the resource's URI  
changes) and not «just a string».

Wouldn't we be better off recommending Bob and his friend a scheme we knew  
were safer against future modifications, universally uniqueness, etc? Or  
do you have faith in that Bob, although he doesn't know anything (he has  
no idea what the difference between URI, URL or URN is, and he has only  
seen URL's «live»), will pick a scheme that is universally unique «enough»?

-- 
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 Jul 25 12:46: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 MAA16906
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 12:46:29 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6PGZm4O038529;
	Sun, 25 Jul 2004 09:35: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 i6PGZmIL038528;
	Sun, 25 Jul 2004 09:35:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6PGZma0038522
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 09:35:48 -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 i6PGapr3015043;
	Sun, 25 Jul 2004 12:36:51 -0400
Message-ID: <4103E15F.3030408@intertwingly.net>
Date: Sun, 25 Jul 2004 12:35:43 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <djpowell@djpowell.net>
CC: atom-syntax@imc.org
Subject: Re: PaceDateline
References: <41027456.5040109@intertwingly.net> <1672548655.20040725111138@djpowell.net>
In-Reply-To: <1672548655.20040725111138@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: <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


David Powell wrote:
>>Remove sections 5.6 "atom:modified", 5.7 "atom:issued", and 5.8
>>"atom:created" Element.
> 
> -1
> 
> Several people thought "modified" should be required, so I'd want to
> see that at least in the spec (whether it goes in atom: or dcterms: )

modified is present in this proposal, and, if not present, defaults to 
the value of an element which MUST be present.  This achieves the same 
effect without requiring explicit redundancy in the common case where 
the resource has yet to be modified.

>>this value is to be presumed as the the date that the entry was
>>created, valid, available, issued, modified, accepted, copyrighted,
>>and submitted. 
> 
> -1
> 
> If dates aren't present, then they aren't present. I don't think that
> we should require that they are defaulted to other dates. Dateline
> could be in the future if it was used to associate an entry with the
> date of an upcoming event, it would obviously be wrong to default most
> of those dates in that case.
> 
> Atom should be communicating an author's metadata, not making it up
> itself.

Atom needs to be cleanly and thoroughly specified.  What this means is 
that there must be a clear and consistent way of communicating an 
author's metadata.  Such a goal is not inconsistent with the present of 
defaults.

If the author's metadata includes six dates which are known to be 
identical, one which is known to be different, and one that is unknown, 
requiring eight elements to express this is a rather cumbersome mechanism.

I added an example to the pace.

It is clear to me that in order to be inclusive, atom will have more 
dates than most people will want to have to deal with explicitly. 
Therefore, to me it makes sense for the discussion to turn to what are 
the common cases, how the syntax can be optimized for these common 
cases, and how to set expectations so that people can consistently 
interpret the resulting syntax correctly.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Sun Jul 25 12: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 MAA16989
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 12:48:48 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6PGdh9k038836;
	Sun, 25 Jul 2004 09:39: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 i6PGdhT6038835;
	Sun, 25 Jul 2004 09:39:43 -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 i6PGdhSq038826
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 09:39:43 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040725163941.18745.qmail@web41214.mail.yahoo.com>
Received: from [67.160.87.187] by web41214.mail.yahoo.com via HTTP; Sun, 25 Jul 2004 09:39:41 PDT
Date: Sun, 25 Jul 2004 09:39:41 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Featuritis. was Re: Propose partial consensus on dates
To: "Bill_de_hÓra" <bill@dehora.net>
Cc: Arve Bersvendsen <arve@virtuelvis.com>, atom-syntax@imc.org
In-Reply-To: <4103A63E.6060309@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:
> 
> Have you a compiled a list of such features in your
> opinion? 
> Seriously,  as a contributor to one of the better OS
> readers, that 
> would be good to know.

It isn't that there are too many features but more
that people aren't acknowledging that the contents of
an entry when used for syndication are different from
when it is used as a payload of an API call or as an
archival format. 

For example, a created date is useful for an archival
format and probably should be required. It is
unncecessary in a syndication format and definitely
quite useless as data passed to the server as part of
an API call.  

I seriously think there should be profiles of Atom for
the 3 primary use cases and a glossary/inventory of
Atom elements that is the union of all the
elements/constructs in the 3 profiles. 

=====
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  Sun Jul 25 12:55: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 MAA17297
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 12: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 i6PGmE37039778;
	Sun, 25 Jul 2004 09:48:14 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6PGmEQe039777;
	Sun, 25 Jul 2004 09:48: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 i6PGmDlD039769
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 09:48:13 -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 i6PGnGf5015578;
	Sun, 25 Jul 2004 12:49:17 -0400
Message-ID: <4103E449.9040000@intertwingly.net>
Date: Sun, 25 Jul 2004 12:48:09 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Arve Bersvendsen <arve@virtuelvis.com>
CC: "Roger B." <roger@agincourtmedia.com>, atom-syntax@imc.org
Subject: Re: Date Options Survey
References: <200407251114.i6PBE9iZ011871@above.proper.com>
In-Reply-To: <200407251114.i6PBE9iZ011871@above.proper.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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:

> * Roger Benningfield:
> 
>>If an MT user puts mutable dates in issued and you put immutable dates in
>>issued, how is the consumption of your feed compromised by the consumption
>>of the MT user's feed? 
> 
> What if you track millions of feeds, and want to do something potentially
> useful to them, and every generator out there assigns their own meaning to
> it?  If you knew that MT assigned one meaning, where the date was only a
> fancified version of 'Created'. For LJ, this date was always equal to
> 'modified', for JournURL, this was actually 'first-issued' (read: immutable).
> Add 10 to 15 generators down the line using one of the already mentioned
> dates.
> 
> You'd end up having to write a generator-sniffing mess to do anything useful
> with the data.

Arve, I believe that Roger is asking a question based on what he has 
directly observed with existing blogging tools and existing formats.  I 
believe it to be a valid question.

It is hoped that a format that is  cleanly and thoroughly specified, and 
containing elements for concepts that correspond to what people already 
is doing anyway, would improve situations.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Sun Jul 25 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 NAA18023
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 13: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 i6PH3q40041194;
	Sun, 25 Jul 2004 10:03:52 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6PH3qpr041193;
	Sun, 25 Jul 2004 10:03:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from ms-smtp-03.nyroc.rr.com (ms-smtp-03.nyroc.rr.com [24.24.2.57])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6PH3pxE041187
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 10:03:51 -0700 (PDT)
	(envelope-from tommyers@dreamscape.com)
Received: from dreamscape.com (syr-24-59-252-7.twcny.rr.com [24.59.252.7])
	by ms-smtp-03.nyroc.rr.com (8.12.10/8.12.10) with ESMTP id i6PH3kv2022143;
	Sun, 25 Jul 2004 13:03:47 -0400 (EDT)
Message-ID: <4103E770.2090704@dreamscape.com>
Date: Sun, 25 Jul 2004 13:01:36 -0400
From: Tom Myers <tommyers@dreamscape.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Atom WG <atom-syntax@imc.org>
Subject: Re: URI scheme delusions
References: <OF031774D8.BEC98F6C-ON88256EDB.00084992-88256EDB.00090B2C@us.ibm.com> <opsbm7jgwuuvpchu@quark> <41026240.8020009@intertwingly.net> <410266E4.6040304@dehora.net> <14be96d304072408524788c699@mail.gmail.com> <02F0CB0F-DD90-11D8-8C8C-000A95A51C9E@sun.com> <14be96d304072419285ec80400@mail.gmail.com> <E162E7FC-DDFE-11D8-8C8C-000A95A51C9E@sun.com> <opsboxrwu4uvpchu@quark> <p06110421bd2979d0ed16@[10.20.30.249]>
In-Reply-To: <p06110421bd2979d0ed16@[10.20.30.249]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Symantec AntiVirus Scan Engine
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


Paul Hoffman / IMC wrote:
> 
> If we're going by the 80/20 rule (heck, the 99/1 rule), entries and 
> feeds will be software-generated. It is completely trivial for software 
> to generate IDs that won't get re-used except in the most extreme cases, 
> such as a domain name turnover. In those very rare cases, there is 
> nothing we can do. We live with it. We sleep anyway.

Is it absotively posilutely definite that "there is nothing we can do"
about domain name turnovers? Suppose the spec said that IDs, if done as
retrievables, SHOULD or even MUST be of a form such as A/B/C  where

   A= a base URI, http://www.example.com:8765/stuff/JoeSchmoe/blog
   B= date info,  2004-07-26
   C= something to make it unique for that date, My_Funny_Story.html

Now, it may well be that example.com will get sold out from under dear
old JoeSchmoe, but the URI A/B/C will never be reused because you'll have
new dates for B. An aggregator seeks an old A/B/C and finds that it's not
there, there isn't even any Atom data there. The aggregator will then
ask technorati or somebody

   is there any replacement baseURI for
      A = http://www.example.com:8765/stuff/JoeSchmoe/blog

and it will be told, perhaps, that one has been seen, namely

      A' = http://www.JoeSchmoe.net/blog

and a few milliseconds later it will retrieve the entry from Joe's new
place for it, A'/B/C, having noted the baseURI replacement for future usage.

Now, maybe most aggregators will not want to support this, but I don't
see why it couldn't work, and it could give some competitive advantage
to those that did support it. (And maybe a further competitive advantage
to those that correctly handle the .001 case where the new domain owner
publishes, using an identical baseURI.)

  All the spec would have to do is push the use of decomposable URIs in
some format like A/B/C as described...right?

You could go further, of course, saying that Joe's new blog could claim

   <atom:prevBase baseURI="prevA" from="yyyy-mm-dd" to="yyyy-mm-dd"/>

once for each previous baseURI Joe has used. That would make the
technorati (or whoever) end of it easy, too. And then you would have
people trying to use this to hijack instapundit, or whatever, and
getting themselves banned. There are lots of aspects that might be
worth thinking through, for core or extensions, and I've probably
made a fool of myself sufficiently for now, so I'll go back to lurking....

Tom Myers




From owner-atom-syntax@mail.imc.org  Sun Jul 25 14:07: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 OAA19679
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 14:07: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 i6PHvC08045465;
	Sun, 25 Jul 2004 10:57: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 i6PHvCLE045464;
	Sun, 25 Jul 2004 10:57:12 -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 i6PHvB9h045454
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 10:57:11 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040725175705.15101.qmail@web41203.mail.yahoo.com>
Received: from [67.160.87.187] by web41203.mail.yahoo.com via HTTP; Sun, 25 Jul 2004 10:57:05 PDT
Date: Sun, 25 Jul 2004 10:57:05 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: URI scheme delusions
To: Tim Bray <Tim.Bray@Sun.COM>, Mark Pilgrim <pilgrim@gmail.com>
Cc: "Bill_de_hÓra" <bill@dehora.net>, Sam Ruby <rubys@intertwingly.net>,
        Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <E162E7FC-DDFE-11D8-8C8C-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:
> 
> For example, 
> I'm quite sure that the character string 
> "http://www.w3.org/XML/1998/namespace" (the URI for
> the "xml:" prefix) 
> will remain widely recognized in software long after
> the W3C has faded 
> away and w3.org is owned by Wholesale Wolves and
> Weasels, Inc.  

Will it still the mean the same thing? There was a
time one could have made the same statement about
http://www.w3.org/TR/SOAP and SOAP 1.1. That turns out
to not have been true.  

> It's 
> just a character string and the character string
> need not change.  As 
> long as I own the namespace, the identifier will be
> potentially more 
> useful because you might be able to dereference it
> to get some 
> explanatory/supporting material. 

How does one 'own a namespace'? 

> A URN or tag: or
> whatever removes the 
> possibility of direct dereference by ubiquitous
> software, thus 
> buying... uh, what?  I've never understood. 

Then you don't use the technologies that have had this
mess foisted on them. The two primary places URIs as
identifiers have been deployed have been a royal mess
of ambiguity; XML namespaces and RDF. 

See http://www.kuro5hin.org/story/2003/2/5/11349/85355
for one of my rants about this from last year. 


> But can we please stop arguing?  Because it doesn't
> matter, I REALLY 
> THINK it doesn't matter. 

That's unfortunate. As an aggregator author, the
screwed up nature of identifiers is one of my biggest
problems with RSS. In fact, that and the optionality
of a date field. If the folks working on Atom screw
this two thing up to since "it doesn't really matter"
then Atom would stand as an example of how to reinvent
the wheel but only worse. 


> In Atom, there are going
> to be places where 
> it says "this identifier should be a URI".  Those
> who really believe in 
> a useful distinction between naming and location, or
> who believe that 
> the URN registration process really produces
> longer-lived identifiers, 
> can use that kind of URI.  Those of us who think
> that identifiers are 
> made more useful by being potentially dereferencable
> will use HTTP 
> URIs.   In a few decades we'll know who was right.

We already have examples from RSS, XML namespaces and
RDF that using HTTP URLs as URIs causes problems. What
other proof do you 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!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail 



From owner-atom-syntax@mail.imc.org  Sun Jul 25 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 OAA20006
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 14: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 i6PI8MKI046120;
	Sun, 25 Jul 2004 11:08: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 i6PI8ME7046119;
	Sun, 25 Jul 2004 11:08:22 -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 i6PI8LuW046110
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 11:08:21 -0700 (PDT)
	(envelope-from roger@agincourtmedia.com)
Received: from biggreen ([216.63.148.42]) by journurl.com with MailEnable ESMTP; Sun, 25 Jul 2004 13:08:06 -0500
From: "Roger B." <roger@agincourtmedia.com>
To: <atom-syntax@imc.org>
Subject: RE: Date Options Survey
Date: Sun, 25 Jul 2004 13:13:21 -0500
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: <200407251114.i6PBE9iZ011871@above.proper.com>
Thread-Index: AcRyONfzcmWyvum+SuOXSE3HqXGgwQAL72ig
Message-ID: <A90F3D41DF748CFB8886A18409CC6.MAI@journurl.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


> What if you track millions of feeds, and want to do something potentially
> useful to them, and every generator out there assigns their own meaning to
> it?  

Arve: See, this is where I think we're having a fundamental disconnect.
That's not a "what if"... that's the way it is.

I produce all kinds of feeds. A single entry can show up in a dozen
different places, targeted at different needs. If I'm forced to provide an
issued date, then that date will be pulled from different fields depending
upon context. In a blog feed, the closest thing I have is the entry's
"published" date. In a forum feed, the closest date would be "created".
Right there, in a single app, you've got two potential origins for data that
ends up in a single element.

When I insert a date into an element, I'm not promising you that the date
came from an internal field with a spec that exactly matches Atom's. I am
asserting that you should use it for the purposes described in the spec.
That's it, and nothing more. The harder it is for me to make accurate
assertions, the harder it will be for consuming applications to satisfy
their users.

Note that this is not an argument in favor of allowing mutable dates in
"issued". If folks need "issued" to be immutable, hey, no problem. But if
you require that I provide such an element, see above for details.

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/ 







From owner-atom-syntax@mail.imc.org  Sun Jul 25 14:17: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 OAA20119
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 14:17: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 i6PI8uvL046179;
	Sun, 25 Jul 2004 11:08: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 i6PI8ugH046178;
	Sun, 25 Jul 2004 11:08: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.202])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6PI8tMQ046170
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 11:08:55 -0700 (PDT)
	(envelope-from eliast@gmail.com)
Received: by mproxy.gmail.com with SMTP id m68so69513rne
        for <atom-syntax@imc.org>; Sun, 25 Jul 2004 11:08:58 -0700 (PDT)
Received: by 10.38.89.38 with SMTP id m38mr467695rnb;
        Sun, 25 Jul 2004 11:08:58 -0700 (PDT)
Message-ID: <905f7c910407251108948a64f@mail.gmail.com>
Date: Sun, 25 Jul 2004 14:08:58 -0400
From: Elias Torres <eliast@gmail.com>
Reply-To: elias@torrez.us
To: Tim Bray <tim.bray@sun.com>
Subject: Re: URI scheme delusions
Cc: Mark Pilgrim <pilgrim@gmail.com>, "Bill de hÓra" <bill@dehora.net>,
        Sam Ruby <rubys@intertwingly.net>, Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <E162E7FC-DDFE-11D8-8C8C-000A95A51C9E@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <OF031774D8.BEC98F6C-ON88256EDB.00084992-88256EDB.00090B2C@us.ibm.com>
 <opsbm7jgwuuvpchu@quark> <41026240.8020009@intertwingly.net>
 <410266E4.6040304@dehora.net> <14be96d304072408524788c699@mail.gmail.com>
 <02F0CB0F-DD90-11D8-8C8C-000A95A51C9E@sun.com>
 <14be96d304072419285ec80400@mail.gmail.com> <E162E7FC-DDFE-11D8-8C8C-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 Sat, 24 Jul 2004 22:52:58 -0700, Tim Bray <tim.bray@sun.com> wrote:
> 
> On Jul 24, 2004, at 7:28 PM, Mark Pilgrim wrote:
> 
> >>   I
> >> am increasingly convinced of the virtue of putting dates in URIs, as
> >> in
> >> http://www.tbray.org/ongoing/When/200x/2004/07/24/WillYou [<== just an
> >> example, no Atom-related content here].
> >
> > If you lose the tbray.org domain, what then?  The new owner could
> > legitimately reuse this ID at any time to mean something else.  The
> > entire namespace belongs to them now; they can map it any way they
> > want without violating the http:// URI scheme.
> >
> > urn: solves this by registering namespaces permanently.
> 
> It seems to me that the identifier remains valid as an identifier even
> if someone else owns the namespace, particularly if there's a lot of
> software out there that knows it.  The identifier's function as an
> identifier does not, in any protocol we're likely to design, have any
> dependency on what you might get when you dereference it.  For example,
> I'm quite sure that the character string
> "http://www.w3.org/XML/1998/namespace" (the URI for the "xml:" prefix)
> will remain widely recognized in software long after the W3C has faded
> away and w3.org is owned by Wholesale Wolves and Weasels, Inc.  It's
> just a character string and the character string need not change.  As
> long as I own the namespace, the identifier will be potentially more
> useful because you might be able to dereference it to get some
> explanatory/supporting material.  A URN or tag: or whatever removes the
> possibility of direct dereference by ubiquitous software, thus
> buying... uh, what?  I've never understood.  The most typical use case
> of an identifier is as an input to a call like strcmp(), which doesn't
> care in the slightest about URI schemes.

I agree with Tim here. As a matter of fact this was the reason why I
suggested LSID. Although part of the LSID spec is about resolving and
fetching the data/metadata about an entry regardless of the protocol,
my recommendation was purely from an Identifier-only perspective.
Something that readers/applications/etc can use it to do strcmp()
with. At first, I thought Tim wanted HTTP URL/URIs because they were
resolvable etc, but I think the danger with it is that it will be
redundant. For example, why would we want to use the HTTP URL to the
entry as a unique identifier, when that URL is already available as
part of the feed in possible several other fields. It seems that every
RSS reader in the world uses the permalink (and maybe other things to
make an unique identifier). So what's the point of an ID field? I
would say that it's only for advanced users or applications that know
what they are doing and are really creating something unique and
durable.

I think through the excellent discussion everyone has had on the
subject, I see a concensus on dates playing an extremely important
role in identifiers so we can avoid GUIDs. For example, this URIs are
great examples of perfectly fine IDs.

http://fishbowl.pastiche.org/2004/05/31/jroller_does_it_again

urn:lsid:fishbowl.pastiche.org:2004.05.31:jroller_does_it_again

urn:lsid:fishbowl.pastiche.org:2004.05.31:jroller_does_it_again:21

I would also love to end this long thread, but not without a
conclusion. I cannot leave this topic with an atom:id that only says
"it must an URI". I think we would be doing a disservice to our users
if we did so.

I state that if you are going to use the same URL as the entry itself
whether is "good" or "bad" according to Tim Berners Lee, then might as
well not add extra bytes. If you are, we should have an excerpt on
suggested schemes. If we do, I'd rather use something that has been
spec'd out, such as LSID. Why? Because just like we suggest a specific
ISO format for date, we should do the same for IDs. The fishbowl
example is only useful to us in strcmp() and a browser, but nothing
else. On the other hand, the LSID URI has parts that need to be
conformant, such as authority (i.e. domain), namespace (i.e. a year),
object (i.e an entry ID) and optionally a version. Again, I strongly
believe we would get more benefit out of that , than just saying "use
an URI".

I'm really excited to be part of this mailing list. The diversity in
intellect and experience is so diverse that gives me hope that Atom
will be an excellent standard and addition to the Internet and if we
get lucky it will be as simple as C, HTTP, XML and others.

Elias

> 
> But can we please stop arguing?  Because it doesn't matter, I REALLY
> THINK it doesn't matter.  In Atom, there are going to be places where
> it says "this identifier should be a URI".  Those who really believe in
> a useful distinction between naming and location, or who believe that
> the URN registration process really produces longer-lived identifiers,
> can use that kind of URI.  Those of us who think that identifiers are
> made more useful by being potentially dereferencable will use HTTP
> URIs.   In a few decades we'll know who was right. -Tim
> 
>



From owner-atom-syntax@mail.imc.org  Sun Jul 25 14: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 OAA21616
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 14: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 i6PIlrM6049400;
	Sun, 25 Jul 2004 11: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 i6PIlrRH049399;
	Sun, 25 Jul 2004 11:47:53 -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 i6PIlqIq049386
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 11:47:52 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040725184751.91600.qmail@web41215.mail.yahoo.com>
Received: from [67.160.87.187] by web41215.mail.yahoo.com via HTTP; Sun, 25 Jul 2004 11:47:51 PDT
Date: Sun, 25 Jul 2004 11:47:51 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: URI scheme delusions
To: elias@torrez.us, Tim Bray <tim.bray@sun.com>
Cc: Mark Pilgrim <pilgrim@gmail.com>, Bill de "hÓra" <bill@dehora.net>,
        Sam Ruby <rubys@intertwingly.net>, Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <905f7c910407251108948a64f@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>


--- Elias Torres <eliast@gmail.com> wrote:
>
>  For example, why would we want to use the
> HTTP URL to the
> entry as a unique identifier, when that URL is
> already available as
> part of the feed in possible several other fields.
> It seems that every
> RSS reader in the world uses the permalink (and
> maybe other things to
> make an unique identifier). So what's the point of
> an ID field? 

Because using the permalink as a unique identifier is
a FUCKING HACK!!!!

Every aggregator author I have talked to wants a
unique identifier that is guaranteed to be relatively
stable. HTTP URLs are not. 

Excuse my language but this discussion along with the
one about dates implies to me that lots of the people
debating on this list aren't very knowledgeable about
technologies related to sydnication and are just
arguing based on assumption and suppositions. And you
know what they say about assumptions...

=====
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  Sun Jul 25 15:17: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 PAA23384
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 15:16: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 i6PJ6uVa050827;
	Sun, 25 Jul 2004 12:06: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 i6PJ6uPO050824;
	Sun, 25 Jul 2004 12:06:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6PJ6ufk050816
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 12:06:56 -0700 (PDT)
	(envelope-from hsivonen@iki.fi)
Received: from 217-140-251-133.adsl-net.finnetcom.net ([217.140.251.133]:58527
        "EHLO [217.140.251.133]" TLS-CIPHER: <none>) by smtp2.dnainternet.net
        with ESMTP id S1230668AbUGYTGw convert rfc822-to-8bit (ORCPT
        <rfc822;atom-syntax@imc.org>); Sun, 25 Jul 2004 22:06:52 +0300
Mime-Version: 1.0 (Apple Message framework v618)
In-Reply-To: <BD290B81.22365%eric.scheid@ironclad.net.au>
References: <BD290B81.22365%eric.scheid@ironclad.net.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <C79877C2-DE6D-11D8-9617-003065B8CF0E@iki.fi>
Content-Transfer-Encoding: 8BIT
From: Henri Sivonen <hsivonen@iki.fi>
Subject: Re: PaceDateline
Date:   Sun, 25 Jul 2004 22:06:48 +0300
To: Atom Syntax <atom-syntax@imc.org>
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>
Content-Transfer-Encoding: 8BIT


On Jul 25, 2004, at 00:02, Eric Scheid wrote:

> On 25/7/04 6:36 AM, "Asbjørn Ulsberg" <asbjorn@tigerstaden.no> wrote:
>
>>> Far better to have 'issued' missing than to have it polluted
>>
>> I agree, but why would people pollute it? If it is managed 100% by the
>> tool issuing the entries, how can it be polluted? And if tools have
>> difficulties providing this date, why is that?
>
> lack of capability in the tool + spec says 'issued' MUST be present
> = some other date gets stuffed in there, including dates which change
> = pollution

That's exactly what would happen.

The main argument for allowing mode="escaped" type="text/html" on 
various elements was that GIGO-CMSs with retrofitted Atom support will 
spew out entity escaped tag soup anyway, so it is better to provide the 
means for flagging it instead of fighting the phenomenon.

I see a very different design attitude wrt. required dates. Hmm.

-- 
Henri Sivonen
hsivonen@iki.fi
http://iki.fi/hsivonen/



From owner-atom-syntax@mail.imc.org  Sun Jul 25 15:25: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 PAA23917
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 15:25: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 i6PJFYsG051986;
	Sun, 25 Jul 2004 12:15:34 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6PJFY81051985;
	Sun, 25 Jul 2004 12:15:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from 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 i6PJFXU1051972
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 12:15:33 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040725191532.83929.qmail@web41201.mail.yahoo.com>
Received: from [67.160.87.187] by web41201.mail.yahoo.com via HTTP; Sun, 25 Jul 2004 12:15:32 PDT
Date: Sun, 25 Jul 2004 12:15:32 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: PaceDateline
To: Graham <dtcd@mac.com>, Sam Ruby <rubys@intertwingly.net>
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <A7D4B42E-DDB6-11D8-9170-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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


--- Graham <dtcd@mac.com> wrote:
> 
> > I then thought about the subtle distinction
> between updated and 
> > modified.  If aggregators are sorting on
> available, then I'm not sure 
> > what they would do with another field.  Thinking
> about it a bit more, 
> > one could argue that if somebody made a change and
> chose NOT to update 
> > the value of available, then one could imply a bit
> of intent.
> 
> I don't like this line of thought. I'd probably use
> <updated> to flag 
> an update in the listing (eg mark as unread). In
> fact I'd rather do 
> that than sort by it (or at least have the choice of
> not sorting by 
> it).

+1 

As an aggregator author I don't plan to sort on any
other date field besides available/issued. All the
other dates like modified/updated give me is the
option to do other things with the content like show
an HTML diff or highlight as unread. 


=====
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!?
Express yourself with Y! Messenger! Free. Download now. 
http://messenger.yahoo.com



From owner-atom-syntax@mail.imc.org  Sun Jul 25 15:29: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 PAA24260
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 15:29: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 i6PJKZDH052452;
	Sun, 25 Jul 2004 12: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 i6PJKZl8052451;
	Sun, 25 Jul 2004 12:20:35 -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 i6PJKYSZ052439
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 12:20:34 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040725192033.92675.qmail@web41206.mail.yahoo.com>
Received: from [67.160.87.187] by web41206.mail.yahoo.com via HTTP; Sun, 25 Jul 2004 12:20:33 PDT
Date: Sun, 25 Jul 2004 12:20:33 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: PaceDateline
To: "Asbjørn_Ulsberg" <asbjorn@tigerstaden.no>,
        Antone Roundy <antone@geckotribe.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <opsbovj6d6uvpchu@quark>
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>


--- Asbjørn_Ulsberg <asbjorn@tigerstaden.no> wrote:
> 
> > [1] It's been said before, but I'll say it again:
> you can claim that  
> > nothing special needs to be done to support the
> superceding mechanism,  
> > but any aggregator that doesn't implement it is
> going to have users  
> > screaming about duplicate entries and jumping ship
> to another aggregator.
> 
> That's exactly what happens today if an entry
> reappears in a feed, isn't  
> it? 

No it isn't. I've said so at least twice on this list
already. 

=====
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  Sun Jul 25 15:33:26 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24474
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 15:33: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 i6PJOfxN052752;
	Sun, 25 Jul 2004 12:24: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 i6PJOfsE052751;
	Sun, 25 Jul 2004 12:24:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6PJOe4T052737
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 12:24:40 -0700 (PDT)
	(envelope-from asbjorn@tigerstaden.no)
Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19])
	by smtpgateway.itweb.no (Postfix) with ESMTP
	id F08EF7C11E; Sun, 25 Jul 2004 22:20:38 +0200 (CEST)
Date: Sun, 25 Jul 2004 21:28:39 +0200
To: "Roger B." <roger@agincourtmedia.com>
Subject: Re: Date Options Survey
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <A90F3D41DF748CFB8886A18409CC6.MAI@journurl.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: <opsbpkd1dbuvpchu@quark>
In-Reply-To: <A90F3D41DF748CFB8886A18409CC6.MAI@journurl.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 25 Jul 2004 13:13:21 -0500, Roger B. <roger@agincourtmedia.com>  
wrote:

> I produce all kinds of feeds. A single entry can show up in a dozen
> different places, targeted at different needs. If I'm forced to provide  
> an issued date, then that date will be pulled from different fields  
> depending upon context.

The tools you use might not stamp the resources they issue with the time  
of issuance, but is there a good reason why these tools will _never_ do  
it? Absolutely all tools on the planet need to issue the resource to put  
it onto the web. That's how it gets there. If it's not issued, it's not on  
the web. If it issues stuff, why is it impossible to give that action a  
timestamp which goes with the issued resource?

> In a blog feed, the closest thing I have is the entry's "published" date.
> In a forum feed, the closest date would be "created".

Both forum posts and blog entries are issued.

> When I insert a date into an element, I'm not promising you that the date
> came from an internal field with a spec that exactly matches Atom's. I am
> asserting that you should use it for the purposes described in the spec.
> That's it, and nothing more. The harder it is for me to make accurate
> assertions, the harder it will be for consuming applications to satisfy
> their users.

So, if it is harder than today to give accurate metadata about your  
entries, _consumers_ will suffer? I don't understand this. If anything,  
it's the consumers, and not the publishers, who gain on having high  
quality data in the feeds.

-- 
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 Jul 25 15: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 PAA24868
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 15:47: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 i6PJbqrM053887;
	Sun, 25 Jul 2004 12:37: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 i6PJbqXx053886;
	Sun, 25 Jul 2004 12:37: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 i6PJbphl053871;
	Sun, 25 Jul 2004 12:37: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 B199F7C11E; Sun, 25 Jul 2004 22:33:54 +0200 (CEST)
Date: Sun, 25 Jul 2004 21:41:58 +0200
To: "Paul Hoffman / IMC" <phoffman@imc.org>
Subject: Re: URI scheme delusions
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <OF031774D8.BEC98F6C-ON88256EDB.00084992-88256EDB.00090B2C@us.ibm.com> <opsbm7jgwuuvpchu@quark> <41026240.8020009@intertwingly.net> <410266E4.6040304@dehora.net> <14be96d304072408524788c699@mail.gmail.com> <02F0CB0F-DD90-11D8-8C8C-000A95A51C9E@sun.com> <14be96d304072419285ec80400@mail.gmail.com> <E162E7FC-DDFE-11D8-8C8C-000A95A51C9E@sun.com> <opsboxrwu4uvpchu@quark> <p06110421bd2979d0ed16@[10.20.30.249]>
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: <opsbpkz8apuvpchu@quark>
In-Reply-To: <p06110421bd2979d0ed16@[10.20.30.249]>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 25 Jul 2004 07:58:40 -0700, Paul Hoffman / IMC <phoffman@imc.org>  
wrote:

> No. Trying to teach Bob and his friends why URNs are better than URLs is  
> futile, and that's OK. He shouldn't have to worry about it.

So you think it's more feasible for the few of those who actually know the  
difference between URN's and URL's to use the rest of the remaing days of  
their lives to go around preaching, writing articles, how-to's and so on  
about these differences, than to add a couple of sentences about it in the  
specification?

>>  Or do you have faith in that Bob, although he doesn't know anything  
>> (he has no idea what the difference between URI, URL or URN is, and he  
>> has only seen URL's «live»), will pick a scheme that is universally  
>> unique «enough»?
>
> Yes. If he is hand-coding, he has probably read enough of the RFC to get  
> it right. If he is using a tool, the tool will probably get it right.

If he is hard-coding, and the specification is completely silent on what  
scheme he should use, he will probably think «URI? What's that?», do some  
searching, and after having read a couple of pages about «Uri Geller»,  
«United Religions Initiative» and «Uniform Resource Identifiers» it's  
possible that he finally finds out that URI's are a superset for URL's.

«Oh, URL's! I know URL's», he will think, and just copy + paste the URL's  
of his entries into the atom:id element. Okay, the specification says that  
atom:id is globally unique («But my domain is my domain», Bob thinks) and  
MUST NOT change over time («But I'm not going to move my blog», Bob  
thinks), but that will not stop him from using his very non-universally  
unique URL's as identifiers for his entries.

May I remind you, this is not an exaggerated edge case. Many users are  
dumber than Bob, many users don't even read the specification, and many  
users read specifications and don't understand a crap of what it's saying,  
because their native language isn't english, because the specification is  
in hostile plain text, because specifications in general are hard to read,  
etc.

Instead of having so high thoughts about what Bob and his friends is able  
to think, find out and accomplish, just out of the blue, I would be more  
comfortable with making the specification as thorough and examplified as  
possible. Adding a couple of sentences about 'tag' and LSID URI's (if  
those schemes are final by the time Atom 1.0 ships) in section 4.2.6 and  
5.5, would do nothing but good.

> In those very rare cases, there is nothing we can do.

If everyone used a tag or LSID URI scheme, because the specification  
recommended everyone to do so, domain turnovers wouldn't be a problem  
either.

-- 
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 Jul 25 15:55:06 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25132
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 15:55:05 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6PJkFIx054415;
	Sun, 25 Jul 2004 12:46: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 i6PJkFXj054414;
	Sun, 25 Jul 2004 12:46:15 -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 i6PJkC32054404
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 12:46:15 -0700 (PDT)
	(envelope-from bill@wkearney.com)
Received: (qmail 18473 invoked from network); 25 Jul 2004 19:46:14 -0000
Received: from xbox.wkearney.com (HELO media) ([66.92.145.79])
          (envelope-sender <bill@wkearney.com>)
          by mail1.speakeasy.net (qmail-ldap-1.03) with SMTP
          for <atom-syntax@imc.org>; 25 Jul 2004 19:46:14 -0000
Message-ID: <001e01c47280$0b776190$200ca8c0@wkearney.com>
From: "Bill Kearney" <bill@wkearney.com>
To: <atom-syntax@imc.org>
References: <20040725163941.18745.qmail@web41214.mail.yahoo.com>
Subject: Re: Featuritis. was Re: Propose partial consensus on dates
Date: Sun, 25 Jul 2004 15:45:31 -0400
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: <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 isn't that there are too many features but more
> that people aren't acknowledging that the contents of
> an entry when used for syndication are different from
> when it is used as a payload of an API call or as an
> archival format.

+1.  The timestamps needed as a client pushes/pulls entries to/from whatever is
managing them are very likely to NEED to be different than those used in a thing
like a feed.  A feed, otoh, may well benefit from having it's own variations on
these.  Thus it becomes apparent that an archiving format would need to take
into account both and perhaps even add it's own.  Is this not clear to everyone
already?

> I seriously think there should be profiles of Atom for
> the 3 primary use cases and a glossary/inventory of
> Atom elements that is the union of all the
> elements/constructs in the 3 profiles.

I can't see any reason not to support such a notion.  However, the profiles
necessary to support individual item management and syndication output are
probably a lot less complicated than what might be used for archiving.  If only
from the standpoint of dealing with versioning of entries.

-Bill Kearney
Syndic8.com



From owner-atom-syntax@mail.imc.org  Sun Jul 25 16: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 QAA25551
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 16:05: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 i6PJt7e6055246;
	Sun, 25 Jul 2004 12:55: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 i6PJt7hf055245;
	Sun, 25 Jul 2004 12:55:07 -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 i6PJt6Ye055237
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 12:55:06 -0700 (PDT)
	(envelope-from wkearney@syndic8.com)
Received: (qmail 22195 invoked from network); 25 Jul 2004 19:55:10 -0000
Received: from xbox.wkearney.com (HELO media) ([66.92.145.79])
          (envelope-sender <wkearney@syndic8.com>)
          by mail3.speakeasy.net (qmail-ldap-1.03) with SMTP
          for <atom-syntax@imc.org>; 25 Jul 2004 19:55:10 -0000
Message-ID: <002501c47281$4ada1390$200ca8c0@wkearney.com>
From: "Bill Kearney" <wkearney@syndic8.com>
To: <atom-syntax@imc.org>
References: <200407251211.i6PCBQTC016639@above.proper.com>
Subject: Re: PaceDateline
Date: Sun, 25 Jul 2004 15:55:10 -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: <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 connection between geodata and notion of time is interesting, from a
> human point of view. If we reduce the connection between geodata and
> date/time to numbers, information is lost.

I disagree.  Furthermore I'll stress that the notion of equating time to
location is a horrible one, right up there with all the idiotic assumptions
about character encoding and well-formedness.  If you want to express geo-data
then do so, but do not expect a timestamp to reflect it.

> "Mid-February, northern Norway, in the middle of a spooky winter night"
> carries different information from:
>
> Date: 2005-02-14T03:07:32+02:00
> Latitude: 69 Deg 01 Min. 21 Sec.
> Longitude: 17 Deg 13 Min. 0 Sec.
>
> The first one says this is winter. Says that it is in Norway. Says it is
> spooky. This cannot be derived from the geodata,

Yes it most certainly can.  Just as many news and mail reading programs handle
showing you things grouped by Today, Yesterday, Last week and Ages ago, it's
entirely reasonable for them to provide filtering based on geo-data when
present.  A reader program interested in providing this sort of functionality is
a hell of a lot better off having machine processable data; not some mishmash of
text parsing hacks.

> In conclusion: connecting date and geo-information when this information is
> only meant for machine parsing, is quite meaningless. Allowing connection of
> human-provided info for humans is not.

This is an application issue, not a data storage or transport issue.

Don't get me wrong, I think it's a fascinating idea.  To be able to put material
into context based on locality and time is indeed a wonderful thing.

-Bill Kearney



From owner-atom-syntax@mail.imc.org  Sun Jul 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 QAA26285
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 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 i6PKAX8m056765;
	Sun, 25 Jul 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 i6PKAXDP056764;
	Sun, 25 Jul 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 smtpgateway.itweb.no ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6PKAWwq056751
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 13:10: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 069AC7C11E; Sun, 25 Jul 2004 23:06:36 +0200 (CEST)
To: elias@torrez.us
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: URI scheme delusions
References: <OF031774D8.BEC98F6C-ON88256EDB.00084992-88256EDB.00090B2C@us.ibm.com> <opsbm7jgwuuvpchu@quark> <41026240.8020009@intertwingly.net> <410266E4.6040304@dehora.net> <14be96d304072408524788c699@mail.gmail.com> <02F0CB0F-DD90-11D8-8C8C-000A95A51C9E@sun.com> <14be96d304072419285ec80400@mail.gmail.com> <E162E7FC-DDFE-11D8-8C8C-000A95A51C9E@sun.com> <905f7c910407251108948a64f@mail.gmail.com>
Message-ID: <opsbpmixbkuvpchu@quark>
Date: Sun, 25 Jul 2004 22:14:47 +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: <905f7c910407251108948a64f@mail.gmail.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 25 Jul 2004 14:08:58 -0400, Elias Torres <eliast@gmail.com> wrote:

> I would also love to end this long thread, but not without a
> conclusion. I cannot leave this topic with an atom:id that only says
> "it must an URI". I think we would be doing a disservice to our users
> if we did so.

I agree. LSID's or 'tag' URI's should be recommended as URI schemes in the  
specification. Something in the line of:

   atom:id MAY be a resolvable HTTP URI, but MUST NOT be expected to be
   one. The recommended URI schemes for atom:id is [...]

> If we do, I'd rather use something that has been spec'd out, such as
> LSID. Why? Because just like we suggest a specific ISO format for
> date, we should do the same for IDs.

Well put. +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  Sun Jul 25 16: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 QAA26332
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 16: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 i6PK5i8X056166;
	Sun, 25 Jul 2004 13:05:44 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6PK5hws056165;
	Sun, 25 Jul 2004 13:05:43 -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 i6PK5heD056158
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 13:05:43 -0700 (PDT)
	(envelope-from wkearney@syndic8.com)
Received: (qmail 31641 invoked from network); 25 Jul 2004 20:05:47 -0000
Received: from xbox.wkearney.com (HELO media) ([66.92.145.79])
          (envelope-sender <wkearney@syndic8.com>)
          by mail3.speakeasy.net (qmail-ldap-1.03) with SMTP
          for <atom-syntax@imc.org>; 25 Jul 2004 20:05:47 -0000
Message-ID: <004e01c47282$c65ec0f0$200ca8c0@wkearney.com>
From: "Bill Kearney" <wkearney@syndic8.com>
To: <atom-syntax@imc.org>
References: <BD29940B.22526%eric.scheid@ironclad.net.au>
Subject: Re: URI scheme delusions
Date: Sun, 25 Jul 2004 16:05:22 -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: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 8bit


> Given the rise of über-aggregators like syndic8, bloglines, technorati, etc
> ... it wouldn't be difficult for them to provide a dereferencing interface,
> providing the last known URL for any given URI (tag, urn, LSID, etc).

Yep, on Syndic8 we do this already for the source URL of an RSS feed.  When we
find a feed's moved we mark it as such and note the new location.  To resolve an
entry in a feed, however, is nearly impossible at this point in time.  There's
no consistent way to 'ask' for an instance of an item.  Mainly due to the
ambiguity of specs and the lack of useful data in the feeds themselves.

-Bill Kearney
Syndic8.com



From owner-atom-syntax@mail.imc.org  Sun Jul 25 16:47: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 QAA27170
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 16:47: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 i6PKZrcn058257;
	Sun, 25 Jul 2004 13:35:53 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6PKZrv8058256;
	Sun, 25 Jul 2004 13:35: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 i6PKZqIh058248
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 13:35: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 52DD27C11E; Sun, 25 Jul 2004 23:31:56 +0200 (CEST)
Date: Sun, 25 Jul 2004 22:40:13 +0200
To: "Roger B." <roger@agincourtmedia.com>
Subject: Re: Date Options Analysis: Issued
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <8D0C838FBFA146559761C1532C1EA4.MAI@journurl.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: <opsbpnpbfhuvpchu@quark>
In-Reply-To: <8D0C838FBFA146559761C1532C1EA4.MAI@journurl.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 25 Jul 2004 02:12:56 -0500, Roger B. <roger@agincourtmedia.com>  
wrote:

>> Since I've answered your questions regarding this, what is the solid use
>> case for ever changing 'issued'?
>
> Asbjorn: Happens every day.

There are use cases, but if you don't even _want_ 'issued' in Atom Core,  
why would you want to destroy it?

> (1) User is on vacation and posts (via email) three messages documenting
> three days of her trip. She hits "send", and all three messages get  
> posted. However, she has no way to specify the publish date from within
> her mail client, so all three posts end up with today's date. When she
> gets home, she logs in and fixes the problem.

I'd say she should use 'dateline' instead.

> (2) User posts via an API client that doesn't support user-specified pub
> dates. Later, she has to log in and fix the problem.

Dateline.

> (3) User keeps a rigid, daily diary, but forgets to post until 1AM the  
> next day. So he posts quickly before bed, and goes back in the morning
> to fix the problem.

Dateline.

> (4) User posts three entries that are meant to be read in a specific  
> order, but forgets to take her blog's reverse chronological order into
> account.

Ordering of elements _inside_ the publishing system should not be based on  
the data being served outside of it. I know Movable Type works like this,  
but I can't make myself to think anything else than that this behavior is  
wrong.

Other, more professional content management systems order elements based  
on explicit order if you tell them to. E.g., they get ordered  
automatically by issued date until you interfere and say «I want this to  
go there instead». Destroying perfectly good data because the CMS behaves  
bad is not a good use case to allow for a destroyed 'issued' date.

> (5) User is cheating on his wife, and suddenly realizes that his blog  
> entry from three days ago indicates that he was playing golf, when he
> told her that he was playing golf *four* days ago. She he has to login
> and fix the problem.

He has to log in, I presume. This would be in the same ally as the use  
case as when an issued date is set wrong because of bad server  
configuration, so the data needs to be fixed afterwards. This should of  
course be possible, but nothing the CMS encourages the user to do. E.g.  
not as available as the 'Created' field in Movable Type.

> (6) User posts "into the future" about an event or whatever, and the  
> event gets pushed back. He has to login and fix the problem.

What does he fix then? Doesn't he just delete the entry, or removes the  
'Publish' state? Why does the date have to change, when the entry isn't  
even issued yet? Or do you think it's perfectly okay that an entry appears  
in a feed, but have 'issued' set to a future date?

> (7) JournURL-specific: User posts an entry, but forgets to check the
> "weblog" box on the posting page. Her entry shows up in the forum, but  
> not in her blog. When she spots the missing post four days later, she
> edits it to make it show up in her blog, and updates the pub date so
> her readers won't miss it.

One could maybe see the two entries as such separate as different 'issued'  
is okay, but this should be much more elegantly solved in the CMS. If a  
user edits the entry, checks the «weblog» box and issues the entry again,  
it should appear in her feed with the recent issued date, while reside  
with first one in the forum.

> I could go on like this for pages. People are people. They change their
> minds. They do dumb things. Sometimes they're evil. Sometimes the world  
> is.

People should maintain dates that are interesting to people. Machines  
should maintain dates that are interesting do machines. People _may_ be  
allowed to edit the dates that are interesting to machines, but should not  
be encouraged to 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  Sun Jul 25 16: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 QAA27278
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 16: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 i6PKgf6E058569;
	Sun, 25 Jul 2004 13:42: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 i6PKgf4K058568;
	Sun, 25 Jul 2004 13:42: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 i6PKge6l058561
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 13:42:41 -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 i6PKhhxr026001;
	Sun, 25 Jul 2004 16:43:47 -0400
Message-ID: <41041B3C.1040402@intertwingly.net>
Date: Sun, 25 Jul 2004 16:42:36 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Dare Obasanjo <kpako@yahoo.com>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceDateline
References: <20040725191532.83929.qmail@web41201.mail.yahoo.com>
In-Reply-To: <20040725191532.83929.qmail@web41201.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: <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:
> --- Graham <dtcd@mac.com> wrote:
> 
>>>I then thought about the subtle distinction
>>between updated and 
>>>modified.  If aggregators are sorting on
>>available, then I'm not sure 
>>>what they would do with another field.  Thinking
>>about it a bit more, 
>>>one could argue that if somebody made a change and
>>chose NOT to update 
>>>the value of available, then one could imply a bit
>>of intent.
>>
>>I don't like this line of thought. I'd probably use
>><updated> to flag 
>>an update in the listing (eg mark as unread). In
>>fact I'd rather do 
>>that than sort by it (or at least have the choice of
>>not sorting by 
>>it).
> 
> +1 
> 
> As an aggregator author I don't plan to sort on any
> other date field besides available/issued. All the
> other dates like modified/updated give me is the
> option to do other things with the content like show
> an HTML diff or highlight as unread. 

Here's a concrete example that I will use to set up my question below:

http://www.tbray.org/ongoing/When/200x/2004/07/20/AuthoringPain

This was originally published on 2004/07/20.  It was significantly 
updated four days later.  If you look at http://www.tbray.org/ongoing/, 
you will see that this entry was sorted back to the top.

It clearly was Tim's intent that readers who saw the original be 
presented with the updated version.  Presumably, there are other changes 
(typo fixes) for which there isn't this intent.

It is desirable for there to be a way for Tim to unambiguously to convey 
his intent.  Tim attempted to signal his intent by updating the value of 
pubDate.

Testing with RSSBandit, I found that to my surprise, it appears that if 
the value of pubDate changes from the first time the feed is fetched, 
RSSBandit will continue to present, and optionally sort by, the original 
value.

At the present time, with the version of RSSBandit that I have installed 
(1.2.0.112), it appears that the only way to achieve this is to change 
the value of the link tag.

I take it that you are with Asbjørn in suggesting that this is the right 
way to signal significant changes?

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Sun Jul 25 17:10: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 RAA27833
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 17:10: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 i6PL0Vus059619;
	Sun, 25 Jul 2004 14: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 i6PL0VHd059618;
	Sun, 25 Jul 2004 14:00:31 -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 i6PL0U08059611
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 14:00:30 -0700 (PDT)
	(envelope-from wkearney@syndic8.com)
Received: (qmail 9879 invoked from network); 25 Jul 2004 21:00:32 -0000
Received: from xbox.wkearney.com (HELO media) ([66.92.145.79])
          (envelope-sender <wkearney@syndic8.com>)
          by mail3.speakeasy.net (qmail-ldap-1.03) with SMTP
          for <atom-syntax@imc.org>; 25 Jul 2004 21:00:32 -0000
Message-ID: <007001c4728a$6c68b030$200ca8c0@wkearney.com>
From: "Bill Kearney" <wkearney@syndic8.com>
Cc: "Atom-Syntax" <atom-syntax@imc.org>
References: <OF031774D8.BEC98F6C-ON88256EDB.00084992-88256EDB.00090B2C@us.ibm.com> <opsbm7jgwuuvpchu@quark> <41026240.8020009@intertwingly.net> <410266E4.6040304@dehora.net> <14be96d304072408524788c699@mail.gmail.com> <02F0CB0F-DD90-11D8-8C8C-000A95A51C9E@sun.com> <14be96d304072419285ec80400@mail.gmail.com>
Subject: Re: URI scheme delusions
Date: Sun, 25 Jul 2004 17:00:31 -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: <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


> If you lose the tbray.org domain, what then?  The new owner could
> legitimately reuse this ID at any time to mean something else.  The
> entire namespace belongs to them now; they can map it any way they
> want without violating the http:// URI scheme.

So who the hell cares?  If someone doesn't care enough to 'maintain stewardship'
over a URL space then what's the f'ing point?  They're just as likely to be
derelict in their stewardship of any other form of identifier.

There are distinct differences on why something needs the ability to be
"identified".  Perhaps a discussion about that would be more useful than just
sniping at one specific form of identifier vs another.

-Bill Kearney



From owner-atom-syntax@mail.imc.org  Sun Jul 25 17: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 RAA27953
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 17:14:22 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6PL42uT060016;
	Sun, 25 Jul 2004 14:04: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 i6PL42GB060015;
	Sun, 25 Jul 2004 14:04:02 -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 i6PL42N5060000
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 14:04:02 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040725210402.56030.qmail@web41214.mail.yahoo.com>
Received: from [67.160.87.187] by web41214.mail.yahoo.com via HTTP; Sun, 25 Jul 2004 14:04:02 PDT
Date: Sun, 25 Jul 2004 14:04:02 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: PaceDateline
To: Sam Ruby <rubys@intertwingly.net>
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <41041B3C.1040402@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:
> Dare Obasanjo wrote:
> > 
> > As an aggregator author I don't plan to sort on
> any
> > other date field besides available/issued. All the
> > other dates like modified/updated give me is the
> > option to do other things with the content like
> show
> > an HTML diff or highlight as unread. 
> 
> Here's a concrete example that I will use to set up
> my question below:
> 
>
http://www.tbray.org/ongoing/When/200x/2004/07/20/AuthoringPain
> 
> This was originally published on 2004/07/20.  It was
> significantly 
> updated four days later.  If you look at
> http://www.tbray.org/ongoing/, 
> you will see that this entry was sorted back to the
> top.
> 
> It clearly was Tim's intent that readers who saw the
> original be 
> presented with the updated version.  Presumably,
> there are other changes 
> (typo fixes) for which there isn't this intent.

Probably. 

> It is desirable for there to be a way for Tim to
> unambiguously to convey 
> his intent.  Tim attempted to signal his intent by
> updating the value of 
> pubDate.

OK. 

> Testing with RSSBandit, I found that to my surprise,
> it appears that if 
> the value of pubDate changes from the first time the
> feed is fetched, 
> RSSBandit will continue to present, and optionally
> sort by, the original 
> value.

Yes. I'm debating with myself on whether I should
consider this a bug or not. 

> At the present time, with the version of RSSBandit
> that I have installed 
> (1.2.0.112), it appears that the only way to achieve
> this is to change 
> the value of the link tag.

Yes. 

> I take it that you are with Asbjørn in suggesting
> that this is the right 
> way to signal significant changes?

No. As has been pointed out before Asbjørn's solution
makes aggregators that support his supersede mechanism
appear broken to users since they end up with
"duplicate" entries. 

RSS Bandit does not visually identify modifications
and the like because it is not functionality I have
found desirable nor is it something that the several
thousand people who've used RSS Bandit or the hundreds
of people who've submitted feature requests and bug
reports have ever asked for. So it shouldn't be used
as an example of an aggregator that cares about
modifications. I'd suggest trying NetNewsWire or
SharpReader to see what they do with Tim's post. 






=====
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  Sun Jul 25 17:42: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 RAA28816
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 17: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 i6PLQFqq061737;
	Sun, 25 Jul 2004 14:26: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 i6PLQFQC061736;
	Sun, 25 Jul 2004 14:26:15 -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 i6PLQDHx061725
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 14:26:15 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040725212613.20279.qmail@web41209.mail.yahoo.com>
Received: from [67.160.87.187] by web41209.mail.yahoo.com via HTTP; Sun, 25 Jul 2004 14:26:13 PDT
Date: Sun, 25 Jul 2004 14:26:13 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: PaceDateline
To: Dare Obasanjo <kpako@yahoo.com>, Sam Ruby <rubys@intertwingly.net>
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <20040725210402.56030.qmail@web41214.mail.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


Missing word in my response. Added in ALL CAPS. 

--- Dare Obasanjo <kpako@yahoo.com> wrote:
>  > I take it that you are with Asbjørn in suggesting
> > that this is the right 
> > way to signal significant changes?
> 
> No. As has been pointed out before Asbjørn's
> solution
> makes aggregators that DON'T support his supersede
> mechanism
> appear broken to users since they end up with
> "duplicate" entries. 
> 

=====
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  Sun Jul 25 18:26: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 SAA01349
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 18:26: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 i6PMG6sC065316;
	Sun, 25 Jul 2004 15:16: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 i6PMG6N1065315;
	Sun, 25 Jul 2004 15:16:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from dumle.webhuset.no (dumle.webhuset.no [81.27.32.66])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6PMG4FO065298
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 15:16:05 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Message-Id: <200407252216.i6PMG4FO065298@above.proper.com>
Received: (qmail 25886 invoked from network); 25 Jul 2004 22:14:27 -0000
Received: from unknown (HELO localhost.localdomain) (81.27.34.19)
  by 0 with SMTP; 25 Jul 2004 22:14:27 -0000
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
MIME-Version: 1.0
From: "Arve Bersvendsen" <arve@virtuelvis.com>
To: "Bill Kearney" <wkearney@syndic8.com>, atom-syntax@imc.org
Subject: Re: PaceDateline
Date: Mon, 26 Jul 2004 00:16:04 +0200
X-Mailer: WHMail 1.0 (http://www.webhuset.no)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6PMG6FO065310
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 Kearney
> > The connection between geodata and notion of time is interesting, from a
> > human point of view. If we reduce the connection between geodata and
> > date/time to numbers, information is lost.
> 
> I disagree.  Furthermore I'll stress that the notion of equating time to
> location is a horrible one, right up there with all the idiotic assumptions

> about character encoding and well-formedness.  If you want to express
> geo-data  then do so, but do not expect a timestamp to reflect it.

Eh. I think we are in agreement here. I might have expressed it in a clumsy
way: I think geodata is wonderful as well: I just don't think it belongs
inside a date construct.

> > "Mid-February, northern Norway, in the middle of a spooky winter night"
> > carries different information from:
> >
> > Date: 2005-02-14T03:07:32+02:00
> > Latitude: 69 Deg 01 Min. 21 Sec.
> > Longitude: 17 Deg 13 Min. 0 Sec.
> >
> > The first one says this is winter. Says that it is in Norway. Says it is
> > spooky. This cannot be derived from the geodata,
> 
> Yes it most certainly can.  

It carries a lot of the information, but not all. Note that I'm not arguing
in favour of the textual piece of information: I'm simply arguing that
they're different, and carries different information to the person _reading_.


btw: I don't think the first construct belongs in DateLine. It would suit
much better within the first few paragraphs of the actual content.

> A reader program interested in providing this sort of functionality
> is a hell of a lot better off having machine processable data; not some
mishmash
> of text parsing hacks.

+1 

> Don't get me wrong, I think it's a fascinating idea.	To be able to put
> material into context based on locality and time is indeed a wonderful
thing.

Yeah, but you donšt think it belongs inside a date construct either?



From owner-atom-syntax@mail.imc.org  Sun Jul 25 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 TAA02740
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 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 i6PMuTuN068314;
	Sun, 25 Jul 2004 15: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 i6PMuTDc068313;
	Sun, 25 Jul 2004 15:56:29 -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 i6PMuSZw068304
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 15:56:28 -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 i6PMuJvu024174;
	Sun, 25 Jul 2004 18:56:19 -0400 (EDT)
Received: from w2kbwyman (66-65-128-165.nyc.rr.com [66.65.128.165])
	by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA)
	with ESMTP id BJZ53306 (AUTH bob@wyman.us);
	Sun, 25 Jul 2004 18:56:28 -0400 (EDT)
Reply-To: <bob@wyman.us>
From: "Bob Wyman" <bob@wyman.us>
To: "'Mark Pilgrim'" <pilgrim@gmail.com>, "'Bill de hXra'" <bill@dehora.net>
Cc: "'Sam Ruby'" <rubys@intertwingly.net>,
        "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: RE: URI scheme delusions
Date: Sun, 25 Jul 2004 18:58:22 -0400
Message-ID: <007701c4729a$e37cbf30$6601a8c0@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: <14be96d304072408524788c699@mail.gmail.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


Mark Pilgrim wrote:
> If only there were some way to create an identifier that 
> combined a domain name with, say, a date on which you
> controlled that domain.
	That's exactly what is done in:

RFC-3085 URN Namespace for NewsML Resources. A. Coates, D. Allen, D.
     Rivers-Moore. March 2001. (Format: TXT=10016 bytes) (Status:
     INFORMATIONAL)
See: http://www.ietf.org/rfc/rfc3085.txt

	It might be nice to have a similar, if not almost identical,
scheme for "atomid"...

		bob wyman



From owner-atom-syntax@mail.imc.org  Sun Jul 25 19: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 TAA03410
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 19:26: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 i6PNF1f5069452;
	Sun, 25 Jul 2004 16: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 i6PNF1GB069451;
	Sun, 25 Jul 2004 16:15: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 i6PNF0E8069440
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 16:15:00 -0700 (PDT)
	(envelope-from roger@agincourtmedia.com)
Received: from biggreen ([216.63.148.42]) by journurl.com with MailEnable ESMTP; Sun, 25 Jul 2004 18:14:46 -0500
From: "Roger B." <roger@agincourtmedia.com>
To: "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: RE: Date Options Analysis: Issued
Date: Sun, 25 Jul 2004 18:20:20 -0500
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: <opsbpnpbfhuvpchu@quark>
Thread-Index: AcRyhzIbeUIi3OVvRE6quYl06q58VgAEX5Iw
Message-ID: <39A3314160A548FEB49DF065FFC37D.MAI@journurl.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


> There are use cases, but if you don't even _want_ 'issued' in Atom Core,
> why would you want to destroy it?

Asbjorn: I've said this repeatedly on the list and on the wiki, but I'll say
it yet again.

I do not wish to "destroy" your definition of "issued". In the spirit of
compromise, I would be more than willing to embrace it. I'm not convinced it
needs to be in the core, given that millions of feeds can't supply it, but
I'm flexible on that as well.

*All* I am saying at this point is that "issued" cannot be required. That's
it. If it's required, it's a non-starter. If it's optional, our little
corner of the world will live as one.

> I'd say she should use 'dateline' instead.

I agree. Unfortunately, you've been advocating "issued" as a required
element, which means that whatever would normally go into "dateline" will
just have to go into "issued" as well.

> I know Movable Type works like this,
> but I can't make myself to think anything else than that this behavior is
> wrong.

You can keep on thinkin' it, but we're not here to tell Six Apart how to
build their apps. 

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/ 







From owner-atom-syntax@mail.imc.org  Sun Jul 25 19:31:42 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03595
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 19: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 i6PNO7ZF069952;
	Sun, 25 Jul 2004 16:24:07 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6PNO7TT069951;
	Sun, 25 Jul 2004 16:24: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-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 i6PNO6xc069943
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 16:24:06 -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 i6PNLr53007698
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 17:21:53 -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 <0I1F007LUL09IM@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sun, 25 Jul 2004 17:24:09 -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 <0I1F00KYFL083N@mail.sun.net> for atom-syntax@imc.org; Sun,
 25 Jul 2004 17:24:09 -0600 (MDT)
Date: Sun, 25 Jul 2004 16:24:22 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: URI scheme delusions
In-reply-to: <opsbpmixbkuvpchu@quark>
To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
Cc: elias@torrez.us, Atom-Syntax <atom-syntax@imc.org>
Message-id: <C2C9EB04-DE91-11D8-8C8C-000A95A51C9E@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.618)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
References: 
 <OF031774D8.BEC98F6C-ON88256EDB.00084992-88256EDB.00090B2C@us.ibm.com>
 <opsbm7jgwuuvpchu@quark> <41026240.8020009@intertwingly.net>
 <410266E4.6040304@dehora.net> <14be96d304072408524788c699@mail.gmail.com>
 <02F0CB0F-DD90-11D8-8C8C-000A95A51C9E@sun.com>
 <14be96d304072419285ec80400@mail.gmail.com>
 <E162E7FC-DDFE-11D8-8C8C-000A95A51C9E@sun.com>
 <905f7c910407251108948a64f@mail.gmail.com> <opsbpmixbkuvpchu@quark>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6PNO6xc069946
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 Jul 25, 2004, at 1:14 PM, Asbjørn Ulsberg wrote:

> I agree. LSID's or 'tag' URI's should be recommended as URI schemes in 
> the specification.

For the record, I strongly disagree.  If it turns out that I'm a tiny 
minority, we'll recognize consensus the other way.  However, it will be 
unacceptable to reference an unregistered URI scheme.

BTW, consider http://www.w3.org/TR/webarch/#generic-uri

>  Something in the line of:
>
>   atom:id MAY be a resolvable HTTP URI, but MUST NOT be expected to be
>   one.

I agree with that part.  Anyone have a problem with that?  -Tim



From owner-atom-syntax@mail.imc.org  Sun Jul 25 19:35: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 TAA03775
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 19:35: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 i6PNSdCM070227;
	Sun, 25 Jul 2004 16:28:39 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6PNSdog070226;
	Sun, 25 Jul 2004 16:28:39 -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 i6PNSdCt070220
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 16:28:39 -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 i6PNQS53008554
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 17:26:28 -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 <0I1F00J1CL7VHM@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sun, 25 Jul 2004 17:28: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 <0I1F00KYKL7V3N@mail.sun.net> for atom-syntax@imc.org; Sun,
 25 Jul 2004 17:28:43 -0600 (MDT)
Date: Sun, 25 Jul 2004 16:28:56 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceDateline
In-reply-to: <20040725210402.56030.qmail@web41214.mail.yahoo.com>
To: Dare Obasanjo <kpako@yahoo.com>
Cc: Sam Ruby <rubys@intertwingly.net>, Atom-Syntax <atom-syntax@imc.org>
Message-id: <662EE006-DE92-11D8-8C8C-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: <20040725210402.56030.qmail@web41214.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 Jul 25, 2004, at 2:04 PM, Dare Obasanjo wrote:

> http://www.tbray.org/ongoing/When/200x/2004/07/20/AuthoringPain
>>
>> This was originally published on 2004/07/20.  It was
>> significantly
>> updated four days later.  If you look at
>> http://www.tbray.org/ongoing/,
>> you will see that this entry was sorted back to the
>> top.
>>
>> It clearly was Tim's intent that readers who saw the
>> original be
>> presented with the updated version.  Presumably,
>> there are other changes
>> (typo fixes) for which there isn't this intent.
>
> Probably.

It was.

>  Testing with RSSBandit, I found that to my surprise,
>> it appears that if
>> the value of pubDate changes from the first time the
>> feed is fetched,
>> RSSBandit will continue to present, and optionally
>> sort by, the original
>> value.
>
> Yes. I'm debating with myself on whether I should
> consider this a bug or not.

 From my point of view, in this case, it's clearly a bug.  I don't knonw 
whether I'm an edge case, but what I did certainly feels like a natural 
idiomatic use of the Web.

> I'd suggest trying NetNewsWire or
> SharpReader to see what they do with Tim's post.

NNW lets you choose whether to sort on date or title, I've never sorted 
by anything but date, which brings the revised version to the top. -Tim



From owner-atom-syntax@mail.imc.org  Sun Jul 25 19: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 TAA03980
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 19:39: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 i6PNU4GO070355;
	Sun, 25 Jul 2004 16:30: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 i6PNU4ND070351;
	Sun, 25 Jul 2004 16:30:04 -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 i6PNU3cC070345
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 16:30:04 -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 i6PNOKuo001490;
	Sun, 25 Jul 2004 19:24:20 -0400 (EDT)
Received: from w2kbwyman (66-65-128-165.nyc.rr.com [66.65.128.165])
	by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA)
	with ESMTP id BJZ61162 (AUTH bob@wyman.us);
	Sun, 25 Jul 2004 19:29:48 -0400 (EDT)
Reply-To: <bob@wyman.us>
From: "Bob Wyman" <bob@wyman.us>
To: <elias@torrez.us>, "'Tim Bray'" <tim.bray@sun.com>
Cc: "'Mark Pilgrim'" <pilgrim@gmail.com>, "'Bill de hXra'" <bill@dehora.net>,
        "'Sam Ruby'" <rubys@intertwingly.net>,
        "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: RE: URI scheme delusions
Date: Sun, 25 Jul 2004 19:31:43 -0400
Message-ID: <007801c4729f$8bb41d20$6601a8c0@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: <905f7c910407251108948a64f@mail.gmail.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


Elias Torres wrote:
> we should have an excerpt on suggested schemes. If we do, I'd 
> rather use something that has been spec'd out, such as LSID.
> Why? Because just like we suggest a specific ISO format for
> date, we should do the same for IDs.
	As far as I can see, LSID offers nothing over what is provided
by the NewsML URN scheme[1]. In fact, I would suggest that the NewsML
scheme is better since it is more strongly specified. (i.e. the "date
field" must really be a date while LSID apparently only requires a
"unique id" such as the "myblog-entries-2003" that Elias provided in one
of his examples.) Given that LSID offers nothing new and given that it
appears less rigorously specified, I would strongly suggest that any new
standard should be based on NewsML, not the later and weaker LSID. As
Elias points out, it is sensible to base practices on things that are
already "spec'd out." NewsML has been in use in the field for quite a
few years and was made an RFC back in 2001. It has history and it was
designed to address the problem of "news syndication" -- which is
precisely the same problem, but in a different realm, that Atom is
attempting to address.

	Apparently, the LSID scheme is:
urn:lsid:yourdomain.com:namespace:uniqueID[:version]

	The NewsML scheme can be summarized as:
urn:newsml:domain:date:itemId[:RevisionId][Update]

	Note: Update is specific to "News" items and is probably
relevant to syndication usage (no surprise since NewsML was generated by
news syndicators). The value of update is "U" if the referenced item is
an update to a previous item, "A" if it is a replacement for a previous
item and suppressed in all other cases.
	The sample urns from RFC 3085 are:
   urn:newsml:iptc.org:20001006:NewsMLv1.0:1
 
urn:newsml:reuters.com:20000206:IIMFFH05643_2000-02-06_17-54-01_L0615658
4:1U

		bob wyman

[1] http://www.ietf.org/rfc/rfc3085.txt



From owner-atom-syntax@mail.imc.org  Sun Jul 25 19:44: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 TAA04181
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 19:44: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 i6PNXR7s070637;
	Sun, 25 Jul 2004 16:33: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 i6PNXREf070636;
	Sun, 25 Jul 2004 16:33: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-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 i6PNXQ7b070630
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 16:33:26 -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 i6PNXWil015414
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 17:33:32 -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 <0I1F00J5HLFVHM@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sun, 25 Jul 2004 17:33:32 -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 <0I1F00KDMLFV3Q@mail.sun.net> for atom-syntax@imc.org; Sun,
 25 Jul 2004 17:33:31 -0600 (MDT)
Date: Sun, 25 Jul 2004 16:33:45 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Survey please
To: "Atom-Syntax Syntax'" <atom-syntax@imc.org>
Message-id: <120E0E3B-DE93-11D8-8C8C-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: <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 see reputable implementors with widely-distributed products arguing 
about the date conundrum here but not making their mark over at 
http://intertwingly.net/wiki/pie/DateSurvey - please help with the 
information-gathering.  If you have some sort of a problem using the 
wiki, email me and I'll record your position for you. -Tim



From owner-atom-syntax@mail.imc.org  Sun Jul 25 19: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 TAA04516
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 19: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 i6PNjpUJ071729;
	Sun, 25 Jul 2004 16:45: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 i6PNjpIu071728;
	Sun, 25 Jul 2004 16:45:51 -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 i6PNjo5V071717
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 16:45:50 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040725234551.63163.qmail@web41210.mail.yahoo.com>
Received: from [67.160.87.187] by web41210.mail.yahoo.com via HTTP; Sun, 25 Jul 2004 16:45:51 PDT
Date: Sun, 25 Jul 2004 16:45:51 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: PaceDateline
To: Tim Bray <Tim.Bray@Sun.COM>
Cc: Sam Ruby <rubys@intertwingly.net>, Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <662EE006-DE92-11D8-8C8C-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:

> >
>
http://www.tbray.org/ongoing/When/200x/2004/07/20/AuthoringPain
> >>
> >> This was originally published on 2004/07/20.  It
> was
> >> significantly
> >> updated four days later.  If you look at
> >> http://www.tbray.org/ongoing/,
> >> you will see that this entry was sorted back to
> the
> >> top.

> >> RSSBandit will continue to present, and
> optionally
> >> sort by, the original
> >> value.
> >
> > Yes. I'm debating with myself on whether I should
> > consider this a bug or not.
> 
>  From my point of view, in this case, it's clearly a
> bug. 

What spec backs up this position? Reading the RSS 2.0
description of pubDate it seems to map quite well to
dc:issued. I find it quote illogical to expect that
the date of issuance for a particular entry should
change, so RSS Bandit does not change the original
pubDate of an entry. 

It seems you are trying to add additional semantics to
those of pubDate above and beyond the intent and
letter of the RSS 2.0 specification. 

> I don't knonw 
> whether I'm an edge case, but what I did certainly
> feels like a natural 
> idiomatic use of the Web.

If it is idiomatic can you point at 5 other entities
amongst the millions that use the WWW that also engage
in this behavior? 

> > I'd suggest trying NetNewsWire or
> > SharpReader to see what they do with Tim's post.
> 
> NNW lets you choose whether to sort on date or
> title, I've never sorted 
> by anything but date, which brings the revised
> version to the top. -Tim

The question isn't whether they sort on date but
whether they replace old pubDate values with the new
one or do other things to imply that the post has been
updated. 

=====
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  Sun Jul 25 19:58: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 TAA04812
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 19:58: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 i6PNnWqR071899;
	Sun, 25 Jul 2004 16:49:32 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6PNnWGQ071898;
	Sun, 25 Jul 2004 16:49:32 -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 i6PNnVlD071891
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 16:49:31 -0700 (PDT)
	(envelope-from bobwyman@pubsub.com)
Received: from w2kbwyman (66-65-128-165.nyc.rr.com [66.65.128.165])
	by mail.pubsub.com (Postfix) with ESMTP
	id 4E914171D2A; Sun, 25 Jul 2004 19:50:38 -0400 (EDT)
Reply-To: <bobwyman@pubsub.com>
From: "Bob Wyman" <bobwyman@pubsub.com>
To: "'Dare Obasanjo'" <kpako@yahoo.com>, <elias@torrez.us>,
        "'Tim Bray'" <tim.bray@sun.com>
Cc: "'Mark Pilgrim'" <pilgrim@gmail.com>, "'Bill de hXra'" <bill@dehora.net>,
        "'Sam Ruby'" <rubys@intertwingly.net>,
        "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: RE: URI scheme delusions
Date: Sun, 25 Jul 2004 19:51:25 -0400
Organization: PubSub Concepts, Inc.
Message-ID: <007901c472a2$4c62ac60$6601a8c0@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: <20040725184751.91600.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


Dare Obasanjo wrote:
> [passionate expressions censored...]
> Every aggregator author I have talked to wants a
> unique identifier that is guaranteed to be relatively
> stable. HTTP URLs are not. 
	+1. I would like to strongly support Dare's comments (although
not his language...) on this subject. It is critical for aggregators and
services like PubSub.com's that we get as close to unique, stable, entry
identifiers as we can. Experience with RSS and Atom indicates clearly
that URL's just don't do the job. I appreciate all the arguments that
say that they *could* do the job -- however, experience processing over
1.5 million entries every day culled from several million RSS and Atom
files indicates that they don't. i.e. theory and reality don't match in
this case. 
	The problem here may be that people have traditionally been very
relaxed about assigning URL's. Support for and reliance on HTTP's
redirection may be the root of this problem... Nonetheless, there is
very little rigor involved in creating and maintaining URL's -- even
though there *could* be. But, it is clear that we're not going to be
able to get people to change the way they work today. Thus, the best
argument for insisting that atom:id *not* be an URL may be simply to get
people to treat atom:id's differently then they do URLs. By declaring
atom:id to be a different "type" we can also encourage a different set
of practices around it.

> this discussion along with the one about dates implies
> to me that lots of the people debating on this list
> aren't very knowledgeable about technologies related
> to sydnication and are just arguing based on assumption
> and suppositions.
	I fear that I have to support Dare on the above comment as well.
I hate to do a "call to authority" but the truth is that it seems clear
that the problems related to consuming massive quantities of Atom feeds
just aren't as obvious as they might be. For folk that *aren't* actually
building aggregators or feed processors, I think it would be good from
time to time if you gave a little weight to those of us who are doing
this things. Yes, we should probably be doing a better job of explaining
what the issues are, however, when many of us have the same
complaint/request, it should at least indicate that a real problem
exists. Also, please note that is is very clear that the issues related
to generating feeds are very different from those related to consuming
them.

		bob wyman

	
-----Original Message-----
From: owner-atom-syntax@mail.imc.org
[mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Dare Obasanjo
Sent: Sunday, July 25, 2004 2:48 PM
To: elias@torrez.us; Tim Bray
Cc: Mark Pilgrim; Bill de hXra; Sam Ruby; Atom-Syntax
Subject: Re: URI scheme delusions



--- Elias Torres <eliast@gmail.com> wrote:
>
>  For example, why would we want to use the
> HTTP URL to the
> entry as a unique identifier, when that URL is
> already available as
> part of the feed in possible several other fields.
> It seems that every
> RSS reader in the world uses the permalink (and
> maybe other things to
> make an unique identifier). So what's the point of
> an ID field?

Because using the permalink as a unique identifier is
a FUCKING HACK!!!!

Every aggregator author I have talked to wants a
unique identifier that is guaranteed to be relatively
stable. HTTP URLs are not. 

Excuse my language but this discussion along with the
one about dates implies to me that lots of the people
debating on this list aren't very knowledgeable about technologies
related to sydnication and are just arguing based on assumption and
suppositions. And you know what they say about assumptions...

=====
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  Sun Jul 25 19:59:21 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04846
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 19:59:21 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6PNp2ja072012;
	Sun, 25 Jul 2004 16:51: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 i6PNp2lI072011;
	Sun, 25 Jul 2004 16:51: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 i6PNp2aA072000
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 16:51:02 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040725235102.21028.qmail@web41201.mail.yahoo.com>
Received: from [67.160.87.187] by web41201.mail.yahoo.com via HTTP; Sun, 25 Jul 2004 16:51:02 PDT
Date: Sun, 25 Jul 2004 16:51:02 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: RE: URI scheme delusions
To: bob@wyman.us, elias@torrez.us, "'Tim Bray'" <tim.bray@sun.com>
Cc: "'Mark Pilgrim'" <pilgrim@gmail.com>, "'Bill de hXra'" <bill@dehora.net>,
        "'Sam Ruby'" <rubys@intertwingly.net>,
        "'Atom-Syntax'" <atom-syntax@imc.org>
In-Reply-To: <007801c4729f$8bb41d20$6601a8c0@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:
> 
> 	As far as I can see, LSID offers nothing over what
> is provided
> by the NewsML URN scheme[1]. In fact, I would
> suggest that the NewsML
> scheme is better since it is more strongly
> specified. (i.e. the "date
> field" must really be a date while LSID apparently
> only requires a
> "unique id" such as the "myblog-entries-2003" that
> Elias provided in one
> of his examples.) Given that LSID offers nothing new
> and given that it
> appears less rigorously specified, I would strongly
> suggest that any new
> standard should be based on NewsML, not the later
> and weaker LSID. 

+1 

I definitely would be love to see an addition to the
Atom spec encouraging the use of NewsML URNs as
identifiers in Atom feeds. 

> 
> 	Apparently, the LSID scheme is:
> urn:lsid:yourdomain.com:namespace:uniqueID[:version]
> 
> 	The NewsML scheme can be summarized as:
> urn:newsml:domain:date:itemId[:RevisionId][Update]
> 
> 	Note: Update is specific to "News" items and is
> probably
> relevant to syndication usage (no surprise since
> NewsML was generated by
> news syndicators). The value of update is "U" if the
> referenced item is
> an update to a previous item, "A" if it is a
> replacement for a previous
> item and suppressed in all other cases.

I seem to remember reading somewhere that the Web
Architecture is for URIs to be opaque. I feel a little
uncomfortable with the idea of storing change tracking
and revision information as part of the identifier.
But not that uncomfortable as to prevent me from
adding my +1 to using NewsML URNs in Atom. 

=====
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  Sun Jul 25 20:04: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 UAA05178
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 20: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 i6PNtwWw072712;
	Sun, 25 Jul 2004 16:55: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 i6PNtwJn072711;
	Sun, 25 Jul 2004 16:55: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.205])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6PNtvHe072705
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 16:55:57 -0700 (PDT)
	(envelope-from eliast@gmail.com)
Received: by mproxy.gmail.com with SMTP id m68so78155rne
        for <atom-syntax@imc.org>; Sun, 25 Jul 2004 16:56:03 -0700 (PDT)
Received: by 10.38.12.79 with SMTP id 79mr498882rnl;
        Sun, 25 Jul 2004 16:56:02 -0700 (PDT)
Message-ID: <905f7c910407251656205472e9@mail.gmail.com>
Date: Sun, 25 Jul 2004 19:56:02 -0400
From: Elias Torres <eliast@gmail.com>
Reply-To: elias@torrez.us
To: bob@wyman.us
Subject: Re: URI scheme delusions
Cc: elias@torrez.us, Tim Bray <tim.bray@sun.com>,
        Mark Pilgrim <pilgrim@gmail.com>, Bill de hXra <bill@dehora.net>,
        Sam Ruby <rubys@intertwingly.net>, Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <007801c4729f$8bb41d20$6601a8c0@wyman.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <007801c4729f$8bb41d20$6601a8c0@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


You are correct, Bob. Just looking at the URN schemes I think either
way is better than just recommending URIs w/o any extra specification.
Although, I must say LSID is more than just a URN scheme but a
protocol for resolving and fetching data associated with whatever it
is you named with the LSID.

Although, I think we need to focus the energy of this discussion into
what needs to come out of it:

Leave the spec as it with just a URI? 
Is it a "recommendation" of several schemes that would serve good to
both readers and publisher of atom feeds?
Come up with an atom scheme for IDs? 

What will it be? There's no right or wrong, but what we can agree
would help most Atom users.

Elias

On Sun, 25 Jul 2004 19:31:43 -0400, Bob Wyman <bob@wyman.us> wrote:
> 
> Elias Torres wrote:
> > we should have an excerpt on suggested schemes. If we do, I'd
> > rather use something that has been spec'd out, such as LSID.
> > Why? Because just like we suggest a specific ISO format for
> > date, we should do the same for IDs.
>         As far as I can see, LSID offers nothing over what is provided
> by the NewsML URN scheme[1]. In fact, I would suggest that the NewsML
> scheme is better since it is more strongly specified. (i.e. the "date
> field" must really be a date while LSID apparently only requires a
> "unique id" such as the "myblog-entries-2003" that Elias provided in one
> of his examples.) Given that LSID offers nothing new and given that it
> appears less rigorously specified, I would strongly suggest that any new
> standard should be based on NewsML, not the later and weaker LSID. As
> Elias points out, it is sensible to base practices on things that are
> already "spec'd out." NewsML has been in use in the field for quite a
> few years and was made an RFC back in 2001. It has history and it was
> designed to address the problem of "news syndication" -- which is
> precisely the same problem, but in a different realm, that Atom is
> attempting to address.
> 
>         Apparently, the LSID scheme is:
> urn:lsid:yourdomain.com:namespace:uniqueID[:version]
> 
>         The NewsML scheme can be summarized as:
> urn:newsml:domain:date:itemId[:RevisionId][Update]
> 
>         Note: Update is specific to "News" items and is probably
> relevant to syndication usage (no surprise since NewsML was generated by
> news syndicators). The value of update is "U" if the referenced item is
> an update to a previous item, "A" if it is a replacement for a previous
> item and suppressed in all other cases.
>         The sample urns from RFC 3085 are:
>    urn:newsml:iptc.org:20001006:NewsMLv1.0:1
> 
> urn:newsml:reuters.com:20000206:IIMFFH05643_2000-02-06_17-54-01_L0615658
> 4:1U
> 
>                 bob wyman
> 
> [1] http://www.ietf.org/rfc/rfc3085.txt
> 
>



From owner-atom-syntax@mail.imc.org  Sun Jul 25 20: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 UAA05240
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 20: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 i6PNv8Cp072751;
	Sun, 25 Jul 2004 16:57: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 i6PNv8Vm072750;
	Sun, 25 Jul 2004 16:57:08 -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 i6PNv7i1072744
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 16:57:07 -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 i6PNwCL0002716;
	Sun, 25 Jul 2004 19:58:12 -0400
Message-ID: <410448D6.3080207@intertwingly.net>
Date: Sun, 25 Jul 2004 19:57:10 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <Tim.Bray@Sun.COM>
CC: Dare Obasanjo <kpako@yahoo.com>, Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceDateline
References: <20040725210402.56030.qmail@web41214.mail.yahoo.com> <662EE006-DE92-11D8-8C8C-000A95A51C9E@sun.com>
In-Reply-To: <662EE006-DE92-11D8-8C8C-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 Jul 25, 2004, at 2:04 PM, Dare Obasanjo wrote:

>> I'd suggest trying NetNewsWire or
>> SharpReader to see what they do with Tim's post.
> 
> NNW lets you choose whether to sort on date or title, I've never sorted 
> by anything but date, which brings the revised version to the top. -Tim

Now we are getting to the heart of the issue that is bothering me.

In the absense of guidance in the existing specifications, Tim did what 
made sense to him, and what worked with his preferred tool.

Other people have different ideas of what makes sense to them, and what 
works in their preferred tools.  Trying to transpose what Tim did to the 
terminology used by Atom and/or Dublin Core results in a thumbs down by 
Graham and Dare.

That's not the way this should work.

- Sam Ruby







From owner-atom-syntax@mail.imc.org  Sun Jul 25 20: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 UAA05456
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 20:09: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 i6Q00whQ073004;
	Sun, 25 Jul 2004 17:00: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 i6Q00w5m073003;
	Sun, 25 Jul 2004 17:00:58 -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 i6Q00v7r072997
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 17:00:57 -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 i6Q013il021443
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 18:01:03 -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 <0I1F009I8MPQLU@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sun, 25 Jul 2004 18:01:03 -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 <0I1F00KE0MPP3Q@mail.sun.net> for atom-syntax@imc.org; Sun,
 25 Jul 2004 18:01:01 -0600 (MDT)
Date: Sun, 25 Jul 2004 17:01:14 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceDateline
In-reply-to: <20040725234551.63163.qmail@web41210.mail.yahoo.com>
To: Dare Obasanjo <kpako@yahoo.com>
Cc: Sam Ruby <rubys@intertwingly.net>, Atom-Syntax <atom-syntax@imc.org>
Message-id: <E93DB728-DE96-11D8-8C8C-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: <20040725234551.63163.qmail@web41210.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 Jul 25, 2004, at 4:45 PM, Dare Obasanjo wrote:

>>> Yes. I'm debating with myself on whether I should
>>> consider this a bug or not.
>>
>>  From my point of view, in this case, it's clearly a
>> bug.
>
> What spec backs up this position? Reading the RSS 2.0
> description of pubDate it seems to map quite well to
> dc:issued. I find it quote illogical to expect that
> the date of issuance for a particular entry should
> change, so RSS Bandit does not change the original
> pubDate of an entry.

http://blogs.law.harvard.edu/tech/rss#hrelementsOfLtitemgt says "Its 
value is a date, indicating when the item was published".  Well, I 
clearly did something to that entry yesterday which resulted in 
substantially new content showing up on the web.  I had naively thought 
that "published" was a reasonable word to describe what I did.  But if 
the correct reading is "same as dc:issued" then clearly I'm mis-using 
it.  Uh, let's agree that in Atom, we're going to be a little more 
explicit so that if someone like me screws up then someone like Dare 
has a better basis for the pointing of fingers.

>> I don't knonw
>> whether I'm an edge case, but what I did certainly
>> feels like a natural
>> idiomatic use of the Web.
>
> If it is idiomatic can you point at 5 other entities
> amongst the millions that use the WWW that also engage
> in this behavior?

It may be the case that I've been mis-using <pubDate>.  However, the 
notion of "Last-Modified" is important enough to have its own HTTP 
header.  In what I would consider normal syndication workflows 
last-modified is generally seen as important information to have.

Surely you would agree that one of the defining differences between the 
Web and prior publishing media is that you can update in place.

>> NNW lets you choose whether to sort on date or
>> title, I've never sorted
>> by anything but date, which brings the revised
>> version to the top. -Tim
>
> The question isn't whether they sort on date but
> whether they replace old pubDate values with the new
> one or do other things to imply that the post has been
> updated.

Both.  That is to say, if you change the content of the feed NNW will 
notice and highlight it even if you don't change the date.  But if you 
change the date, NNW definitely respects that. -Tim



From owner-atom-syntax@mail.imc.org  Sun Jul 25 20:32:33 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06181
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 20:32:32 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q0P0H6074756;
	Sun, 25 Jul 2004 17:25: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 i6Q0P0EN074754;
	Sun, 25 Jul 2004 17:25:00 -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 i6Q0P0hF074748
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 17:25:00 -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 i6Q0Otvu006215
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 20:24:55 -0400 (EDT)
Received: from w2kbwyman (66-65-128-165.nyc.rr.com [66.65.128.165])
	by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA)
	with ESMTP id BJZ73492 (AUTH bob@wyman.us);
	Sun, 25 Jul 2004 20:25:03 -0400 (EDT)
Reply-To: <bob@wyman.us>
From: "Bob Wyman" <bob@wyman.us>
To: "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: PaceAtomIDIsNewsML (Requiring atom:id to be a NewsML URN)
Date: Sun, 25 Jul 2004 20:26:57 -0400
Message-ID: <007c01c472a7$431c9cb0$6601a8c0@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


I've created a Pace to require that atom:id be a NewsML URN.
See: http://www.intertwingly.net/wiki/pie/PaceAtomIDIsNewsML

For the specification of NewsML URNs see:
http://ietf.org/rfc/rfc3085.txt

		bob wyman

=========================
Abstract
Require that atom:id is a NewsML URN. Proposed by: [BobWyman] 

Status
Open 

Rationale
Much aggregator and processor experience indicates that not providing
strong guidance on the proper formation of atom:id's results in great
difficulties for the processors of atom feeds. See: mailing list
discussion. 

Proposal
Change sections 4.2.6 and 5.5 of the format specification to read: 

4.2.6 "atom:id" Element 

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. atom:head elements MAY contain an atom:id element, but
MUST NOT contain more than one. The content of this element, when
present, MUST be a NewsML URN. 
5.5 "atom:id" Element 

The "atom:id" element's content conveys a permanent, globally unique
identifier for the entry. It 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. 

atom:entry MUST contain exactly one atom:id element. The content of this
element MUST be a NewsML URN. 

Impacts
Slightly increases complexity of generating atom feeds and entries since
an identifier other than permalink must be created for each feed and
entry. 

Significantly increases the ability of feed aggregators and other atom
processors to detect and manage new atom entries and feeds. 

Notes
See: RFC 3085 http://ietf.org/rfc/rfc3085.txt 



From owner-atom-syntax@mail.imc.org  Sun Jul 25 20:54: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 UAA07005
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 20: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 i6Q0hSjA076002;
	Sun, 25 Jul 2004 17:43: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 i6Q0hSvJ076001;
	Sun, 25 Jul 2004 17:43:28 -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 i6Q0hR11075992
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 17:43:28 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 40079 messnum 437003 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 26 Jul 2004 00:43:28 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail05.svc.cra.dublin.eircom.net (qp 40079) with SMTP; 26 Jul 2004 00:43:28 -0000
Message-ID: <41045392.9000606@dehora.net>
Date: Mon, 26 Jul 2004 01:42:58 +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: Tim Bray <Tim.Bray@Sun.COM>
CC: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>,
        elias@torrez.us, Atom-Syntax <atom-syntax@imc.org>
Subject: Re: URI scheme delusions
References: <OF031774D8.BEC98F6C-ON88256EDB.00084992-88256EDB.00090B2C@us.ibm.com> <opsbm7jgwuuvpchu@quark> <41026240.8020009@intertwingly.net> <410266E4.6040304@dehora.net> <14be96d304072408524788c699@mail.gmail.com> <02F0CB0F-DD90-11D8-8C8C-000A95A51C9E@sun.com> <14be96d304072419285ec80400@mail.gmail.com> <E162E7FC-DDFE-11D8-8C8C-000A95A51C9E@sun.com> <905f7c910407251108948a64f@mail.gmail.com> <opsbpmixbkuvpchu@quark> <C2C9EB04-DE91-11D8-8C8C-000A95A51C9E@sun.com>
In-Reply-To: <C2C9EB04-DE91-11D8-8C8C-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:

> 
> On Jul 25, 2004, at 1:14 PM, Asbjørn Ulsberg wrote:
> 
> BTW, consider http://www.w3.org/TR/webarch/#generic-uri
> 
>>  Something in the line of:
>>
>>   atom:id MAY be a resolvable HTTP URI, but MUST NOT be expected to be
>>   one.
> 
> I agree with that part.  Anyone have a problem with that?  -Tim

Other than wondering if "resolvable" is introducing new terminology 
where "dereferencable" would do, no.

cheers
Bill




From owner-atom-syntax@mail.imc.org  Sun Jul 25 21: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 VAA07203
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 21: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 i6Q0pD21076411;
	Sun, 25 Jul 2004 17:51:13 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6Q0pDGt076410;
	Sun, 25 Jul 2004 17:51:13 -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 i6Q0pCdT076391
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 17:51:12 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 3068 messnum 2009980 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 26 Jul 2004 00:51:12 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail09.svc.cra.dublin.eircom.net (qp 3068) with SMTP; 26 Jul 2004 00:51:12 -0000
Message-ID: <41045562.2020102@dehora.net>
Date: Mon, 26 Jul 2004 01:50:42 +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: bobwyman@pubsub.com
CC: "'Dare Obasanjo'" <kpako@yahoo.com>, elias@torrez.us,
        "'Tim Bray'" <tim.bray@Sun.COM>, "'Mark Pilgrim'" <pilgrim@gmail.com>,
        "'Sam Ruby'" <rubys@intertwingly.net>,
        "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: Re: URI scheme delusions
References: <007901c472a2$4c62ac60$6601a8c0@wyman.us>
In-Reply-To: <007901c472a2$4c62ac60$6601a8c0@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:
> Dare Obasanjo wrote:
> 
>>[passionate expressions censored...]
>>Every aggregator author I have talked to wants a
>>unique identifier that is guaranteed to be relatively
>>stable. HTTP URLs are not. 
> 
> 	+1. I would like to strongly support Dare's comments (although
> not his language...) on this subject. It is critical for aggregators and
> services like PubSub.com's that we get as close to unique, stable, entry
> identifiers as we can. Experience with RSS and Atom indicates clearly
> that URL's just don't do the job. I appreciate all the arguments that
> say that they *could* do the job -- however, experience processing over
> 1.5 million entries every day culled from several million RSS and Atom
> files indicates that they don't. i.e. theory and reality don't match in
> this case. 
> 	The problem here may be that people have traditionally been very
> relaxed about assigning URL's. Support for and reliance on HTTP's
> redirection may be the root of this problem... Nonetheless, there is
> very little rigor involved in creating and maintaining URL's -- even
> though there *could* be. But, it is clear that we're not going to be
> able to get people to change the way they work today. Thus, the best
> argument for insisting that atom:id *not* be an URL may be simply to get
> people to treat atom:id's differently then they do URLs. By declaring
> atom:id to be a different "type" we can also encourage a different set
> of practices around it.

I'm more curious about the requirements in Atom for identifiers 
rather than the technology/policy used, so I can figure out if folks 
are getting testy for interesting reasons. My /impression/ is that 
what's driving this is the implicit requirement, "all Atom entries 
must have unique (space and time) surrogate keys to support 
aggregation use-cases". Is that right?

Also, does anyone think that specifying that atom:id not contain 
HTTP (or some broader subset of) URIs is baking bad practice into 
the spec? For example, as one might argue that not speccing 
PUT/DELETE is baking in the bad practice of subsetting HTTP.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Sun Jul 25 21:04: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 VAA07289
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 21: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 i6Q0qur4076558;
	Sun, 25 Jul 2004 17: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 i6Q0quWA076557;
	Sun, 25 Jul 2004 17:52:56 -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 i6Q0qt67076551
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 17:52:56 -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 i6Q0qu53025969
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 19:52:56 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6Q0qtHr025965;
	Sun, 25 Jul 2004 19:52:55 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: <atom-syntax@imc.org>
Subject: Re: PaceAtomIDIsNewsML (Requiring atom:id to be a NewsML URN)
References: <007c01c472a7$431c9cb0$6601a8c0@wyman.us>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 25 Jul 2004 19:52:55 -0500
In-Reply-To: <007c01c472a7$431c9cb0$6601a8c0@wyman.us>
Message-ID: <m3ekmz8u8o.fsf@bitsko.slc.ut.us>
Lines: 18
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: <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> writes:

> I've created a Pace to require that atom:id be a NewsML URN.  See:
> http://www.intertwingly.net/wiki/pie/PaceAtomIDIsNewsML

-1.

Permathread.

Merely suggesting that the identifier should not be a URI-locator in
the examples and user guides is bad enough, but mandating a particular
URI scheme is a non-starter.

The current Atom spec says the URI should be globally (not
universally, ie. time-wise) unique.  That is sufficient for
interoperation and sufficient for the specification.

  -- Ken



From owner-atom-syntax@mail.imc.org  Sun Jul 25 21:07: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 VAA07498
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 21:07: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 i6Q0vnoL076891;
	Sun, 25 Jul 2004 17:57: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 i6Q0vnEe076890;
	Sun, 25 Jul 2004 17:57:49 -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 i6Q0vnKx076878
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 17:57:49 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040726005750.87290.qmail@web41214.mail.yahoo.com>
Received: from [67.160.87.187] by web41214.mail.yahoo.com via HTTP; Sun, 25 Jul 2004 17:57:50 PDT
Date: Sun, 25 Jul 2004 17:57:50 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: URI scheme delusions
To: "Bill_de_hÓra" <bill@dehora.net>, bobwyman@pubsub.com
Cc: "'Dare Obasanjo'" <kpako@yahoo.com>, elias@torrez.us,
        "'Tim Bray'" <tim.bray@Sun.COM>, "'Mark Pilgrim'" <pilgrim@gmail.com>,
        "'Sam Ruby'" <rubys@intertwingly.net>,
        "'Atom-Syntax'" <atom-syntax@imc.org>
In-Reply-To: <41045562.2020102@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:
>  
> I'm more curious about the requirements in Atom for
> identifiers 
> rather than the technology/policy used, so I can
> figure out if folks 
> are getting testy for interesting reasons. My
> /impression/ is that 
> what's driving this is the implicit requirement,
> "all Atom entries 
> must have unique (space and time) surrogate keys to
> support 
> aggregation use-cases". Is that right?

As long as I've followed Atom this has been the
driving use case. 

> Also, does anyone think that specifying that atom:id
> not contain 
> HTTP (or some broader subset of) URIs is baking bad
> practice into 
> the spec? For example, as one might argue that not
> speccing 
> PUT/DELETE is baking in the bad practice of
> subsetting HTTP.

What is the bad practice? Don't believe in the
delusion that URLs and URNs are equal? Quite frankly,
the bad practice was foisted on us by the IETF and W3C
when they created the mess that are URIs instead of
leaving URLs and URNs seperate. 

As I mentioned before, everywhere I have seen HTTP
URLs used as URIs (i.e. identifiers instead of
locations) it has lead to confusion, ambiguity and
user irritation. RSS, RDF and XML namespaces are all
examples of the problems that the URI fallacy has
caused. 

=====
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  Sun Jul 25 21:07: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 VAA07537
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 21:07: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 i6Q0rKZ9076595;
	Sun, 25 Jul 2004 17: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 i6Q0rKFu076594;
	Sun, 25 Jul 2004 17:53:20 -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 i6Q0rKxe076586
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 17:53:20 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040726005321.2333.qmail@web41213.mail.yahoo.com>
Received: from [67.160.87.187] by web41213.mail.yahoo.com via HTTP; Sun, 25 Jul 2004 17:53:21 PDT
Date: Sun, 25 Jul 2004 17:53:21 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: PaceAtomIDIsNewsML (Requiring atom:id to be a NewsML URN)
To: bob@wyman.us, "'Atom-Syntax'" <atom-syntax@imc.org>
In-Reply-To: <007c01c472a7$431c9cb0$6601a8c0@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:
> 
> I've created a Pace to require that atom:id be a
> NewsML URN.
> See:
>
http://www.intertwingly.net/wiki/pie/PaceAtomIDIsNewsML

+1 

Awesome. 

=====
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  Sun Jul 25 21: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 VAA07555
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 21: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 i6Q0wRZx076943;
	Sun, 25 Jul 2004 17:58: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 i6Q0wRSk076942;
	Sun, 25 Jul 2004 17:58:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [165.121.169.136] (user-2ivfmik.dialup.mindspring.com [165.247.218.84])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q0vxlT076897;
	Sun, 25 Jul 2004 17:58:18 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p06110404bd2a062c02e6@[165.121.169.136]>
In-Reply-To: <C2C9EB04-DE91-11D8-8C8C-000A95A51C9E@sun.com>
References: 
  <OF031774D8.BEC98F6C-ON88256EDB.00084992-88256EDB.00090B2C@us.ibm.com>
 <opsbm7jgwuuvpchu@quark> <41026240.8020009@intertwingly.net>
 <410266E4.6040304@dehora.net> <14be96d304072408524788c699@mail.gmail.com>
 <02F0CB0F-DD90-11D8-8C8C-000A95A51C9E@sun.com>
 <14be96d304072419285ec80400@mail.gmail.com>
 <E162E7FC-DDFE-11D8-8C8C-000A95A51C9E@sun.com>
 <905f7c910407251108948a64f@mail.gmail.com> <opsbpmixbkuvpchu@quark>
 <C2C9EB04-DE91-11D8-8C8C-000A95A51C9E@sun.com>
Date: Sun, 25 Jul 2004 17:52:34 -0700
To: Tim Bray <Tim.Bray@Sun.COM>,
        =?iso-8859-1?Q?Asbj=F8rn?= Ulsberg <asbjorn@tigerstaden.no>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: URI scheme delusions
Cc: elias@torrez.us, Atom-Syntax <atom-syntax@imc.org>
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 4:24 PM -0700 7/25/04, Tim Bray wrote:
>For the record, I strongly disagree.  If it turns out that I'm a 
>tiny minority, we'll recognize consensus the other way.  However, it 
>will be unacceptable to reference an unregistered URI scheme.

Further, it will never get approved by the IESG, for very good reason.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Sun Jul 25 21:12:23 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07686
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 21:12:23 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q14Jlo077337;
	Sun, 25 Jul 2004 18:04: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 i6Q14Jb2077336;
	Sun, 25 Jul 2004 18:04:19 -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 i6Q14IfE077330
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 18:04:18 -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 i6Q13lvu012555;
	Sun, 25 Jul 2004 21:03:47 -0400 (EDT)
Received: from w2kbwyman (66-65-128-165.nyc.rr.com [66.65.128.165])
	by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA)
	with ESMTP id BJZ81877 (AUTH bob@wyman.us);
	Sun, 25 Jul 2004 21:03:56 -0400 (EDT)
Reply-To: <bob@wyman.us>
From: "Bob Wyman" <bob@wyman.us>
To: "=?iso-8859-1?Q?'Bill_de_h=D3ra'?=" <bill@dehora.net>
Cc: "'Dare Obasanjo'" <kpako@yahoo.com>, <elias@torrez.us>,
        "'Tim Bray'" <tim.bray@Sun.COM>, "'Mark Pilgrim'" <pilgrim@gmail.com>,
        "'Sam Ruby'" <rubys@intertwingly.net>,
        "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: RE: URI scheme delusions
Date: Sun, 25 Jul 2004 21:05:50 -0400
Message-ID: <007d01c472ac$b182feb0$6601a8c0@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
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Importance: Normal
In-Reply-To: <41045562.2020102@dehora.net>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6Q14JfE077331
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:
> My /impression/ is that what's driving this is the implicit
> requirement, "all Atom entries must have unique (space and
> time) surrogate keys to support aggregation use-cases".
> Is that right?
	Yes. The NUMBER ONE complaint we get from PubSub users is that
there are duplicate entries in the feeds we generate. Other aggregators
have told me that their experience is the same. The problem is that we
simply can't do good enough duplicate detection based on textual
analysis of entries (i.e. computing MD5 hashes, etc.) if only because
entries that are hosted in multiple feeds often undergo slight changes
when copied from feed to feed (i.e. some whitespace may be dropped URL's
may change because of a "base" change.) Thus, the only hope we have of
doing a good job of duplicate detection is relying on statements by the
entry generator. i.e. if they give us unique, immutable ids and explicit
"Updated" dates.

> Also, does anyone think that specifying that atom:id not
> contain HTTP (or some broader subset of) URIs is baking
> bad practice into the spec?
	No. HTTP is only one of many protocols that are support URIs. In
the case of identifiers it turns out that its use introduces unfortunate
side-effects. One can support URI's and URN's without supporting HTTP. 

		bob wyman




From owner-atom-syntax@mail.imc.org  Sun Jul 25 21:15: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 VAA07834
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 21: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 i6Q17dXH077718;
	Sun, 25 Jul 2004 18:07: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 i6Q17dUh077717;
	Sun, 25 Jul 2004 18:07:39 -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 i6Q17cQX077711
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 18:07:39 -0700 (PDT)
	(envelope-from distobj@acm.org)
Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian))
	id 1Botya-0001gP-00; Sun, 25 Jul 2004 21:08:24 -0400
Date: Sun, 25 Jul 2004 21:08:24 -0400
To: Bob Wyman <bob@wyman.us>
Cc: "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: Re: PaceAtomIDIsNewsML (Requiring atom:id to be a NewsML URN)
Message-ID: <20040726010824.GG30868@markbaker.ca>
References: <007c01c472a7$431c9cb0$6601a8c0@wyman.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <007c01c472a7$431c9cb0$6601a8c0@wyman.us>
User-Agent: Mutt/1.3.28i
From: Mark Baker <distobj@acm.org>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


On Sun, Jul 25, 2004 at 08:26:57PM -0400, Bob Wyman wrote:
> I've created a Pace to require that atom:id be a NewsML URN.
> See: http://www.intertwingly.net/wiki/pie/PaceAtomIDIsNewsML

-1, for the same reasons Ken gave.

Mark.



From owner-atom-syntax@mail.imc.org  Sun Jul 25 21:21:27 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08021
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 21:21:27 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q1D9NG078218;
	Sun, 25 Jul 2004 18: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 i6Q1D9FD078217;
	Sun, 25 Jul 2004 18:13:09 -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 i6Q1D8g4078198
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 18:13:08 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 49382 messnum 1892152 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 26 Jul 2004 01:13:08 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail02.svc.cra.dublin.eircom.net (qp 49382) with SMTP; 26 Jul 2004 01:13:08 -0000
Message-ID: <41045A85.5030704@dehora.net>
Date: Mon, 26 Jul 2004 02:12:37 +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: Dare Obasanjo <kpako@yahoo.com>
CC: bob@wyman.us, elias@torrez.us, "'Tim Bray'" <tim.bray@sun.com>,
        "'Mark Pilgrim'" <pilgrim@gmail.com>,
        "'Sam Ruby'" <rubys@intertwingly.net>,
        "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: Re: URI scheme delusions
References: <20040725235102.21028.qmail@web41201.mail.yahoo.com>
In-Reply-To: <20040725235102.21028.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: <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:


> I seem to remember reading somewhere that the Web
> Architecture is for URIs to be opaque. I feel a little
> uncomfortable with the idea of storing change tracking
> and revision information as part of the identifier.
> But not that uncomfortable as to prevent me from
> adding my +1 to using NewsML URNs in Atom. 

NewsML isn't neccessarily inconsistent with that. But given you 
would be mandating a urn that has semantic import (update classs, 
rev numbers), tunneling/abuse wrt Atom notions of identity seems 
inevitable.

I suggest that a Tag URI is a better choice as it has less semantics 
that NewsML plus NewsML urns are explicitly specified as being for 
identifying NewsML content.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Sun Jul 25 21:28: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 VAA08262
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 21:28: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 i6Q1JRpW079037;
	Sun, 25 Jul 2004 18:19: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 i6Q1JRxS079036;
	Sun, 25 Jul 2004 18:19: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 i6Q1JRsU079023
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 18:19:27 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040726011928.44460.qmail@web41215.mail.yahoo.com>
Received: from [67.160.87.187] by web41215.mail.yahoo.com via HTTP; Sun, 25 Jul 2004 18:19:28 PDT
Date: Sun, 25 Jul 2004 18:19:28 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: PaceAtomIDIsNewsML (Requiring atom:id to be a NewsML URN)
To: Ken MacLeod <ken@bitsko.slc.ut.us>, atom-syntax@imc.org
In-Reply-To: <m3ekmz8u8o.fsf@bitsko.slc.ut.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>


--- Ken MacLeod <ken@bitsko.slc.ut.us> wrote:
>  
> The current Atom spec says the URI should be
> globally (not
> universally, ie. time-wise) unique.  That is
> sufficient for
> interoperation and sufficient for the specification.
> 

No it isn't. Bob is an aggregator author and I'm an
aggregator author who both have experience having to
write code to process the millions of syndication
feeds out there and answer to thousands of customers.
Both of us have said based on our experience the
current specification text is for interoperation and
is harmful to a positive user experience. 

Besides dismissing our points of view with your
statements of authority do you have any arguments to
justify your position. I have several. What are yours? 

=====
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!?
Express yourself with Y! Messenger! Free. Download now. 
http://messenger.yahoo.com



From owner-atom-syntax@mail.imc.org  Sun Jul 25 21:28:15 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08286
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 21:28: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 i6Q1K97C079128;
	Sun, 25 Jul 2004 18:20:09 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6Q1K92F079127;
	Sun, 25 Jul 2004 18:20:09 -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 i6Q1K8St079103
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 18:20:08 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 95381 messnum 1997643 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 26 Jul 2004 01:20:09 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail09.svc.cra.dublin.eircom.net (qp 95381) with SMTP; 26 Jul 2004 01:20:09 -0000
Message-ID: <41045C2B.7080300@dehora.net>
Date: Mon, 26 Jul 2004 02:19:39 +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: Mark Baker <distobj@acm.org>
CC: Bob Wyman <bob@wyman.us>, "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: Re: PaceAtomIDIsNewsML (Requiring atom:id to be a NewsML URN)
References: <007c01c472a7$431c9cb0$6601a8c0@wyman.us> <20040726010824.GG30868@markbaker.ca>
In-Reply-To: <20040726010824.GG30868@markbaker.ca>
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


Mark Baker wrote:

> On Sun, Jul 25, 2004 at 08:26:57PM -0400, Bob Wyman wrote:
> 
>>I've created a Pace to require that atom:id be a NewsML URN.
>>See: http://www.intertwingly.net/wiki/pie/PaceAtomIDIsNewsML
> 
> 
> -1, for the same reasons Ken gave.

-1 for two other reasons (I just sent them elsewhere before I saw this):

  - NewsML urns have non-Atom semantic import. It is arguably an 
abuse to put them into Atom.

  -NewsML urns are explicitly specified as being for identifying 
NewsML items.

If this the way you want to go, please use Tag URIs - they do not 
have non-Atom semantic import, they are in fact general purpose 
identifiers, there are the same number of them as NewsML urns.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Sun Jul 25 21: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 VAA08344
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 21: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 i6Q1Ll1E079298;
	Sun, 25 Jul 2004 18:21:47 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6Q1Lli7079297;
	Sun, 25 Jul 2004 18:21:47 -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 i6Q1Lkk8079289
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 18:21:46 -0700 (PDT)
	(envelope-from wkearney@syndic8.com)
Received: (qmail 2128 invoked from network); 26 Jul 2004 01:21:52 -0000
Received: from xbox.wkearney.com (HELO media) ([66.92.145.79])
          (envelope-sender <wkearney@syndic8.com>)
          by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP
          for <atom-syntax@imc.org>; 26 Jul 2004 01:21:52 -0000
Message-ID: <012801c472ae$ee881c30$200ca8c0@wkearney.com>
From: "Bill Kearney" <wkearney@syndic8.com>
To: <atom-syntax@imc.org>
References: <200407252216.i6PMG4FO065298@above.proper.com>
Subject: Re: PaceDateline
Date: Sun, 25 Jul 2004 21:21:52 -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: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 8bit


> I think geodata is wonderful as well: I just don't think it belongs
> inside a date construct.

Indeed, the ambiguities on timestamps are bad enough already.

> It carries a lot of the information, but not all. Note that I'm not arguing
> in favour of the textual piece of information: I'm simply arguing that
> they're different, and carries different information to the person _reading_.

Well, to a certain extent there's a desire to have syndication data be able to
provide reasonably detailed data.  What varies are people's ideas of what's
considered reasonable.  Some folks would annotate the beejeesus out of the text,
others are fine with letting their own minds fill in the details.

> btw: I don't think the first construct belongs in DateLine. It would suit
> much better within the first few paragraphs of the actual content.

In the text content?  No, I don't think so...  There's enough gibberish inside
content elements now.  Inside the entry container more likely.

> Yeah, but you donšt think it belongs inside a date construct either?

My turn to be clumsy, I wasn't under the impression anyone was trying to jam it
there.  I agree that it seems like a tremendously bad idea.

Besides, it seems like it ought to be some sort of per-channel default.  Better
to let something publish 'where' it's source should be considered such that it
could be inherited.  Should an individual entry need to be different, much like
language, it'd be appropriate to add it as needed.  Prepare yourself, however,
for a huge mess as to what are considered 'location' constructs.  If you think
timestamps are bad....

I suppose that raises the question of which location is being stated.  An XML
document is delivered from a source. But it's unlikely most feeds would care to
have the location of their colocated server or hosting provider be used as
"their" location.  In the profile scenario of creation/editing it might be
useful to have the content management system track something to this effect.  I
shudder to think about management abuses of said data.  And much like the
timestamp issue it's likely the published 'location' would be different.  Of
course there's also are we publishing location "from" someplace or "about"
someplace else?  What do we markup while on a flight from NYC to LA (somewhere
over Kansas) while posting about a meeting in London?  Open can, prepare worm
recipes...

This is reminiscent of the arguments RSS had over the item link element.  Is it
a link "to" something or "about" something?

Likewise, is this the location about which the content describes or is it some
location (or god help us, various locations) involved in its creation?  I'm sure
the feeping creaturitis crowd would happily run amok annotating it to an
infinite degree.

-Bill Kearney



From owner-atom-syntax@mail.imc.org  Sun Jul 25 21:29: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 VAA08371
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 21:29: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 i6Q1LVgg079266;
	Sun, 25 Jul 2004 18:21: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 i6Q1LVE6079265;
	Sun, 25 Jul 2004 18:21:31 -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 i6Q1LU5c079259
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 18:21:30 -0700 (PDT)
	(envelope-from wkearney@syndic8.com)
Received: (qmail 26062 invoked from network); 26 Jul 2004 01:21:36 -0000
Received: from xbox.wkearney.com (HELO media) ([66.92.145.79])
          (envelope-sender <wkearney@syndic8.com>)
          by mail1.speakeasy.net (qmail-ldap-1.03) with SMTP
          for <roger@agincourtmedia.com>; 26 Jul 2004 01:21:36 -0000
Message-ID: <012701c472ae$e51e2310$200ca8c0@wkearney.com>
From: "Bill Kearney" <wkearney@syndic8.com>
To: "Roger B." <roger@agincourtmedia.com>,
        "'Atom-Syntax'" <atom-syntax@imc.org>
References: <39A3314160A548FEB49DF065FFC37D.MAI@journurl.com>
Subject: Re: Date Options Analysis: Issued
Date: Sun, 25 Jul 2004 21:21:36 -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: <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 do not wish to "destroy" your definition of "issued". In the spirit of
> compromise, I would be more than willing to embrace it. I'm not convinced it
> needs to be in the core, given that millions of feeds can't supply it,

Hardly millions, and perhaps more like "currently don't have a means to supply
it".  If it's something that offers compelling functionality it's highly
unlikely those tools will remain deficient.

> > I'd say she should use 'dateline' instead.
>
> I agree. Unfortunately, you've been advocating "issued" as a required
> element, which means that whatever would normally go into "dateline" will
> just have to go into "issued" as well.

Is it a matter of issued being "defined" before dateline "evolved"?  Is there a
more evolved consensus on which is better in the *context of a feed* instance?

> You can keep on thinkin' it, but we're not here to tell Six Apart how to
> build their apps.

And I'd leave it for them to make comments about their own tools and
desire/ability to adapt.  They've been mighty flexible in the past.

-Bill Kearney
Syndic8.com



From owner-atom-syntax@mail.imc.org  Sun Jul 25 21:30: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 VAA08435
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 21:30: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 i6Q1K43g079111;
	Sun, 25 Jul 2004 18: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 i6Q1K45M079110;
	Sun, 25 Jul 2004 18:20:04 -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 i6Q1K3XS079102
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 18:20:03 -0700 (PDT)
	(envelope-from wkearney@syndic8.com)
Received: (qmail 22507 invoked from network); 26 Jul 2004 01:20:07 -0000
Received: from xbox.wkearney.com (HELO media) ([66.92.145.79])
          (envelope-sender <wkearney@syndic8.com>)
          by mail3.speakeasy.net (qmail-ldap-1.03) with SMTP
          for <rubys@intertwingly.net>; 26 Jul 2004 01:20:07 -0000
Message-ID: <011f01c472ae$b00fadb0$200ca8c0@wkearney.com>
From: "Bill Kearney" <wkearney@syndic8.com>
To: "Sam Ruby" <rubys@intertwingly.net>
Cc: "Atom-Syntax" <atom-syntax@imc.org>
References: <20040725210402.56030.qmail@web41214.mail.yahoo.com> <662EE006-DE92-11D8-8C8C-000A95A51C9E@sun.com> <410448D6.3080207@intertwingly.net>
Subject: Re: PaceDateline
Date: Sun, 25 Jul 2004 21:19:12 -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: <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


> In the absense of guidance in the existing specifications, Tim did what
> made sense to him, and what worked with his preferred tool..
>
> Other people have different ideas of what makes sense to them, and what
> works in their preferred tools.  Trying to transpose what Tim did to the
> terminology used by Atom and/or Dublin Core results in a thumbs down by
> Graham and Dare.
>
> That's not the way this should work.

Bearing in mind that the tools could only work with what was known.  Shitty data
often made for shitty tools.  Some tools, however, have risen about the data
available at the time and built in better functionality.  FeedDemon is another
such tool that uses item dates when present as well as sorting.  The question
here isn't whether crappy data should persist, nor whether we should cater to
weak tools.  The question is what core data should we specify as required so as
to encourage the growth of BETTER tools.

The users have, consistently, requested that their reader programs be able to
remember what they've already considered 'seen'.  Given the badly written specs,
bad tools and, frankly, bad editorial practices on the part of some feed
producers it has been a real pain in the ass to handle this consistently.
Perhaps an argument from the other end, looking at what users expect and how the
extant tools can or can't be made to meet those expectations, is in order.

-Bill Kearney



From owner-atom-syntax@mail.imc.org  Sun Jul 25 21:31: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 VAA08453
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 21:31: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 i6Q1M7O6079331;
	Sun, 25 Jul 2004 18:22:07 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6Q1M7RE079330;
	Sun, 25 Jul 2004 18:22:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q1M6f0079321
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 18:22:06 -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 esmtp (Exim 4.34)
	id 1BouBt-0004zo-PZ; Mon, 26 Jul 2004 01:22:09 +0000
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Sun, 25 Jul 2004 21:22:03 -0400
Subject: Re: PaceAtomIDIsNewsML (Requiring atom:id to be a NewsML URN)
From: Robert Sayre <mint@franklinmint.fm>
To: Ken MacLeod <ken@bitsko.slc.ut.us>, Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD29D4FB.145AF%mint@franklinmint.fm>
In-Reply-To: <m3ekmz8u8o.fsf@bitsko.slc.ut.us>
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: <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 7/25/04 8:52 PM, "Ken MacLeod" <ken@bitsko.slc.ut.us> wrote:

> 
> "Bob Wyman" <bob@wyman.us> writes:
> 
>> I've created a Pace to require that atom:id be a NewsML URN.  See:
>> http://www.intertwingly.net/wiki/pie/PaceAtomIDIsNewsML
> 
> -1.
> 
> Permathread.
> 
> Merely suggesting that the identifier should not be a URI-locator in
> the examples and user guides is bad enough, but mandating a particular
> URI scheme is a non-starter.
> 

I fail to see why (please explain :). Pretty much everyone looking to create
an Atom feed went looking for Mark's tag: scheme article. We *can* prescribe
a scheme.

Furthermore, you're free to include a service.edit link in the entry, which
you can make publicly GETable, if you wish.

Robert Sayre



From owner-atom-syntax@mail.imc.org  Sun Jul 25 21:40: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 VAA08876
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 21:40:27 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q1UrNB080759;
	Sun, 25 Jul 2004 18: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 i6Q1UrQm080758;
	Sun, 25 Jul 2004 18:30:53 -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 i6Q1Ur3l080695
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 18:30:53 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040726013054.35764.qmail@web41201.mail.yahoo.com>
Received: from [67.160.87.187] by web41201.mail.yahoo.com via HTTP; Sun, 25 Jul 2004 18:30:54 PDT
Date: Sun, 25 Jul 2004 18:30:54 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: PaceAtomIDIsNewsML (Requiring atom:id to be a NewsML URN)
To: Mark Baker <distobj@acm.org>, Bob Wyman <bob@wyman.us>
Cc: "'Atom-Syntax'" <atom-syntax@imc.org>
In-Reply-To: <20040726010824.GG30868@markbaker.ca>
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 Baker <distobj@acm.org> wrote:
> 
>
http://www.intertwingly.net/wiki/pie/PaceAtomIDIsNewsML
> 
> -1, for the same reasons Ken gave.

I didn't see any technical reasons in Ken's email. Can
you clarify exactly what they were so I can decipher
what your technical opinions on this matter are?

=====
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  Sun Jul 25 21:43:49 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08997
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 21:43: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 i6Q1YwDg081089;
	Sun, 25 Jul 2004 18:34: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 i6Q1Ywsr081088;
	Sun, 25 Jul 2004 18:34:58 -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 i6Q1YwDh081082
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 18:34:58 -0700 (PDT)
	(envelope-from wkearney@syndic8.com)
Received: (qmail 9960 invoked from network); 26 Jul 2004 01:35:04 -0000
Received: from xbox.wkearney.com (HELO media) ([66.92.145.79])
          (envelope-sender <wkearney@syndic8.com>)
          by mail1.speakeasy.net (qmail-ldap-1.03) with SMTP
          for <atom-syntax@imc.org>; 26 Jul 2004 01:35:04 -0000
Message-ID: <012b01c472b0$c667d2c0$200ca8c0@wkearney.com>
From: "Bill Kearney" <wkearney@syndic8.com>
Cc: "Atom-Syntax" <atom-syntax@imc.org>
References: <20040725175705.15101.qmail@web41203.mail.yahoo.com>
Subject: Re: URI scheme delusions
Date: Sun, 25 Jul 2004 21:33:56 -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: <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 unfortunate. As an aggregator author, the
> screwed up nature of identifiers is one of my biggest
> problems with RSS. In fact, that and the optionality
> of a date field. If the folks working on Atom screw
> this two thing up to since "it doesn't really matter"
> then Atom would stand as an example of how to reinvent
> the wheel but only worse.

There are indeed problems with how ambiguity in the specs for RSS has caused
problems.

There has been an on-going interest on the part of the PEOPLE that consume feeds
in having a way to distinguish uniqueness of an item within a feed.  This has
been screwed up several times on the part of several toolmakers; both on the
producing AND on the consuming end of the equation.

So perhaps if we take a look, again, at the reasons why the identifying bits
that exist currently are problematic and/or misimplemented and why.

> We already have examples from RSS, XML namespaces and
> RDF that using HTTP URLs as URIs causes problems. What
> other proof do you need?

This blanket statement does little to clarify the situation.  There's nothing
wrong with using HTTP URI.  It's in the implementations seen thus far that
problems develop.  Overloading whether or not something is resolveable against
an HTTP identifier seems to confuse more than it helps.  This is one of the many
mistakes RSS made.  Let's not repeat it.

One big problem will be reaggregated or mutiply-published items.  That is, items
re-published from feed X into feed Y, where X and Y are considered distinctly
different sources (an entry from BBC's feed then picked up by Billy Bob's
Slanted News from Europe feed).  Or from sub-category or other composite feeds
from the same publisher (breaking news with an item from finance and then a
finance feed having the same item).

This gets worse when Billy Bob picks up the item and makes edits to it.  Perhaps
little more than a source quote.  As it stands now virtually NONE of the
aggregation tools retain anything resembling authoritative source information
when they re-aggregate an item.   Asking for source attribution or some sort of
provenance is going to be something these tools can't easily provide.
Sub-category feeds are perhaps less-worse in that the items themselves are often
spec'd by the same HTTP URL across the instances
(http://example.com/archives/00001.html regardless of it being in
http://example.com/rss/financial.rss or http://example.com/rss/breakingnews.xml)
But there are certainly going to be some that don't.  Nevermind the whole
consistency of ID arguments.

I'd favor an approach that strictly parts identifier from resolvable resource.
Let's just cut that cord and be done with it.  Whether or not these identifiers
are part of some 'registered' scheme is another matter.  If the items gain a
reliable identifying strategy I'm sure we and other aggregators will step up to
offer resolvability services regardless of whose scheme gets used.

-Bill Kearney
Syndic8.com




From owner-atom-syntax@mail.imc.org  Sun Jul 25 22:02: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 WAA09676
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 22:02: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 i6Q1ppCb083426;
	Sun, 25 Jul 2004 18:51:51 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6Q1ppd1083425;
	Sun, 25 Jul 2004 18:51:51 -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 i6Q1pohY083418
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 18:51:50 -0700 (PDT)
	(envelope-from roger@agincourtmedia.com)
Received: from biggreen ([216.63.148.42]) by journurl.com with MailEnable ESMTP; Sun, 25 Jul 2004 20:51:30 -0500
From: "Roger B." <roger@agincourtmedia.com>
To: "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: RE: Date Options Analysis: Issued
Date: Sun, 25 Jul 2004 20:56:37 -0500
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: <012701c472ae$e51e2310$200ca8c0@wkearney.com>
Thread-Index: AcRyrt4kp0ncQfcERjmkdxTOKNprEgAAnECA
Message-ID: <D72A9E13D73D4464964DA4DED2881E.MAI@journurl.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


> Hardly millions, and perhaps more like "currently don't have a means to
supply
> it".  If it's something that offers compelling functionality it's highly
> unlikely those tools will remain deficient.

Bill: I haven't seen any Blogger, MT, TypePad, or LJ blogs supplying the
immutable issued upon which we seem to have settled. Adding it up, we're
getting into "millions" territory.

> Is it a matter of issued being "defined" before dateline "evolved"?  

Not from what I've read of the arguments put forth here. It's a matter of
"issued" being defined by the traditional publishing industry and Dublin
Core, and that definition being considered a crucial and essential part of
Atom's date selection. 

> And I'd leave it for them to make comments about their own tools and
> desire/ability to adapt.

As would I. In fact, that's almost exactly what I said: "...we're not here
to tell Six Apart how to build their apps."

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/ 







From owner-atom-syntax@mail.imc.org  Sun Jul 25 22:18: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 WAA10030
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 22:18: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 i6Q27rkT084437;
	Sun, 25 Jul 2004 19:07: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 i6Q27rdM084436;
	Sun, 25 Jul 2004 19:07: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 i6Q27rJT084429
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 19:07:53 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040726020754.82924.qmail@web41210.mail.yahoo.com>
Received: from [67.160.87.187] by web41210.mail.yahoo.com via HTTP; Sun, 25 Jul 2004 19:07:54 PDT
Date: Sun, 25 Jul 2004 19:07:54 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: What is Wrong with HTTP URIs (Was Re: URI scheme delusions)
To: Bill Kearney <wkearney@syndic8.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <012b01c472b0$c667d2c0$200ca8c0@wkearney.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>


--- Bill Kearney <wkearney@syndic8.com> wrote:
> 
> > We already have examples from RSS, XML namespaces
> and
> > RDF that using HTTP URLs as URIs causes problems.
> What
> > other proof do you need?
> 
> This blanket statement does little to clarify the
> situation.  There's nothing
> wrong with using HTTP URI.  It's in the
> implementations seen thus far that
> problems develop.  

There's lots wrong with HTTP URIs as opposed to HTTP
URLs, see
http://www.kuro5hin.org/story/2003/2/5/11349/85355 for
descriptions of the problems HTTP URIs have caused to
RDF and XML namespaces. 

Also a number of problems with aggregation today would
fade away if HTTP URLs weren't being used as
identifiers to entries. Duplicate entries in across
the same or multiple feeds is just one problem this
would solve. 

> Overloading whether or not
> something is resolveable against
> an HTTP identifier seems to confuse more than it
> helps.  This is one of the many
> mistakes RSS made.  Let's not repeat it.

The IETF/W3C were the ones that one day decided that
even though there were seperate constructs one limited
to identifying (URNs) the other for locations (URLs)
it would make sense to muddy the waters. 

> I'd favor an approach that strictly parts identifier
> from resolvable resource.
> Let's just cut that cord and be done with it. 
> Whether or not these identifiers
> are part of some 'registered' scheme is another
> matter.  If the items gain a
> reliable identifying strategy I'm sure we and other
> aggregators will step up to
> offer resolvability services regardless of whose
> scheme gets used.

:) 

I see that we agree. 


=====
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  Sun Jul 25 22:21: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 WAA10102
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 22:21: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 i6Q2AcQ5084552;
	Sun, 25 Jul 2004 19:10: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 i6Q2AcYH084551;
	Sun, 25 Jul 2004 19:10:38 -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 i6Q2AafN084536;
	Sun, 25 Jul 2004 19:10:36 -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 F250B171D2A; Sun, 25 Jul 2004 22:11:44 -0400 (EDT)
Reply-To: <bobwyman@pubsub.com>
From: "Bob Wyman" <bobwyman@pubsub.com>
To: "'Paul Hoffman / IMC'" <phoffman@imc.org>, "'Tim Bray'" <Tim.Bray@Sun.COM>,
        "=?iso-8859-1?Q?'Asbj=F8rn_Ulsberg'?=" <asbjorn@tigerstaden.no>
Cc: <elias@torrez.us>, "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: RE: URI scheme delusions
Date: Sun, 25 Jul 2004 22:12:33 -0400
Organization: PubSub Concepts, Inc.
Message-ID: <000501c472b6$03608cd0$6400a8c0@wyman.us>
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, Build 10.0.2627
Importance: Normal
In-Reply-To: <p06110404bd2a062c02e6@[165.121.169.136]>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


Paul Hoffman wrote:
>At 4:24 PM -0700 7/25/04, Tim Bray wrote:
>>For the record, I strongly disagree.  If it turns out that I'm a
>>tiny minority, we'll recognize consensus the other way.  However, it 
>>will be unacceptable to reference an unregistered URI scheme.
>Further, it will never get approved by the IESG, for very good reason.
	That is precisely why PaceAtomIDIsNewsML proposes that we use
the already registered (since 2001) URN scheme for NewsML[1]. NewsML
provides what LDIS and tag do but has the advantage that it is already
registered. Also, it was the result of work done on a problem (news
syndication by formal news organizations) that is very similar to the
syndication problem being addressed by Atom.

		bob wyman

[1] http://ietf.org/rfc/rfc3085.txt



From owner-atom-syntax@mail.imc.org  Sun Jul 25 22:29: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 WAA10361
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 22:29: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 i6Q2JhZg085144;
	Sun, 25 Jul 2004 19: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 i6Q2Jho0085143;
	Sun, 25 Jul 2004 19:19:43 -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 i6Q2JgFI085136
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 19:19:42 -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 i6Q2Jh53027024
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 21:19:43 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6Q2JhvO027020;
	Sun, 25 Jul 2004 21:19:43 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: atom-syntax@imc.org
Subject: Re: PaceAtomIDIsNewsML (Requiring atom:id to be a NewsML URN)
References: <20040726011928.44460.qmail@web41215.mail.yahoo.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 25 Jul 2004 21:19:42 -0500
In-Reply-To: <20040726011928.44460.qmail@web41215.mail.yahoo.com>
Message-ID: <m37jsr8q81.fsf@bitsko.slc.ut.us>
Lines: 36
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: <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> writes:

> --- Ken MacLeod <ken@bitsko.slc.ut.us> wrote:
> >  
> > The current Atom spec says the URI should be globally (not
> > universally, ie. time-wise) unique.  That is sufficient for
> > interoperation and sufficient for the specification.
> 
> No it isn't. Bob is an aggregator author and I'm an aggregator
> author who both have experience having to write code to process the
> millions of syndication feeds out there and answer to thousands of
> customers.  Both of us have said based on our experience the current
> specification text is for interoperation and is harmful to a
> positive user experience.
> 
> Besides dismissing our points of view with your statements of
> authority do you have any arguments to justify your position. I have
> several. What are yours?

The URI scheme is not the root cause of the duplicate, unchanging,
reused, or non-existent ID problems.

Thus, mandating a particular URI scheme will not solve the symptoms of
those ID problems in any significant way.

What we can do is provide dozens of examples of what globally unique
identifiers are, show how they affect interoperability, and say why
publishers should support them.

The most significant things a publishing system can do to prevent
identifier problems is 1) provide the ability to create globally
unique identifiers (preferably without user interaction) and 2)
preserve the original URI with the entry.  Neither of those require
mandating a URI scheme.

 -- Ken



From owner-atom-syntax@mail.imc.org  Sun Jul 25 22: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 WAA10612
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 22:34: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 i6Q2P9nQ085574;
	Sun, 25 Jul 2004 19:25:09 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6Q2P9sY085573;
	Sun, 25 Jul 2004 19:25:09 -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 i6Q2P9iC085567
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 19:25: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 i6Q2Jiuo027723;
	Sun, 25 Jul 2004 22:19:44 -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 BKA01297 (AUTH bob@wyman.us);
	Sun, 25 Jul 2004 22:25:13 -0400 (EDT)
Reply-To: <bob@wyman.us>
From: "Bob Wyman" <bob@wyman.us>
To: "'Ken MacLeod'" <ken@bitsko.slc.ut.us>, <atom-syntax@imc.org>
Subject: RE: PaceAtomIDIsNewsML (Requiring atom:id to be a NewsML URN)
Date: Sun, 25 Jul 2004 22:27:08 -0400
Message-ID: <000601c472b8$0d3a25c0$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
Importance: Normal
In-Reply-To: <m3ekmz8u8o.fsf@bitsko.slc.ut.us>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


Ken MacLeod wrote:
>  but mandating a particular URI scheme is a non-starter.
	Thank you for your opinion. Now, how about explaining *why* it
is a non-starter? If we can mandate the format for a date, why can't we
mandate the format for atom:id? Or, do you think we should also support
user creativity in date formats as well? If we can mandate the
identifiers for languages, why can't we mandate atom:id format? Etc...
	Can you make a case which justifies supporting variety and user
creativity in forming atom:id's? Given that these things should be
treated as opaque strings, just about all the arguments that would rely
on embedding meaning into the ids are immediately made mute. As long as
ids that should be handled as opaque strings, why is variety valuable?
What user benefit comes from variety in atom:id format?

> The current Atom spec says the URI should be globally
> (not universally, ie. time-wise) unique.  That is
> sufficient for interoperation and sufficient for
> the specification.
	In theory, it *should be* enough. However, in practice it simply
isn't. Every aggregator developer I've ever discussed this with has
expressed extreme frustration with the id's in both RSS and Atom feeds
and every one of them has said that it would be much easier to deliver
user-demanded quality if the ID's were, in fact, unique. Clearly, just
asking people to "do the right thing" isn't getting us where we need to
be in order to meet user expectations. Given that, we have little choice
but to mandate a solution.

		bob wyman



From owner-atom-syntax@mail.imc.org  Sun Jul 25 23:02: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 XAA11603
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 23:02:32 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q2pdSU088096;
	Sun, 25 Jul 2004 19:51:39 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6Q2pddp088095;
	Sun, 25 Jul 2004 19:51:39 -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 i6Q2pdiJ088087
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 19:51:39 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040726025140.60361.qmail@web41204.mail.yahoo.com>
Received: from [67.160.87.187] by web41204.mail.yahoo.com via HTTP; Sun, 25 Jul 2004 19:51:40 PDT
Date: Sun, 25 Jul 2004 19:51:40 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: PaceAtomIDIsNewsML (Requiring atom:id to be a NewsML URN)
To: Ken MacLeod <ken@bitsko.slc.ut.us>, atom-syntax@imc.org
In-Reply-To: <m37jsr8q81.fsf@bitsko.slc.ut.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>


--- Ken MacLeod <ken@bitsko.slc.ut.us> wrote:
> 
> The URI scheme is not the root cause of the
> duplicate, unchanging,
> reused, or non-existent ID problems.
>
> Thus, mandating a particular URI scheme will not
> solve the symptoms of
> those ID problems in any significant way.

Interesting. I'll list 3 problems that using HTTP URLs
as identifiers cause in RSS to RSS Bandit users today.
I'll claim that using identifiers that double
locations of network retrievable documents will cause
a significant reduction of these problems. 

1.) Duplicate posts in feeds generated by search
engines. Lots of people cross post entries (e.g. any
body who is on the Artima Buzz forums or Java.blogs).
When a search matches one of these entries it shows up
in the search generated feed multiple times because
the permalinks are different although the same entry
is referenced. 

2.) Duplicate posts when people change weblogging
tools or hosting providers. HTTP URLs vary dependent
on the users hosting provider and the tool they use.
When this information changes, the identity of every
post in the feed changes. 

3.) Redundant posts from aggregated feeds. Since I
work at Microsoft I read many feeds from
http://weblogs.asp.net, however I am also subscribed
to individual blogs of Microsoft employees who are
hosted on http://blogs.msdn.com but whose posts show
up in the feed for the former site since one domain
name is an alias for the other. Having a unique
identifier for an item would let me mark an item as
seen independent on whether it was seen on the
http://weblogs.asp.net feed or http://blogs.msdn.com
feed. 

> What we can do is provide dozens of examples of what
> globally unique
> identifiers are, show how they affect
> interoperability, and say why
> publishers should support them.
> 
> The most significant things a publishing system can
> do to prevent
> identifier problems is 1) provide the ability to
> create globally
> unique identifiers (preferably without user
> interaction) and 2)
> preserve the original URI with the entry.  Neither
> of those require
> mandating a URI scheme.

You seem to miss the point. No one is claiming that
you can't make HTTP URLs globally unique using some
algorithm. 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". Using permalinks as identifiers causes
problems. I have listed 3 above. I can come up with
more if you'd like. 


=====
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  Sun Jul 25 23:15:04 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12025
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 23:15:04 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q35LB1089080;
	Sun, 25 Jul 2004 20: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 i6Q35LNM089079;
	Sun, 25 Jul 2004 20:05:21 -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 i6Q35KG3089073
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 20:05:20 -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 i6Q33A53029725
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 21:03:11 -0600 (MDT)
Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0I1F007NYV92IM@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sun, 25 Jul 2004 21:05:27 -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 <0I1F003MDV91L2@mail.sun.net> for atom-syntax@imc.org; Sun,
 25 Jul 2004 21:05:26 -0600 (MDT)
Date: Sun, 25 Jul 2004 20:05:38 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: URI scheme delusions
In-reply-to: <007d01c472ac$b182feb0$6601a8c0@wyman.us>
To: bob@wyman.us
Cc: "'Atom-Syntax'" <atom-syntax@imc.org>, "'Dare Obasanjo'" <kpako@yahoo.com>,
        elias@torrez.us, "=?ISO-8859-1?Q?'Bill_de_h=D3ra'?=" <bill@dehora.net>,
        "'Mark Pilgrim'" <pilgrim@gmail.com>,
        "'Sam Ruby'" <rubys@intertwingly.net>
Message-id: <AC08A482-DEB0-11D8-8C8C-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: <007d01c472ac$b182feb0$6601a8c0@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 Jul 25, 2004, at 6:05 PM, Bob Wyman wrote:

> 	Yes. The NUMBER ONE complaint we get from PubSub users is that
> there are duplicate entries in the feeds we generate. Other aggregators
> have told me that their experience is the same. The problem is that we
> simply can't do good enough duplicate detection based on textual
> analysis of entries (i.e. computing MD5 hashes, etc.) if only because
> entries that are hosted in multiple feeds often undergo slight changes
> when copied from feed to feed (i.e. some whitespace may be dropped 
> URL's
> may change because of a "base" change.) Thus, the only hope we have of
> doing a good job of duplicate detection is relying on statements by the
> entry generator. i.e. if they give us unique, immutable ids and 
> explicit
> "Updated" dates.

Bob is *so* right.  I'm a heavy PubSub user and I get irritated at 
seeing the same thing 8 times and I know perfectly well that if we gave 
them deterministic, reliable date-stamps to work with the problem would 
just evaporate. -Tim



From owner-atom-syntax@mail.imc.org  Sun Jul 25 23: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 XAA12238
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 23: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 i6Q3CGp4089539;
	Sun, 25 Jul 2004 20:12: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 i6Q3CGYM089538;
	Sun, 25 Jul 2004 20:12: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-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 i6Q3CFk6089532
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 20:12:16 -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 i6Q3CMil007257
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 21:12:22 -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 <0I1F007W1VKMIM@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sun, 25 Jul 2004 21:12:22 -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 <0I1F003MSVKLL2@mail.sun.net> for atom-syntax@imc.org; Sun,
 25 Jul 2004 21:12:22 -0600 (MDT)
Date: Sun, 25 Jul 2004 20:12:35 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceAtomIDIsNewsML (Requiring atom:id to be a NewsML URN)
In-reply-to: <20040726011928.44460.qmail@web41215.mail.yahoo.com>
To: Dare Obasanjo <kpako@yahoo.com>
Cc: atom-syntax@imc.org, Ken MacLeod <ken@bitsko.slc.ut.us>
Message-id: <A40C8C38-DEB1-11D8-8C8C-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: <20040726011928.44460.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 Jul 25, 2004, at 6:19 PM, Dare Obasanjo wrote:

> No it isn't. Bob is an aggregator author and I'm an
> aggregator author who both have experience having to
> write code to process the millions of syndication
> feeds out there and answer to thousands of customers.
> Both of us have said based on our experience the
> current specification text is for interoperation and
> is harmful to a positive user experience.

Well, you are advancing the hypothesis that people who cannot 
competently manage a stable identifier space when the identifiers begin 
with "http:" will become capable of doing so when the identifiers begin 
with some other prefix.  It's not obviously insane and it is possible 
that you are correct.  Looking at the same evidence, I doubt it, and 
that's life.  In any case, I seriously think there is lack of 
sufficient experimental evidence to write this hypothesis into an RFC. 
-Tim



From owner-atom-syntax@mail.imc.org  Sun Jul 25 23:21: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 XAA12285
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 23:21: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 i6Q3Bo0Z089496;
	Sun, 25 Jul 2004 20:11: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 i6Q3BoPo089495;
	Sun, 25 Jul 2004 20:11:50 -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 i6Q3BoUp089486
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 20:11:50 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040726031151.60085.qmail@web41215.mail.yahoo.com>
Received: from [67.160.87.187] by web41215.mail.yahoo.com via HTTP; Sun, 25 Jul 2004 20:11:51 PDT
Date: Sun, 25 Jul 2004 20:11:51 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: URI scheme delusions
To: Tim Bray <Tim.Bray@Sun.COM>, bob@wyman.us
Cc: "'Atom-Syntax'" <atom-syntax@imc.org>, "'Dare Obasanjo'" <kpako@yahoo.com>,
        elias@torrez.us, "'Bill_de_hÓra'" <bill@dehora.net>,
        "'Mark Pilgrim'" <pilgrim@gmail.com>,
        "'Sam Ruby'" <rubys@intertwingly.net>
In-Reply-To: <AC08A482-DEB0-11D8-8C8C-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:
>  
> Bob is *so* right.  I'm a heavy PubSub user and I
> get irritated at 
> seeing the same thing 8 times and I know perfectly
> well that if we gave 
> them deterministic, reliable date-stamps to work
> with the problem would 
> just evaporate. -Tim

That's only a small part of the problem. 

The major problem has little to do with date stamps
and more to do with providing globally unique IDs.
This is the problem I see in the Feedster and PubSub
feeds I've seen. 

=====
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 Jul 25 23:44:06 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13045
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 23: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 i6Q3W9Uq091127;
	Sun, 25 Jul 2004 20:32: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 i6Q3W97m091126;
	Sun, 25 Jul 2004 20:32: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 i6Q3W92J091117
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 20:32: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 i6Q3W2vu006150;
	Sun, 25 Jul 2004 23:32:02 -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 BKA18251 (AUTH bob@wyman.us);
	Sun, 25 Jul 2004 23:32:08 -0400 (EDT)
Reply-To: <bob@wyman.us>
From: "Bob Wyman" <bob@wyman.us>
To: "'Dare Obasanjo'" <kpako@yahoo.com>,
        "'Ken MacLeod'" <ken@bitsko.slc.ut.us>, <atom-syntax@imc.org>
Subject: RE: PaceAtomIDIsNewsML (Requiring atom:id to be a NewsML URN)
Date: Sun, 25 Jul 2004 23:34:00 -0400
Message-ID: <000801c472c1$67f91c10$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
Importance: Normal
In-Reply-To: <20040726025140.60361.qmail@web41204.mail.yahoo.com>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


Dare Obasanjo wrote:
> 3.) Redundant posts from aggregated feeds. Since I work at
> Microsoft I read many feeds from http://weblogs.asp.net,
> however I am also subscribed to individual blogs of Microsoft
> employees who are hosted on http://blogs.msdn.com but whose
> posts show up in the feed for the former site since one domain
> name is an alias for the other.
	The Microsoft blogs are a real nightmare for any aggregator
developer because of this dual hosting business. Disambiguating between
duplicates on the Microsoft site is impossible without site-specific
logic. Picking one blog at random will demonstrate the problem.
	One can find a recent entry from "Rakesh's Blog" at either:
	http://blogs.msdn.com/rakeshna/archive/2004/07/25/196520.aspx
Or	http://weblogs.asp.net/rakeshna/archive/2004/07/25/196520.aspx

	On both pages, you'll find a link to "Syndication". The contents
of the file retrieved will, however, depend on the domain you use. 

The following fragment is from the RSS file at:
http://weblogs.asp.net/rakeshna/Rss.aspx

- <item>
  <dc:creator>Rakesh Namineni</dc:creator> 
  <title>Decisions.</title> 
 
<link>http://weblogs.asp.net/rakeshna/archive/2004/07/25/196520.aspx</li
nk> 
  <pubDate>Sun, 25 Jul 2004 19:09:00 GMT</pubDate> 
 
<guid>http://weblogs.asp.net/rakeshna/archive/2004/07/25/196520.aspx</gu
id> 

The following is from the RSS file at
http://blogs.msdn.com/rakeshna/Rss.aspx and describes precisely the same
entry as the previous example. The only diffence is in the URL's used as
permalinks.

- <item>
  <dc:creator>Rakesh Namineni</dc:creator> 
  <title>Decisions.</title> 
 
<link>http://blogs.msdn.com/rakeshna/archive/2004/07/25/196520.aspx</lin
k> 
  <pubDate>Sun, 25 Jul 2004 19:09:00 GMT</pubDate> 
 
<guid>http://blogs.msdn.com/rakeshna/archive/2004/07/25/196520.aspx</gui
d> 

	What you see here is a single "entry" that has completely
different metadata based on which site is used to access the entry.
These are the sorts of things that people do when they see that  an
identifier is an URL. Now, there is no question that we could contact
the Microsoft people and beg them to stop this silliness. Given the
"new, kinder, gentler" Microsoft, they might even agree to fix the
problem. However, there are many others out there who do similar things.
Who wants to be the policeman on this issue?
	Some might argue that this is just an artifact of RSS use.
However, the reality is that if Microsoft didn't understand the impact
of what they were doing when they defined their RSS feeds, it isn't any
more probable that they will figure it out when creating Atom feeds --
unless we simply make sure that atom:id is NOT an URL and thus, they
can't get confused.

		bob wyman



From owner-atom-syntax@mail.imc.org  Sun Jul 25 23:46:19 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13195
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 23:46: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 i6Q3cxel091488;
	Sun, 25 Jul 2004 20:38: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 i6Q3cxZx091487;
	Sun, 25 Jul 2004 20:38:59 -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 i6Q3cw4k091465
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 20:38:58 -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 i6Q3cx53027821
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 22:38:59 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6Q3cxSl027817;
	Sun, 25 Jul 2004 22:38:59 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: atom-syntax@imc.org
Subject: Re: PaceAtomIDIsNewsML (Requiring atom:id to be a NewsML URN)
References: <20040726025140.60361.qmail@web41204.mail.yahoo.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 25 Jul 2004 22:38:59 -0500
In-Reply-To: <20040726025140.60361.qmail@web41204.mail.yahoo.com>
Message-ID: <m3wu0r77zg.fsf@bitsko.slc.ut.us>
Lines: 35
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: <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> writes:

> Interesting. I'll list 3 problems that using HTTP URLs as
> identifiers cause in RSS to RSS Bandit users today.  I'll claim that
> using identifiers that double locations of network retrievable
> documents will cause a significant reduction of these problems.

    <id>urn:newsml:$HOSTNAME:$DATE:$CATEGORY.$POSTNUM:1</id>

This host template "macro" will also not help any of the three issues
described, regardless that they use the 'newsml' URN scheme.

> You seem to miss the point. No one is claiming that you can't make
> HTTP URLs globally unique using some algorithm. 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". Using permalinks as identifiers causes
> problems. I have listed 3 above. I can come up with more if you'd
> like.

I'm not sure how or if we can mandate this, but mandating that
publishers preserve the originally generated URI for an entry and that
the same URI is put in <id> for every instance of that entry and that
intermediaries always preserve the URI seems to be the most promising
solution to the problem.

Any specific URI scheme is only an example of a possible identifier,
it's not an inherent solution for the problem.

I am not trying to be argumentative about this nor do I think I
misunderstand the situation.  I *have seen* the existing publishers
use "macros" to provide IDs in their templates instead of preserving
URIs.  Mandating URI schemes isn't going to solve that problem.

  -- Ken



From owner-atom-syntax@mail.imc.org  Sun Jul 25 23:51: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 XAA13310
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 23:51: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 i6Q3gTJ7091666;
	Sun, 25 Jul 2004 20:42: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 i6Q3gTfg091665;
	Sun, 25 Jul 2004 20:42:29 -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 i6Q3gTYq091658
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 20:42:29 -0700 (PDT)
	(envelope-from distobj@acm.org)
Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian))
	id 1BowOT-00023Z-00; Sun, 25 Jul 2004 23:43:17 -0400
Date: Sun, 25 Jul 2004 23:43:17 -0400
To: Dare Obasanjo <kpako@yahoo.com>
Cc: atom-syntax@imc.org
Subject: Re: PaceAtomIDIsNewsML (Requiring atom:id to be a NewsML URN)
Message-ID: <20040726034317.GH30868@markbaker.ca>
References: <m37jsr8q81.fsf@bitsko.slc.ut.us> <20040726025140.60361.qmail@web41204.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040726025140.60361.qmail@web41204.mail.yahoo.com>
User-Agent: Mutt/1.3.28i
From: Mark Baker <distobj@acm.org>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


On Sun, Jul 25, 2004 at 07:51:40PM -0700, Dare Obasanjo wrote:
> 1.) Duplicate posts in feeds generated by search
> engines. Lots of people cross post entries (e.g. any
> body who is on the Artima Buzz forums or Java.blogs).
> When a search matches one of these entries it shows up
> in the search generated feed multiple times because
> the permalinks are different although the same entry
> is referenced. 

Why is that the fault of the http URI scheme?  It seems to me that it's
the fault of the posting mechanisms of those sites for not asking the
user for a permalink id in case there's already one (as there is in this
case).

> 2.) Duplicate posts when people change weblogging
> tools or hosting providers. HTTP URLs vary dependent
> on the users hosting provider and the tool they use.
> When this information changes, the identity of every
> post in the feed changes. 

In both cases, there is an answer for users; use your own domain name,
and use better tools or at least additional tools which help you evolve
your URI space (e.g. mod_redirect).

Again, this is not a problem with the http URI scheme.

> 3.) Redundant posts from aggregated feeds. Since I
> work at Microsoft I read many feeds from
> http://weblogs.asp.net, however I am also subscribed
> to individual blogs of Microsoft employees who are
> hosted on http://blogs.msdn.com but whose posts show
> up in the feed for the former site since one domain
> name is an alias for the other. Having a unique
> identifier for an item would let me mark an item as
> seen independent on whether it was seen on the
> http://weblogs.asp.net feed or http://blogs.msdn.com
> feed. 

And if that unique identifier were an http URI, it would work just as
well.  See #1 above.

I applaud your interests in ensuring that its easy for your users to
make permanent links, but ultimately, it's they who need to make the
committment, not us (see my answer to #2).  IMO, any attempt to try to
do for users what they won't do for themselves will result in
undesirable artifacts in the spec which impede evolution (e.g. the
mandating-the-URI-scheme requirement mentioned in the pace) and
generally just unnecessarily constrain implementations.

Mark.



From owner-atom-syntax@mail.imc.org  Sun Jul 25 23:52:41 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13343
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 23: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 i6Q3gW5d091676;
	Sun, 25 Jul 2004 20:42:32 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6Q3gWMv091675;
	Sun, 25 Jul 2004 20:42:32 -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 i6Q3gWsr091669
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 20:42:32 -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 i6Q3gJvu007849;
	Sun, 25 Jul 2004 23:42: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 BKA20243 (AUTH bob@wyman.us);
	Sun, 25 Jul 2004 23:42:28 -0400 (EDT)
Reply-To: <bob@wyman.us>
From: "Bob Wyman" <bob@wyman.us>
To: <Tim.Bray@Sun.COM>
Cc: "'Atom-Syntax'" <atom-syntax@imc.org>, "'Dare Obasanjo'" <kpako@yahoo.com>,
        <elias@torrez.us>,
        "=?iso-8859-1?Q?'Bill_de_h=D3ra'?=" <bill@dehora.net>,
        "'Mark Pilgrim'" <pilgrim@gmail.com>,
        "'Sam Ruby'" <rubys@intertwingly.net>
Subject: RE: URI scheme delusions
Date: Sun, 25 Jul 2004 23:44:23 -0400
Message-ID: <000901c472c2$d7cc5150$6400a8c0@wyman.us>
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, Build 10.0.2627
Importance: Normal
In-Reply-To: <AC08A482-DEB0-11D8-8C8C-000A95A51C9E@sun.com>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


Tim Bray wrote:
> Bob is *so* right.  I'm a heavy PubSub user and I get 
> irritated at seeing the same thing 8 times and I know
> perfectly well that if we gave them deterministic, 
> reliable date-stamps to work with the problem would 
> just evaporate. -Tim
	Aargh... We work pretty hard at finding duplicates... The idea
that you'd see as many as 8 dupes of a single entry is kind of
depressing. Of course, if we didn't run our detection code, you'd see
many more... Please accept that we're doing the best we can but there
really are limits to what you can accomplish using textual analysis and
the junk we get for guids, permalinks, atom:ids and dates today. Garbage
in, Garbage out...
	Also, please note that to do duplicate detection properly, we
need *both* unique atom:ids and reliable, meaningful date-stamps. (Note:
That "meaningful" bit is important. We find too many dates in feeds that
are dynamically generated with code like "Now()" and change every time
you access the feed.)

		bob wyman





From owner-atom-syntax@mail.imc.org  Sun Jul 25 23:56: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 XAA13603
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 23:56:27 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q3mF0B091952;
	Sun, 25 Jul 2004 20:48:15 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6Q3mFPo091951;
	Sun, 25 Jul 2004 20:48:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from 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 i6Q3mFPs091941
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 20:48:15 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040726034817.11800.qmail@web41214.mail.yahoo.com>
Received: from [67.160.87.187] by web41214.mail.yahoo.com via HTTP; Sun, 25 Jul 2004 20:48:17 PDT
Date: Sun, 25 Jul 2004 20:48:17 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: PaceAtomIDIsNewsML (Requiring atom:id to be a NewsML URN)
To: Tim Bray <Tim.Bray@Sun.COM>
Cc: atom-syntax@imc.org, Ken MacLeod <ken@bitsko.slc.ut.us>
In-Reply-To: <A40C8C38-DEB1-11D8-8C8C-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:
>  
> Well, you are advancing the hypothesis that people
> who cannot 
> competently manage a stable identifier space when
> the identifiers begin 
> with "http:" will become capable of doing so when
> the identifiers begin 
> with some other prefix.  It's not obviously insane
> and it is possible 
> that you are correct.  Looking at the same evidence,
> I doubt it, and 
> that's life.  In any case, I seriously think there
> is lack of 
> sufficient experimental evidence to write this
> hypothesis into an RFC. 

There is enough experimental evidence to show that
HTTP URLs don't work as unique identifiers. So I'd
like to see where we go from there. I'm saddened to
see that instead of listening to implementers who have
to deal with this mess on a daily basis we are still
hearing the URI religion broken record. 

This debate reminds me why other aggregator authors
have decided to stay out of the Atom discussion.   

=====
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  Sun Jul 25 23:59: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 XAA13672
	for <atompub-archive@lists.ietf.org>; Sun, 25 Jul 2004 23:59: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 i6Q3o0MG092182;
	Sun, 25 Jul 2004 20: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 i6Q3o0Ku092181;
	Sun, 25 Jul 2004 20:50:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q3nx06092166
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 20:49:59 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Mon, 26 Jul 2004 13:55:43 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Mon, 26 Jul 2004 13:33:22 +1000
Subject: Re: PaceAtomIDIsNewsML (Requiring atom:id to be a NewsML URN)
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD2AB8A2.2283F%eric.scheid@ironclad.net.au>
In-Reply-To: <A40C8C38-DEB1-11D8-8C8C-000A95A51C9E@sun.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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 26/7/04 1:12 PM, "Tim Bray" <Tim.Bray@Sun.COM> wrote:

> Well, you are advancing the hypothesis that people who cannot
> competently manage a stable identifier space when the identifiers begin
> with "http:" will become capable of doing so when the identifiers begin
> with some other prefix.

It may not be a matter of "cannot competently manage", but instead "looks
like a URL will do, won't bother thinking any further". Unfortunately, using
'http' URIs properly requires them to think not just about the id aspect,
but also how to handle the compromises imposed by the deferencing aspect.

If they are guided to using some arcane thing they've not seen before, and
which doesn't look like a URL does (lots of slashes and stuff), then they
might actually engage brain for the few short cycles necessary.

One hopes.

e.



From owner-atom-syntax@mail.imc.org  Mon Jul 26 00:01:43 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13795
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 00:01: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 i6Q3rn5D092400;
	Sun, 25 Jul 2004 20:53:49 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6Q3rn6U092399;
	Sun, 25 Jul 2004 20:53:49 -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 i6Q3rmal092390
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 20:53:48 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040726035350.20818.qmail@web41212.mail.yahoo.com>
Received: from [67.160.87.187] by web41212.mail.yahoo.com via HTTP; Sun, 25 Jul 2004 20:53:50 PDT
Date: Sun, 25 Jul 2004 20:53:50 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: PaceAtomIDIsNewsML (Requiring atom:id to be a NewsML URN)
To: Mark Baker <distobj@acm.org>
Cc: atom-syntax@imc.org
In-Reply-To: <20040726034317.GH30868@markbaker.ca>
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>


*sigh* 

"Guns don't kill people, people do."

I feel like a gun control advocate arguing with
members of the NRA. I really don't have time to engage
in the eternal URI permathread. HTTP URLs used as
identifiers cause problems today, Atom can choose to
mitigate this error by avoiding them or not. Atom can
fix the mess that is the various flavors of RSS or it
can wallow in their filth. You and Tim have decided
that it should do the latter. I am not attached to
Atom enough to continue debating this more than I have
now. Enjoy. 

That's all folks. 


--- Mark Baker <distobj@acm.org> wrote:
> On Sun, Jul 25, 2004 at 07:51:40PM -0700, Dare
> Obasanjo wrote:
> > 1.) Duplicate posts in feeds generated by search
> > engines. Lots of people cross post entries (e.g.
> any
> > body who is on the Artima Buzz forums or
> Java.blogs).
> > When a search matches one of these entries it
> shows up
> > in the search generated feed multiple times
> because
> > the permalinks are different although the same
> entry
> > is referenced. 
> 
> Why is that the fault of the http URI scheme?  It
> seems to me that it's
> the fault of the posting mechanisms of those sites
> for not asking the
> user for a permalink id in case there's already one
> (as there is in this
> case).
> 
> > 2.) Duplicate posts when people change weblogging
> > tools or hosting providers. HTTP URLs vary
> dependent
> > on the users hosting provider and the tool they
> use.
> > When this information changes, the identity of
> every
> > post in the feed changes. 
> 
> In both cases, there is an answer for users; use
> your own domain name,
> and use better tools or at least additional tools
> which help you evolve
> your URI space (e.g. mod_redirect).
> 
> Again, this is not a problem with the http URI
> scheme.
> 
> > 3.) Redundant posts from aggregated feeds. Since I
> > work at Microsoft I read many feeds from
> > http://weblogs.asp.net, however I am also
> subscribed
> > to individual blogs of Microsoft employees who are
> > hosted on http://blogs.msdn.com but whose posts
> show
> > up in the feed for the former site since one
> domain
> > name is an alias for the other. Having a unique
> > identifier for an item would let me mark an item
> as
> > seen independent on whether it was seen on the
> > http://weblogs.asp.net feed or
> http://blogs.msdn.com
> > feed. 
> 
> And if that unique identifier were an http URI, it
> would work just as
> well.  See #1 above.
> 
> I applaud your interests in ensuring that its easy
> for your users to
> make permanent links, but ultimately, it's they who
> need to make the
> committment, not us (see my answer to #2).  IMO, any
> attempt to try to
> do for users what they won't do for themselves will
> result in
> undesirable artifacts in the spec which impede
> evolution (e.g. the
> mandating-the-URI-scheme requirement mentioned in
> the pace) and
> generally just unnecessarily constrain
> implementations.
> 
> Mark.
> 


=====
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  Mon Jul 26 00:19:16 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14469
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 00:19: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 i6Q4BNuX093577;
	Sun, 25 Jul 2004 21:11:23 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6Q4BNTr093576;
	Sun, 25 Jul 2004 21:11:23 -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 i6Q4BMgW093551
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 21:11:23 -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 i6Q45wuo015781;
	Mon, 26 Jul 2004 00:05:58 -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 BKA26057 (AUTH bob@wyman.us);
	Mon, 26 Jul 2004 00:11:28 -0400 (EDT)
Reply-To: <bob@wyman.us>
From: "Bob Wyman" <bob@wyman.us>
To: "'Tim Bray'" <Tim.Bray@Sun.COM>, "'Dare Obasanjo'" <kpako@yahoo.com>
Cc: <atom-syntax@imc.org>, "'Ken MacLeod'" <ken@bitsko.slc.ut.us>
Subject: RE: PaceAtomIDIsNewsML (Requiring atom:id to be a NewsML URN)
Date: Mon, 26 Jul 2004 00:13:23 -0400
Message-ID: <001101c472c6$e47a7c20$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
Importance: Normal
In-Reply-To: <A40C8C38-DEB1-11D8-8C8C-000A95A51C9E@sun.com>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


Tim Bray wrote:
> Well, you are advancing the hypothesis that people who
> cannot competently manage a stable identifier space when
> the identifiers begin with "http:" will become capable of
> doing so when the identifiers begin with some other prefix.
> It's not obviously insane and it is possible that you are correct.
	What we're talking about here is as much psychology as it is
technology. What we *do* know is that we don't want people to be
confused by "http-think" when they are creating atom:ids. For instance
http-think leads to the idea that a URI should be somehow related to the
name of the machine that is used to access an item. This is the problem
that creates the mess on the Microsoft machines. It is *obvious* that
the guids for items on blogs.msdn.com should start with "blogs.msdn.com"
while the guids for items accessed on weblogs.asp.net should be
different. Unfortunately, what is obvious isn't true.
	The goal is to get people to think clearly about the problem of
defining a unique identifier and to allow them to do it without the
confusion of unrelated ideas like those related to HTTP retrieval. This
is a psychology problem -- not a technology problem.

		bob wyman




From owner-atom-syntax@mail.imc.org  Mon Jul 26 00:32: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 AAA14976
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 00: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 i6Q4JNUI094264;
	Sun, 25 Jul 2004 21:19: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 i6Q4JNSm094263;
	Sun, 25 Jul 2004 21:19:23 -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 i6Q4JN0v094257
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 21:19:23 -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 i6Q4O0h8008582;
	Mon, 26 Jul 2004 00:24:00 -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 BKA27625 (AUTH bob@wyman.us);
	Mon, 26 Jul 2004 00:19:27 -0400 (EDT)
Reply-To: <bob@wyman.us>
From: "Bob Wyman" <bob@wyman.us>
To: "'Ken MacLeod'" <ken@bitsko.slc.ut.us>, <atom-syntax@imc.org>
Subject: RE: PaceAtomIDIsNewsML (Requiring atom:id to be a NewsML URN)
Date: Mon, 26 Jul 2004 00:21:22 -0400
Message-ID: <001201c472c8$020e3e10$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
Importance: Normal
In-Reply-To: <m3wu0r77zg.fsf@bitsko.slc.ut.us>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


Ken MacLeod wrote:
><id>urn:newsml:$HOSTNAME:$DATE:$CATEGORY.$POSTNUM:1</id>
> This host template "macro" will also not help any of the
> three issues described, regardless that they use the
> 'newsml' URN scheme.
	You are, of course, correct since your macro seems to be
designed to generate output. However, you *should not* be attempting to
generate the atom:id in an output function. Rather, the id should be
generated as a by-product of creating the entry. Once created, it should
be carried with the entry in internal databases, etc. as static data in
precisely the same way that a creation-date or title would be carried.
	The correct macro for output would be something like:

	<id>$ATOMID</id>

	Anything else is going to result in all the problems mentioned
before. Atom:id's should *only* be generated when a new entry is created
and then only as a one-shot input function.

		bob wyman



From owner-atom-syntax@mail.imc.org  Mon Jul 26 00:40:25 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15186
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 00: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 i6Q4SwLC094818;
	Sun, 25 Jul 2004 21:28: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 i6Q4SwXb094817;
	Sun, 25 Jul 2004 21:28: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 i6Q4Svle094811
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 21:28:57 -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 i6Q4U43a014894;
	Mon, 26 Jul 2004 00:30:05 -0400
Message-ID: <4104888E.8000806@intertwingly.net>
Date: Mon, 26 Jul 2004 00:29:02 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: "'Tim Bray'" <Tim.Bray@Sun.COM>, "'Dare Obasanjo'" <kpako@yahoo.com>,
        atom-syntax@imc.org, "'Ken MacLeod'" <ken@bitsko.slc.ut.us>
Subject: Re: PaceAtomIDIsNewsML (Requiring atom:id to be a NewsML URN)
References: <001101c472c6$e47a7c20$6400a8c0@wyman.us>
In-Reply-To: <001101c472c6$e47a7c20$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:

> Tim Bray wrote:
> 
>>Well, you are advancing the hypothesis that people who
>>cannot competently manage a stable identifier space when
>>the identifiers begin with "http:" will become capable of
>>doing so when the identifiers begin with some other prefix.
>>It's not obviously insane and it is possible that you are correct.
> 
> 	What we're talking about here is as much psychology as it is
> technology. What we *do* know is that we don't want people to be
> confused by "http-think" when they are creating atom:ids. For instance
> http-think leads to the idea that a URI should be somehow related to the
> name of the machine that is used to access an item. This is the problem
> that creates the mess on the Microsoft machines. It is *obvious* that
> the guids for items on blogs.msdn.com should start with "blogs.msdn.com"
> while the guids for items accessed on weblogs.asp.net should be
> different. Unfortunately, what is obvious isn't true.
> 	The goal is to get people to think clearly about the problem of
> defining a unique identifier and to allow them to do it without the
> confusion of unrelated ideas like those related to HTTP retrieval. This
> is a psychology problem -- not a technology problem.

To put it more succinctly: syntax matters.

Now, why isn't it *obvious* that the NewsML ID for URIs on 
blogs.msdn.com should have a ProviderId of blogs.msdn.com?

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Mon Jul 26 00:51: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 AAA15790
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 00:51: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 i6Q4iUnL096169;
	Sun, 25 Jul 2004 21:44: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 i6Q4iUKB096168;
	Sun, 25 Jul 2004 21:44: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 i6Q4iTaD096159
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 21:44:29 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040726044426.10296.qmail@web41203.mail.yahoo.com>
Received: from [67.160.87.187] by web41203.mail.yahoo.com via HTTP; Sun, 25 Jul 2004 21:44:26 PDT
Date: Sun, 25 Jul 2004 21:44:26 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: PaceAtomIDIsNewsML (Requiring atom:id to be a NewsML URN)
To: Sam Ruby <rubys@intertwingly.net>, bob@wyman.us
Cc: "'Tim Bray'" <Tim.Bray@Sun.COM>, "'Dare Obasanjo'" <kpako@yahoo.com>,
        atom-syntax@imc.org, "'Ken MacLeod'" <ken@bitsko.slc.ut.us>
In-Reply-To: <4104888E.8000806@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:
>  
> To put it more succinctly: syntax matters.
> 
> Now, why isn't it *obvious* that the NewsML ID for
> URIs on 
> blogs.msdn.com should have a ProviderId of
> blogs.msdn.com?

NewsML IDs may have the same problems as HTTP URLs. So
lets talk about the root of the problem. 

IDs must not change. 

All the problems aggregator authors face with IDs are
because they change. Either because an item is posted
on different sites with each site giving it a site
specific ID or an entry's IDs change when the content
producer changes something about the server such as
the CMS or the hosting provider. 

If Atom plans to do a better job than RSS, it needs to
solve this problem. Suggesting using NewsML URNs is an
attempt to have content producers and tools vendors
realize that entry IDs should be unique and
unchanging. However this doesn't tackle the problem at
its root. 

Ideally Atom should have normative text pointing out
that items should have unique and *unchanging*
identifiers including examples that currently break in
RSS today due to changing identifiers. 

=====
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 Jul 26 00:53: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 AAA15854
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 00:53: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 i6Q4gG8v095992;
	Sun, 25 Jul 2004 21:42: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 i6Q4gGUR095991;
	Sun, 25 Jul 2004 21:42:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q4gFo8095985
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 21:42:16 -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 i6Q4hPHr015438;
	Mon, 26 Jul 2004 00:43:25 -0400
Message-ID: <41048BAE.5070400@intertwingly.net>
Date: Mon, 26 Jul 2004 00:42:22 -0400
From: Sam Ruby <rubys@intertwingly.net>
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@imc.org
Subject: Re: PaceAtomIDIsNewsML (Requiring atom:id to be a NewsML URN)
References: <001201c472c8$020e3e10$6400a8c0@wyman.us>
In-Reply-To: <001201c472c8$020e3e10$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:

> Ken MacLeod wrote:
> 
>><id>urn:newsml:$HOSTNAME:$DATE:$CATEGORY.$POSTNUM:1</id>
>>This host template "macro" will also not help any of the
>>three issues described, regardless that they use the
>>'newsml' URN scheme.
> 
> 	You are, of course, correct since your macro seems to be
> designed to generate output. However, you *should not* be attempting to
> generate the atom:id in an output function. Rather, the id should be
> generated as a by-product of creating the entry. Once created, it should
> be carried with the entry in internal databases, etc. as static data in
> precisely the same way that a creation-date or title would be carried.
> 	The correct macro for output would be something like:
> 
> 	<id>$ATOMID</id>
> 
> 	Anything else is going to result in all the problems mentioned
> before. Atom:id's should *only* be generated when a new entry is created
> and then only as a one-shot input function.

How many existing databases have a "column" for this?

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Mon Jul 26 00:55: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 AAA15909
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 00:55:25 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q4mobD096617;
	Sun, 25 Jul 2004 21:48:50 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6Q4moQU096616;
	Sun, 25 Jul 2004 21:48:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-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 i6Q4moDE096610
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 21: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 i6Q4mvil003969
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 22:48:57 -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 <0I1G00JDT01KHM@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sun, 25 Jul 2004 22:48:57 -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 <0I1G00CAY00FE1@mail.sun.net> for atom-syntax@imc.org; Sun,
 25 Jul 2004 22:48:56 -0600 (MDT)
Date: Sun, 25 Jul 2004 21:49:12 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceAtomIDIsNewsML (Requiring atom:id to be a NewsML URN)
In-reply-to: <20040726044426.10296.qmail@web41203.mail.yahoo.com>
To: Dare Obasanjo <kpako@yahoo.com>
Cc: bob@wyman.us, "'Ken MacLeod'" <ken@bitsko.slc.ut.us>,
        Sam Ruby <rubys@intertwingly.net>, atom-syntax@imc.org
Message-id: <23DBE2C2-DEBF-11D8-8C8C-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: <20040726044426.10296.qmail@web41203.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 Jul 25, 2004, at 9:44 PM, Dare Obasanjo wrote:

> Ideally Atom should have normative text pointing out
> that items should have unique and *unchanging*
> identifiers including examples that currently break in
> RSS today due to changing identifiers.

+1 -Tim



From owner-atom-syntax@mail.imc.org  Mon Jul 26 00:57: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 AAA15979
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 00:57: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 i6Q4mFa5096562;
	Sun, 25 Jul 2004 21:48:15 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6Q4mFE4096561;
	Sun, 25 Jul 2004 21:48: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 i6Q4mEWK096554
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 21:48:14 -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 i6Q4k553028258
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 22:46:05 -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 <0I1G007LT00LIM@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sun, 25 Jul 2004 22:48:21 -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 <0I1G00CAY00FE1@mail.sun.net> for atom-syntax@imc.org; Sun,
 25 Jul 2004 22:48:20 -0600 (MDT)
Date: Sun, 25 Jul 2004 21:48:29 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: PaceItemIDIsNewsML: Struggling for compromise
In-reply-to: <20040726034817.11800.qmail@web41214.mail.yahoo.com>
To: Dare Obasanjo <kpako@yahoo.com>
Cc: atom-syntax@imc.org, Ken MacLeod <ken@bitsko.slc.ut.us>
Message-id: <09B394D6-DEBF-11D8-8C8C-000A95A51C9E@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.618)
Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Content-transfer-encoding: 7BIT
References: <20040726034817.11800.qmail@web41214.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


I care about this identifier stuff, but I care more about getting Atom  
finished.  So I am *not* going to stand in the way of a compromise  
position just on the grounds that I disbelieve its technical  
underpinnings.

So, I think we have *strong* consensus on the following proposition:

- It is not a goal that <atom:id> be usable for retrieval of  
information.

(Does anyone disagree?  I'd be astounded).

I personally think that should suffice, but I get the impression that  
the http-identifiers-are-broken faction is asking for more.  So, here's  
proposed compromise language:

======================================================================== 
==========
Given that HTTP URIs can be used for retrieval of information, it is  
possible that their use in <atom:id> could lead to erroneous  
understanding of the meaning and correct use of <atom:id>.  For this  
reason, implementors SHOULD consider using another URI scheme (see  
[http://www.iana.org/assignments/uri-schemes]) which does not imply  
information-retrieval semantics, for example URNs (see [RFC2141] and  
http://www.iana.org/assignments/urn-namespaces).
======================================================================== 
==========

BTW, with specific reference to urn:newsml:, I think it's a sensible  
and well-designed URN namespace, but I think you're going to have  
trouble getting past the problem that leaps to my eye when I read the  
RFC3085 abstract:
   "This document describes a URN (Uniform Resource Name) namespace for
    identifying NewsML NewsItems.  A NewsItem is an information resource
    that is expressible as a NewsML element within a NewsML document
    conforming to the NewsML Document Type Declaration (DTD) as defined
    by the International Press Telecommunications Council (IPTC)."



From owner-atom-syntax@mail.imc.org  Mon Jul 26 01: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 BAA16479
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 01: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 i6Q53DkM098863;
	Sun, 25 Jul 2004 22:03: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 i6Q53DHv098862;
	Sun, 25 Jul 2004 22:03: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 i6Q53CXN098851
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 22:03:12 -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 i6Q54JY9016466;
	Mon, 26 Jul 2004 01:04:20 -0400
Message-ID: <41049095.1030804@intertwingly.net>
Date: Mon, 26 Jul 2004 01:03:17 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Dare Obasanjo <kpako@yahoo.com>
CC: bob@wyman.us, "'Tim Bray'" <Tim.Bray@Sun.COM>, atom-syntax@imc.org,
        "'Ken MacLeod'" <ken@bitsko.slc.ut.us>
Subject: Re: PaceAtomIDIsNewsML (Requiring atom:id to be a NewsML URN)
References: <20040726044426.10296.qmail@web41203.mail.yahoo.com>
In-Reply-To: <20040726044426.10296.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:
> 
> Ideally Atom should have normative text pointing out
> that items should have unique and *unchanging*
> identifiers including examples that currently break in
> RSS today due to changing identifiers. 

I predict that if somebody were to write up such a pace, it would get 
consensus quickly.

I did a quick scan:

In RSS 1.0, there is a statement: "{item_uri} should be identical to the 
value of the <link>  sub-element of the <item> element, if possible."

In RSS 2.0, one can find "isPermaLink is optional, its default value is 
true."

A single xml.com article which describes how an unregistered URI scheme 
can be used has influenced countless Atom feeds to use the "tag" scheme.

It seems that one can conclude that in feed formats in which the 
documentation suggests that ids be links, results in feeds with ids as 
links.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Mon Jul 26 02: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 CAA03914
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 02:46: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 i6Q6ZTbF037137;
	Sun, 25 Jul 2004 23:35: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 i6Q6ZTfI037136;
	Sun, 25 Jul 2004 23:35:29 -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 i6Q6ZSlc037127
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 23:35:28 -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 5D55B4F0DC;
	Mon, 26 Jul 2004 02:35:26 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040726153232.038e8d90@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Mon, 26 Jul 2004 15:32:45 +0900
To: Tim Bray <Tim.Bray@Sun.COM>, Dare Obasanjo <kpako@yahoo.com>
From: Martin Duerst <duerst@w3.org>
Subject: Re: PaceAtomIDIsNewsML (Requiring atom:id to be a NewsML URN)
Cc: bob@wyman.us, "'Ken MacLeod'" <ken@bitsko.slc.ut.us>,
        Sam Ruby <rubys@intertwingly.net>, atom-syntax@imc.org
In-Reply-To: <23DBE2C2-DEBF-11D8-8C8C-000A95A51C9E@sun.com>
References: <20040726044426.10296.qmail@web41203.mail.yahoo.com>
 <20040726044426.10296.qmail@web41203.mail.yahoo.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 21:49 04/07/25 -0700, Tim Bray wrote:

>On Jul 25, 2004, at 9:44 PM, Dare Obasanjo wrote:
>
>>Ideally Atom should have normative text pointing out
>>that items should have unique and *unchanging*
>>identifiers including examples that currently break in
>>RSS today due to changing identifiers.
>
>+1 -Tim

+1

Regards,   Martin.




From owner-atom-syntax@mail.imc.org  Mon Jul 26 02:47: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 CAA03986
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 02:47: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 i6Q6cosC038316;
	Sun, 25 Jul 2004 23:38: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 i6Q6cop9038315;
	Sun, 25 Jul 2004 23:38:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from omr3.netsolmail.com (omr3.netsolmail.com [216.168.230.164])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q6cnb2038285
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 23:38:49 -0700 (PDT)
	(envelope-from bob@wyman.us)
Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180])
	by omr3.netsolmail.com (8.12.10/8.12.10) with ESMTP id i6Q6bbT6015183;
	Mon, 26 Jul 2004 02:37: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 BKA54816 (AUTH bob@wyman.us);
	Mon, 26 Jul 2004 02:38:45 -0400 (EDT)
Reply-To: <bob@wyman.us>
From: "Bob Wyman" <bob@wyman.us>
To: "'Sam Ruby'" <rubys@intertwingly.net>, <bob@wyman.us>
Cc: <atom-syntax@imc.org>
Subject: RE: PaceAtomIDIsNewsML (Requiring atom:id to be a NewsML URN)
Date: Mon, 26 Jul 2004 02:40:39 -0400
Message-ID: <001501c472db$77c96c70$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
Importance: Normal
In-Reply-To: <41048BAE.5070400@intertwingly.net>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


Sam Ruby wrote:
> How many existing databases have a "column"
> for this? [i.e. AtomID]
	Even with the Atom specification in its current form, anyone who
is generating atom feeds SHOULD have such a column. It is unfortunately
quite clear that many don't even though an atom:id is already required
to be invariant. Thus, the atom:id must be based on invariant data.
Given that base URL's and other elements from which ids might be
composed can vary, the only way you can meet the requirements of the
specification are to fix the atom:id at the time that it is first
generated.
	I'm concerned that your question implies that we should avoid
making specification decisions that might require people to modify their
existing implementations. Frankly, I think such a suggestion is totally
inappropriate. The only way we could meet such a restriction is by
ensuing that Atom is nothing more than a simply transform on RSS. The
point of this exercise is to define a better format, not just change the
names of the existing fields. We should not be overly constrained by
existing implementations. Our goal should be to define a format that
will best allow user's needs to be better addressed by future
implementations.

		bob wyman



From owner-atom-syntax@mail.imc.org  Mon Jul 26 02:48: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 CAA04005
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 02:48: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 i6Q6ZQ0A037116;
	Sun, 25 Jul 2004 23:35: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 i6Q6ZQnA037115;
	Sun, 25 Jul 2004 23:35:26 -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 i6Q6ZQ3A037103
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 23:35:26 -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 922534F0BD;
	Mon, 26 Jul 2004 02:35:24 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040726152444.00ba0140@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Mon, 26 Jul 2004 15:35:36 +0900
To: <bob@wyman.us>, "'Atom-Syntax'" <atom-syntax@imc.org>
From: Martin Duerst <duerst@w3.org>
Subject: Re: PaceAtomIDIsNewsML (Requiring atom:id to be a NewsML URN)
In-Reply-To: <007c01c472a7$431c9cb0$6601a8c0@wyman.us>
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 20:26 04/07/25 -0400, Bob Wyman wrote:

>I've created a Pace to require that atom:id be a NewsML URN.
>See: http://www.intertwingly.net/wiki/pie/PaceAtomIDIsNewsML

-1. It is never a good idea to restrict a specific field to
a single URI scheme (or URN scheme, or whatever). If you do that,
the point of using an URI just disappears. If you want to use
NewsML only, the best thing to do is to call the attribute
"NewsMLid" (or some such), and to remove the leading urn:newsml:.
Otherwise, people will use other uri schemes anyway.

But when you do that, you realize that you severely limit future
extensibility.

Regards,    Martin.



From owner-atom-syntax@mail.imc.org  Mon Jul 26 02:53: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 CAA04092
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 02:53: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 i6Q6iBK2040025;
	Sun, 25 Jul 2004 23: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 i6Q6iB3j040024;
	Sun, 25 Jul 2004 23:44:11 -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 i6Q6iA1R040011
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 23:44:11 -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 i6Q6mfhA001778;
	Mon, 26 Jul 2004 02:48:41 -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 BKA55886 (AUTH bob@wyman.us);
	Mon, 26 Jul 2004 02:44:08 -0400 (EDT)
Reply-To: <bob@wyman.us>
From: "Bob Wyman" <bob@wyman.us>
To: "'Sam Ruby'" <rubys@intertwingly.net>, <bob@wyman.us>
Cc: "'Tim Bray'" <Tim.Bray@Sun.COM>, "'Dare Obasanjo'" <kpako@yahoo.com>,
        <atom-syntax@imc.org>, "'Ken MacLeod'" <ken@bitsko.slc.ut.us>
Subject: RE: PaceAtomIDIsNewsML (Requiring atom:id to be a NewsML URN)
Date: Mon, 26 Jul 2004 02:46:02 -0400
Message-ID: <001601c472dc$384fec30$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
Importance: Normal
In-Reply-To: <4104888E.8000806@intertwingly.net>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


Sam Ruby wrote:
> Now, why isn't it *obvious* that the NewsML ID for 
> URIs on blogs.msdn.com should have a ProviderId of
> blogs.msdn.com?
	Because, an atom:id which is a NewsML URN is something different
from an URL. Thus, users of these things will learn new practices, new
philosophies, new expectations for how they are used. As Eric Scheid
wrote: "If they are guided to using some arcane thing they've not seen
before, and which doesn't look like a URL does (lots of slashes and
stuff), then they might actually engage brain for the few short cycles
necessary."

		bob wyman



From owner-atom-syntax@mail.imc.org  Mon Jul 26 03:09: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 DAA04746
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 03:09: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 i6Q6xbxC045227;
	Sun, 25 Jul 2004 23: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 i6Q6xbTB045226;
	Sun, 25 Jul 2004 23:59: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 (mail.gmx.net [213.165.64.20])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6Q6xZrk045152
	for <atom-syntax@imc.org>; Sun, 25 Jul 2004 23:59:36 -0700 (PDT)
	(envelope-from julian.reschke@gmx.de)
Received: (qmail 17263 invoked by uid 65534); 26 Jul 2004 06:59:25 -0000
Received: from pD95359DE.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.89.222)
  by mail.gmx.net (mp021) with SMTP; 26 Jul 2004 08:59:25 +0200
X-Authenticated: #1915285
Message-ID: <4104ABC5.4010409@gmx.de>
Date: Mon, 26 Jul 2004 08:59:17 +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: Tim Bray <Tim.Bray@Sun.COM>
CC: atom-syntax@imc.org
Subject: Re: PaceItemIDIsNewsML: Struggling for compromise
References: <20040726034817.11800.qmail@web41214.mail.yahoo.com> <09B394D6-DEBF-11D8-8C8C-000A95A51C9E@sun.com>
In-Reply-To: <09B394D6-DEBF-11D8-8C8C-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


Hi,

maybe looking at other IETF specs for guidance would be of interest.

WebDAV (RFC2518) uses URIs to identify locks. The so-called "lock 
tokens" URIs "...MUST be unique across all resources for all time" 
(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.6.3>). So 
this is a very similar problem.

Solution:

1) cleanly spell out the uniqueness requirement, but say that *any* URI 
scheme will do as long as this requirement is fulfilled

2) recommend *one* specific scheme that works fine, and use that one 
through the examples

1) ensures that people how want HTTP URLs can actually use them (or 
something else). 2) helps those who are unsure and just want a reliable 
solution without having to think too much about the details.

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From owner-atom-syntax@mail.imc.org  Mon Jul 26 03:49: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 DAA07084
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 03:49: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 i6Q7eM2C057845;
	Mon, 26 Jul 2004 00:40: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 i6Q7eMjp057844;
	Mon, 26 Jul 2004 00:40: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 [18.29.0.30])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6Q7eM5B057833
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 00:40:22 -0700 (PDT)
	(envelope-from danbri@w3.org)
Received: by homer.w3.org (Postfix, from userid 13522)
	id 24EA34F13A; Mon, 26 Jul 2004 03:40:22 -0400 (EDT)
Date: Mon, 26 Jul 2004 03:40:22 -0400
From: Dan Brickley <danbri@w3.org>
To: Tim Bray <Tim.Bray@Sun.COM>
Cc: Dare Obasanjo <kpako@yahoo.com>, atom-syntax@imc.org,
        Ken MacLeod <ken@bitsko.slc.ut.us>
Subject: Re: PaceAtomIDIsNewsML (Requiring atom:id to be a NewsML URN)
Message-ID: <20040726074021.GA4473@homer.w3.org>
References: <20040726011928.44460.qmail@web41215.mail.yahoo.com> <A40C8C38-DEB1-11D8-8C8C-000A95A51C9E@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <A40C8C38-DEB1-11D8-8C8C-000A95A51C9E@sun.com>
User-Agent: Mutt/1.5.6+20040523i
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> [2004-07-25 20:12-0700]
> 
> On Jul 25, 2004, at 6:19 PM, Dare Obasanjo wrote:
> 
> >No it isn't. Bob is an aggregator author and I'm an
> >aggregator author who both have experience having to
> >write code to process the millions of syndication
> >feeds out there and answer to thousands of customers.
> >Both of us have said based on our experience the
> >current specification text is for interoperation and
> >is harmful to a positive user experience.
> 
> Well, you are advancing the hypothesis that people who cannot 
> competently manage a stable identifier space when the identifiers begin 
> with "http:" will become capable of doing so when the identifiers begin 
> with some other prefix.  It's not obviously insane and it is possible 
> that you are correct.  Looking at the same evidence, I doubt it, and 
> that's life.  In any case, I seriously think there is lack of 
> sufficient experimental evidence to write this hypothesis into an RFC. 

+1

I have a problem with mandating a particular URI scheme (ie. URNs) when
there are other non-HTTP URI schemes (freenet, uuid, tag, ...) that are 
in a similar business. Even in the URN world. there are other corners of
URN space, current and future, which try to do the same thing. I'm not
seeing a compelling reason for creating a dependency on NewsML URN/URIs.

Dan



From owner-atom-syntax@mail.imc.org  Mon Jul 26 03: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 DAA07213
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 03:54: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 i6Q7iNYr059198;
	Mon, 26 Jul 2004 00:44: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 i6Q7iNS2059197;
	Mon, 26 Jul 2004 00:44:23 -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 i6Q7iN4S059187
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 00:44:23 -0700 (PDT)
	(envelope-from danbri@w3.org)
Received: by homer.w3.org (Postfix, from userid 13522)
	id 810A94F0DD; Mon, 26 Jul 2004 03:44:23 -0400 (EDT)
Date: Mon, 26 Jul 2004 03:44:23 -0400
From: Dan Brickley <danbri@w3.org>
To: Martin Duerst <duerst@w3.org>
Cc: Tim Bray <Tim.Bray@Sun.COM>, Dare Obasanjo <kpako@yahoo.com>, bob@wyman.us,
        "'Ken MacLeod'" <ken@bitsko.slc.ut.us>,
        Sam Ruby <rubys@intertwingly.net>, atom-syntax@imc.org
Subject: Re: PaceAtomIDIsNewsML (Requiring atom:id to be a NewsML URN)
Message-ID: <20040726074423.GB4473@homer.w3.org>
References: <20040726044426.10296.qmail@web41203.mail.yahoo.com> <20040726044426.10296.qmail@web41203.mail.yahoo.com> <4.2.0.58.J.20040726153232.038e8d90@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4.2.0.58.J.20040726153232.038e8d90@localhost>
User-Agent: Mutt/1.5.6+20040523i
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>


* Martin Duerst <duerst@w3.org> [2004-07-26 15:32+0900]
> 
> At 21:49 04/07/25 -0700, Tim Bray wrote:
> 
> >On Jul 25, 2004, at 9:44 PM, Dare Obasanjo wrote:
> >
> >>Ideally Atom should have normative text pointing out
> >>that items should have unique and *unchanging*
> >>identifiers including examples that currently break in
> >>RSS today due to changing identifiers.
> >
> >+1 -Tim
> 
> +1

+1

Dan



From owner-atom-syntax@mail.imc.org  Mon Jul 26 04:03: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 EAA07508
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 04: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 i6Q7rXp3061939;
	Mon, 26 Jul 2004 00: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 i6Q7rXe9061938;
	Mon, 26 Jul 2004 00:53: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 i6Q7rWdX061930
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 00:53:32 -0700 (PDT)
	(envelope-from danbri@w3.org)
Received: by homer.w3.org (Postfix, from userid 13522)
	id C29DD4F13A; Mon, 26 Jul 2004 03:53:32 -0400 (EDT)
Date: Mon, 26 Jul 2004 03:53:32 -0400
From: Dan Brickley <danbri@w3.org>
To: Bob Wyman <bob@wyman.us>
Cc: "'Sam Ruby'" <rubys@intertwingly.net>, "'Tim Bray'" <Tim.Bray@Sun.COM>,
        "'Dare Obasanjo'" <kpako@yahoo.com>, atom-syntax@imc.org,
        "'Ken MacLeod'" <ken@bitsko.slc.ut.us>
Subject: Re: PaceAtomIDIsNewsML (Requiring atom:id to be a NewsML URN)
Message-ID: <20040726075326.GC4473@homer.w3.org>
References: <4104888E.8000806@intertwingly.net> <001601c472dc$384fec30$6400a8c0@wyman.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <001601c472dc$384fec30$6400a8c0@wyman.us>
User-Agent: Mutt/1.5.6+20040523i
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> [2004-07-26 02:46-0400]
> 
> Sam Ruby wrote:
> > Now, why isn't it *obvious* that the NewsML ID for 
> > URIs on blogs.msdn.com should have a ProviderId of
> > blogs.msdn.com?
> 	Because, an atom:id which is a NewsML URN is something different
> from an URL. 

I wouldn't be so sure. The more popular such URN ID systems become, the
more likely it is we'll start to see resolution services provided at the
ISP / proxy cache layer. At which point the pschological distinction
between "I can put this into the browser address/URL/etc bar to get
myself a representation of it" vs "I can put this into Google to get
myself a representation of it" starts to crumble.

http://www.dlib.org/dlib/june98/06powell.html for example shows the use
of DOI URNs with a Squid proxy cache. If you plug your laptop into the
Bath University network there's a good chance that identifiers like 
urn:doi:10.1000/1 will behave an awful lot like http URLs. The distinction
between URL and non-URL URI isn't such a technical one, but is more to
do with the transparency and ease of finding/locating/accessing
representations of the thing the URI names. Which in turn is more to do
with markets, adoption and quirks of engineering history. Todays URNs
could be tommorrows URLs.

Dan



From owner-atom-syntax@mail.imc.org  Mon Jul 26 04:13: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 EAA08133
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 04:13: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 i6Q82Aou064758;
	Mon, 26 Jul 2004 01: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 i6Q82AO7064757;
	Mon, 26 Jul 2004 01:02:10 -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 i6Q829wu064748
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 01:02:10 -0700 (PDT)
	(envelope-from danbri@w3.org)
Received: by homer.w3.org (Postfix, from userid 13522)
	id 352E94F170; Mon, 26 Jul 2004 04:02:10 -0400 (EDT)
Date: Mon, 26 Jul 2004 04:02:10 -0400
From: Dan Brickley <danbri@w3.org>
To: Bob Wyman <bob@wyman.us>
Cc: "'Ken MacLeod'" <ken@bitsko.slc.ut.us>, atom-syntax@imc.org
Subject: Re: PaceAtomIDIsNewsML (Requiring atom:id to be a NewsML URN)
Message-ID: <20040726080208.GD4473@homer.w3.org>
References: <m3ekmz8u8o.fsf@bitsko.slc.ut.us> <000601c472b8$0d3a25c0$6400a8c0@wyman.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <000601c472b8$0d3a25c0$6400a8c0@wyman.us>
User-Agent: Mutt/1.5.6+20040523i
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> [2004-07-25 22:27-0400]
> 
> Ken MacLeod wrote:
> >  but mandating a particular URI scheme is a non-starter.
> 	Thank you for your opinion. Now, how about explaining *why* it
> is a non-starter? If we can mandate the format for a date, why can't we
> mandate the format for atom:id? 

I think this comparison misses the mark. Mandating the date syntax
gives us an ISO-8601 profile, ie. an agreed notation for writing dates
down. Mandating an identifier syntax gives us URIs, ie. an agreed
notation for writing identifiers down. Both are wise; but neither is in
the business of telling us *which* dates or identifiers are legitimate.
Messing with the value space ("no dates before Alan Turing, 'cos weblogs
and aggregators didn't exist then"; "no URIs except those assigned
according to the NewsML URN approach") is a reasonable distinct sort of
restriction to be making. An unnecessarily one, in my experience.

Or, do you think we should also support

> 	Can you make a case which justifies supporting variety and user
> creativity in forming atom:id's? 

You make good arguments for restricting to a common identifier syntax 
(in atom:id and elsewhere). The URI spec can serve that purpose for us,
just as we have a common date syntax for date-related fields.

Dan



From owner-atom-syntax@mail.imc.org  Mon Jul 26 04: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 EAA08337
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 04: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 i6Q84QdT065463;
	Mon, 26 Jul 2004 01:04: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 i6Q84QYS065462;
	Mon, 26 Jul 2004 01:04:26 -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 i6Q84Q39065453
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 01:04:26 -0700 (PDT)
	(envelope-from danbri@w3.org)
Received: by homer.w3.org (Postfix, from userid 13522)
	id 7FDE44EFE8; Mon, 26 Jul 2004 04:04:26 -0400 (EDT)
Date: Mon, 26 Jul 2004 04:04:26 -0400
From: Dan Brickley <danbri@w3.org>
To: "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: Re: PaceAtomIDIsNewsML (Requiring atom:id to be a NewsML URN)
Message-ID: <20040726080426.GE4473@homer.w3.org>
References: <007c01c472a7$431c9cb0$6601a8c0@wyman.us> <4.2.0.58.J.20040726152444.00ba0140@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4.2.0.58.J.20040726152444.00ba0140@localhost>
User-Agent: Mutt/1.5.6+20040523i
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>


* Martin Duerst <duerst@w3.org> [2004-07-26 15:35+0900]
> 
> At 20:26 04/07/25 -0400, Bob Wyman wrote:
> 
> >I've created a Pace to require that atom:id be a NewsML URN.
> >See: http://www.intertwingly.net/wiki/pie/PaceAtomIDIsNewsML

-1 to the Pace, for the reasons given by Martin and my recent posts 
in this thread. 

> -1. It is never a good idea to restrict a specific field to
> a single URI scheme (or URN scheme, or whatever). If you do that,
> the point of using an URI just disappears. If you want to use
> NewsML only, the best thing to do is to call the attribute
> "NewsMLid" (or some such), and to remove the leading urn:newsml:.
> Otherwise, people will use other uri schemes anyway.
> 
> But when you do that, you realize that you severely limit future
> extensibility.
> 
> Regards,    Martin.



From owner-atom-syntax@mail.imc.org  Mon Jul 26 06:02: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 GAA12082
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 06:02: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 i6Q9qlGv002030;
	Mon, 26 Jul 2004 02:52: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 i6Q9qlD6002029;
	Mon, 26 Jul 2004 02:52:47 -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 i6Q9qkrr002001
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 02:52:47 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 41007 messnum 364515 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 26 Jul 2004 09:52:42 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.174?) (83.70.33.112)
  by mail05.svc.cra.dublin.eircom.net (qp 41007) with SMTP; 26 Jul 2004 09:52:42 -0000
Message-ID: <4104D468.3060507@dehora.net>
Date: Mon, 26 Jul 2004 10:52:40 +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: Tim Bray <Tim.Bray@Sun.COM>
CC: Dare Obasanjo <kpako@yahoo.com>, atom-syntax@imc.org,
        Ken MacLeod <ken@bitsko.slc.ut.us>
Subject: Re: PaceItemIDIsNewsML: Struggling for compromise
References: <20040726034817.11800.qmail@web41214.mail.yahoo.com> <09B394D6-DEBF-11D8-8C8C-000A95A51C9E@sun.com>
In-Reply-To: <09B394D6-DEBF-11D8-8C8C-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:

> 
> I care about this identifier stuff, but I care more about getting Atom  
> finished.  So I am *not* going to stand in the way of a compromise  
> position just on the grounds that I disbelieve its technical  
> underpinnings.
> 
> So, I think we have *strong* consensus on the following proposition:
> 
> - It is not a goal that <atom:id> be usable for retrieval of  information.
> 
> (Does anyone disagree?  I'd be astounded).

I agree, but more than non-goals are needed. Bob and Dare, the 
implementors  who are boosting NewsML have already indicated 
agreement with this requirement:

"all Atom entries must have unique (space and time) surrogate keys 
to support aggregation use-cases"

Whether or not you one uses URIs for retrieval is not the issue - 
stability of identifiers is - the claim is that HTTP /URIs/ result 
in instability and in part this may be down to them also being URLs. 
But it would be a mistake to think that not saying it's a non-goal 
for atom:ids to be retrievable will address the matter.


> I personally think that should suffice, but I get the impression that  
> the http-identifiers-are-broken faction is asking for more.  So, here's  
> proposed compromise language:

Excellent - text. Thank you.


> ======================================================================== 
> ==========
> Given that HTTP URIs can be used for retrieval of information, it is  
> possible that their use in <atom:id> could lead to erroneous  
> understanding of the meaning and correct use of <atom:id>.  For this  
> reason, implementors SHOULD consider using another URI scheme (see  
> [http://www.iana.org/assignments/uri-schemes]) which does not imply  
> information-retrieval semantics, for example URNs (see [RFC2141] and  
> http://www.iana.org/assignments/urn-namespaces).
> ======================================================================== 
> ==========

I would suggest:

"Atom entries are required to use stable and unique URIs in the 
atom:id elment. Note: past experience has shown that the use of URLs 
(such as the http: scheme) can lead to erroneous understanding of 
the meaning and correct use of atom:id. For this reason, 
implementors SHOULD consider using  URNs which do not have retrieval 
semantics (see [RFC2141] and 
http://www.iana.org/assignments/urn-namespaces). In any case Atom 
consumers MUST NOT expect that the values used in atom:id import any 
semantics other than that of identification."

ie whatever the exact end text is, it should say two things 1) what 
the requirement is (stable identity), 2) not to use identifiers for 
anything other than identity.


> BTW, with specific reference to urn:newsml:, I think it's a sensible  
> and well-designed URN namespace, but I think you're going to have  
> trouble getting past the problem that leaps to my eye when I read the  
> RFC3085 abstract:
>   "This document describes a URN (Uniform Resource Name) namespace for
>    identifying NewsML NewsItems.  A NewsItem is an information resource
>    that is expressible as a NewsML element within a NewsML document
>    conforming to the NewsML Document Type Declaration (DTD) as defined
>    by the International Press Telecommunications Council (IPTC)."

This has already been pointed out twice, along with the extra 
semantics the scheme carries. It seems to have gotten lost in all 
the fire and brimstone so far. Do keep pointing it out every few 
posts - it's not the same concern as Martin's.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Mon Jul 26 08:15: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 IAA18222
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 08: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 i6QC5QvB030497;
	Mon, 26 Jul 2004 05:05: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 i6QC5QEI030496;
	Mon, 26 Jul 2004 05:05:26 -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 i6QC5PeN030489
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 05:05:25 -0700 (PDT)
	(envelope-from wkearney@syndic8.com)
Received: (qmail 32165 invoked from network); 26 Jul 2004 12:05:26 -0000
Received: from xbox.wkearney.com (HELO media) ([66.92.145.79])
          (envelope-sender <wkearney@syndic8.com>)
          by mail3.speakeasy.net (qmail-ldap-1.03) with SMTP
          for <atom-syntax@imc.org>; 26 Jul 2004 12:05:26 -0000
Message-ID: <001101c47308$d67968b0$200ca8c0@wkearney.com>
From: "Bill Kearney" <wkearney@syndic8.com>
To: <atom-syntax@imc.org>
References: <000901c472c2$d7cc5150$6400a8c0@wyman.us>
Subject: Re: URI scheme delusions
Date: Mon, 26 Jul 2004 08:05: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: <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


> Aargh... We work pretty hard at finding duplicates... The idea
> that you'd see as many as 8 dupes of a single entry is kind of
> depressing. Of course, if we didn't run our detection code, you'd see
> many more... Please accept that we're doing the best we can but there
> really are limits to what you can accomplish using textual analysis and
> the junk we get for guids, permalinks, atom:ids and dates today. Garbage
> in, Garbage out....

As we've discovered via Syndic8 it's often better to work with the data sources
to provide better content at the start.  We'd be more than happy to assist in
the process.

> Also, please note that to do duplicate detection properly, we
> need *both* unique atom:ids and reliable, meaningful date-stamps. (Note:
> That "meaningful" bit is important. We find too many dates in feeds that
> are dynamically generated with code like "Now()" and change every time
> you access the feed.)

Yes, when a tool generated the output has merit.  If only to detect when the
output code screwed up and stopped providing workable data.  One could also
argue that knowing that a feed was generated at 1pm and the most recent content
was generated at 3am the previous day is likewise important in some situations.

Recognizing however that polling brings it's own resource consumption issues,
it's worth omitting a generated feed timestamp if the actual content hasn't
changed.  There's little or no sense in changing the feed timestamp because it
invalidates caches and just wastes everyone's resources.

-Bill Kearney



From owner-atom-syntax@mail.imc.org  Mon Jul 26 08:17: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 IAA18384
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 08: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 i6QC0QVl029790;
	Mon, 26 Jul 2004 05:00: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 i6QC0QFG029789;
	Mon, 26 Jul 2004 05:00:26 -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 i6QC0PPO029782
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 05:00:25 -0700 (PDT)
	(envelope-from wkearney@syndic8.com)
Received: (qmail 23532 invoked from network); 26 Jul 2004 12:00:25 -0000
Received: from xbox.wkearney.com (HELO media) ([66.92.145.79])
          (envelope-sender <wkearney@syndic8.com>)
          by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP
          for <atom-syntax@imc.org>; 26 Jul 2004 12:00:25 -0000
Message-ID: <000801c47308$22b2c3d0$200ca8c0@wkearney.com>
From: "Bill Kearney" <wkearney@syndic8.com>
To: <atom-syntax@imc.org>
References: <000501c472b6$03608cd0$6400a8c0@wyman.us>
Subject: Re: URI scheme delusions
Date: Mon, 26 Jul 2004 08:00:24 -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: <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 is precisely why PaceAtomIDIsNewsML proposes that we use
> the already registered (since 2001) URN scheme for NewsML[1]. NewsML
> provides what LDIS and tag do but has the advantage that it is already
> registered. Also, it was the result of work done on a problem (news
> syndication by formal news organizations) that is very similar to the
> syndication problem being addressed by Atom.

For some reason I'm left with the feeling of "inheriting or being restricted to
another effort's semantics".  While at the same time I'd prefer to avoid
reinventing the wheel.  NewsML is not without it's own set of headaches (if you
think RDF is verbose...) so I'm cautious about attempts to adopt it as a
solution here.  That said, it's structure for URN is useful and may well be
worth emulating.

-Bill Kearney
Syndic8.com



From owner-atom-syntax@mail.imc.org  Mon Jul 26 08: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 IAA19257
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 08: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 i6QCNqSu032530;
	Mon, 26 Jul 2004 05:23: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 i6QCNqKx032529;
	Mon, 26 Jul 2004 05:23:52 -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 i6QCNpfD032523
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 05:23:51 -0700 (PDT)
	(envelope-from wkearney@syndic8.com)
Received: (qmail 1495 invoked from network); 26 Jul 2004 12:23:53 -0000
Received: from xbox.wkearney.com (HELO media) ([66.92.145.79])
          (envelope-sender <wkearney@syndic8.com>)
          by mail3.speakeasy.net (qmail-ldap-1.03) with SMTP
          for <atom-syntax@imc.org>; 26 Jul 2004 12:23:53 -0000
Message-ID: <001201c4730b$6a1cbfc0$200ca8c0@wkearney.com>
From: "Bill Kearney" <wkearney@syndic8.com>
To: <atom-syntax@imc.org>
References: <20040726020754.82924.qmail@web41210.mail.yahoo.com>
Subject: Re: What is Wrong with HTTP URIs (Was Re: URI scheme delusions)
Date: Mon, 26 Jul 2004 08:23:53 -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: <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


> There's lots wrong with HTTP URIs as opposed to HTTP
> URLs, see
> http://www.kuro5hin.org/story/2003/2/5/11349/85355 for
> descriptions of the problems HTTP URIs have caused to
> RDF and XML namespaces.

And guns don't kill people, people kill people.  Badly used identifiers are
independent of their structure.  There's no reason an http:// prefixed
identifier can't be used.  Eliminating the prefix won't do a damned thing to
change it besides 'making it look different'.

> Also a number of problems with aggregation today would
> fade away if HTTP URLs weren't being used as
> identifiers to entries.

The separation of them as a resolvable resource versus a unique identifier would
work even if they were still using the http:// prefix.  Even if they (gasp)
proved to actually resolve!

> Duplicate entries in across
> the same or multiple feeds is just one problem this
> would solve.

Properly used identifiers would solve it, what form they use is independent of
the argument.

> The IETF/W3C were the ones that one day decided that
> even though there were seperate constructs one limited
> to identifying (URNs) the other for locations (URLs)
> it would make sense to muddy the waters.

The historical reasons for the mashing together of URI/URL and near abandonment
of URN are muddy at best.  There's a lot more to the argument than what seems
like your desire to beat them up (IETF/W3C interchangeably it seems) about it.

> I see that we agree.

But probably not to the extent you think.

-Bill Kearney
Syndic8.com



From owner-atom-syntax@mail.imc.org  Mon Jul 26 09:10: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 JAA23449
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 09:10:48 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QD0BTV035931;
	Mon, 26 Jul 2004 06: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 i6QD0BdX035930;
	Mon, 26 Jul 2004 06:00:11 -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 i6QD0AC9035924
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 06:00:10 -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 i6QD1FEB007098;
	Mon, 26 Jul 2004 09:01:15 -0400
Message-ID: <4105005A.1080807@intertwingly.net>
Date: Mon, 26 Jul 2004 09:00:10 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Bill Kearney <wkearney@syndic8.com>
CC: atom-syntax@imc.org
Subject: Re: What is Wrong with HTTP URIs (Was Re: URI scheme delusions)
References: <20040726020754.82924.qmail@web41210.mail.yahoo.com> <001201c4730b$6a1cbfc0$200ca8c0@wkearney.com>
In-Reply-To: <001201c4730b$6a1cbfc0$200ca8c0@wkearney.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


Bill Kearney wrote:

>>There's lots wrong with HTTP URIs as opposed to HTTP
>>URLs, see
>>http://www.kuro5hin.org/story/2003/2/5/11349/85355 for
>>descriptions of the problems HTTP URIs have caused to
>>RDF and XML namespaces.
> 
> And guns don't kill people, people kill people.  Badly used identifiers are
> independent of their structure.  There's no reason an http:// prefixed
> identifier can't be used.  Eliminating the prefix won't do a damned thing to
> change it besides 'making it look different'.

Bill, drawing an analogy to a topic where reasonable people disagree is 
not helping you make your case.

I believe that Dare's point (and perhaps Bob's) is that changing the 
prefix will make people stop and think.  And given experience with how 
rdf:about is used in RSS 1.0 today, and how guid is used in RSS 2.0 
today, he is not sure that would be a bad thing.

That goal (make people think) is worthy.  Whether that goal can be 
achieved by documentation, requiring NewsML scheme, or even simply 
inventing a scheme named "ptth" which is exactly identical to http 
except that the name of the scheme is spelled backwards is what we 
should be talking about.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Mon Jul 26 10:32: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 KAA03170
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 10:32: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 i6QEGHF2047200;
	Mon, 26 Jul 2004 07:16: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 i6QEGHXm047199;
	Mon, 26 Jul 2004 07:16: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 i6QEGGb6047181;
	Mon, 26 Jul 2004 07:16:16 -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 i6QEHLOO011934;
	Mon, 26 Jul 2004 10:17:21 -0400
Message-ID: <41051230.4030007@intertwingly.net>
Date: Mon, 26 Jul 2004 10:16:16 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <phoffman@imc.org>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: URI scheme delusions
References: <OF031774D8.BEC98F6C-ON88256EDB.00084992-88256EDB.00090B2C@us.ibm.com> <opsbm7jgwuuvpchu@quark> <41026240.8020009@intertwingly.net> <410266E4.6040304@dehora.net> <14be96d304072408524788c699@mail.gmail.com> <02F0CB0F-DD90-11D8-8C8C-000A95A51C9E@sun.com> <14be96d304072419285ec80400@mail.gmail.com> <E162E7FC-DDFE-11D8-8C8C-000A95A51C9E@sun.com> <905f7c910407251108948a64f@mail.gmail.com> <opsbpmixbkuvpchu@quark> <C2C9EB04-DE91-11D8-8C8C-000A95A51C9E@sun.com> <p06110404bd2a062c02e6@[165.121.169.136]>
In-Reply-To: <p06110404bd2a062c02e6@[165.121.169.136]>
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


Paul Hoffman / IMC wrote:
> 
> At 4:24 PM -0700 7/25/04, Tim Bray wrote:
> 
>> For the record, I strongly disagree.  If it turns out that I'm a tiny 
>> minority, we'll recognize consensus the other way.  However, it will 
>> be unacceptable to reference an unregistered URI scheme.
> 
> Further, it will never get approved by the IESG, for very good reason.

At the moment, the Atom drafts reference an unregistered MIME type.  I 
presume that it is possible to correograph the registration with the 
final approval of the Atom specs.

Is it not possible to do likewise with the registration of URL schemes?

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Mon Jul 26 12:02: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 MAA21909
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 12:01: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 i6QFgrWR077571;
	Mon, 26 Jul 2004 08:42: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 i6QFgrgq077570;
	Mon, 26 Jul 2004 08:42:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from [165.121.169.136] (user-38ldtv3.dialup.mindspring.com [209.86.247.227])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QFgnIq077536;
	Mon, 26 Jul 2004 08:42:51 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p06110412bd2ad6b3cfd1@[165.121.169.136]>
In-Reply-To: <41051230.4030007@intertwingly.net>
References: 
 <OF031774D8.BEC98F6C-ON88256EDB.00084992-88256EDB.00090B2C@us.ibm.com>
 <opsbm7jgwuuvpchu@quark> <41026240.8020009@intertwingly.net>
 <410266E4.6040304@dehora.net> <14be96d304072408524788c699@mail.gmail.com>
 <02F0CB0F-DD90-11D8-8C8C-000A95A51C9E@sun.com>
 <14be96d304072419285ec80400@mail.gmail.com>
 <E162E7FC-DDFE-11D8-8C8C-000A95A51C9E@sun.com>
 <905f7c910407251108948a64f@mail.gmail.com> <opsbpmixbkuvpchu@quark>
 <C2C9EB04-DE91-11D8-8C8C-000A95A51C9E@sun.com>
 <p06110404bd2a062c02e6@[165.121.169.136]>
 <41051230.4030007@intertwingly.net>
Date: Mon, 26 Jul 2004 08:42:50 -0700
To: Sam Ruby <rubys@intertwingly.net>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: URI scheme delusions
Cc: Atom-Syntax <atom-syntax@imc.org>
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 10:16 AM -0400 7/26/04, Sam Ruby wrote:
>At the moment, the Atom drafts reference an unregistered MIME type. 
>I presume that it is possible to correograph the registration with 
>the final approval of the Atom specs.

Yes, this is commonly done.

>Is it not possible to do likewise with the registration of URL schemes?

Yes, for URL schemes that are not controversial.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Mon Jul 26 13:00: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 NAA06903
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 13: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 i6QGdWI8022379;
	Mon, 26 Jul 2004 09:39:32 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6QGdWFS022377;
	Mon, 26 Jul 2004 09:39:32 -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 i6QGdWZu022368
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 09:39:32 -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 i6QGdXfO009845;
	Mon, 26 Jul 2004 09:39:34 -0700 (PDT)
Received: from [192.168.1.101] (66-108-153-170.nyc.rr.com [66.108.153.170])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id i6QGdQaA025178;
	Mon, 26 Jul 2004 09:39:27 -0700 (PDT)
In-Reply-To: <09B394D6-DEBF-11D8-8C8C-000A95A51C9E@sun.com>
References: <20040726034817.11800.qmail@web41214.mail.yahoo.com> <09B394D6-DEBF-11D8-8C8C-000A95A51C9E@sun.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-6-883618742; protocol="application/pkcs7-signature"
Message-Id: <5CA86768-DF22-11D8-9170-000A95DC3D90@mac.com>
Cc: Dare Obasanjo <kpako@yahoo.com>, atom-syntax@imc.org,
        Ken MacLeod <ken@bitsko.slc.ut.us>
From: Graham <dtcd@mac.com>
Subject: Re: PaceItemIDIsNewsML: Struggling for compromise
Date: Mon, 26 Jul 2004 12:39:26 -0400
To: Tim Bray <Tim.Bray@Sun.COM>
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-6-883618742
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed
Content-Transfer-Encoding: 7bit

On 26 Jul 2004, at 12:48 am, Tim Bray wrote:

> - It is not a goal that <atom:id> be usable for retrieval of  
> information.
>
> (Does anyone disagree?  I'd be astounded).
>
> I personally think that should suffice, but I get the impression that  
> the http-identifiers-are-broken faction is asking for more.

I actually agree that the http-identifiers-are-broken group are  
overlooking that in RSS the guid doubles as the address of a  
retrievable resource, whereas in Atom it doesn't. I think that makes  
the problem already solved.

> ======================================================================= 
> ===========
> Given that HTTP URIs can be used for retrieval of information, it is  
> possible that their use in <atom:id> could lead to erroneous  
> understanding of the meaning and correct use of <atom:id>.  For this  
> reason, implementors SHOULD consider using another URI scheme (see  
> [http://www.iana.org/assignments/uri-schemes]) which does not imply  
> information-retrieval semantics, for example URNs (see [RFC2141] and  
> http://www.iana.org/assignments/urn-namespaces).
> ======================================================================= 
> ===========

Saying aggregators should never attempt retrieval of the resource at  
<id>, and that publishers don't need to point them at anything might be  
enough.

Graham
--Apple-Mail-6-883618742
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
9w0BCQUxDxcNMDQwNzI2MTYzOTI3WjAjBgkqhkiG9w0BCQQxFgQUDF6VsWsW4aL7yKIlB/mOdCb4
q/MweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAjiO7wkotR4xV4lf/ZboiMzFx
lCqu6q31d16PGGTEdTe5XTrpncg8tv7i2PepcG9s+LRQHkeHEjiOxhhSNvTiPgg7rfVy6uSNpB8y
LXtDiwoE9As8/I0l3i7HRVAV/SsjEnySNvveI5IOmXyMk6NnXJ8y0J28aKaEOmu+hqpZZZJY2BBS
rhelfm4XLAX9aA7KXgQznhVTupgbAYVhFQYanIC7QnqzIuFRRbZefv8V5nK3WDEEQNsUmg3tMVF6
f25VpjQ3l3/wJ33h9btBc77z351iS+S/ELUhRTBRZPTe+80aGmzzVqAdckhWZwNXiemO9+6heBgM
CFYArCMYzuSoVgAAAAAAAA==

--Apple-Mail-6-883618742--



From owner-atom-syntax@mail.imc.org  Mon Jul 26 13:07: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 NAA08913
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 13:07:40 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QGhqHA025505;
	Mon, 26 Jul 2004 09:43: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 i6QGhqs8025504;
	Mon, 26 Jul 2004 09:43:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QGhp0p025320
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 09:43: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 CC6D77C0F3; Mon, 26 Jul 2004 19:39:37 +0200 (CEST)
Date: Mon, 26 Jul 2004 18:47:22 +0200
To: bob@wyman.us
Subject: Re: URI scheme delusions
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <000901c472c2$d7cc5150$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: <opsbq7k8druvpchu@quark>
In-Reply-To: <000901c472c2$d7cc5150$6400a8c0@wyman.us>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 25 Jul 2004 23:44:23 -0400, Bob Wyman <bob@wyman.us> wrote:

> 	Aargh... We work pretty hard at finding duplicates... The idea
> that you'd see as many as 8 dupes of a single entry is kind of
> depressing. Of course, if we didn't run our detection code, you'd see
> many more.

Off-topic, but anyway: How do you compute the MD5 hashes? Since you  
mentioned that whitespace make entries diff, even if they are the same,  
would it help to do the diff and/or MD5 hashing on the infoset instead of  
the XML string? Or do you compute everything based on the infoset already,  
or is loading every entry into a DOM too much computing? I'd just like to  
know.

> 	Also, please note that to do duplicate detection properly, we
> need *both* unique atom:ids and reliable, meaningful date-stamps.

Would this maybe underscore the need for Atom to explicitly recommend a  
URI scheme that ensures universally uniqueness, in the specification?

> We find too many dates in feeds that are dynamically generated with
> code like "Now()" and change every time you access the feed.

O-M-G. Some people are the most stupid people there is, sometimes.

-- 
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 Jul 26 13:20: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 NAA11289
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 13:20: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 i6QGubTU033766;
	Mon, 26 Jul 2004 09:56: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 i6QGubV6033765;
	Mon, 26 Jul 2004 09:56:37 -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 i6QGub8E033716
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 09:56:37 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040726165635.15615.qmail@web41204.mail.yahoo.com>
Received: from [67.160.87.187] by web41204.mail.yahoo.com via HTTP; Mon, 26 Jul 2004 09:56:35 PDT
Date: Mon, 26 Jul 2004 09:56:35 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: PaceItemIDIsNewsML: Struggling for compromise
To: Graham <dtcd@mac.com>, Tim Bray <Tim.Bray@Sun.COM>
Cc: Dare Obasanjo <kpako@yahoo.com>, atom-syntax@imc.org,
        Ken MacLeod <ken@bitsko.slc.ut.us>
In-Reply-To: <5CA86768-DF22-11D8-9170-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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


--- Graham <dtcd@mac.com> wrote:
> 
> I actually agree that the
> http-identifiers-are-broken group are  
> overlooking that in RSS the guid doubles as the
> address of a  
> retrievable resource, whereas in Atom it doesn't. I
> think that makes  
> the problem already solved.

If past experience tells people that an HTTP URL used
as an identifier in a syndication format should be the
permalink why should they behave differently when a
new syndication format shows up that uses HTTP URLs as
identifiers? 

Are you claiming that there are no Atom feeds out
there that use permalinks as values of atom:id? 

=====
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 Jul 26 13:21: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 NAA11480
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 13:21: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 i6QGq4in030864;
	Mon, 26 Jul 2004 09:52:04 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6QGq4TM030863;
	Mon, 26 Jul 2004 09:52: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 i6QGq3gs030844
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 09:52:03 -0700 (PDT)
	(envelope-from eliast@gmail.com)
Received: by mproxy.gmail.com with SMTP id m68so116332rne
        for <atom-syntax@imc.org>; Mon, 26 Jul 2004 09:52:06 -0700 (PDT)
Received: by 10.38.90.17 with SMTP id n17mr10510rnb;
        Mon, 26 Jul 2004 09:52:06 -0700 (PDT)
Message-ID: <905f7c9104072609525adfbc21@mail.gmail.com>
Date: Mon, 26 Jul 2004 12:52:06 -0400
From: Elias Torres <eliast@gmail.com>
Reply-To: elias@torrez.us
To: Sam Ruby <rubys@intertwingly.net>
Subject: Re: URI scheme delusions
Cc: Paul Hoffman / IMC <phoffman@imc.org>, Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <41051230.4030007@intertwingly.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <OF031774D8.BEC98F6C-ON88256EDB.00084992-88256EDB.00090B2C@us.ibm.com> <opsbm7jgwuuvpchu@quark> <41026240.8020009@intertwingly.net> <410266E4.6040304@dehora.net> <14be96d304072408524788c699@mail.gmail.com> <02F0CB0F-DD90-11D8-8C8C-000A95A51C9E@sun.com> <14be96d304072419285ec80400@mail.gmail.com> <E162E7FC-DDFE-11D8-8C8C-000A95A51C9E@sun.com> <905f7c910407251108948a64f@mail.gmail.com> <opsbpmixbkuvpchu@quark> <C2C9EB04-DE91-11D8-8C8C-000A95A51C9E@sun.com> <p06110404bd2a062c02e6@[165.121.169.136]> <41051230.4030007@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


BTW, LSID will be registered with IANA this year after the next OMG meeting:

http://www.omg.org/lsr/

Unless of course we come up with our own URN scheme for Atom or decide
for NewsML.

Elias

On Mon, 26 Jul 2004 10:16:16 -0400, Sam Ruby <rubys@intertwingly.net> wrote:
> 
> Paul Hoffman / IMC wrote:
> >
> > At 4:24 PM -0700 7/25/04, Tim Bray wrote:
> >
> >> For the record, I strongly disagree.  If it turns out that I'm a tiny
> >> minority, we'll recognize consensus the other way.  However, it will
> >> be unacceptable to reference an unregistered URI scheme.
> >
> > Further, it will never get approved by the IESG, for very good reason.
> 
> At the moment, the Atom drafts reference an unregistered MIME type.  I
> presume that it is possible to correograph the registration with the
> final approval of the Atom specs.
> 
> Is it not possible to do likewise with the registration of URL schemes?
> 
> - Sam Ruby
> 
>



From owner-atom-syntax@mail.imc.org  Mon Jul 26 13: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 NAA14083
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 13:37: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 i6QHHFaZ043631;
	Mon, 26 Jul 2004 10: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 i6QHHFrk043630;
	Mon, 26 Jul 2004 10:17:15 -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 i6QHHEB7043616
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 10:17:15 -0700 (PDT)
	(envelope-from bill@wkearney.com)
Received: (qmail 27005 invoked from network); 26 Jul 2004 17:17:15 -0000
Received: from xbox.wkearney.com (HELO media) ([66.92.145.79])
          (envelope-sender <bill@wkearney.com>)
          by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP
          for <asbjorn@tigerstaden.no>; 26 Jul 2004 17:17:15 -0000
Message-ID: <015401c47334$65d33290$200ca8c0@wkearney.com>
From: "Bill Kearney" <bill@wkearney.com>
To: "Asbjørn Ulsberg" <asbjorn@tigerstaden.no>
Cc: "Atom-Syntax" <atom-syntax@imc.org>
References: <000901c472c2$d7cc5150$6400a8c0@wyman.us> <opsbq7k8druvpchu@quark>
Subject: Re: URI scheme delusions
Date: Mon, 26 Jul 2004 13:17:15 -0400
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: <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 find too many dates in feeds that are dynamically generated with
> > code like "Now()" and change every time you access the feed.
> O-M-G. Some people are the most stupid people there is, sometimes.

While it is indeed pretty brain damaged, it's largely because of the
horrendously ambiguous specs.  That, combined with aggressive promotion of bad
practices and utter contempt for cooperation with others on the part of said
promoter, lead to the current state of affairs.

So I'll toss out the question, what, if any, need is there for an timestamp that
updates based on generation of the document, independent of the content itself?
It would be greatly helpful if the spec and/or examples discussed the downsides
of improper uses of timestamps.  Let's not just say when's the right time to use
a timestamp in a given element, but when it's not.  It's a shame to have to spec
/against/ stupidity but experience shows it might help.

-Bill Kearney
Syndic8.com





From owner-atom-syntax@mail.imc.org  Mon Jul 26 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 NAA14117
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 13:37: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 i6QH3MVK036998;
	Mon, 26 Jul 2004 10:03: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 i6QH3MT1036996;
	Mon, 26 Jul 2004 10:03: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.203])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QH3KsP036957
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 10:03:21 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id 76so96954rnk
        for <atom-syntax@imc.org>; Mon, 26 Jul 2004 10:03:23 -0700 (PDT)
Received: by 10.38.3.58 with SMTP id 58mr81693rnc;
        Mon, 26 Jul 2004 10:03:23 -0700 (PDT)
Message-ID: <14be96d304072610036f83a5e3@mail.gmail.com>
Date: Mon, 26 Jul 2004 13:03:23 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: URI scheme delusions
Cc: Sam Ruby <rubys@intertwingly.net>, Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <p06110412bd2ad6b3cfd1@165.121.169.136>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <OF031774D8.BEC98F6C-ON88256EDB.00084992-88256EDB.00090B2C@us.ibm.com>
 <opsbm7jgwuuvpchu@quark> <41026240.8020009@intertwingly.net>
 <410266E4.6040304@dehora.net> <14be96d304072408524788c699@mail.gmail.com>
 <02F0CB0F-DD90-11D8-8C8C-000A95A51C9E@sun.com>
 <14be96d304072419285ec80400@mail.gmail.com>
 <E162E7FC-DDFE-11D8-8C8C-000A95A51C9E@sun.com>
 <905f7c910407251108948a64f@mail.gmail.com> <opsbpmixbkuvpchu@quark>
 <C2C9EB04-DE91-11D8-8C8C-000A95A51C9E@sun.com>
 <p06110404bd2a062c02e6@[165.121.169.136]>
 <41051230.4030007@intertwingly.net> <p06110412bd2ad6b3cfd1@165.121.169.136>
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 Mon, 26 Jul 2004 08:42:50 -0700, Paul Hoffman / IMC <phoffman@imc.org> wrote:
> At 10:16 AM -0400 7/26/04, Sam Ruby wrote:
> >Is it not possible to do likewise with the registration of URL schemes?
> Yes, for URL schemes that are not controversial.

I guess that would rule out "http://" then.

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Mon Jul 26 13:47: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 NAA16135
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 13:47: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 i6QHOB4o045967;
	Mon, 26 Jul 2004 10:24: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 i6QHOB6k045966;
	Mon, 26 Jul 2004 10:24: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 (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QHOAlG045931
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 10:24: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 EE5577C0F3; Mon, 26 Jul 2004 20:20:03 +0200 (CEST)
Date: Mon, 26 Jul 2004 19:27:56 +0200
To: elias@torrez.us
Subject: Re: URI scheme delusions
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <007801c4729f$8bb41d20$6601a8c0@wyman.us> <905f7c910407251656205472e9@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: <opsbq9guxpuvpchu@quark>
In-Reply-To: <905f7c910407251656205472e9@mail.gmail.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 25 Jul 2004 19:56:02 -0400, Elias Torres <eliast@gmail.com> wrote:

> Leave the spec as it with just a URI? Is it a "recommendation" of
> several schemes that would serve good to both readers and publisher
> of atom feeds? Come up with an atom scheme for IDs?

Since there only seems to be one final and thorough specification for  
ID's, namely News ML ID, I think we should recommend that in the  
specification.

I've created a pace for this. Please read it and make suggestions on how  
to make it better:

<url: http://intertwingly.net/wiki/pie/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  Mon Jul 26 13: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 NAA16834
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 13:52: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 i6QHdLQG049844;
	Mon, 26 Jul 2004 10:39: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 i6QHdLCd049843;
	Mon, 26 Jul 2004 10:39: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 i6QHdKhT049822
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 10:39: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 013537C0F3; Mon, 26 Jul 2004 20:35:09 +0200 (CEST)
Date: Mon, 26 Jul 2004 19:43:04 +0200
To: bobwyman@pubsub.com
Subject: Re: URI scheme delusions
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <000501c472b6$03608cd0$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: <opsbq952druvpchu@quark>
In-Reply-To: <000501c472b6$03608cd0$6400a8c0@wyman.us>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 25 Jul 2004 22:12:33 -0400, Bob Wyman <bobwyman@pubsub.com> wrote:

> That is precisely why PaceAtomIDIsNewsML proposes that we use the
> already registered (since 2001) URN scheme for NewsML[1].

I've created a «competing» pace called PaceRecommendIdScheme[1], for the  
same purpose. The difference seems to be that your pace is more rigid to  
what atom:id may contain.

____
[1] <url: http://intertwingly.net/wiki/pie/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  Mon Jul 26 13: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 NAA17010
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 13: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 i6QHQR8j046704;
	Mon, 26 Jul 2004 10: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 i6QHQRNT046703;
	Mon, 26 Jul 2004 10:26: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.198])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QHQPAl046695
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 10:26:26 -0700 (PDT)
	(envelope-from eliast@gmail.com)
Received: by mproxy.gmail.com with SMTP id m68so118836rne
        for <atom-syntax@imc.org>; Mon, 26 Jul 2004 10:26:29 -0700 (PDT)
Received: by 10.38.11.77 with SMTP id 77mr12332rnk;
        Mon, 26 Jul 2004 10:26:28 -0700 (PDT)
Message-ID: <905f7c9104072610267741042e@mail.gmail.com>
Date: Mon, 26 Jul 2004 13:26:28 -0400
From: Elias Torres <eliast@gmail.com>
Reply-To: elias@torrez.us
To: Graham <dtcd@mac.com>
Subject: Re: PaceItemIDIsNewsML: Struggling for compromise
Cc: Tim Bray <tim.bray@sun.com>, Dare Obasanjo <kpako@yahoo.com>,
        atom-syntax@imc.org, Ken MacLeod <ken@bitsko.slc.ut.us>
In-Reply-To: <5CA86768-DF22-11D8-9170-000A95DC3D90@mac.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <20040726034817.11800.qmail@web41214.mail.yahoo.com> <09B394D6-DEBF-11D8-8C8C-000A95A51C9E@sun.com> <5CA86768-DF22-11D8-9170-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 Mon, 26 Jul 2004 12:39:26 -0400, Graham <dtcd@mac.com> wrote:
> On 26 Jul 2004, at 12:48 am, Tim Bray wrote:
> 
> > - It is not a goal that <atom:id> be usable for retrieval of
> > information.
> >
> > (Does anyone disagree?  I'd be astounded).
> >
> > I personally think that should suffice, but I get the impression that
> > the http-identifiers-are-broken faction is asking for more.
> 
> I actually agree that the http-identifiers-are-broken group are
> overlooking that in RSS the guid doubles as the address of a
> retrievable resource, whereas in Atom it doesn't. I think that makes
> the problem already solved.
> 

I'd rather say that in Atom it shouldn't double up as address and
guid. But that's exactly the problem. Before this discussion started,
everyone either was going to do what Mark suggested in his XML.com
article or just use their current URLs. If we don't make it clear to
people to think twice before creating an ID, they will just use the
URL assuming that the user was clever enough to choose a nice scheme
for their posts (i.e. /archives/200x/02/01/etc).

> > =======================================================================
> > ===========
> > Given that HTTP URIs can be used for retrieval of information, it is
> > possible that their use in <atom:id> could lead to erroneous
> > understanding of the meaning and correct use of <atom:id>.  For this
> > reason, implementors SHOULD consider using another URI scheme (see
> > [http://www.iana.org/assignments/uri-schemes]) which does not imply
> > information-retrieval semantics, for example URNs (see [RFC2141] and
> > http://www.iana.org/assignments/urn-namespaces).
> > =======================================================================
> > ===========
> 
> Saying aggregators should never attempt retrieval of the resource at
> <id>, and that publishers don't need to point them at anything might be
> enough.
> 
> Graham
> 
> 

I'm not advocating that the IDs used cannot be resolved. I actually
would like them to be, but then again that's not the problem. The
problem is not whether something is resolvable or not, the problem is
that IDs need to behave as IDs. That is not changing and unique. So if
Dare and/or others decide to resolve LSIDs or just HTTP URLs used in
the atom:id element that's ok, what they are complaining about is that
they are not unique.

This is extremely important because as you mentioned RSS
publishers/developers are not used with coming up with unique IDs,
they in fact been using URLs for way too long and it does not work (as
per all the reasons already mentioned in this thread). If we want to
improve upon RSS we need to take a definitive step in Atom and not
brush it off with a "Generic URI" element.



From owner-atom-syntax@mail.imc.org  Mon Jul 26 13: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 NAA17126
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 13: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 i6QHg7jd051089;
	Mon, 26 Jul 2004 10:42: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 i6QHg7CW051088;
	Mon, 26 Jul 2004 10:42: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-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 i6QHg6YW051082
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 10:42:06 -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 i6QHdr53005189
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 11:39: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 <0I1G00BBLZU961@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Mon, 26 Jul 2004 11:42:09 -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 <0I1G003JPZU8L2@mail.sun.net> for atom-syntax@imc.org; Mon,
 26 Jul 2004 11:42:09 -0600 (MDT)
Date: Mon, 26 Jul 2004 10:42:21 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceItemIDIsNewsML: Struggling for compromise
In-reply-to: <905f7c9104072610267741042e@mail.gmail.com>
To: elias@torrez.us
Cc: Graham <dtcd@mac.com>, Dare Obasanjo <kpako@yahoo.com>,
        atom-syntax@imc.org, Ken MacLeod <ken@bitsko.slc.ut.us>
Message-id: <2562BE46-DF2B-11D8-8C8C-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: <20040726034817.11800.qmail@web41214.mail.yahoo.com>
 <09B394D6-DEBF-11D8-8C8C-000A95A51C9E@sun.com>
 <5CA86768-DF22-11D8-9170-000A95DC3D90@mac.com>
 <905f7c9104072610267741042e@mail.gmail.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 Jul 26, 2004, at 10:26 AM, Elias Torres wrote:

> If we don't make it clear to
> people to think twice before creating an ID, they will just use the
> URL assuming that the user was clever enough to choose a nice scheme
> for their posts (i.e. /archives/200x/02/01/etc).

Right.  And, given the right level of commitment and management 
structure, there's nothing intrinsically wrong with doing this.  But 
the discussion here has convinced me that it's highly appropriate to 
wave lots of red flags to ensure that people *do* think twice, and if 
they have misgivings about the longevity of their HTTP-space, to use 
something else.  -Tim



From owner-atom-syntax@mail.imc.org  Mon Jul 26 13:55: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 NAA17199
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 13:55: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 i6QHdcFm049898;
	Mon, 26 Jul 2004 10:39: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 i6QHdcaG049897;
	Mon, 26 Jul 2004 10:39:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QHdbtR049889
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 10:39:37 -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 i6QHdfil011483
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 11:39:41 -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 <0I1G007DOZQ45P@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Mon, 26 Jul 2004 11:39:41 -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 <0I1G003IWZQ4L2@mail.sun.net> for atom-syntax@imc.org; Mon,
 26 Jul 2004 11:39:40 -0600 (MDT)
Date: Mon, 26 Jul 2004 10:39:54 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceItemIDIsNewsML: Struggling for compromise
In-reply-to: <4104D468.3060507@dehora.net>
To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>
Cc: Dare Obasanjo <kpako@yahoo.com>, atom-syntax@imc.org,
        Ken MacLeod <ken@bitsko.slc.ut.us>
Message-id: <CDD5F915-DF2A-11D8-8C8C-000A95A51C9E@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.618)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
References: <20040726034817.11800.qmail@web41214.mail.yahoo.com>
 <09B394D6-DEBF-11D8-8C8C-000A95A51C9E@sun.com> <4104D468.3060507@dehora.net>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6QHdctR049890
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 Jul 26, 2004, at 2:52 AM, Bill de hÓra wrote:

>  For this reason, implementors SHOULD consider using  URNs

No.  For example, "tag:" is a URI scheme, not a URN namespace.  
Specifically pointing at URNs is not appropriate. -Tim




From owner-atom-syntax@mail.imc.org  Mon Jul 26 14:05: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 OAA18241
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 14: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 i6QHmGbk052485;
	Mon, 26 Jul 2004 10:48: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 i6QHmG2C052484;
	Mon, 26 Jul 2004 10:48:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QHmF9f052438
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 10:48: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 EE83E7C0F3; Mon, 26 Jul 2004 20:44:05 +0200 (CEST)
Date: Mon, 26 Jul 2004 19:52:02 +0200
To: elias@torrez.us
Subject: Re: URI scheme delusions
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <OF031774D8.BEC98F6C-ON88256EDB.00084992-88256EDB.00090B2C@us.ibm.com> <opsbm7jgwuuvpchu@quark> <41026240.8020009@intertwingly.net> <410266E4.6040304@dehora.net> <14be96d304072408524788c699@mail.gmail.com> <02F0CB0F-DD90-11D8-8C8C-000A95A51C9E@sun.com> <14be96d304072419285ec80400@mail.gmail.com> <E162E7FC-DDFE-11D8-8C8C-000A95A51C9E@sun.com> <905f7c910407251108948a64f@mail.gmail.com> <opsbpmixbkuvpchu@quark> <C2C9EB04-DE91-11D8-8C8C-000A95A51C9E@sun.com> <p06110404bd2a062c02e6@[165.121.169.136]> <41051230.4030007@intertwingly.net> <905f7c9104072609525adfbc21@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: <opsbrak0apuvpchu@quark>
In-Reply-To: <905f7c9104072609525adfbc21@mail.gmail.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Mon, 26 Jul 2004 12:52:06 -0400, Elias Torres <eliast@gmail.com> wrote:

> BTW, LSID will be registered with IANA this year after the next OMG  
> meeting:

Okay, cool.

> Unless of course we come up with our own URN scheme for Atom or decide
> for NewsML.

I think Atom should have its own URN scheme, since NewsML has the perfect  
ID syntax, but explicitly says that the NewsML URN should be used for  
NewsML resources. LSID could work, of course, but the syntax for NewsML  
URN's seems to be even stricter and better for ensuring universally  
uniqueness.

I would be happy with everything but HTTP URI's, though. All of 'tag',  
LSID and NewsML URN's would get us a lot further down Universal Unique  
Lane than HTTP URI's ever will.

-- 
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 Jul 26 14:05:36 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18293
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 14:05: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 i6QHhedV051307;
	Mon, 26 Jul 2004 10:43: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 i6QHhepj051306;
	Mon, 26 Jul 2004 10:43:40 -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 i6QHhchB051277
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 10:43:39 -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 i6QHhY53007536
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 12:43:34 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6QHhXFM007532;
	Mon, 26 Jul 2004 12:43:33 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: atom-syntax@imc.org
Subject: dereferencing atom:id
References: <20040726034817.11800.qmail@web41214.mail.yahoo.com>
	<09B394D6-DEBF-11D8-8C8C-000A95A51C9E@sun.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 26 Jul 2004 12:43:33 -0500
In-Reply-To: <09B394D6-DEBF-11D8-8C8C-000A95A51C9E@sun.com>
Message-ID: <m3d62i7jga.fsf_-_@bitsko.slc.ut.us>
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: <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> writes:

> - It is not a goal that <atom:id> be usable for retrieval of
> information.
> 
> (Does anyone disagree?  I'd be astounded).

For what it's worth, atom:id's probably will be used for retrieval,
but not by using the URI scheme as the primary access mechanism.

It will certainly be used as an internal linking identifier
(eg. PaceLinkParent), and its use for external (cross-feed) linking is
very likely as well.

At first it will only be usable in clients, but I highly suspect the
big feed services to offer URI to URI-location mapping and caching.

That would certainly be easier and more robust than always carring
around the URI name and one of many URI locators for every cross-feed
reference between entries, origins, and other Atom resources.

  -- Ken

PS. I want to emphasize this has nothing to do with the URI scheme.
Even if http: URIs were 95% dereferencable, using the ID for both
internal referencing and caching would still be used.



From owner-atom-syntax@mail.imc.org  Mon Jul 26 14:41: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 OAA23329
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 14:41: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 i6QIQWC6059349;
	Mon, 26 Jul 2004 11:26: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 i6QIQWFQ059348;
	Mon, 26 Jul 2004 11:26: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 i6QIQVuv059276
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 11:26:31 -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 586377C11E; Mon, 26 Jul 2004 21:22:24 +0200 (CEST)
Date: Mon, 26 Jul 2004 20:30:27 +0200
To: "Dare Obasanjo" <kpako@yahoo.com>
Subject: Re: PaceAtomIDIsNewsML (Requiring atom:id to be a NewsML URN)
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <20040726044426.10296.qmail@web41203.mail.yahoo.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: <opsbrcc1zguvpchu@quark>
In-Reply-To: <20040726044426.10296.qmail@web41203.mail.yahoo.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 25 Jul 2004 21:44:26 -0700 (PDT), Dare Obasanjo <kpako@yahoo.com>  
wrote:

> Ideally Atom should have normative text pointing out that items should
> have unique and *unchanging* identifiers

I agree. I've tried to hack down some specification text about this in  
PaceRecommendIdScheme[1]. Please revise it and make comments if you think  
of anything that might improve it.

> including examples that currently break in RSS today due to changing
> identifiers.

Great idea. I've always stated that the Atom specification currently  
contains too few examples (it only contains one). Since you know this  
problem space better than the most of us, could you maybe provide some?  
Just put them down on the Wiki if you will. Thanks in advanced.

____
[1] <url: http://intertwingly.net/wiki/pie/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  Mon Jul 26 14:43: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 OAA23474
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 14:43: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 i6QIPhi3059203;
	Mon, 26 Jul 2004 11:25:43 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6QIPhw8059202;
	Mon, 26 Jul 2004 11:25:43 -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 i6QIPg0G059193
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 11:25:42 -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 i6QIPe53008322
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 13:25:40 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6QIPdQf008318;
	Mon, 26 Jul 2004 13:25:39 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: <atom-syntax@imc.org>
Subject: atom:id permanence and portability testing
References: <001201c472c8$020e3e10$6400a8c0@wyman.us>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 26 Jul 2004 13:25:39 -0500
In-Reply-To: <001201c472c8$020e3e10$6400a8c0@wyman.us>
Message-ID: <m38yd67hi4.fsf@bitsko.slc.ut.us>
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


Focusing on the specific requirement that publishers preserve
identifiers, here are three tests and code review suggestions I came
up with to test atom:id recording and portability in publishing
systems.  I'll link them to the ConformanceTests page when they show
up in the atom-syntax archive.  These tests are not automatable in
general usage, but publishers could automate them for their own needs,
and others can use them manually to validate publishing systems.

These tests apply regardless of URI scheme.

ID-IS-SAME-IN-MULTIPLE-LOCATIONS

    Create an entry intended to appear in multiple locations
    (categories, cross-site syndication), note its atom:id identifier.
    Confirm the same ID appears in all locations.

    Code Review: ensure the atom:id identifier is generated in a
    manner that won't change depending on the location the entry is
    output or when transmitted to other systems (using Atom format or
    internal transmission formats).

ID-IS-SAME-AFTER-MIGRATION

    Create an entry, note its atom:id identifier.  Reconfigure the
    system or relaunch the system in a way that the URI locations that
    entries appear would change, such as new base-URI location, domain
    name change, or user name change.  Confirm that the atom:id noted
    earlier has not changed.

    Code review: ensure that the atom:id identifier is generated once
    and stored with the entry along with its other content, and the
    stored ID is used whenever the entry is output.

ID-IS-SAME-AFTER-IMPORTING

    If the publishing system supports importing of Atom
    archives/feeds, load the Atom test case [[note to editor:
    reference test case]].  Confirm that the atom:id in output is
    [[note to editor: copy atom:id from test case]].

    Code review: ensure that imported atom:id identifiers are stored
    with the entry and the stored ID is used whenever the entry is
    output.  Note that there is no a priori limit on the length of a
    URI, so a variable length storage field is most appropriate; if a
    fixed length must be used, consider making it configurable at
    install and/or run-time, and ensure that the length of imported
    URIs does not exceed the configured length.



From owner-atom-syntax@mail.imc.org  Mon Jul 26 14:45: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 OAA23674
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 14:45: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 i6QIVYl9061378;
	Mon, 26 Jul 2004 11: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 i6QIVYij061377;
	Mon, 26 Jul 2004 11:31:34 -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 i6QIVXPA061368
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 11:31:34 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 77409 messnum 380526 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 26 Jul 2004 18:31:32 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.183?) (83.70.33.112)
  by mail05.svc.cra.dublin.eircom.net (qp 77409) with SMTP; 26 Jul 2004 18:31:32 -0000
Message-ID: <41054E03.7050502@dehora.net>
Date: Mon, 26 Jul 2004 19:31:31 +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: Tim Bray <Tim.Bray@Sun.COM>
CC: Dare Obasanjo <kpako@yahoo.com>, atom-syntax@imc.org,
        Ken MacLeod <ken@bitsko.slc.ut.us>
Subject: Re: PaceItemIDIsNewsML: Struggling for compromise
References: <20040726034817.11800.qmail@web41214.mail.yahoo.com> <09B394D6-DEBF-11D8-8C8C-000A95A51C9E@sun.com> <4104D468.3060507@dehora.net> <CDD5F915-DF2A-11D8-8C8C-000A95A51C9E@sun.com>
In-Reply-To: <CDD5F915-DF2A-11D8-8C8C-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:
> On Jul 26, 2004, at 2:52 AM, Bill de hÓra wrote:
> 
>>  For this reason, implementors SHOULD consider using  URNs
> 
> 
> No.  For example, "tag:" is a URI scheme, not a URN namespace.  
> Specifically pointing at URNs is not appropriate. -Tim

Good catch.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Mon Jul 26 16: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 QAA07777
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 16: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 i6QKEuxM076456;
	Mon, 26 Jul 2004 13:14: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 i6QKEuNt076455;
	Mon, 26 Jul 2004 13:14:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from vspmail.nscp.aoltw.net (h-64-236-139-249.aoltw.net [64.236.139.249])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QKEtt2076430
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 13:14:55 -0700 (PDT)
	(envelope-from jpanzer@AOL.NET)
Received: from h-10-169-146-121.nscp.aoltw.net (h-10-169-146-121.nscp.aoltw.net [10.169.146.121])
	by vspmail.nscp.aoltw.net (8.11.6/8.11.6) with ESMTP id i6QKKAs18013;
	Mon, 26 Jul 2004 13:20:10 -0700
Date: Mon, 26 Jul 2004 13:14:49 -0700
From: "John Panzer" <jpanzer@aol.net>
Subject: Re: dereferencing atom:id
To: "Ken MacLeod" <ken@bitsko.slc.ut.us>
cc: atom-syntax@imc.org
In-Reply-To: <m3d62i7jga.fsf_-_@bitsko.slc.ut.us>
Message-ID: <41056639.4050300@AOL.NET>
References: <20040726034817.11800.qmail@web41214.mail.yahoo.com> <09B394D6-DEBF-11D8-8C8C-000A95A51C9E@sun.com> <m3d62i7jga.fsf_-_@bitsko.slc.ut.us>
X-Mailer: AOL Communicator (20030919.3 Win)
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>


Ken MacLeod wrote on 7/26/2004, 10:43 AM:

 >
 > Tim Bray <Tim.Bray@Sun.COM> writes:
 >
 > > - It is not a goal that <atom:id> be usable for retrieval of
 > > information.
 > >
 > > (Does anyone disagree?  I'd be astounded).
 >
 > For what it's worth, atom:id's probably will be used for retrieval,
 > but not by using the URI scheme as the primary access mechanism.
 >
 > It will certainly be used as an internal linking identifier
 > (eg. PaceLinkParent), and its use for external (cross-feed) linking is
 > very likely as well.
 >
 > At first it will only be usable in clients, but I highly suspect the
 > big feed services to offer URI to URI-location mapping and caching.

It sounds like you're saying that dereferenceability (d16y?) would be an 
add-on extension rather than something needed by the protocol, right?

So any cross-references that someone would typically need to dereference 
would _not_ use atom:id, or at least would require a URI-location as well?

 >
 > That would certainly be easier and more robust than always carring
 > around the URI name and one of many URI locators for every cross-feed
 > reference between entries, origins, and other Atom resources.
 >

Easier for the clients, anyway.  I'll just note this:  It's nontrivial 
for a server to provide an efficient, scalable id lookup service for 
abitrary unique string keys which are not under server control.  Not a 
huge problem, by any means, but it's certainly a layer that doesn't 
exist today for our product and would need to be built.

-John



From owner-atom-syntax@mail.imc.org  Mon Jul 26 16:54: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 QAA09541
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 16:54: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 i6QKjScO079833;
	Mon, 26 Jul 2004 13:45:28 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6QKjSFY079832;
	Mon, 26 Jul 2004 13:45:28 -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 i6QKjS2E079821
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 13:45:28 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040726204525.78872.qmail@web41210.mail.yahoo.com>
Received: from [67.170.36.74] by web41210.mail.yahoo.com via HTTP; Mon, 26 Jul 2004 13:45:25 PDT
Date: Mon, 26 Jul 2004 13:45:25 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: PaceAtomIDIsNewsML (Requiring atom:id to be a NewsML URN)
To: "Asbjørn_Ulsberg" <asbjorn@tigerstaden.no>
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <opsbrcc1zguvpchu@quark>
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>


--- Asbjørn_Ulsberg <asbjorn@tigerstaden.no> wrote:
> On Sun, 25 Jul 2004 21:44:26 -0700 (PDT), Dare
> Obasanjo <kpako@yahoo.com>  
> wrote:
> 
> > Ideally Atom should have normative text pointing
> out that items should
> > have unique and *unchanging* identifiers
> 
> I agree. I've tried to hack down some specification
> text about this in  
> PaceRecommendIdScheme[1]. Please revise it and make
> comments if you think  
> of anything that might improve it.

I'm busy today and tomorrow. If no one has helped with
this Pace by Wednesday I'll give it a whirl.

> > including examples that currently break in RSS
> today due to changing
> > identifiers.
> 
> Great idea. I've always stated that the Atom
> specification currently  
> contains too few examples (it only contains one).
> Since you know this  
> problem space better than the most of us, could you
> maybe provide some?  
> Just put them down on the Wiki if you will. Thanks
> in advanced.

Ditto. 

=====
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  Mon Jul 26 19:27: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 TAA20042
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 19:27: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 i6QNGPHn097650;
	Mon, 26 Jul 2004 16:16:25 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6QNGPul097649;
	Mon, 26 Jul 2004 16:16:25 -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 i6QNGM3G097633
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 16:16:24 -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 i6QNGM6i027483;
	Mon, 26 Jul 2004 19:16: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 BKE54402 (AUTH bob@wyman.us);
	Mon, 26 Jul 2004 19:16:20 -0400 (EDT)
Message-Id: <200407262316.BKE54402@ms8.netsolmail.com>
Reply-To: <bob@wyman.us>
From: "Bob Wyman" <bob@wyman.us>
To: "'Tim Bray'" <Tim.Bray@Sun.COM>,
        "=?iso-8859-1?Q?'Bill_de_h=D3ra'?=" <bill@dehora.net>
Cc: "'Dare Obasanjo'" <kpako@yahoo.com>, <atom-syntax@imc.org>,
        "'Ken MacLeod'" <ken@bitsko.slc.ut.us>
Subject: RE: PaceItemIDIsNewsML: Struggling for compromise
Date: Mon, 26 Jul 2004 19:16:20 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <CDD5F915-DF2A-11D8-8C8C-000A95A51C9E@sun.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Thread-Index: AcRzOxg6suXjXJz5R/iMXwNJDuU+BQAKrILg
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 sent mail to Tim Kindberg, author of the Tag ID, to check on the status of
Tag. The following is his response (published with his permission):

"We are continuing to push for registration -- especially because Atom has
been tending towards using tags and YAML has adopted them."

"It's absurd that newsml has been registered but tag hasn't. The
registration process is notoriously broken. Larry Masinter has organised a
BOF session for the next IETF meeting (around 1st August) which will
consider, among other things, why certain schemes including ours are not
getting anywhere. No reason has been given for the lack of progress. We're
busy people and have sometimes been a little slow to get the next draft out
but we've done everything asked of us."

"Tags have been endlessly debated but before now we've been missing a user
community to back us up. If representatives of the Atom community were to
send out a message to uri@w3.org, cc Ted Hardie, the IETF area director,
saying you want to use tags but need the scheme to be recognised, that could
only help."

"Cheers, Tim."

	From this, it sounds like those who would prefer tag to NewsML and
who are attending the IETF meeting should consider attending the BOF to
encourage progress on tag adoption.

		bob wyman




From owner-atom-syntax@mail.imc.org  Mon Jul 26 20: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 UAA21745
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 20: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 i6QNkvrH000532;
	Mon, 26 Jul 2004 16:46:57 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6QNkvd9000531;
	Mon, 26 Jul 2004 16:46: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-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 i6QNkuIw000525
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 16:46:56 -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 i6QNl2il011562
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 17:47: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 <0I1H00KEPGQDTR@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Mon, 26 Jul 2004 17:47:02 -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 <0I1H00EVYGQCXB@mail.sun.net> for atom-syntax@imc.org; Mon,
 26 Jul 2004 17:47:01 -0600 (MDT)
Date: Mon, 26 Jul 2004 16:47:14 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceItemIDIsNewsML: Struggling for compromise
In-reply-to: <200407262316.BKE54402@ms8.netsolmail.com>
To: bob@wyman.us
Cc: "=?ISO-8859-1?Q?'Bill_de_h=D3ra'?=" <bill@dehora.net>,
        "'Dare Obasanjo'" <kpako@yahoo.com>, atom-syntax@imc.org,
        "'Ken MacLeod'" <ken@bitsko.slc.ut.us>
Message-id: <1F25CA88-DF5E-11D8-8C8C-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: <200407262316.BKE54402@ms8.netsolmail.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 Jul 26, 2004, at 4:16 PM, Bob Wyman wrote:

> 	From this, it sounds like those who would prefer tag to NewsML and
> who are attending the IETF meeting should consider attending the BOF to
> encourage progress on tag adoption.

Hmm, I note that the TAG URI home page states 
[http://www.taguri.org/#whoIsUsing] that "Tags are used to identify 
blog items in the  Atom personal publishing standard,  as in this 
example." (points at http://www.intertwingly.net/wiki/pie/IdElement?)  
-Tim



From owner-atom-syntax@mail.imc.org  Mon Jul 26 20: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 UAA22137
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 20: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 i6QNx4jx001808;
	Mon, 26 Jul 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 i6QNx40J001807;
	Mon, 26 Jul 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 mta05-svc.ntlworld.com (mta05-svc.ntlworld.com [62.253.162.45])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6QNx3qo001797
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 16:59:03 -0700 (PDT)
	(envelope-from djpowell@djpowell.net)
Received: from cpc1-stke1-5-0-cust6.bagu.cable.ntl.com ([81.97.134.6])
          by mta05-svc.ntlworld.com
          (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP
          id <20040726235651.TSWP9796.mta05-svc.ntlworld.com@cpc1-stke1-5-0-cust6.bagu.cable.ntl.com>
          for <atom-syntax@imc.org>; Tue, 27 Jul 2004 00:56:51 +0100
Date: Tue, 27 Jul 2004 00:59:00 +0100
From: David Powell <djpowell@djpowell.net>
X-Mailer: The Bat! (v2.12 RC/4) Business
Reply-To: David Powell <djpowell@djpowell.net>
X-Priority: 3 (Normal)
Message-ID: <834420551.20040727005900@djpowell.net>
To: atom-syntax@imc.org
Subject: Relative URI references
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


I've got a couple of questions about relative URIs in Atom:

Atom defines all of it's URI-ish elements to contain URIs. If XML Base
processing is to be applied to these elements, then don't they need to
be defined as URI references, rather than URIs?


Also, what is supposed to happen if relative URI references are used
in places where xml:base isn't in scope?

If relative URIs outside of the scope of xml:base are present in PUT
and POST requests, what are they relative to? The PostURI?, the
FeedURI?, the EditURI?  Or are they not allowed?

-- 
Dave



From owner-atom-syntax@mail.imc.org  Mon Jul 26 20:37:34 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23345
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 20: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 i6R0PKR2004146;
	Mon, 26 Jul 2004 17:25: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 i6R0PKf2004145;
	Mon, 26 Jul 2004 17:25:20 -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 i6R0PJ9i004138
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 17:25:20 -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 i6R0PPh8016645;
	Mon, 26 Jul 2004 20:25:25 -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 BKE74429 (AUTH bob@wyman.us);
	Mon, 26 Jul 2004 20:25:24 -0400 (EDT)
Message-Id: <200407270025.BKE74429@ms8.netsolmail.com>
Reply-To: <bob@wyman.us>
From: "Bob Wyman" <bob@wyman.us>
To: "'Tim Bray'" <Tim.Bray@Sun.COM>
Cc: <atom-syntax@imc.org>
Subject: RE: PaceItemIDIsNewsML: Struggling for compromise
Date: Mon, 26 Jul 2004 20:25: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
In-Reply-To: <CDD5F915-DF2A-11D8-8C8C-000A95A51C9E@sun.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Thread-Index: AcRzOxg6suXjXJz5R/iMXwNJDuU+BQAAFh3Q
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:
> No.  For example, "tag:" is a URI scheme, not a URN namespace.  
> Specifically pointing at URNs is not appropriate. -Tim
	Tim, forgive me for obviously missing something here... Could you
please explain why "pointing at URNs is not appropriate." I don't get it.
Please accept my apology if this is a really stupid question.

		bob wyman




From owner-atom-syntax@mail.imc.org  Mon Jul 26 23:53: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 XAA01613
	for <atompub-archive@lists.ietf.org>; Mon, 26 Jul 2004 23:53: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 i6R3eMmu025662;
	Mon, 26 Jul 2004 20:40: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 i6R3eMZv025661;
	Mon, 26 Jul 2004 20:40: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 i6R3eKA8025655
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 20:40:20 -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 i6R3eRil027807
	for <atom-syntax@imc.org>; Mon, 26 Jul 2004 21:40:27 -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 <0I1H0003ORJE2B@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Mon, 26 Jul 2004 21:40:27 -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 <0I1H003GWRJEL2@mail.sun.net> for atom-syntax@imc.org; Mon,
 26 Jul 2004 21:40:26 -0600 (MDT)
Date: Mon, 26 Jul 2004 20:40:41 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Relative URI references
In-reply-to: <834420551.20040727005900@djpowell.net>
To: David Powell <djpowell@djpowell.net>
Cc: atom-syntax@imc.org
Message-id: <BB9A9F4A-DF7E-11D8-8C8C-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: <834420551.20040727005900@djpowell.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 Jul 26, 2004, at 4:59 PM, David Powell wrote:

> Atom defines all of it's URI-ish elements to contain URIs. If XML Base
> processing is to be applied to these elements, then don't they need to
> be defined as URI references, rather than URIs?

In 2396classic terms, you're absolutely right.  Have to check 2396bis.

> Also, what is supposed to happen if relative URI references are used
> in places where xml:base isn't in scope?

2396 specifies a hierarchy of ways that you can go about establishing a 
base URI.  While it seems obvious that these apply to Atom, it would 
probably be beneficial to say so explicitly in the drafts.

> If relative URIs outside of the scope of xml:base are present in PUT
> and POST requests, what are they relative to? The PostURI?, the
> FeedURI?, the EditURI?  Or are they not allowed?

Urgh, good questions.  Did you just volunteer to suggest some draft 
language? -Tim



From owner-atom-syntax@mail.imc.org  Tue Jul 27 03: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 DAA26181
	for <atompub-archive@lists.ietf.org>; Tue, 27 Jul 2004 03:55: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 i6R7h0kq006666;
	Tue, 27 Jul 2004 00:43: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 i6R7h0Gf006665;
	Tue, 27 Jul 2004 00:43:00 -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 i6R7gwaA006570
	for <atom-syntax@imc.org>; Tue, 27 Jul 2004 00:42:59 -0700 (PDT)
	(envelope-from laurent.lemeur@afp.com)
Received: from alox.afp.com (unknown [158.50.165.141])
	by smtp1.afp.com (Sendmail) with ESMTP
	id 889124698D; Tue, 27 Jul 2004 09:41:17 +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 i6R7eJt6026303;
	Tue, 27 Jul 2004 09:40:20 +0200 (METDST)
From: "Laurent Le Meur" <laurent.lemeur@afp.com>
To: "'Julian Reschke'" <julian.reschke@gmx.de>, <atom-syntax@imc.org>
Cc: <newsml@yahoogroups.com>
Subject: RE : PaceItemIDIsNewsML: Struggling for compromise
Date: Tue, 27 Jul 2004 09:40:16 +0200
Message-ID: <002f01c473ac$fad50490$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
Importance: Normal
In-Reply-To: <4104ABC5.4010409@gmx.de>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-MailScanner: Found to be clean
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6R7gxaA006657
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 followed the discussion and will just add a quick comment as a former
participant to the creation of the NewsML URN.

The requirement (please see http://www.newsml.org/pages/intro_newsml2.php if
you want to read the complete NewsML requirements, recently written during
the study of the totally revamped NewsML 2) is expressed as follows:
 	
Identification
1) Each news-item MUST have a globally unique identifier, i.e. an identifier
that is unique, unambiguous and permanent. 
2) This news-item globally unique identifier MUST take the form of a URN.
3) The globally unique identifier of a news-item MUST be independent of its
physical representation.

Globally unique identifiers are defined as: An identifier that is unique,
unambiguous, and permanent. Being unique and unambiguous means that there is
a 1:1 relationship between the identifier and the identified object. Being
permanent means that its value never changes when time passes, and is never
reused as an identifier for another object even if the original object
disappears.

The IPTC decided to create globally unique identifiers in the form of URNs
in order to avoid the usual ambiguity between an id and a locator (it has
been discussed extensively here). 

We knew that this had more to do with "good practices" than technical
features. The main interest of the NewsML URN is effectively that it gives
providers a *recipe* for globally unique ids creation. It is easy: no
specific central body is needed for the affectation of provider ids, as
internet domain names are used. As news archives are important, the fact
that a domain name ownership can change is taken into account. As in the
case of the Tag URIs, it uses the association of a domain name and a date
(it is a full ISO date/time stamp, but a year could usually be sufficient)
to get an unambiguous provider id. As revisions are an important part of
news handling (atom will certainly also go there some day), the NewsML URN
also use revision ids.

And it works well, for the main news providers worldwide, for 3 years now. 

Certainly Atom should not require a specific URI scheme; I see at least one
specific reason for this: an Atom item may be created out of another form of
item, maybe a NewsML news item, and we should be able to keep the guid
across the change of format.

But as Julian says, the specs could show the use of a good URI scheme via
samples. As the IPTC has already thought about a modification of the wording
of the RFC3085 (there is an ambiguity in some wording), removing the express
association between this URN and NewsML NewsItems could perhaps be studied
by the IPTC, if NewsML URN are of interest for a broad range of users. 

Laurent Le Meur
NewsML WG chairman
Agence France Presse
 

  > -----Message d'origine-----
  > De : owner-atom-syntax@mail.imc.org [mailto:owner-atom-
  > syntax@mail.imc.org] De la part de Julian Reschke
  > Envoyé : lundi 26 juillet 2004 08:59
  > À : Tim Bray
  > Cc : atom-syntax@imc.org
  > Objet : Re: PaceItemIDIsNewsML: Struggling for compromise
  > 
  > 
  > Hi,
  > 
  > maybe looking at other IETF specs for guidance would be of interest.
  > 
  > WebDAV (RFC2518) uses URIs to identify locks. The so-called "lock
  > tokens" URIs "...MUST be unique across all resources for all time"
  > (<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.6.3>). So
  > this is a very similar problem.
  > 
  > Solution:
  > 
  > 1) cleanly spell out the uniqueness requirement, but say that *any* URI
  > scheme will do as long as this requirement is fulfilled
  > 
  > 2) recommend *one* specific scheme that works fine, and use that one
  > through the examples
  > 
  > 1) ensures that people how want HTTP URLs can actually use them (or
  > something else). 2) helps those who are unsure and just want a reliable
  > solution without having to think too much about the details.
  > 
  > Julian
  > 
  > --
  > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760




From owner-atom-syntax@mail.imc.org  Tue Jul 27 10:44: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 KAA18139
	for <atompub-archive@lists.ietf.org>; Tue, 27 Jul 2004 10:44:37 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6RETjIs047124;
	Tue, 27 Jul 2004 07: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 i6RETj73047123;
	Tue, 27 Jul 2004 07:29:45 -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 i6RETiNM047114
	for <atom-syntax@imc.org>; Tue, 27 Jul 2004 07:29:44 -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 i6RETS6o025754;
	Tue, 27 Jul 2004 10:29:30 -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 BKG93925 (AUTH bob@wyman.us);
	Tue, 27 Jul 2004 10:29:28 -0400 (EDT)
Message-Id: <200407271429.BKG93925@ms8.netsolmail.com>
Reply-To: <bob@wyman.us>
From: "Bob Wyman" <bob@wyman.us>
To: "'Laurent Le Meur'" <laurent.lemeur@afp.com>,
        "'Julian Reschke'" <julian.reschke@gmx.de>, <atom-syntax@imc.org>
Cc: <newsml@yahoogroups.com>
Subject: RE: PaceItemIDIsNewsML: Struggling for compromise
Date: Tue, 27 Jul 2004 10:29:29 -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: <002f01c473ac$fad50490$67b4329e@afp.local>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Thread-Index: AcRzsEAYIGwnyHgfT0iO6aaVXWR3OwAL+R5w
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


Laurent Le Meur wrote:
> an Atom item may be created out of another form of
> item, maybe a NewsML news item, and we should be able
> to keep the guid across the change of format.
	A common case of needing to import an identifier into an Atom
document arises whenever an RSS feed is converted to an Atom feed or
whenever one or more items from an RSS feed are inserted into an Atom feed. 
	If the Atom spec requires (as I proposed in PaceItemIDIsNewsML) that
the id MUST be of one form or another, then it will be necessary for tools
to create new and conformant ids for "foreign" items that are imported or
converted. This would be unfortunate since it is unlikely that different
synthesizers would agree on the precise method for improvising ids for
foreign items/entries. Thus, we would have duplicates flowing through the
system which had different ids. Over time, as Atom becomes the dominant
format, this problem would slowly evaporate, however, I think we need to be
prepared for a long transition from RSS to Atom. Also, we need to recognize
that even if RSS were to be completely replaced by Atom, we would still have
many entries that are sourced from feeds such as NewsML, NNTP newsfeeds,
etc.
	It seems that atom:id should permit any URI, if only to ensure that
items can be imported from non-Atom sources with minimal loss of
information. However, I think it is still important that we attempt to
achieve as much consistency as possible in the ids that are generated for
native Atom encodings. Thus, I would argue that the specification should say
that "An atom id SHOULD be a NewsML [Tag, or whatever] URN/URI" in order to
encourage that consistency.
	An alternative would be to provide a means by which a "native"
atom:id can be distinguished from one which is not native. This could be
done with an attribute as in:

	<id type="foreign">ISBN:97898709870</id>

Or, the rule could simply be that if an id did not conform to the native
Atom format, it should be treated as foreign. If NewsML or Tag was the
"native" format, Atom would prohibit foreign ids that started with either
"urn:newsml:" or "tag:" and declare that any id that did not start with
those characters was to be considered "foreign" and thus treated differently
from a native id. For a native id, a duplicate detecting algorithm might
trust the combination of atom:id and atom:updated (or some similar date) to
determine uniqueness. With a foreign id, one might also do textual analysis
when determining uniqueness.

		bob wyman



From owner-atom-syntax@mail.imc.org  Tue Jul 27 11:07: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 LAA19781
	for <atompub-archive@lists.ietf.org>; Tue, 27 Jul 2004 11:07: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 i6REtnVZ052702;
	Tue, 27 Jul 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 i6REtnDh052701;
	Tue, 27 Jul 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 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 i6REtmYZ052690
	for <atom-syntax@imc.org>; Tue, 27 Jul 2004 07:55:48 -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 i6REtj53024556
	for <atom-syntax@imc.org>; Tue, 27 Jul 2004 09:55:45 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6REtikf024552;
	Tue, 27 Jul 2004 09:55:44 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Text in atom:feed
References: <200407191919.PAA17914@ietf.org> <873c3nu0kp.fsf@nwalsh.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 27 Jul 2004 09:55:44 -0500
In-Reply-To: <873c3nu0kp.fsf@nwalsh.com>
Message-ID: <m3oem15wjz.fsf@bitsko.slc.ut.us>
Lines: 20
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


Norman Walsh <ndw@nwalsh.com> writes:

> | 4.  The "atom:feed" Element
> | 
> |    The "atom:feed" element is the document (i.e., top-level)
> |    element of an Atom Feed Document, acting as a container for
> |    metadata and data associated with the feed.  Its first element
> |    child MUST be atom:head, which MAY be followed zero or more
> |    atom:entry child elements.
> 
> I don't think this description goes far enough to forbid text
> content in atom:feed, which I think should be forbidden. Do we agree
> it should be forbidden?

+1, but I note that there are several constructs where text should not
be allowed.  Can we make a general requirement in "2. Atom Documents",
where we provide general XML processing, that text is *only* allowed
where explicitly specified?

  -- Ken



From owner-atom-syntax@mail.imc.org  Tue Jul 27 11:19: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 LAA20674
	for <atompub-archive@lists.ietf.org>; Tue, 27 Jul 2004 11:19: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 i6RFAPiA055881;
	Tue, 27 Jul 2004 08:10: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 i6RFAPJt055880;
	Tue, 27 Jul 2004 08:10: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 i6RFANHa055873
	for <atom-syntax@imc.org>; Tue, 27 Jul 2004 08:10:24 -0700 (PDT)
	(envelope-from eliast@gmail.com)
Received: by mproxy.gmail.com with SMTP id 79so148125rnk
        for <atom-syntax@imc.org>; Tue, 27 Jul 2004 08:10:25 -0700 (PDT)
Received: by 10.38.74.13 with SMTP id w13mr389rna;
        Tue, 27 Jul 2004 08:10:16 -0700 (PDT)
Message-ID: <905f7c9104072708107c5dc127@mail.gmail.com>
Date: Tue, 27 Jul 2004 11:10:00 -0400
From: Elias Torres <eliast@gmail.com>
Reply-To: elias@torrez.us
To: bob@wyman.us
Subject: Re: PaceItemIDIsNewsML: Struggling for compromise
Cc: Laurent Le Meur <laurent.lemeur@afp.com>,
        Julian Reschke <julian.reschke@gmx.de>, atom-syntax@imc.org,
        newsml@yahoogroups.com
In-Reply-To: <200407271429.BKG93925@ms8.netsolmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <200407271429.BKG93925@ms8.netsolmail.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


My group in IBM has been helping many organizations with large amounts
of data migrate to an LSID identification scheme and this has not been
a problem. If we are going to recommend atom:id must be of a specific
format, then we should.

For example, let's say I have several wordpress databases, one for
each blog. Wordpress only uses an integer for the id of the entry.
Then what we always do is create a mapping to the new ids w/o having
to change their existing structure (columns). Again, this is only
works in the case where the id cannot change (opposed to date columns
in blog dbs).

urn:lsid:torrez.us:blog:1 where blog maps to mySQL db torrez_wp and
row with ID 1.

Now let's say somebody already is using a NewsML identifier or
another. The fact is that most identifiers have within their
environment a unique id.  For example:

urn:newsml:reuters.com:20000206:IIMFFH05643_2000-02-06_17-54-01_L06156584:1U

would get translated to:

urn:lsid[*]:reuters.com:20000206:IIMFFH05643_2000-02-06_17-54-01_L06156584:1U

Then, if they wanted to keep their newsml urn they would store as
extra data under their own namespace or a common extension namespace
for that matter. Because they need to know what that entry maps to in
their existing systems, unless they can derive the same thing from the
LSID for example. Most likely News dbs don't store the whole urn as
their id in the db. The urn is generated from an internal private key.

The point is that if we are going to the whole trouble of discussing a
scheme for IDs, let really solve the problem so everyone can
cross-link "Atom" feeds uniformly and can get more information from
the id than just a strcmp() result and get stuff like resolving for
example.

[*] or whatever scheme the group decides.

Elias Torres

On Tue, 27 Jul 2004 10:29:29 -0400, Bob Wyman <bob@wyman.us> wrote:
> 
> Laurent Le Meur wrote:
> > an Atom item may be created out of another form of
> > item, maybe a NewsML news item, and we should be able
> > to keep the guid across the change of format.
>         A common case of needing to import an identifier into an Atom
> document arises whenever an RSS feed is converted to an Atom feed or
> whenever one or more items from an RSS feed are inserted into an Atom feed.
>         If the Atom spec requires (as I proposed in PaceItemIDIsNewsML) that
> the id MUST be of one form or another, then it will be necessary for tools
> to create new and conformant ids for "foreign" items that are imported or
> converted. This would be unfortunate since it is unlikely that different
> synthesizers would agree on the precise method for improvising ids for
> foreign items/entries. Thus, we would have duplicates flowing through the
> system which had different ids. Over time, as Atom becomes the dominant
> format, this problem would slowly evaporate, however, I think we need to be
> prepared for a long transition from RSS to Atom. Also, we need to recognize
> that even if RSS were to be completely replaced by Atom, we would still have
> many entries that are sourced from feeds such as NewsML, NNTP newsfeeds,
> etc.
>         It seems that atom:id should permit any URI, if only to ensure that
> items can be imported from non-Atom sources with minimal loss of
> information. However, I think it is still important that we attempt to
> achieve as much consistency as possible in the ids that are generated for
> native Atom encodings. Thus, I would argue that the specification should say
> that "An atom id SHOULD be a NewsML [Tag, or whatever] URN/URI" in order to
> encourage that consistency.
>         An alternative would be to provide a means by which a "native"
> atom:id can be distinguished from one which is not native. This could be
> done with an attribute as in:
> 
>         <id type="foreign">ISBN:97898709870</id>
> 
> Or, the rule could simply be that if an id did not conform to the native
> Atom format, it should be treated as foreign. If NewsML or Tag was the
> "native" format, Atom would prohibit foreign ids that started with either
> "urn:newsml:" or "tag:" and declare that any id that did not start with
> those characters was to be considered "foreign" and thus treated differently
> from a native id. For a native id, a duplicate detecting algorithm might
> trust the combination of atom:id and atom:updated (or some similar date) to
> determine uniqueness. With a foreign id, one might also do textual analysis
> when determining uniqueness.
> 
>                 bob wyman
> 
>



From owner-atom-syntax@mail.imc.org  Tue Jul 27 11:32: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 LAA22121
	for <atompub-archive@lists.ietf.org>; Tue, 27 Jul 2004 11:32: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 i6RFK6B1058215;
	Tue, 27 Jul 2004 08:20:06 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6RFK6pr058214;
	Tue, 27 Jul 2004 08:20:06 -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 i6RFK5vw058208
	for <atom-syntax@imc.org>; Tue, 27 Jul 2004 08:20:06 -0700 (PDT)
	(envelope-from distobj@acm.org)
Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian))
	id 1BpTl4-0000JZ-00; Tue, 27 Jul 2004 11:20:50 -0400
Date: Tue, 27 Jul 2004 11:20:50 -0400
To: Sam Ruby <rubys@intertwingly.net>
Cc: atom-syntax@imc.org
Subject: Re: What is Wrong with HTTP URIs (Was Re: URI scheme delusions)
Message-ID: <20040727152050.GI30868@markbaker.ca>
References: <20040726020754.82924.qmail@web41210.mail.yahoo.com> <001201c4730b$6a1cbfc0$200ca8c0@wkearney.com> <4105005A.1080807@intertwingly.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4105005A.1080807@intertwingly.net>
User-Agent: Mutt/1.3.28i
From: Mark Baker <distobj@acm.org>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


On Mon, Jul 26, 2004 at 09:00:10AM -0400, Sam Ruby wrote:
> I believe that Dare's point (and perhaps Bob's) is that changing the 
> prefix will make people stop and think.  And given experience with how 
> rdf:about is used in RSS 1.0 today, and how guid is used in RSS 2.0 
> today, he is not sure that would be a bad thing.
> 
> That goal (make people think) is worthy.  Whether that goal can be 
> achieved by documentation, requiring NewsML scheme, or even simply 
> inventing a scheme named "ptth" which is exactly identical to http 
> except that the name of the scheme is spelled backwards is what we 
> should be talking about.

+1 to using documentation.  -1 to the other options.

/me contemplates a "How to build persistent, dereferencable identifiers"
BCP.

Mark.



From owner-atom-syntax@mail.imc.org  Tue Jul 27 12: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 MAA24714
	for <atompub-archive@lists.ietf.org>; Tue, 27 Jul 2004 12:05: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 i6RFm4vK064729;
	Tue, 27 Jul 2004 08:48: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 i6RFm4Xm064728;
	Tue, 27 Jul 2004 08:48:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from dumle.webhuset.no (dumle.webhuset.no [81.27.32.66])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6RFm3Qk064702
	for <atom-syntax@imc.org>; Tue, 27 Jul 2004 08:48:03 -0700 (PDT)
	(envelope-from arve@virtuelvis.com)
Message-Id: <200407271548.i6RFm3Qk064702@above.proper.com>
Received: (qmail 5354 invoked from network); 27 Jul 2004 15:46:21 -0000
Received: from unknown (HELO localhost.localdomain) (81.27.34.19)
  by 0 with SMTP; 27 Jul 2004 15:46:21 -0000
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
MIME-Version: 1.0
From: "Arve Bersvendsen" <arve@virtuelvis.com>
To: atom-syntax@imc.org
Subject: Input formats for editing API
Date: Tue, 27 Jul 2004 17:48:00 +0200
X-Mailer: WHMail 1.0 (http://www.webhuset.no)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6RFm4Qk064723
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


Ok. Possible headache: 

An Atom-enabled editing client, could possibly signal that it understands for
instance Textile or any other "humane text" system, using a mechanism like
HTTP Accept and a x-prefixed pseudo-mimetype:

Accept: application/xhtml+xml; q=0.5, text/x-textile; q=0.8,
application/atom+xml

The problem is going the other way: How can/should an Atom-enabled server
indicate which mime- or pseudo-mime-types it understand.

-- 
Arve Bersvendsen



From owner-atom-syntax@mail.imc.org  Tue Jul 27 14: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 OAA03352
	for <atompub-archive@lists.ietf.org>; Tue, 27 Jul 2004 14: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 i6RI28nD094963;
	Tue, 27 Jul 2004 11: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 i6RI289P094950;
	Tue, 27 Jul 2004 11:02: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 i6RI24kj094870
	for <atom-syntax@imc.org>; Tue, 27 Jul 2004 11:02: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 C47787C0F3; Tue, 27 Jul 2004 20:57:39 +0200 (CEST)
Date: Tue, 27 Jul 2004 20:05:45 +0200
To: "Dare Obasanjo" <kpako@yahoo.com>
Subject: Re: PaceDateline
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <20040725210402.56030.qmail@web41214.mail.yahoo.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: <opsbs5vvfhuvpchu@quark>
In-Reply-To: <20040725210402.56030.qmail@web41214.mail.yahoo.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 25 Jul 2004 14:04:02 -0700 (PDT), Dare Obasanjo <kpako@yahoo.com>  
wrote:

> RSS Bandit does not visually identify modifications and the like because
> it is not functionality I have found desirable nor is it something that
> the several thousand people who've used RSS Bandit or the hundreds of
> people who've submitted feature requests and bug reports have ever asked
> for.

I think that a feature like this is primarily interesting from a  
publisher's point of view, not a consumer. That's why you probably haven't  
seen this as a feature request in RSS Bandit.

As Atom is going to fulfill (at least I hope so) both producer's and  
consumer's wishes, Atom may need to support revisioning some day. How and  
when is still to be sorted out, but it _may_ be that ID's will change for  
each new version of an entry. This is to accommodate producer's needs. As  
users subscribe to more and more feeds that shows duplicate entries,  
because their RSS aggregator doesn't support Atom's revisioning mechanism,  
they will report this to the aggregator developers, e.g. you.

Would you build support for a revisioning model into RSS Bandit before, or  
only after, users make requests for 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  Tue Jul 27 16:24: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 QAA11598
	for <atompub-archive@lists.ietf.org>; Tue, 27 Jul 2004 16:24: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 i6RKF8Yi026612;
	Tue, 27 Jul 2004 13:15:08 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6RKF8Mi026611;
	Tue, 27 Jul 2004 13:15: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 i6RKF703026594
	for <atom-syntax@imc.org>; Tue, 27 Jul 2004 13:15: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 723FC7C0F3; Tue, 27 Jul 2004 23:10:49 +0200 (CEST)
Date: Tue, 27 Jul 2004 22:19:24 +0200
To: "Roger B." <roger@agincourtmedia.com>
Subject: Re: Date Options Analysis: Issued
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <D72A9E13D73D4464964DA4DED2881E.MAI@journurl.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: <opsbtb2mnquvpchu@quark>
In-Reply-To: <D72A9E13D73D4464964DA4DED2881E.MAI@journurl.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 25 Jul 2004 20:56:37 -0500, Roger B. <roger@agincourtmedia.com>  
wrote:

> Bill: I haven't seen any Blogger, MT, TypePad, or LJ blogs supplying the
> immutable issued upon which we seem to have settled. Adding it up, we're
> getting into "millions" territory.

The immutable issued is not anything anyone has settled on, and have never  
existed as writing in any specification. That would be the primary reason  
for its lousy support in existing tools. A better example of bad support,  
although good specification language (that proves that you're right about  
this), is the immutable atom:id.

Since the beginning, atom:id has been specified to be globally unique and  
that it MUST NOT change. I believe that it does change in most tools,  
however, since it's not stored with the entry in an RDBMS (or wherever)  
statically, but generated rather dynamically.

> Not from what I've read of the arguments put forth here. It's a matter of
> "issued" being defined by the traditional publishing industry and Dublin
> Core, and that definition being considered a crucial and essential part  
> of Atom's date selection.

It is, but I've come to the conclusion that it's better to have optional  
high-quality dates in the entries, than having required low-quality ones.  
Therefore, I propose requiring at least one date, but making all of  
'issued', 'modified' and 'created' SHOULD's, and 'dateline' MAY. I'll try  
to write up a pace for this if this is something everyone can live with.

We still need to find a solution for 'first-issued', though, since Ken and  
I have agreed on that «flat» publishing systems (that is, systems without  
a separation between stories and story instances; e.g. revisioning  
systems) only have the latest instance of a story, and therefore also at  
all times the metadata about the latest instance.

I'll try to explain this with some ASCII art:

   [Story]
   ID

   [StoryInstance]
   IsVersionOf
   VersionID
   Issued
   Created
   Modified
   Title
   Body

'StoryInstance.IsVersionOf' is a foreign key for 'Story.ID'.  
'StoryInstance.VersionID' is unique for each 'StoryInstance.VersionID'.  
Each StoryInstance is issued created and issued exactly once, but can be  
modified several times. When re-issuing the Story, a new StoryInstance is  
created with a new 'VersionID, 'Created', 'Issued' and 'Modified' set.

The above is a rough description of how a revisioning CMS _could_ work.  
They could also, without any problems, work with just one table, but the  
above sketch makes it clearer that we're really talking about two levels  
within each «story».

Non-revisioning CMS's have flattened the above view, effectively deleting  
'StoryInstance.IsVersionOf' and 'StoryInstance.VersionID'. That makes the  
one 'Story.ID' the ID's of all instances, but as that ID at all time only  
holds the latest instance, 'StoryInstance.Issued' will refer to the latest  
issuance as well.

However, knowing when a story was first issued is important. Not so  
important that we MUST require it in Atom (Core), but so important that we  
SHOULD have it, and so important that for all «flattened» systems, we  
shold have an atom:first-issued date. The alternative is to have multiple  
atom:issued elements, but as Ken noted; few, if any, that have such a flat  
CMS wil ever store the individual 'issued' dates, but only store the last  
one.

This is a big furball to swallow, as I'm used to having separate stories  
and instances, which means that a story instance only can be issued once,  
and once only. For a story instance, there is no such thing as  
'first-issued' or 'last-issued'; it's just 'issued'. Just as the same with  
'created'; you can only create something once.

> [...] I said: "...we're not here to tell Six Apart how to build
> their apps."

If the specification tells them to e.g. ensure global uniqueness in their  
ID's; yes we are. Maybe we can't require 'issued' or 'first-issued' in  
Atom Core v 1.0, but we should at least encourage everyone to put them in,  
either so that everyone can improve their tools, or so that those who have  
those dates available already, can serve them.

-- 
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 Jul 27 17:19: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 RAA14231
	for <atompub-archive@lists.ietf.org>; Tue, 27 Jul 2004 17:19: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 i6RL927W038468;
	Tue, 27 Jul 2004 14:09: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 i6RL92tm038467;
	Tue, 27 Jul 2004 14:09: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 i6RL90rD038409
	for <atom-syntax@imc.org>; Tue, 27 Jul 2004 14:09: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 003537C130; Wed, 28 Jul 2004 00:04:43 +0200 (CEST)
Date: Tue, 27 Jul 2004 23:13:34 +0200
To: "Dare Obasanjo" <kpako@yahoo.com>
Subject: Re: Propose partial consensus on dates
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <20040724234940.43822.qmail@web41206.mail.yahoo.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: <opsbtekwzvuvpchu@quark>
In-Reply-To: <20040724234940.43822.qmail@web41206.mail.yahoo.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 24 Jul 2004 16:49:40 -0700 (PDT), Dare Obasanjo <kpako@yahoo.com>  
wrote:

> When an entry [with a link or guid which has been previously seen]
> reappears in a feed then RSS Bandit silently updates the title and
> content of the entry it has stored on the local machine. If the entry
> appears with a different permalink or guid then it is treated as a
> brand new entry.

Exactly. Not having support for revisions would be the same as not being  
able to recognize the entries today. Although the latter problem doesn't  
have a solution, the first one has. It's just to support the revision  
mechanism. That's either about parsing the atom:id, or supporting the  
superseding mechanism.

Either way, it would improve the current situation for both consumers and  
producers, and I don't think it's very difficult doing an  
ID.LastIndexOf(":") and getting the substring of that to check if you've  
seen anything like this before (that would be the algorithm for NewsML  
URN's as atom:id's).

>> Since RSS supports extensions via namespaces, they would
>> semantically be almost the same, with different ID's and with a
>> <publishing:relation /> element that points to the ID they
>> supersede.
>
> Gotcha.

What? Where? How? Why?

-- 
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 Jul 27 17:56: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 RAA15717
	for <atompub-archive@lists.ietf.org>; Tue, 27 Jul 2004 17:56: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 i6RLgowE045175;
	Tue, 27 Jul 2004 14:42: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 i6RLgoUH045174;
	Tue, 27 Jul 2004 14:42:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mta02-svc.ntlworld.com (mta02-svc.ntlworld.com [62.253.162.42])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6RLgnvM045111
	for <atom-syntax@imc.org>; Tue, 27 Jul 2004 14:42:49 -0700 (PDT)
	(envelope-from djpowell@djpowell.net)
Received: from cpc1-stke1-5-0-cust6.bagu.cable.ntl.com ([81.97.134.6])
          by mta02-svc.ntlworld.com
          (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP
          id <20040727214116.BBVD7908.mta02-svc.ntlworld.com@cpc1-stke1-5-0-cust6.bagu.cable.ntl.com>;
          Tue, 27 Jul 2004 22:41:16 +0100
Date: Tue, 27 Jul 2004 22:42:45 +0100
From: David Powell <djpowell@djpowell.net>
X-Mailer: The Bat! (v2.12 RC/4) Business
Reply-To: David Powell <djpowell@djpowell.net>
X-Priority: 3 (Normal)
Message-ID: <792475969.20040727224245@djpowell.net>
To: Tim Bray <Tim.Bray@Sun.COM>
CC: atom-syntax@imc.org
Subject: Re: Relative URI references
In-Reply-To: <BB9A9F4A-DF7E-11D8-8C8C-000A95A51C9E@sun.com>
References: <834420551.20040727005900@djpowell.net>
 <BB9A9F4A-DF7E-11D8-8C8C-000A95A51C9E@sun.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


Tuesday, July 27, 2004, 4:40:41 AM, Tim.Bray@Sun.COM wrote:

>> Atom defines all of it's URI-ish elements to contain URIs. If XML Base
>> processing is to be applied to these elements, then don't they need to
>> be defined as URI references, rather than URIs?

> In 2396classic terms, you're absolutely right.  Have to check 2396bis.

Seems to be the same. "URIs" are always absolute, Only
"URI References" can be relative. It doesn't make sense to resolve an
absolute URI relative to xml:base - it is already resolved, so if we
are allowing xml:base, then this implies that all of our URIs should
actually be "URI References"

I'll write a Pace to fix this wording.  I'll do this separately to the
second issue, because I think this one is pretty uncontroversial and
applies predominately to AtomFormat, whereas the second issue is
with AtomPub.


>> If relative URIs outside of the scope of xml:base are present in PUT
>> and POST requests, what are they relative to? The PostURI?, the
>> FeedURI?, the EditURI?  Or are they not allowed?

> Urgh, good questions.  Did you just volunteer to suggest some draft 
> language? -Tim

Ok, but first here are my current thoughts on this. I have have two
options that I think are usable. If nobody says that my preference is
unimplementable then I'll write it up as a Pace.


Background
----------

RFC2396bis section 5.1 [1] describes how to resolve a relative URI
reference.

Rule 5.1.1 describes the use of xml:base like techniques.  Ok - we are
doing that.

Rule 5.1.2 describes the situation for encapsulated content like MHTML
- not relevant for us.

Rule 5.1.3 describes resolving the reference relative to the retrieval
URI - this works for retrieval of Atom documents, but isn't relevant
to publishing using AtomPP.

Rule 5.1.4 allows us to define our own application specific rules.


So in our current spec, if content containing relative URIs is POSTed
to a PostURI or PUT to an EditURI, and no xml:base is in scope, then
how to resolve this URI reference is currently undefined.



Options
-------

Option 1: URIRefs are resolved relative to the EditURI for PUTs
          and relative to the PostURI for POSTs at the time of creation by the server

Option 2: URIRefs are resolved relative to the FeedURI for PUTs and POSTs at
          the time of creation by the server

Option 3: Unresolvable URIRefs are left as-is, and are resolved by the client:
            a) relative to the FeedURI and
            b) relative to the EditURI
          depending on how they are accessed.

Option 4: Unresolvable URIRefs are left as-is, and are resolved by the client
          relative to the FeedURI irrespective of whether the entry is
          accessed via the FeedURI or the EditURI

Option 5: Unresolvable URIRefs are not allowed in AtomPP


My thoughts on the Options
--------------------------

1) and 2) are not feasible because the server would have to know what
elements contain URIRefs, including extension elements that it doesn't
recognize.  This is not possible without requiring schemas, which I
don't think that we want to do.


3) imposes the constraint that the FeedURI and EditURI would need to
be siblings in a URI hierarchy else they would resolve to different
URIs in each case. I thought that we were clear that it is the content
providers responsibility to define all URIs.
I think it would be reasonable to want to host the FeedURI on a
different server, so this option seems too restrictive.


4) would basically be a 5.1.4 rule [2] that we define for AtomPP.

Drawbacks:
 
  i) It would allow people to create really bad atom:id's that mutate
when they are moved to a different server.

 ii) It requires publishing clients to know about where the feed will
 be served from if they want to use relative URIs.


5) If people want to use relative URIs, they need to supply an
explicit xml:base.

It would prevent unresolvable relative URIs from being published via
AtomPP, but they could still appear in AtomFormat if they got put
there by other means, in which case they would be resolved relative to
the FeedURI using the standard rules [1]. This provides a migration
path for RSS feeds, .

This makes atom:entries self contained entities which can be put into
databases and served up from different places without getting involved
in arcane URI resolution rules.


The vote
--------

Option 5 is my preferred choice, but Option 4 would probably work too.

If anybody can not live without doing funny stuff with relative URIs
from publishing clients then say something now, otherwise I'll propose
that we don't allow relative URIs in AtomPP unless they are in the
scope of an xml:base declaration.



[1] http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#base-uri
[2] http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#base-default


-- 
Dave



From owner-atom-syntax@mail.imc.org  Tue Jul 27 18:26: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 SAA18091
	for <atompub-archive@lists.ietf.org>; Tue, 27 Jul 2004 18: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 i6RMH3F2052479;
	Tue, 27 Jul 2004 15: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 i6RMH3wW052478;
	Tue, 27 Jul 2004 15:17: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 i6RMH3ra052462
	for <atom-syntax@imc.org>; Tue, 27 Jul 2004 15:17: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 esmtp (Exim 4.34)
	id 1BpaFo-0006ri-Ps; Tue, 27 Jul 2004 22:17:01 +0000
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Tue, 27 Jul 2004 18:16:59 -0400
Subject: Re: Relative URI references
From: Robert Sayre <mint@franklinmint.fm>
To: David Powell <djpowell@djpowell.net>, Tim Bray <Tim.Bray@Sun.COM>
CC: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD2C4C9B.14648%mint@franklinmint.fm>
In-Reply-To: <792475969.20040727224245@djpowell.net>
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: <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 7/27/04 5:42 PM, "David Powell" <djpowell@djpowell.net> wrote:

> 
> 
> Option 3: Unresolvable URIRefs are left as-is, and are resolved by the client:
>           a) relative to the FeedURI and
>           b) relative to the EditURI
>         depending on how they are accessed.
> 

> 
> 
> 3) imposes the constraint that the FeedURI and EditURI would need to
> be siblings in a URI hierarchy else they would resolve to different
> URIs in each case. I thought that we were clear that it is the content
> providers responsibility to define all URIs.
> I think it would be reasonable to want to host the FeedURI on a
> different server, so this option seems too restrictive.
> 
> 
> 

This is only a restriction if entries must be serialized identically when
they appear in feeds (the spec doesn't say anything about this). Servers are
free to mangle URIs as they please, no? The status quo doesn't prevent
clients from supplying an xml:base.

Robert Sayre



From owner-atom-syntax@mail.imc.org  Tue Jul 27 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 TAA19298
	for <atompub-archive@lists.ietf.org>; Tue, 27 Jul 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 i6RMpbWV059837;
	Tue, 27 Jul 2004 15: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 i6RMpbB1059836;
	Tue, 27 Jul 2004 15:51:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mta03-svc.ntlworld.com (mta03-svc.ntlworld.com [62.253.162.43])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6RMpacV059814
	for <atom-syntax@imc.org>; Tue, 27 Jul 2004 15:51:37 -0700 (PDT)
	(envelope-from djpowell@djpowell.net)
Received: from cpc1-stke1-5-0-cust6.bagu.cable.ntl.com ([81.97.134.6])
          by mta03-svc.ntlworld.com
          (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP
          id <20040727224900.EAIL17417.mta03-svc.ntlworld.com@cpc1-stke1-5-0-cust6.bagu.cable.ntl.com>;
          Tue, 27 Jul 2004 23:49:00 +0100
Date: Tue, 27 Jul 2004 23:50:16 +0100
From: David Powell <djpowell@djpowell.net>
X-Mailer: The Bat! (v2.12 RC/4) Business
Reply-To: David Powell <djpowell@djpowell.net>
X-Priority: 3 (Normal)
Message-ID: <533381601.20040727235016@djpowell.net>
To: Robert Sayre <mint@franklinmint.fm>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Relative URI references
In-Reply-To: <BD2C4C9B.14648%mint@franklinmint.fm>
References: <792475969.20040727224245@djpowell.net>
 <BD2C4C9B.14648%mint@franklinmint.fm>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


Tuesday, July 27, 2004, 11:16:59 PM, mint@franklinmint.fm wrote:

>>
>> Option 3: Unresolvable URIRefs are left as-is, and are resolved by the client:
>>           a) relative to the FeedURI and
>>           b) relative to the EditURI
>>         depending on how they are accessed.
>>
>> 3) imposes the constraint that the FeedURI and EditURI would need to
>> be siblings in a URI hierarchy else they would resolve to different
>> URIs in each case. I thought that we were clear that it is the content
>> providers responsibility to define all URIs.
>> I think it would be reasonable to want to host the FeedURI on a
>> different server, so this option seems too restrictive.
>> 

> This is only a restriction if entries must be serialized identically when
> they appear in feeds (the spec doesn't say anything about this).

> Servers are free to mangle URIs as they please, no?

I'm not sure what you mean.

To serialize the representation of EditURI and FeedURI differently
then the server would need to know which elements contain URIs so that
it can resolve/mangle them - but that isn't possible because the
document can contain extension elements that the server doesn't
understand - some of these might hold URIs.

> The status quo doesn't prevent clients from supplying an xml:base.

No I agree, but I was trying to define what happens if the clients
don't supply an xml:base.

-- 
Dave



From owner-atom-syntax@mail.imc.org  Tue Jul 27 20:02:39 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22149
	for <atompub-archive@lists.ietf.org>; Tue, 27 Jul 2004 20:02:39 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6RNoNtp072653;
	Tue, 27 Jul 2004 16:50:23 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6RNoNYI072652;
	Tue, 27 Jul 2004 16:50:23 -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 i6RNoMV0072645
	for <atom-syntax@imc.org>; Tue, 27 Jul 2004 16:50:22 -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 i6RNoR4Q015776;
	Tue, 27 Jul 2004 16:50:27 -0700
Received: from ussjex01.amer.bea.com ([172.16.120.50]) by ussjfe01.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Tue, 27 Jul 2004 16:50:26 -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: Private extension support (was Re: Q: Put request should return Atom entry?
Date: Tue, 27 Jul 2004 16:50:25 -0700
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF093335A3@ussjex01.amer.bea.com>
Thread-Topic: Private extension support (was Re: Q: Put request should return Atom entry?
Thread-Index: AcRuAYKlpySdn+JkRIqhiUgVzhqJygGKkxew
From: "David Orchard" <dorchard@bea.com>
To: "Mark Baker" <distobj@acm.org>
Cc: "Atom Syntax" <atom-syntax@imc.org>
X-OriginalArrivalTime: 27 Jul 2004 23:50:26.0561 (UTC) FILETIME=[7D7BE710:01C47434]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6RNoMV0072647
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 want to clearly understand the issue that you are talking about.  I'm
not sure what you mean by protocol extensibility, because the example
you gave seemed like format extensibility

There are 2 different types of extensions that I see:
1. An extension to the protocol is done, ie a new method is added.
2. An extension to the format is done.

In the case of an extension to the format, I think we are mostly covered
if we follow the things I wrote up on the extensibility/versioning pace.
I agree that we could use SOAP to take advantage of header/body
separation and role, mustUnderstand adornment.  One solution is that
application extensions could be done as soap headers marked with mU.

IMO, the Web services folks are really hamstrung on the issue of
application extensions.  OOH, the movement has been to basically not
allow or define application extensions in headers.  I had to fight like
a demon to get the Application Data feature into WSDL 2.0 (basically
optional/mandatory headers), and I still think it's a deficient feature
and probably won't get supported by the big cos.  OTOH, folks from the
big cos have regularly said that soap provides a mustUnderstand model
for mandatory extensions.  Trying to reconcile these positions leaves
you where application extensions are done as soap headers but not
described in wsdl.  And here I thought WS was about contracts and
interface specifications.

So, I think that a mustUnderstand in the application level is just
right, because then we can control and model the schema the way we want.
And there's no weird modeling to get it into the format aspects of soap.

I also think that the "protocol" aspect of soap really kills the ability
to use it as a RESTful format.  For example, soap 1.2 prohibits PUT and
DELETE as part of the soap-response MEP.  So Atom would have to invent a
new SOAP 1.2 mep.  gak!

On an extension to the protocol, I don't know how SOAP helps us.  Are
you talking about a 3rd party wanting to do a new verb and possibly mark
it as mU?  But I argued you want to fail as early as possible, which
could only be done with Mark's profile idea.

Ie, you don't want to fail when you get the message, you want to fail
earlier.  

Dave 

-----Original Message-----
From: Mark Baker [mailto:distobj@acm.org] 
Sent: Monday, July 19, 2004 7:31 PM
To: David Orchard
Cc: Atom Syntax
Subject: Re: Private extension support (was Re: Q: Put request should
return Atom entry?

On Mon, Jul 19, 2004 at 09:49:49AM -0700, David Orchard wrote:
> I wrote up some thoughts a while ago on applying some "standard"
format extensibility rules to protocols
> 
>
http://www.pacificspirit.com/blog/2004/06/14/protocol_extensibility_and_
versioning

Right-o.

> Seems like a reasonable question to ask, but it's harder to figure out
what to do...

As I see it, we have three options, at least to begin with;

1. support (RESTful) SOAP
2. support RFC 2774
3. forget about it

With both #1 and #2, my plan is that vanilla HTTP would be used by
agents not implementing an incompatible extension.  For agents that do
support such an extension, we'd recommend that the extension be defined
using whichever one of those options we decide upon.  Where it gets
tricky is that we'd also need to define behaviour for agents that choose
not to support either option (since to support one is a significant
burden with no immediate payback) so that their behaviour is
consistent with that of an agent which does support it, but no
extensions.  For example, if we opted to use SOAP, then an Atom server
choosing not to support it would still need to be able to respond with a
SOAP mustUnderstand fault to all incoming SOAP requests (as we're
assuming that SOAP is only used when mustUnderstand is used, though
there's some wiggle room there we can play with).

FWIW, I'd personally like to see SOAP supported since extensibility is
what it's best at, and, unlike RFC 2774, actually has a deployed SDK or
two. 8-)

I'd be happy to spend the time writing a Pace on this - I just wanted to
get a feel from folks about whether that would be a waste of my time or
not.  Obviously I'd be looking directly to you, Dave, for support and
input because I believe you appreciate the importance and complexity of
this space.

Mark.



From owner-atom-syntax@mail.imc.org  Tue Jul 27 21:43:03 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27176
	for <atompub-archive@lists.ietf.org>; Tue, 27 Jul 2004 21:43:02 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6S1VEfS094168;
	Tue, 27 Jul 2004 18:31:14 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6S1VE2l094167;
	Tue, 27 Jul 2004 18:31:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.194])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6S1VDI8094149
	for <atom-syntax@imc.org>; Tue, 27 Jul 2004 18:31:14 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id 76so163383rnk
        for <atom-syntax@imc.org>; Tue, 27 Jul 2004 18:31:17 -0700 (PDT)
Received: by 10.38.88.43 with SMTP id l43mr74019rnb;
        Tue, 27 Jul 2004 18:31:17 -0700 (PDT)
Message-ID: <3f1451f504072718312e51bc85@mail.gmail.com>
Date: Tue, 27 Jul 2004 21:31:17 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Norman Walsh <ndw@nwalsh.com>
Subject: Re: Unstructured text
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <87fz7itw1c.fsf@nwalsh.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <BD22B042.21030%eric.scheid@ironclad.net.au>
 <605A99DE882CEC36E3B093C1@adsl-64-166-133-244.dsl.snfc21.pacbell.net> <87fz7itw1c.fsf@nwalsh.com>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


On Fri, 23 Jul 2004 14:31:43 -0400, Norman Walsh <ndw@nwalsh.com> wrote:
> (Not the US-centric bit, just the fact that getting the markup right
> is very, very hard and will add significantly to the complexity of our
> spec for very little payoff. IMHO.)

+1

    -joe

-- 
Joe Gregorio        http://bitworking.org



From owner-atom-syntax@mail.imc.org  Tue Jul 27 23:09: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 XAA00593
	for <atompub-archive@lists.ietf.org>; Tue, 27 Jul 2004 23: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 i6S2xbHe014205;
	Tue, 27 Jul 2004 19: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 i6S2xbrb014204;
	Tue, 27 Jul 2004 19:59:37 -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 i6S2xaxc014157
	for <atom-syntax@imc.org>; Tue, 27 Jul 2004 19:59:36 -0700 (PDT)
	(envelope-from distobj@acm.org)
Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian))
	id 1Bpeg0-0002NZ-00; Tue, 27 Jul 2004 23:00:20 -0400
Date: Tue, 27 Jul 2004 23:00:20 -0400
To: David Orchard <dorchard@bea.com>
Cc: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Private extension support (was Re: Q: Put request should return Atom entry?
Message-ID: <20040728030020.GJ30868@markbaker.ca>
References: <32D5845A745BFB429CBDBADA57CD41AF093335A3@ussjex01.amer.bea.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <32D5845A745BFB429CBDBADA57CD41AF093335A3@ussjex01.amer.bea.com>
User-Agent: Mutt/1.3.28i
From: Mark Baker <distobj@acm.org>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


On Tue, Jul 27, 2004 at 04:50:25PM -0700, David Orchard wrote:
> I want to clearly understand the issue that you are talking about.  I'm
> not sure what you mean by protocol extensibility, because the example
> you gave seemed like format extensibility

Sorry if I wasn't clear, but I definitely intended to refer to protocol
extensibility.  Specifically, how does one go about adding a new header
when using the Atom "API"?

> I also think that the "protocol" aspect of soap really kills the ability
> to use it as a RESTful format.  For example, soap 1.2 prohibits PUT and
> DELETE as part of the soap-response MEP.  So Atom would have to invent a
> new SOAP 1.2 mep.  gak!

I think PUT would be covered with the req/resp MEP, but you're right
about DELETE.  But is adding a new MEP such a big deal?  I dunno.  I
haven't looked at any SOAP 1.2 tools to see how they handle (or not)
extension MEPs.

> On an extension to the protocol, I don't know how SOAP helps us.  Are
> you talking about a 3rd party wanting to do a new verb and possibly mark
> it as mU?

Actually, I was just thinking about extension headers, not methods,
(since extension methods are already effectively mU in HTTP).  i.e. if
you wanted to add a non-mU header you could do so as an HTTP header, but
if you wanted to add an mU one, you'd do it with SOAP.  SOAP helps us by
adding mU to HTTP, effectively.

Anyhow, I'm obviously not going to stand up screaming for this, since
I'd personally be happy to see SOAP not used in Atom.  I just felt that
this was one option around which concensus could form.

>  But I argued you want to fail as early as possible, which
> could only be done with Mark's profile idea.
> 
> Ie, you don't want to fail when you get the message, you want to fail
> earlier.  

You mean when your spidey sense is tingling? 8-)

But seriously, for adhoc integration, when there's no prior agreement
between parties, I don't think there is anything earlier than "when you
get the message".

Mark.



From owner-atom-syntax@mail.imc.org  Tue Jul 27 23:30:51 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01484
	for <atompub-archive@lists.ietf.org>; Tue, 27 Jul 2004 23:30:50 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6S3N5ee019698;
	Tue, 27 Jul 2004 20:23: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 i6S3N5gN019697;
	Tue, 27 Jul 2004 20:23:05 -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 i6S3N4Jp019660
	for <atom-syntax@imc.org>; Tue, 27 Jul 2004 20:23:04 -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 i6S3N353001317
	for <atom-syntax@imc.org>; Tue, 27 Jul 2004 22:23:04 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6S3N23O001313;
	Tue, 27 Jul 2004 22:23:02 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: "Atom Syntax" <atom-syntax@imc.org>
Subject: Re: Private extension support (was Re: Q: Put request should return Atom entry?
References: <32D5845A745BFB429CBDBADA57CD41AF093335A3@ussjex01.amer.bea.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 27 Jul 2004 22:23:02 -0500
In-Reply-To: <32D5845A745BFB429CBDBADA57CD41AF093335A3@ussjex01.amer.bea.com>
Message-ID: <m38yd46cix.fsf@bitsko.slc.ut.us>
Lines: 17
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


"David Orchard" <dorchard@bea.com> writes:

> There are 2 different types of extensions that I see:
> 1. An extension to the protocol is done, ie a new method is added.
> 2. An extension to the format is done.

This is probably obvious to the point of being mundane, but the
simplest forms of extensions to the protocol will be in the area of
endpoints (collections of resources in a URL-space or active
endpoints, like searches) and more Atom-inspired resource types
(configuration, blogrolls, users, FOAF).

This is all basic REST but nevertheless should be mentioned and
recommended as routes of extensibility for Atom because people often
forget it's there -- kinda like breathing.

  -- Ken



From owner-atom-syntax@mail.imc.org  Wed Jul 28 00:30:25 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04028
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 00: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 i6S4EDmU029641;
	Tue, 27 Jul 2004 21:14: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 i6S4EDus029640;
	Tue, 27 Jul 2004 21:14:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from beattie.info (Debian-exim@26.69-93-195.reverse.theplanet.com [69.93.195.26] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6S4ECdC029621
	for <atom-syntax@imc.org>; Tue, 27 Jul 2004 21:14:12 -0700 (PDT)
	(envelope-from russ@russellbeattie.com)
Received: from [64.164.31.160] (helo=[192.168.0.217])
	by beattie.info with asmtp (Exim 4.33)
	id 1Bpfsc-0001ne-UN
	for atom-syntax@imc.org; Tue, 27 Jul 2004 21:17:27 -0700
Message-ID: <4107280A.500@russellbeattie.com>
Date: Tue, 27 Jul 2004 21:14:02 -0700
From: Russell Beattie <russ@russellbeattie.com>
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22smp i686; en-US; m18) Gecko/20010110 Netscape6/6.5
X-Accept-Language: en-us, ja, es-es
MIME-Version: 1.0
To: Atom Syntax <atom-syntax@imc.org>
Subject: AtomME: Posting from a Java mobile phone via the Atom API
Content-Type: text/plain; charset=ISO-8859-15; 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



Sorry for the delay on this, I just ran into a bug I couldn't work out, 
then got caught up in other issues and couldn't get back to it until 
this evening.

Last week we were deep in the POST vs. PUT/DELETE debate when I started 
working with Sam Ruby on a simple J2ME app which would post to an 
Atom-enabled weblog via J2ME. Sam did the heavy lifting of working out 
the Base64 and SHA1 encoding in J2ME-compatible Java (which he published 
on his weblog last week) and I used that code to create a small J2ME 
application which simply allows you to post a title and content field to 
a weblog.

If you want to just play with the app on your mobile, I added a link to 
the .jad/.jar to a WAP page, which you can get to from my short url:

http://rbeattie.com/wap

Navigate to Links, then "Install AtomME". It should download and 
install. I tested it on the phones I have handy at the moment: a Nokia 
7610, 6200, SonyEricsson 616 and a Motorola v400. It's a *very* basic 
app - the J2ME equivalent of a command-line program. I usually use this 
sort of code as a harness to test J2ME functionality. It simply allows 
you to fill out a form with your posting information for a server like 
TypePad (in fact it defaults to their API) then dumps out the XML being 
passed over the wire to the screen.

I've posted the code under an MIT license here:

http://www.russellbeattie.com/download/AtomME.zip

In order to use it, you'll need to have Sun's Wireless Toolkit (WTK), 
Ant, and Antenna installed. Edit the build.properties file to point at 
the at the directory where the WTK is and you should be able to compile 
it quickly. To run the app in the emulator, simply type "ant emulate."

There were several problems getting this working. First, the Base64 and 
SHA1 code is non-trivial, but Sam has gotten that down to a small class 
which I just grabbed and included, but if I had to develop that myself 
it wouldn't have happened. The second problem was the date formatting. 
Some phones (like my beloved, but flawed Nokia 6600) have real problems 
with the Calendar object. I finally gave up trying to get that phone to 
work.

And thirdly and most importantly, neither TypePad nor Blogger (my two 
testing servers) supported chunked HTTP posting. For various reasons 
having to do with unreliable wireless networks, the J2ME Connection 
class will chunk the HTTP whether you like it or not. I did find a way 
of  not forcing the chunking by not calling OutputStream.flush(), but 
that only works on some phones and if the data gets long enough the 
KVM/JVM will still chunk whether you like it or not. Since chunking is 
part of the HTTP 1.1 spec, I don't feel this isn't a big deal in terms 
of the Atom Spec: the servers just have a bug at the moment which they 
need to fix.

So my thoughts are this: SHA1 encoding isn't bad if you have someone 
else write it for you ;-), setting headers on the phone works (at least 
on my carrier), and if POST were the only HTTP verb required, Atom could 
be implemented on a wide variety of handsets right now. The fact that 
this app runs on the 6200 and T616 show a lot - those are *not* very 
powerful phones.

This is just a first step. I'm sure someone can take this code and build 
on it to create a more full-featured Atom client which can do much more. 
For example, using the MultiMedia APIs, it should be possible to post 
PNG images and maybe even video via Atom from J2ME as well.

The next step is for everyone who has a Java-enabled mobile to try the 
app. (Feel free to send bug reports to me, just don't expect a prompt 
answer. :-) ) Do you have a phone which doesn't work? We'll have to 
figure out why - maybe it's a bug, maybe it's something more serious. Do 
you have a carrier which strips out the headers? Etc. etc. Then  we can 
move on to trying to implement the SOAP-based PUT/DELETE alternative and 
see how well that works. I would *much* rather have some sort of action 
header or stanza, as it would make this code much more reusable and 
maintainable, but let's try what's speced now and see.

Thanks,

-Russ




From owner-atom-syntax@mail.imc.org  Wed Jul 28 01:05: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 BAA05553
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 01:05: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 i6S4tKaP037450;
	Tue, 27 Jul 2004 21:55:20 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6S4tKbo037449;
	Tue, 27 Jul 2004 21:55:20 -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 i6S4tKOk037441
	for <atom-syntax@imc.org>; Tue, 27 Jul 2004 21:55:20 -0700 (PDT)
	(envelope-from david@blojsom.com)
Received: (qmail 2980 invoked from network); 28 Jul 2004 04:45:28 -0000
Received: from alb-24-195-142-151.nycap.rr.com (HELO ?10.0.1.3?) (24.195.142.151)
  by air643.startdedicated.com with SMTP; 28 Jul 2004 04:45:28 -0000
User-Agent: Microsoft-Entourage/11.0.0.040405
Date: Wed, 28 Jul 2004 00:58:09 -0400
Subject: Re: AtomME: Posting from a Java mobile phone via the Atom API
From: David Czarnecki <david@blojsom.com>
To: atom-syntax <atom-syntax@imc.org>
Message-ID: <BD2CAAA1.44B1%david@blojsom.com>
In-Reply-To: <4107280A.500@russellbeattie.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



> 
> The next step is for everyone who has a Java-enabled mobile to try the
> app. (Feel free to send bug reports to me, just don't expect a prompt
> answer. :-) ) Do you have a phone which doesn't work? We'll have to
> figure out why - maybe it's a bug, maybe it's something more serious. Do
> you have a carrier which strips out the headers? Etc. etc. Then  we can
> move on to trying to implement the SOAP-based PUT/DELETE alternative and
> see how well that works. I would *much* rather have some sort of action
> header or stanza, as it would make this code much more reusable and
> maintainable, but let's try what's speced now and see.
> 
> Thanks,
> 
> -Russ
> 
> 

Personally I like the alternative proposal of PacePutDelete [1]. As an
addendum to what I wrote [2] this evening, this proposal seems to be one of
the simplest things that could work without requiring SOAP on the client and
server. It's not that SOAP enabling is hard, but implementing this (at least
how I've got things working in blojsom) would only be a couple lines of code
to check for the appropriate header and route things accordingly.

-David 

[1] - http://www.intertwingly.net/wiki/pie/PacePutDelete
[2] - 
http://www.blojsom.com/blog/blojsom/2004/7/27/atom-blojsom-http-put.html




From owner-atom-syntax@mail.imc.org  Wed Jul 28 02: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 CAA07927
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 02: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 i6S6SSWj088918;
	Tue, 27 Jul 2004 23:28: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 i6S6SSnE088916;
	Tue, 27 Jul 2004 23:28: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 i6S6SRI4088803
	for <atom-syntax@imc.org>; Tue, 27 Jul 2004 23:28: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 3E39E7C122; Wed, 28 Jul 2004 09:23:55 +0200 (CEST)
Date: Wed, 28 Jul 2004 08:32:05 +0200
To: "Ken MacLeod" <ken@bitsko.slc.ut.us>
Subject: Re: atom:id permanence and portability testing
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <001201c472c8$020e3e10$6400a8c0@wyman.us> <m38yd67hi4.fsf@bitsko.slc.ut.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: <opsbt4frd6uvpchu@quark>
In-Reply-To: <m38yd67hi4.fsf@bitsko.slc.ut.us>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 26 Jul 2004 13:25:39 -0500, Ken MacLeod <ken@bitsko.slc.ut.us> wrote:

> ID-IS-SAME-IN-MULTIPLE-LOCATIONS
> [...]
>
> ID-IS-SAME-AFTER-MIGRATION
> [...]
>
> ID-IS-SAME-AFTER-IMPORTING
> [...]

Great, Ken. Such tests will make it easier for developers to understand  
what atom:id must conform to.

-- 
Asbjørn Ulsberg         -=|=-        asbjornu@hotmail.com
«He's a loathsome offensive brute, yet I can't look away»



From owner-atom-syntax@mail.imc.org  Wed Jul 28 02:41: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 CAA08042
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 02:41: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 i6S6WEdt090728;
	Tue, 27 Jul 2004 23:32:14 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6S6WE6a090727;
	Tue, 27 Jul 2004 23:32:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6S6WDdw090687
	for <atom-syntax@imc.org>; Tue, 27 Jul 2004 23:32:14 -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 4A5427C122; Wed, 28 Jul 2004 09:27:48 +0200 (CEST)
Date: Wed, 28 Jul 2004 08:35:57 +0200
To: bob@wyman.us
Subject: Re: PaceItemIDIsNewsML: Struggling for compromise
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <200407262316.BKE54402@ms8.netsolmail.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: <opsbt4l7j9uvpchu@quark>
In-Reply-To: <200407262316.BKE54402@ms8.netsolmail.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Mon, 26 Jul 2004 19:16:20 -0400, Bob Wyman <bob@wyman.us> wrote:

> From this, it sounds like those who would prefer tag to NewsML and
> who are attending the IETF meeting should consider attending the BOF to
> encourage progress on tag adoption.

Definately. But another thing: Would it be possible to request a minor  
feature request for tag URI's? It would be great if the URI scheme we  
chose as atom:id's recommended scheme, supported revisions, like NewsML  
URN'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 Jul 28 03: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 DAA09537
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 03:02:22 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6S6t1AN002497;
	Tue, 27 Jul 2004 23:55: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 i6S6t1dl002496;
	Tue, 27 Jul 2004 23:55:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6S6sxZk002434
	for <atom-syntax@imc.org>; Tue, 27 Jul 2004 23:55:00 -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 6C03C7C122; Wed, 28 Jul 2004 09:50:34 +0200 (CEST)
Date: Wed, 28 Jul 2004 08:58:48 +0200
To: "Tim Bray" <Tim.Bray@sun.com>
Subject: Re: PaceDateline
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <41027456.5040109@intertwingly.net> <opsbndknqruvpchu@quark> <41027CC9.5060202@intertwingly.net> <opsbnj16g8uvpchu@quark> <DF629C3B-DD9B-11D8-8C8C-000A95A51C9E@sun.com> <opsbnsfhcvuvpchu@quark> <73CB0D64-DDB4-11D8-8C8C-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: <opsbt5oaoluvpchu@quark>
In-Reply-To: <73CB0D64-DDB4-11D8-8C8C-000A95A51C9E@sun.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 24 Jul 2004 14:00:11 -0700, Tim Bray <Tim.Bray@Sun.COM> wrote:

> I don't ask that you adopt my publishing semantics, but I also don't
> expect to adopt yours.

Still, «your» publishing semantics is the one that gets represented in  
Atom. I have settled with this, though. See my reply to Roger B. about  
this:

<url: http://www.imc.org/atom-syntax/mail-archive/msg07940.html>

If what I wrote there is something we can have consensus on (basically  
that all date elements are optional, but that every entry MUST have a date  
element of some sort), I'll write it up in a pace.

> I have spent some years in professional publishing technology and I  
> fully, completely, totally, understand your model of publishing an  
> immutable article and never revising but only superseding it.  I agree  
> that it's appropriate for lots of applications.  But it isn't popular  
> among a large part of the user base and it isn't going to become popular  
> and you are just going to have to live with this fact.

Yes. Evidently.

-- 
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 Jul 28 04:45: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 EAA14977
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 04:45: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 i6S8aSBM053288;
	Wed, 28 Jul 2004 01:36: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 i6S8aSIB053287;
	Wed, 28 Jul 2004 01:36:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from cat-proof.de (cat.cat-proof.de [213.239.198.176])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6S8aQ8x053211
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 01:36:27 -0700 (PDT)
	(envelope-from sc@itst.net)
Received: from [192.168.1.10] (p508171C7.dip0.t-ipconnect.de [80.129.113.199])
	by cat-proof.de (Postfix) with ESMTP id 821CA340B665
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 10:34:48 +0200 (CEST)
Message-ID: <41076602.7030907@itst.net>
Date: Wed, 28 Jul 2004 10:38:26 +0200
From: Sascha Carlin <sc@itst.net>
User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707)
X-Accept-Language: de, en
MIME-Version: 1.0
To: atom-syntax@imc.org
Subject: Re: Date Options Survey
References: <475BB4D1-DCF3-11D8-AFAD-000A95A51C9E@sun.com> <410383FF.8030603@itst.net>
In-Reply-To: <410383FF.8030603@itst.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


Seems like nobody is interested? Is my suggestion so odd?

Regards, Sascha

-- 
Sascha Carlin * Heinrich-Heine-Str. 1 * 64319 Pfungstadt
http://www.itst.org/         **         +49 6157 157 205



From owner-atom-syntax@mail.imc.org  Wed Jul 28 07:16: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 HAA21763
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 07:16: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 i6SB2Vha033411;
	Wed, 28 Jul 2004 04: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 i6SB2V3V033410;
	Wed, 28 Jul 2004 04:02:31 -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 i6SB2TRi033367
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 04:02:30 -0700 (PDT)
	(envelope-from laurent.lemeur@afp.com)
Received: from alox.afp.com (unknown [158.50.165.141])
	by smtp3.afp.com (Sendmail) with ESMTP id 9B91246354
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 13:02:23 +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 i6SB2Dt6021987
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 13:02:13 +0200 (METDST)
From: "Laurent Le Meur" <laurent.lemeur@afp.com>
To: "'Atom syntax'" <atom-syntax@imc.org>
Subject: RE : PaceDateline 
Date: Wed, 28 Jul 2004 13:02:13 +0200
Message-ID: <00d601c47492$561db050$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: <2BDD4646-DDA5-11D8-9170-000A95DC3D90@mac.com>
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 i6SB2VRi033399
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


  > b) "dateline" was offered as a name for a consensus *date* construct.
  > No one said datelines themselves (ie including place information) were
  > a good idea.

Sorry but it would be a mess to use a name (Dateline) universally known in
the news industry, and *warp* its meaning in Atom = a news-related
initiative.  

A dateline appears at the beginning of a story like:
"PARIS, July 25 (AFP) - American Lance Armstrong became the first six-time
winner of the Tour de France after completing the final 20th stage of the
race into Paris here Sunday." The dateline goes up to the hyphen!

Dateline obey to strict editorial rules (you name the country only when you
send a story to people who don't know where a city is situated), identify
the location and date logically associated with the content (ie origin of
the story, a subjective notion), and are *human friendly*, so an ISO profile
is not recommended for it.

As Sam Ruby wrote in his Pace, "If the WG decides not to provide a means for
capturing the place of origin, then a different element name should be
chosen. "

ATFU NewsML 1 uses a DateLine label (human friendly), and doubles it with
what has been named "DateLineDate" (not a very elegant name I confess) which
is an ISO date. NewsML 1 also uses two other fields, FirstCreated and
ThisRevisionCreated. This could evolve in NewsML 2.

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 Graham
  > Envoyé : samedi 24 juillet 2004 21:11
  > À : Sam Ruby
  > Cc : Atom syntax
  > Objet : Re: PaceDateline - process issue
  > 
  > 
  > a) Where on earth did the dcterms idea come back from? Not discussing
  > dates properly in the spec seems like a sure way to discourage
  > interoperability.
  > 
  > I really hope you're just playing devil's advocate with these two
  > suggestions.
  > 
  > Graham




From owner-atom-syntax@mail.imc.org  Wed Jul 28 07:21:32 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21968
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 07:21: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 i6SBCcA2036364;
	Wed, 28 Jul 2004 04:12: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 i6SBCcxJ036363;
	Wed, 28 Jul 2004 04:12:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from relay.bbhmail.com (68-22-85-68.ded.ameritech.net [68.22.85.68])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SBCbIR036351
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 04:12:37 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net ([65.85.192.194])
	by relay.bbhmail.com (8.12.8/8.12.8) with ESMTP id i6SBSZ62021434;
	Wed, 28 Jul 2004 07:28:36 -0400
Received: from *Unknown*-port4-SMSHGIBEAVERTON[10.42.1.27] by SMSHGIBEAVERTON[65.85.192.194]; Wed, 28 Jul 2004 06:52:22 -0000 (???)
Message-ID: <41078A1F.6010609@intertwingly.net>
Date: Wed, 28 Jul 2004 07:12:31 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Ken MacLeod <ken@bitsko.slc.ut.us>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Private extension support (was Re: Q: Put request should return
 Atom entry?
References: <32D5845A745BFB429CBDBADA57CD41AF093335A3@ussjex01.amer.bea.com> <m38yd46cix.fsf@bitsko.slc.ut.us>
In-Reply-To: <m38yd46cix.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: <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


Ken MacLeod wrote:

> "David Orchard" <dorchard@bea.com> writes:
> 
>>There are 2 different types of extensions that I see:
>>1. An extension to the protocol is done, ie a new method is added.
>>2. An extension to the format is done.
> 
> This is probably obvious to the point of being mundane, but the
> simplest forms of extensions to the protocol will be in the area of
> endpoints (collections of resources in a URL-space or active
> endpoints, like searches) and more Atom-inspired resource types
> (configuration, blogrolls, users, FOAF).
> 
> This is all basic REST but nevertheless should be mentioned and
> recommended as routes of extensibility for Atom because people often
> forget it's there -- kinda like breathing.

IMHO, this argument is strenghtened if we keep:

   <atom:link href="..." type="..."/>

And weakened if every unique resource type needs a new and unique 
extension to the format.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Wed Jul 28 09:55:10 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00473
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 09:55: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 i6SDgwdf080333;
	Wed, 28 Jul 2004 06: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 i6SDgwrl080332;
	Wed, 28 Jul 2004 06:42: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 i6SDgvu9080324
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 06:42:57 -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 1Bpoht-0000sf-9i; Wed, 28 Jul 2004 13:42:57 +0000
Message-ID: <4107AD5D.1080902@franklinmint.fm>
Date: Wed, 28 Jul 2004 09:42:53 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: David Powell <djpowell@djpowell.net>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Relative URI references
References: <792475969.20040727224245@djpowell.net> <BD2C4C9B.14648%mint@franklinmint.fm> <533381601.20040727235016@djpowell.net>
In-Reply-To: <533381601.20040727235016@djpowell.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


David Powell wrote:

> Tuesday, July 27, 2004, 11:16:59 PM, Robert Sayre wrote:
> 
>>This is only a restriction if entries must be serialized identically when
>>they appear in feeds (the spec doesn't say anything about this).

> 
> 
> I'm not sure what you mean.
> 
> To serialize the representation of EditURI and FeedURI differently
> then the server would need to know which elements contain URIs so that
> it can resolve/mangle them - but that isn't possible because the
> document can contain extension elements that the server doesn't
> understand - some of these might hold URIs.

The client could mark the extensions "mustUnderstand" (not in the spec, 
but planned), it could make the URIs absolute, or it could supply an 
xml:base. Or we could specify a common link construct.

Perhaps I misunderstood. Were you proposing rules for extension 
elements, or all of Atom?

Robert Sayre



From owner-atom-syntax@mail.imc.org  Wed Jul 28 10:49:02 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04771
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 10:49:01 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SEcZxa096868;
	Wed, 28 Jul 2004 07: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 i6SEcZRu096867;
	Wed, 28 Jul 2004 07:38:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SEcY4p096858
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 07:38: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 i6SEcbil006231
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 08:38: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 <0I1K00JF0GOC5V@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Wed, 28 Jul 2004 08:38:37 -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 <0I1K0096IGOCL9@mail.sun.net> for atom-syntax@imc.org; Wed,
 28 Jul 2004 08:38:36 -0600 (MDT)
Date: Wed, 28 Jul 2004 07:38:51 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Relative URI references
In-reply-to: <792475969.20040727224245@djpowell.net>
To: David Powell <djpowell@djpowell.net>
Cc: atom-syntax@imc.org
Message-id: <D83EF099-E0A3-11D8-8C8C-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: <834420551.20040727005900@djpowell.net>
 <BB9A9F4A-DF7E-11D8-8C8C-000A95A51C9E@sun.com>
 <792475969.20040727224245@djpowell.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 Jul 27, 2004, at 2:42 PM, David Powell wrote:

> Option 5: Unresolvable URIRefs are not allowed in AtomPP

Based on the discussion from you and Rob, if we modify this by saying 
"xml:base is allowed anywhere in AtomPP, and relative URIs may not be 
used unless the base URI has been established using xml:base" then I 
think we have something that's easy to explain and easy to understand 
and easy to implement.  I think that trying to write a set of base-URI 
rules around this URI and that URI and the other URI is going to be 
complex and tricky and easy to get wrong.  -Tim



From owner-atom-syntax@mail.imc.org  Wed Jul 28 11:03:49 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05672
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 11:03:49 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SEsniu001651;
	Wed, 28 Jul 2004 07:54: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 i6SEsnrn001650;
	Wed, 28 Jul 2004 07:54:49 -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 i6SEsmBb001598
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 07:54:48 -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 i6SEsj53009622
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 09:54:45 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6SEsjVg009618;
	Wed, 28 Jul 2004 09:54:45 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Private extension support (was Re: Q: Put request should return Atom entry?
References: <32D5845A745BFB429CBDBADA57CD41AF093335A3@ussjex01.amer.bea.com>
	<m38yd46cix.fsf@bitsko.slc.ut.us> <41078A1F.6010609@intertwingly.net>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 28 Jul 2004 09:54:44 -0500
In-Reply-To: <41078A1F.6010609@intertwingly.net>
Message-ID: <m3n01k41xn.fsf@bitsko.slc.ut.us>
Lines: 49
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: <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> writes:

> Ken MacLeod wrote:
> 
> > "David Orchard" <dorchard@bea.com> writes:
> >
> >>There are 2 different types of extensions that I see:
> >>1. An extension to the protocol is done, ie a new method is added.
> >>2. An extension to the format is done.
> > This is probably obvious to the point of being mundane, but the
> > simplest forms of extensions to the protocol will be in the area
> > of endpoints (collections of resources in a URL-space or active
> > endpoints, like searches) and more Atom-inspired resource types
> > (configuration, blogrolls, users, FOAF).  This is all basic REST
> > but nevertheless should be mentioned and recommended as routes of
> > extensibility for Atom because people often forget it's there --
> > kinda like breathing.
> 
> IMHO, this argument is strenghtened if we keep:
> 
>    <atom:link href="..." type="..."/>
> 
> And weakened if every unique resource type needs a new and unique
> extension to the format.

Yes, that's why having a relation name (whereever it goes) declaring a
resource type is a bad idea.

However, that shouldn't be confused with having a unique relation name
(whereever it goes) for indicating *why* you would want to traverse a
link (regardless of or only secondarily dependent on the resource type
at the other end of the link).

Every new relation name (wherever it goes) is going to be a new and
unique extension to the format.

Dave Orchard's PaceExtensibilityAndVersioning is recommending XML
qnames as attribute values for those relation names, and whereas I
prefer not to have qnames in content I believe that approach is better
than the other suggested alternatives for @rel.

What is really less than optimal is having URI references appear in
"odd places", like other attributes (@uri) or element content (<id>,
<uri>), without an extensibility model for locating them there.
Extensions will follow the pattern set by the core and Atom processors
will not be able to apply rules, like xml:base, to those URI
references in new, odd places.

  -- Ken



From owner-atom-syntax@mail.imc.org  Wed Jul 28 11:12:01 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06133
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 11:12:01 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SExcH5003060;
	Wed, 28 Jul 2004 07:59: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 i6SExc6s003059;
	Wed, 28 Jul 2004 07:59:38 -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 i6SExbb9003041
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 07:59:38 -0700 (PDT)
	(envelope-from distobj@acm.org)
Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian))
	id 1Bpput-00043O-00
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 11:00:27 -0400
Date: Wed, 28 Jul 2004 11:00:27 -0400
To: atom-syntax@imc.org
Subject: Re: Relative URI references
Message-ID: <20040728150027.GK30868@markbaker.ca>
References: <834420551.20040727005900@djpowell.net> <BB9A9F4A-DF7E-11D8-8C8C-000A95A51C9E@sun.com> <792475969.20040727224245@djpowell.net> <D83EF099-E0A3-11D8-8C8C-000A95A51C9E@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <D83EF099-E0A3-11D8-8C8C-000A95A51C9E@sun.com>
User-Agent: Mutt/1.3.28i
From: Mark Baker <distobj@acm.org>
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 Wed, Jul 28, 2004 at 07:38:51AM -0700, Tim Bray wrote:
> On Jul 27, 2004, at 2:42 PM, David Powell wrote:
> 
> >Option 5: Unresolvable URIRefs are not allowed in AtomPP
> 
> Based on the discussion from you and Rob, if we modify this by saying 
> "xml:base is allowed anywhere in AtomPP, and relative URIs may not be 
> used unless the base URI has been established using xml:base" then I 
> think we have something that's easy to explain and easy to understand 
> and easy to implement.  I think that trying to write a set of base-URI 
> rules around this URI and that URI and the other URI is going to be 
> complex and tricky and easy to get wrong.  -Tim



From owner-atom-syntax@mail.imc.org  Wed Jul 28 11:34: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 LAA07594
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 11:34: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 i6SFLilr009635;
	Wed, 28 Jul 2004 08: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 i6SFLiGR009634;
	Wed, 28 Jul 2004 08:21:44 -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 i6SFLgOd009584
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 08:21:43 -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 i6SFLe53010015
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 10:21:40 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6SFLcaK010010;
	Wed, 28 Jul 2004 10:21:38 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: atom-syntax@imc.org
Subject: Re: Relative URI references
References: <834420551.20040727005900@djpowell.net>
	<BB9A9F4A-DF7E-11D8-8C8C-000A95A51C9E@sun.com>
	<792475969.20040727224245@djpowell.net>
	<D83EF099-E0A3-11D8-8C8C-000A95A51C9E@sun.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 28 Jul 2004 10:21:38 -0500
In-Reply-To: <D83EF099-E0A3-11D8-8C8C-000A95A51C9E@sun.com>
Message-ID: <m3isc840ot.fsf@bitsko.slc.ut.us>
Lines: 49
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: <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> writes:

> On Jul 27, 2004, at 2:42 PM, David Powell wrote:
> 
> > Option 5: Unresolvable URIRefs are not allowed in AtomPP
> 
> Based on the discussion from you and Rob, if we modify this by
> saying "xml:base is allowed anywhere in AtomPP, and relative URIs
> may not be used unless the base URI has been established using
> xml:base" then I think we have something that's easy to explain and
> easy to understand and easy to implement.  I think that trying to
> write a set of base-URI rules around this URI and that URI and the
> other URI is going to be complex and tricky and easy to get wrong.

Rob, Arve, and I had a rather long discussion in #atom about this
yesterday[1], and it's more complex than that.

  1) the editing client, today, has no a priori knowledge of what the
     ultimate xml:base of the server will be, therefore depending on
     the context of where an xml:base declaration occurrs, it is
     likely "wrong" and must be overridden by the publishing system.

     The questions are: which ones are wrong and who knows better?
     The processer emitting the xml:base or the processor tasked with
     knowing the xml:base of certain locations?

  2) if we determine that the interaction between editing client and
     publishing system is "exempt" from xml:base processing (ie. it's
     entirely up to the publishing system), then we need to specify
     that xml:base processing does not occur in that interaction.

  3) if we determine that the server should indicate its known
     xml:base locations for various resources (links, ids, and
     content), that'll need to go in introspection and may be messy.

  4) some xml:base'd resources at the time the editing client is
     previewing content will be local (not yet published) and some
     will be remote (already published).  It should be noted that the
     client needs to be aware of that, along with (2) or (3).

We also ventured into other interactions and touched on test cases for
a variety of situations.  It feels to me like we've only begun to
scratch the surface of the issues with xml:base processing outside of
a purely "output" resource from a singly-based, known, web served
document instance.

  -- Ken

[1] http://www.ilrt.bris.ac.uk/discovery/chatlogs/atom/2004-07-27.html#T22-01-22



From owner-atom-syntax@mail.imc.org  Wed Jul 28 11: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 LAA07616
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 11:34: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 i6SFQsqd011199;
	Wed, 28 Jul 2004 08:26: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 i6SFQsDi011196;
	Wed, 28 Jul 2004 08:26: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.202])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SFQp0T011155
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 08:26:51 -0700 (PDT)
	(envelope-from eliast@gmail.com)
Received: by mproxy.gmail.com with SMTP id 78so100130rnk
        for <atom-syntax@imc.org>; Wed, 28 Jul 2004 08:26:51 -0700 (PDT)
Received: by 10.38.74.56 with SMTP id w56mr454117rna;
        Wed, 28 Jul 2004 08:26:51 -0700 (PDT)
Message-ID: <905f7c9104072808264144573e@mail.gmail.com>
Date: Wed, 28 Jul 2004 11:26:51 -0400
From: Elias Torres <eliast@gmail.com>
Reply-To: elias@torrez.us
To: Tim Bray <tim.bray@sun.com>
Subject: Re: Relative URI references
Cc: David Powell <djpowell@djpowell.net>, atom-syntax@imc.org
In-Reply-To: <D83EF099-E0A3-11D8-8C8C-000A95A51C9E@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <834420551.20040727005900@djpowell.net>
 <BB9A9F4A-DF7E-11D8-8C8C-000A95A51C9E@sun.com>
 <792475969.20040727224245@djpowell.net> <D83EF099-E0A3-11D8-8C8C-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


I have a question since I'm not an expert in xml:base. Can xml:base be
an attribute of any element in an Atom document? Would it mean then
that everytime you have a URI you must check upwards for any existing
xml:base? If that's all it takes, it's not that bad, but maybe we need
to remind people about that. Maybe there's an XPath that does it in
one query?

Elias Torres

On Wed, 28 Jul 2004 07:38:51 -0700, Tim Bray <tim.bray@sun.com> wrote:
> 
> On Jul 27, 2004, at 2:42 PM, David Powell wrote:
> 
> > Option 5: Unresolvable URIRefs are not allowed in AtomPP
> 
> Based on the discussion from you and Rob, if we modify this by saying
> "xml:base is allowed anywhere in AtomPP, and relative URIs may not be
> used unless the base URI has been established using xml:base" then I
> think we have something that's easy to explain and easy to understand
> and easy to implement.  I think that trying to write a set of base-URI
> rules around this URI and that URI and the other URI is going to be
> complex and tricky and easy to get wrong.  -Tim
> 
>



From owner-atom-syntax@mail.imc.org  Wed Jul 28 12:15: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 MAA11151
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 12:15: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 i6SFv0kP018831;
	Wed, 28 Jul 2004 08:57: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 i6SFv0oN018830;
	Wed, 28 Jul 2004 08:57:00 -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 i6SFv0P1018782
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 08:57:00 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040728155658.58331.qmail@web41214.mail.yahoo.com>
Received: from [24.17.234.175] by web41214.mail.yahoo.com via HTTP; Wed, 28 Jul 2004 08:56:58 PDT
Date: Wed, 28 Jul 2004 08:56:58 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Private extension support (was Re: Q: Put request should return Atom entry?
To: Sam Ruby <rubys@intertwingly.net>, Ken MacLeod <ken@bitsko.slc.ut.us>
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <41078A1F.6010609@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:
> 
> > This is probably obvious to the point of being
> mundane, but the
> > simplest forms of extensions to the protocol will
> be in the area of
> > endpoints (collections of resources in a URL-space
> or active
> > endpoints, like searches) and more Atom-inspired
> resource types
> > (configuration, blogrolls, users, FOAF).
> > 
> > This is all basic REST but nevertheless should be
> mentioned and
> > recommended as routes of extensibility for Atom
> because people often
> > forget it's there -- kinda like breathing.
> 
> IMHO, this argument is strenghtened if we keep:
> 
>    <atom:link href="..." type="..."/>
> 
> And weakened if every unique resource type needs a
> new and unique 
> extension to the format.

Surely you mean 

  <atom:service href="..." />

or whatever that Pace became?

=====
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 Jul 28 12:17: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 MAA12291
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 12:17: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 i6SG0XeC019567;
	Wed, 28 Jul 2004 09:00: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 i6SG0X4U019566;
	Wed, 28 Jul 2004 09:00: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.203])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SG0WMH019552
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 09:00:32 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id 73so209811rnl
        for <atom-syntax@imc.org>; Wed, 28 Jul 2004 09:00:35 -0700 (PDT)
Received: by 10.38.92.20 with SMTP id p20mr204233rnb;
        Wed, 28 Jul 2004 09:00:35 -0700 (PDT)
Message-ID: <14be96d30407280900529180e4@mail.gmail.com>
Date: Wed, 28 Jul 2004 12:00:35 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: elias@torrez.us
Subject: Re: Relative URI references
Cc: Tim Bray <tim.bray@sun.com>, David Powell <djpowell@djpowell.net>,
        atom-syntax@imc.org
In-Reply-To: <905f7c9104072808264144573e@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <834420551.20040727005900@djpowell.net>
 <BB9A9F4A-DF7E-11D8-8C8C-000A95A51C9E@sun.com>
 <792475969.20040727224245@djpowell.net> <D83EF099-E0A3-11D8-8C8C-000A95A51C9E@sun.com> <905f7c9104072808264144573e@mail.gmail.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 Wed, 28 Jul 2004 11:26:51 -0400, Elias Torres <eliast@gmail.com> wrote:
> 
> I have a question since I'm not an expert in xml:base. Can xml:base be
> an attribute of any element in an Atom document?

Yes.  Section 2 of the latest draft:

"""Any element in an Atom Document MAY have an xml:base attribute.  XML
   Base [W3C.REC-xmlbase-20010627] processing MUST be applied to any
   relative URI reference present in an Atom document.  This includes
   such elements and attributes as specified by Atom itself, as well as
   those specified by extensions to Atom."""

> Would it mean then
> that everytime you have a URI you must check upwards for any existing
> xml:base?

Yes.  As per the XML:Base specification [1], if no xml:base is
present, the parent element's xml:base attribute is in scope (and so
on all the way up the tree).  A child's xml:base attribute can be a
relative URI, in which case it is relative to its parent xml:base
(after that is resolved relative to *its* parent, and so on all the
way up the tree).

You also need to track the base URI of the Atom document itself, which
in turn means you need to track the request URI and the
Content-Location header [2] (if present).  As per RFC 2616, the
Content-Location header can itself be relative, in which case it is
relative to the request URI.

As you might expect, I have written a few test cases [3] and
documentation [4] for my own feed parser.  Feedback welcome.

[1] http://www.w3.org/TR/xmlbase/
[2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.14
[3] http://feedparser.org/tests/wellformed/base/
[4] http://feedparser.org/docs/resolving-relative-links.html

> If that's all it takes, it's not that bad, but maybe we need
> to remind people about that. Maybe there's an XPath that does it in
> one query?

I sincerely doubt it (my parser is based on SAX and uses a stack to
track base URIs going in and out of scope), but I would be happy to be
proved wrong.

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Wed Jul 28 12:25: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 MAA13124
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 12:25: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 i6SGD1ia022565;
	Wed, 28 Jul 2004 09:13: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 i6SGD1Wg022564;
	Wed, 28 Jul 2004 09:13: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 i6SGD0C3022552
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 09:13:00 -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 i6SGAj53015081
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 10:10:45 -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 <0I1K0084TL1RVI@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Wed, 28 Jul 2004 10:13:03 -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 <0I1K00KXWL1Q3N@mail.sun.net> for atom-syntax@imc.org; Wed,
 28 Jul 2004 10:13:03 -0600 (MDT)
Date: Wed, 28 Jul 2004 09:13:18 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Relative URI references
In-reply-to: <m3isc840ot.fsf@bitsko.slc.ut.us>
To: Ken MacLeod <ken@bitsko.slc.ut.us>
Cc: atom-syntax@imc.org
Message-id: <099FB762-E0B1-11D8-8C8C-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: <834420551.20040727005900@djpowell.net>
 <BB9A9F4A-DF7E-11D8-8C8C-000A95A51C9E@sun.com>
 <792475969.20040727224245@djpowell.net>
 <D83EF099-E0A3-11D8-8C8C-000A95A51C9E@sun.com>
 <m3isc840ot.fsf@bitsko.slc.ut.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 Jul 28, 2004, at 8:21 AM, Ken MacLeod wrote:

> We also ventured into other interactions and touched on test cases for
> a variety of situations.  It feels to me like we've only begun to
> scratch the surface of the issues with xml:base processing outside of
> a purely "output" resource from a singly-based, known, web served
> document instance.

Candidate text for inclusion in our drafts would be welcome -Tim



From owner-atom-syntax@mail.imc.org  Wed Jul 28 12: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 MAA13763
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 12: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 i6SGPprr025859;
	Wed, 28 Jul 2004 09:25: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 i6SGPpdG025858;
	Wed, 28 Jul 2004 09:25:51 -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 i6SGPoYL025834
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 09:25:50 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net (ip2.198.145.31.iinet.com [198.145.31.2])
	(authenticated bits=0)
	by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i6SGQkBp002966;
	Wed, 28 Jul 2004 12:26:52 -0400
Message-ID: <4107D37D.3060609@intertwingly.net>
Date: Wed, 28 Jul 2004 12:25:33 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Dare Obasanjo <kpako@yahoo.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Private extension support (was Re: Q: Put request should return
 Atom entry?
References: <20040728155658.58331.qmail@web41214.mail.yahoo.com>
In-Reply-To: <20040728155658.58331.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: <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:
> 
>>>This is probably obvious to the point of being
>>
>>mundane, but the
>>
>>>simplest forms of extensions to the protocol will
>>
>>be in the area of
>>
>>>endpoints (collections of resources in a URL-space
>>
>>or active
>>
>>>endpoints, like searches) and more Atom-inspired
>>
>>resource types
>>
>>>(configuration, blogrolls, users, FOAF).
>>>
>>>This is all basic REST but nevertheless should be
>>
>>mentioned and
>>
>>>recommended as routes of extensibility for Atom
>>
>>because people often
>>
>>>forget it's there -- kinda like breathing.
>>
>>IMHO, this argument is strenghtened if we keep:
>>
>>   <atom:link href="..." type="..."/>
>>
>>And weakened if every unique resource type needs a
>>new and unique 
>>extension to the format.
> 
> Surely you mean 
> 
>   <atom:service href="..." />
> 
> or whatever that Pace became?

No, I mean atom:link as described in 
http://www.imc.org/atom-syntax/mail-archive/msg07382.html

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Wed Jul 28 13:45: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 NAA20537
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 13:45: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 i6SHXD4D042800;
	Wed, 28 Jul 2004 10:33: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 i6SHXDvf042799;
	Wed, 28 Jul 2004 10:33:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from bork.markbaker.ca (static-80-155.dsl.cuic.ca [216.126.80.155] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SHXDTd042793
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 10:33:13 -0700 (PDT)
	(envelope-from distobj@acm.org)
Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian))
	id 1BpsJQ-0004TK-00; Wed, 28 Jul 2004 13:33:56 -0400
Date: Wed, 28 Jul 2004 13:33:56 -0400
To: Ken MacLeod <ken@bitsko.slc.ut.us>
Cc: atom-syntax@imc.org
Subject: Re: Relative URI references
Message-ID: <20040728173356.GL30868@markbaker.ca>
References: <834420551.20040727005900@djpowell.net> <BB9A9F4A-DF7E-11D8-8C8C-000A95A51C9E@sun.com> <792475969.20040727224245@djpowell.net> <D83EF099-E0A3-11D8-8C8C-000A95A51C9E@sun.com> <m3isc840ot.fsf@bitsko.slc.ut.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <m3isc840ot.fsf@bitsko.slc.ut.us>
User-Agent: Mutt/1.3.28i
From: Mark Baker <distobj@acm.org>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


On Wed, Jul 28, 2004 at 10:21:38AM -0500, Ken MacLeod wrote:
> Rob, Arve, and I had a rather long discussion in #atom about this
> yesterday[1], and it's more complex than that.

Ay carumba, indeed it is.  I'll have to give this more thought.

Mark.



From owner-atom-syntax@mail.imc.org  Wed Jul 28 14:02: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 OAA21736
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 14:02: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 i6SHop22047509;
	Wed, 28 Jul 2004 10:50: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 i6SHopQx047508;
	Wed, 28 Jul 2004 10:50:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from beattie.info (Debian-exim@26.69-93-195.reverse.theplanet.com [69.93.195.26] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SHoouW047501
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 10:50:50 -0700 (PDT)
	(envelope-from russ@russellbeattie.com)
Received: from [64.164.31.160] (helo=[192.168.0.160])
	by beattie.info with asmtp (Exim 4.33)
	id 1Bpscw-0002bt-M9
	for atom-syntax@imc.org; Wed, 28 Jul 2004 10:54:06 -0700
Message-ID: <4107E77D.8090807@russellbeattie.com>
Date: Wed, 28 Jul 2004 10:50:53 -0700
From: Russell Beattie <russ@russellbeattie.com>
User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040708)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: atomlist <atom-syntax@imc.org>
Subject: Re: AtomME: Posting from a Java mobile phone via the Atom API
References: <BD2CAAA1.44B1%david@blojsom.com>
In-Reply-To: <BD2CAAA1.44B1%david@blojsom.com>
Content-Type: multipart/alternative;
 boundary="------------070507090503070006070509"
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>


This is a multi-part message in MIME format.
--------------070507090503070006070509
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


+1

I hadn't seen that addendum until now. I suggested a header alternative 
to the HTTP verb months ago. It's easy to understand and easy to 
implement. It's definitely my preferred option, rather than mess with 
SOAP or an additional "action" tag.

However, right now the servers out there are using SOAP (or should be). 
What I was suggesting is that anyone advocating hand-coding SOAP is more 
than welcome to edit the J2ME code I published and implement it to see 
how well it works with the current servers implementations. I think 
we'll find that a simple additional header will be much easier on 
everyone involved.

There was some concern in the list that some wireless carriers might 
strip out the request headers. Part of the purpose of the J2ME 
application sample was to see if that was the case. If it is, then we 
have more problems because the security won't work either... but if not, 
I think the the X-ATOM-METHOD is a *great* alternative.

Seriously, we could have something up and running on millions of clients 
tomorrow if it was that simple to do.

-Russ





David Czarnecki wrote:

>  
>
>>The next step is for everyone who has a Java-enabled mobile to try the
>>app. (Feel free to send bug reports to me, just don't expect a prompt
>>answer. :-) ) Do you have a phone which doesn't work? We'll have to
>>figure out why - maybe it's a bug, maybe it's something more serious. Do
>>you have a carrier which strips out the headers? Etc. etc. Then  we can
>>move on to trying to implement the SOAP-based PUT/DELETE alternative and
>>see how well that works. I would *much* rather have some sort of action
>>header or stanza, as it would make this code much more reusable and
>>maintainable, but let's try what's speced now and see.
>>
>>Thanks,
>>
>>-Russ
>>
>>
>>    
>>
>
>Personally I like the alternative proposal of PacePutDelete [1]. As an
>addendum to what I wrote [2] this evening, this proposal seems to be one of
>the simplest things that could work without requiring SOAP on the client and
>server. It's not that SOAP enabling is hard, but implementing this (at least
>how I've got things working in blojsom) would only be a couple lines of code
>to check for the appropriate header and route things accordingly.
>
>-David 
>
>[1] - http://www.intertwingly.net/wiki/pie/PacePutDelete
>[2] - 
>http://www.blojsom.com/blog/blojsom/2004/7/27/atom-blojsom-http-put.html
>
>
>  
>

--------------070507090503070006070509
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
+1<br>
<br>
I hadn't seen that addendum until now. I suggested a header alternative
to the HTTP verb months ago. It's easy to understand and easy to
implement. It's definitely my preferred option, rather than mess with
SOAP or an additional "action" tag. <br>
<br>
However, right now the servers out there are using SOAP (or should be).
What I was suggesting is that anyone advocating hand-coding SOAP is
more than welcome to edit the J2ME code I published and implement it to
see how well it works with the current servers implementations. I think
we'll find that a simple additional header will be much easier on
everyone involved.<br>
<br>
There was some concern in the list that some wireless carriers might
strip out the request headers. Part of the purpose of the J2ME
application sample was to see if that was the case. If it is, then we
have more problems because the security won't work either... but if
not, I think the the X-ATOM-METHOD is a *great* alternative. <br>
<br>
Seriously, we could have something up and running on millions of
clients tomorrow if it was that simple to do.<br>
<br>
-Russ<br>
<br>
<br>
<br>
<br>
<br>
David Czarnecki wrote:
<blockquote cite="midBD2CAAA1.44B1%25david@blojsom.com" type="cite">
  <pre wrap="">
  </pre>
  <blockquote type="cite">
    <pre wrap="">The next step is for everyone who has a Java-enabled mobile to try the
app. (Feel free to send bug reports to me, just don't expect a prompt
answer. :-) ) Do you have a phone which doesn't work? We'll have to
figure out why - maybe it's a bug, maybe it's something more serious. Do
you have a carrier which strips out the headers? Etc. etc. Then  we can
move on to trying to implement the SOAP-based PUT/DELETE alternative and
see how well that works. I would *much* rather have some sort of action
header or stanza, as it would make this code much more reusable and
maintainable, but let's try what's speced now and see.

Thanks,

-Russ


    </pre>
  </blockquote>
  <pre wrap=""><!---->
Personally I like the alternative proposal of PacePutDelete [1]. As an
addendum to what I wrote [2] this evening, this proposal seems to be one of
the simplest things that could work without requiring SOAP on the client and
server. It's not that SOAP enabling is hard, but implementing this (at least
how I've got things working in blojsom) would only be a couple lines of code
to check for the appropriate header and route things accordingly.

-David 

[1] - <a class="moz-txt-link-freetext" href="http://www.intertwingly.net/wiki/pie/PacePutDelete">http://www.intertwingly.net/wiki/pie/PacePutDelete</a>
[2] - 
<a class="moz-txt-link-freetext" href="http://www.blojsom.com/blog/blojsom/2004/7/27/atom-blojsom-http-put.html">http://www.blojsom.com/blog/blojsom/2004/7/27/atom-blojsom-http-put.html</a>


  </pre>
</blockquote>
</body>
</html>

--------------070507090503070006070509--



From owner-atom-syntax@mail.imc.org  Wed Jul 28 14:08: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 OAA22093
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 14:08: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 i6SHxiii049064;
	Wed, 28 Jul 2004 10:59: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 i6SHxi6s049063;
	Wed, 28 Jul 2004 10:59:44 -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 i6SHxhxJ049057
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 10:59:43 -0700 (PDT)
	(envelope-from david@blojsom.com)
Received: (qmail 7058 invoked from network); 28 Jul 2004 17:49:49 -0000
Received: from localhost (127.0.0.1)
  by localhost with SMTP; 28 Jul 2004 17:49:49 -0000
Received: from air643.startdedicated.com (air643.startdedicated.com [69.64.38.51]) 
	by webmail.blojsom.com (IMP) with HTTP 
	for <david@blojsom.com@localhost>; Wed, 28 Jul 2004 13:49:49 -0400
Message-ID: <1091036989.4107e73d86f36@webmail.blojsom.com>
Date: Wed, 28 Jul 2004 13:49:49 -0400
From: David Czarnecki <david@blojsom.com>
To: atomlist <atom-syntax@imc.org>
Subject: Re: AtomME: Posting from a Java mobile phone via the Atom API
References: <BD2CAAA1.44B1%david@blojsom.com> <4107E77D.8090807@russellbeattie.com>
In-Reply-To: <4107E77D.8090807@russellbeattie.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: 69.64.38.51
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


It seems as if a new proposal, PaceAtomActionHeader [1] is open. Sam, can you
add this to the AtomPubIssuesList [2] in the "Not Yet Taken up Or Need to
Revisit" section? 

-David

[1] - http://www.intertwingly.net/wiki/pie/PaceAtomActionHeader
[2] - http://www.intertwingly.net/wiki/pie/AtomPubIssuesList

Quoting Russell Beattie <russ@russellbeattie.com>:

> 
> +1
> 
> I hadn't seen that addendum until now. I suggested a header alternative 
> to the HTTP verb months ago. It's easy to understand and easy to 
> implement. It's definitely my preferred option, rather than mess with 
> SOAP or an additional "action" tag.
> 
> However, right now the servers out there are using SOAP (or should be). 
> What I was suggesting is that anyone advocating hand-coding SOAP is more 
> than welcome to edit the J2ME code I published and implement it to see 
> how well it works with the current servers implementations. I think 
> we'll find that a simple additional header will be much easier on 
> everyone involved.
> 
> There was some concern in the list that some wireless carriers might 
> strip out the request headers. Part of the purpose of the J2ME 
> application sample was to see if that was the case. If it is, then we 
> have more problems because the security won't work either... but if not, 
> I think the the X-ATOM-METHOD is a *great* alternative.
> 
> Seriously, we could have something up and running on millions of clients 
> tomorrow if it was that simple to do.
> 
> -Russ
> 
> 
> 
> 
> 
> David Czarnecki wrote:
> 
> >  
> >
> >>The next step is for everyone who has a Java-enabled mobile to try the
> >>app. (Feel free to send bug reports to me, just don't expect a prompt
> >>answer. :-) ) Do you have a phone which doesn't work? We'll have to
> >>figure out why - maybe it's a bug, maybe it's something more serious. Do
> >>you have a carrier which strips out the headers? Etc. etc. Then  we can
> >>move on to trying to implement the SOAP-based PUT/DELETE alternative and
> >>see how well that works. I would *much* rather have some sort of action
> >>header or stanza, as it would make this code much more reusable and
> >>maintainable, but let's try what's speced now and see.
> >>
> >>Thanks,
> >>
> >>-Russ
> >>
> >>
> >>    
> >>
> >
> >Personally I like the alternative proposal of PacePutDelete [1]. As an
> >addendum to what I wrote [2] this evening, this proposal seems to be one of
> >the simplest things that could work without requiring SOAP on the client
> and
> >server. It's not that SOAP enabling is hard, but implementing this (at
> least
> >how I've got things working in blojsom) would only be a couple lines of
> code
> >to check for the appropriate header and route things accordingly.
> >
> >-David 
> >
> >[1] - http://www.intertwingly.net/wiki/pie/PacePutDelete
> >[2] - 
> >http://www.blojsom.com/blog/blojsom/2004/7/27/atom-blojsom-http-put.html
> >
> >
> >  
> >
> 






From owner-atom-syntax@mail.imc.org  Wed Jul 28 14:12: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 OAA22520
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 14: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 i6SI2dgV050023;
	Wed, 28 Jul 2004 11: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 i6SI2d56050022;
	Wed, 28 Jul 2004 11:02:39 -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 i6SI2bYL049928
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 11:02:38 -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 i6SI2Z53012059
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 13:02:35 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6SI2Y6T012055;
	Wed, 28 Jul 2004 13:02:34 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: <atom-syntax@imc.org>
Subject: Re: AtomME: Posting from a Java mobile phone via the Atom API
References: <BD2CAAA1.44B1%david@blojsom.com>
	<4107E77D.8090807@russellbeattie.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 28 Jul 2004 13:02:34 -0500
In-Reply-To: <4107E77D.8090807@russellbeattie.com>
Message-ID: <m3acxk3t8l.fsf@bitsko.slc.ut.us>
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


Russell Beattie <russ@russellbeattie.com> writes:

> I hadn't seen that addendum [to PacePutDelete] until now. I
> suggested a header alternative to the HTTP verb months ago. It's
> easy to understand and easy to implement. It's definitely my
> preferred option, rather than mess with SOAP or an additional
> "action" tag.

Note, PacePutDelete was withdrawn and the part that was the addendum
was reincarnated in PaceAtomActionHeader.

    http://intertwingly.net/wiki/pie/PaceAtomActionHeader

  -- Ken



From owner-atom-syntax@mail.imc.org  Wed Jul 28 14: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 OAA24121
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 14:37: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 i6SIRFKr057207;
	Wed, 28 Jul 2004 11:27: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 i6SIRFNC057206;
	Wed, 28 Jul 2004 11:27: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 i6SIREQu057199
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 11:27:14 -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 i6SIP053026696
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 12:25:00 -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 <0I1K00G01R5KHD@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com)
 for atom-syntax@imc.org; Wed, 28 Jul 2004 14:27:17 -0400 (EDT)
Received: from mercury (vpn-129-150-32-29.Central.Sun.COM [129.150.32.29])
 by bur-mail1.east.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
 with ESMTP id <0I1K00D52R9HWH@bur-mail1.east.sun.com> for atom-syntax@imc.org;
 Wed, 28 Jul 2004 14:27:17 -0400 (EDT)
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1Bpt8j-0001wW-00	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 14:26:57 -0400
X-URL: http://nwalsh.com/
Date: Wed, 28 Jul 2004 14:26:57 -0400
From: Norman Walsh <ndw@nwalsh.com>
Subject: Re: PaceItemIDIsNewsML: Struggling for compromise
In-reply-to: <09B394D6-DEBF-11D8-8C8C-000A95A51C9E@sun.com>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <87fz7cxa1a.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: <20040726034817.11800.qmail@web41214.mail.yahoo.com>
 <09B394D6-DEBF-11D8-8C8C-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-Type: text/plain

/ Tim Bray <Tim.Bray@Sun.COM> was heard to say:
| BTW, with specific reference to urn:newsml:, I think it's a sensible
| and well-designed URN namespace, but I think you're going to have
| trouble getting past the problem that leaps to my eye when I read the
| RFC3085 abstract:
|    "This document describes a URN (Uniform Resource Name) namespace for
|     identifying NewsML NewsItems.  A NewsItem is an information resource
|     that is expressible as a NewsML element within a NewsML document
|     conforming to the NewsML Document Type Declaration (DTD) as defined
|     by the International Press Telecommunications Council (IPTC)."

You might find RFC 3151 "A URN Namespace for Public Identifiers" a little
less troublesome along those lines.

Interestingly, I used such URNs as IDs for a while. You can still find them
in the everything feed, http://norman.walsh.name/atom/everything.xml
For example:

   <entry>
      <title>Dinner with Vermeer</title>
      <link rel="alternate" type="text/html"
            href="http://norman.walsh.name/2004/02/08/vermeer"/>
      <id>urn:publicid:%2B:IDN+norman.walsh.name:DOCUMENT+007,023</id>
      <issued>2004-04-01T04:22:00Z</issued>
      <modified>2004-04-01T13:35:54Z</modified>
      <dc:subject xmlns:dc="http://purl.org/dc/elements/1.1/">Theater</dc:subject>
      <dc:subject xmlns:dc="http://purl.org/dc/elements/1.1/">Reviews</dc:subject>
      <summary>On Friday and Saturday evening, Amherst Writers &amp;
Artists Press presented a theatrical fundraiser: dinner
accompanied by a series of tableaux
vivants of Vermeer paintings. [Update: there are now 35 known Vermeer paintings.]
</summary>
   </entry>

I have carefully preserved these identifiers even as I've reverted to HTTP URIs.
I now wonder if I'll feel inclined to re-revert. Hmm.

And, in the off chance that you want to retreive a representation of
the entry and you find that you only have the atom:id at hand, you
have only to include http://norman.walsh.name/catalog.xml in your XML
Catalog path and it'll resolve just fine. I'm just sayin'.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Extinction, n. The raw material out of
http://nwalsh.com/            | which theology created the future
                              | state.--Ambrose Bierce

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBBB+/xOyltUcwYWjsRAhN2AJ97/oE8Wa7G5nth2MKyZGRNLpyBaQCgiqvA
Ao0ZXuz9CYvTwYGa51VTGU0=
=qy28
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Wed Jul 28 14: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 OAA24146
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 14: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 i6SIQU9b056990;
	Wed, 28 Jul 2004 11: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 i6SIQUW7056989;
	Wed, 28 Jul 2004 11:26:30 -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 i6SIQUqP056938
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 11:26:30 -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 i6SIQT4Q014916;
	Wed, 28 Jul 2004 11:26:29 -0700
Received: from ussjex01.amer.bea.com ([172.16.120.50]) by ussjfe01.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Wed, 28 Jul 2004 11:26:30 -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: Private extension support (was Re: Q: Put request should return Atom entry?
Date: Wed, 28 Jul 2004 11:26:27 -0700
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF09333C14@ussjex01.amer.bea.com>
Thread-Topic: Private extension support (was Re: Q: Put request should return Atom entry?
Thread-Index: AcR0k+6gHZ2bHSg6To6etWOW9MuE+QAOhZDg
From: "David Orchard" <dorchard@bea.com>
To: "Sam Ruby" <rubys@intertwingly.net>, "Ken MacLeod" <ken@bitsko.slc.ut.us>
Cc: "Atom Syntax" <atom-syntax@imc.org>
X-OriginalArrivalTime: 28 Jul 2004 18:26:30.0023 (UTC) FILETIME=[66D15170:01C474D0]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6SIQUqP056983
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


If I understand this correctly, there is an extensibility point that
needs some more discussion.  Couple of clarifications about the
cardinalities.  

Could:
- a new resource type be created without adding new endpoints?  I would
think not as each new resource type would be deployed at a new endpoint.
- a new endpoint be created without adding a resource type?  I would
think so.

I think that Sam is arguing that we should constrain link extensibility
to be types and endpoints, and not allow arbitrary extensibility of
types/endpoints in links.  

I also wonder about backwards compatibility of interfaces.  If it is
possible to add new resource types, is there any possibility that the
additions will not be backwards compatible?  Generally we think that
adding operations is a backwards compatible change because an old client
simply won't invoke the new operation.  But imagine a new resource type
and related endpoints are added into a site.  Is it possible that a
client may be required to invoke the new resource type at some point?
There is roughly a "workflow" (I tread carefully here) that will require
the client to invoke the resource type.  In this case, it may be
advisable that the client will want to fail earlier rather than later.
This is what I talked about in one of my blog entries that failing a
"protocol" mustUnderstand is quite different in time that a format
mustUnderstand, and you typically want to fail earlier in protocol mUs.

I can easily update the Pace on this if I'm at all on the right track on
these.

What's ironic about atom:link as Sam talks about it is basically a
wsdl:service element.  It contains an address.  WSDL uses a "binding"
which indirectly refers to an interface, and atom:link has skipped the
binding and gone directly to the interface.  Has the issue about
bindings and links been resolved, ie is a reference to a resource
required to support all bindings or at least one?

Dave


> -----Original Message-----
> From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-
> syntax@mail.imc.org] On Behalf Of Sam Ruby
> Sent: Wednesday, July 28, 2004 4:13 AM
> To: Ken MacLeod
> Cc: Atom Syntax
> Subject: Re: Private extension support (was Re: Q: Put request should
> return Atom entry?
> 
> 
> Ken MacLeod wrote:
> 
> > "David Orchard" <dorchard@bea.com> writes:
> >
> >>There are 2 different types of extensions that I see:
> >>1. An extension to the protocol is done, ie a new method is added.
> >>2. An extension to the format is done.
> >
> > This is probably obvious to the point of being mundane, but the
> > simplest forms of extensions to the protocol will be in the area of
> > endpoints (collections of resources in a URL-space or active
> > endpoints, like searches) and more Atom-inspired resource types
> > (configuration, blogrolls, users, FOAF).
> >
> > This is all basic REST but nevertheless should be mentioned and
> > recommended as routes of extensibility for Atom because people often
> > forget it's there -- kinda like breathing.
> 
> IMHO, this argument is strenghtened if we keep:
> 
>    <atom:link href="..." type="..."/>
> 
> And weakened if every unique resource type needs a new and unique
> extension to the format.
> 
> - Sam Ruby




From owner-atom-syntax@mail.imc.org  Wed Jul 28 16:31:46 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02729
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 16: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 i6SKHX0J082666;
	Wed, 28 Jul 2004 13:17: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 i6SKHXMB082665;
	Wed, 28 Jul 2004 13:17: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 (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SKHVcJ082636
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 13:17: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 938B77C122; Wed, 28 Jul 2004 23:12:57 +0200 (CEST)
To: "Tim Bray" <Tim.Bray@sun.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Relative URI references
References: <834420551.20040727005900@djpowell.net> <BB9A9F4A-DF7E-11D8-8C8C-000A95A51C9E@sun.com> <792475969.20040727224245@djpowell.net> <D83EF099-E0A3-11D8-8C8C-000A95A51C9E@sun.com> <m3isc840ot.fsf@bitsko.slc.ut.us> <099FB762-E0B1-11D8-8C8C-000A95A51C9E@sun.com>
Message-ID: <opsbu6twvzuvpchu@quark>
Date: Wed, 28 Jul 2004 22:21:22 +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: <099FB762-E0B1-11D8-8C8C-000A95A51C9E@sun.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Wed, 28 Jul 2004 09:13:18 -0700, Tim Bray <Tim.Bray@Sun.COM> wrote:

> Candidate text for inclusion in our drafts would be welcome -Tim

Specification text for atom:id exists in PaceRecommendIdScheme[1]:

   "If atom:id is dereferencable, it MUST be an absolute URI and MUST
    NOT be relative."

Not sure if the wording is the best, so we might need to work on that, but  
it at least captures the essence: Relative URI's should be forbidden in  
atom:id.

____
[1] <url: http://intertwingly.net/wiki/pie/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  Wed Jul 28 16:51:33 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04157
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 16:51:32 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SKds5u088407;
	Wed, 28 Jul 2004 13:39: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 i6SKdsfq088406;
	Wed, 28 Jul 2004 13:39: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.194])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SKdraH088391
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 13:39:53 -0700 (PDT)
	(envelope-from eliast@gmail.com)
Received: by mproxy.gmail.com with SMTP id 78so128774rnk
        for <atom-syntax@imc.org>; Wed, 28 Jul 2004 13:39:54 -0700 (PDT)
Received: by 10.38.209.3 with SMTP id h3mr110146rng;
        Wed, 28 Jul 2004 13:39:54 -0700 (PDT)
Message-ID: <905f7c9104072813395d8cac05@mail.gmail.com>
Date: Wed, 28 Jul 2004 16:39:54 -0400
From: Elias Torres <eliast@gmail.com>
Reply-To: elias@torrez.us
To: "Asbjørn Ulsberg" <asbjorn@tigerstaden.no>
Subject: Re: Relative URI references
Cc: Tim Bray <tim.bray@sun.com>, Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <opsbu6twvzuvpchu@quark>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
References: <834420551.20040727005900@djpowell.net> <BB9A9F4A-DF7E-11D8-8C8C-000A95A51C9E@sun.com> <792475969.20040727224245@djpowell.net> <D83EF099-E0A3-11D8-8C8C-000A95A51C9E@sun.com> <m3isc840ot.fsf@bitsko.slc.ut.us> <099FB762-E0B1-11D8-8C8C-000A95A51C9E@sun.com> <opsbu6twvzuvpchu@quark>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6SKdsaH088393
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'd say that atom:id MUST be an absolute URI always, whether is
dereferencable or not.

Elias

On Wed, 28 Jul 2004 22:21:22 +0200, Asbjørn Ulsberg
<asbjorn@tigerstaden.no> wrote:
> 
> On Wed, 28 Jul 2004 09:13:18 -0700, Tim Bray <Tim.Bray@Sun.COM> wrote:
> 
> > Candidate text for inclusion in our drafts would be welcome -Tim
> 
> Specification text for atom:id exists in PaceRecommendIdScheme[1]:
> 
>    "If atom:id is dereferencable, it MUST be an absolute URI and MUST
>     NOT be relative."
> 
> Not sure if the wording is the best, so we might need to work on that, but
> it at least captures the essence: Relative URI's should be forbidden in
> atom:id.
> 
> ____
> [1] <url: http://intertwingly.net/wiki/pie/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  Wed Jul 28 16:57: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 QAA04485
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 16:56:59 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SKi8Fa089391;
	Wed, 28 Jul 2004 13:44: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 i6SKi84i089390;
	Wed, 28 Jul 2004 13:44:08 -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 i6SKi7dL089376
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 13:44:08 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net (ip2.198.145.31.iinet.com [198.145.31.2])
	(authenticated bits=0)
	by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i6SKjFUr016439
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 16:45:18 -0400
Message-ID: <41081011.2020700@intertwingly.net>
Date: Wed, 28 Jul 2004 16:44:01 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 Syntax <atom-syntax@imc.org>
Subject: New AtomPubIssuesList for 2004/07/16
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


http://www.intertwingly.net/wiki/pie/AtomPubIssuesList

Now that things are calming down again, I'm resuming the scheduling of 
issues.  This round, I've scheduled two major areas (one in the format, 
one in the protocol), and one minor item.

For the format, there is a number of issues related to autodiscovery. 
Key to this is deciding if autodiscovery is something that the workgroup 
wants to take on, and if so, should it be a separate RFC.  Part of this 
discussion also involves the comparison of URIs, something that appears 
at first to be deceptively simple, but in reality can be complicated if 
we let it be.

For the protocol, I've scheduled PaceResource and 
PaceSimpleResourcePosting.  In reality, there are quite a few related 
issues, but it seems to me that the core issue is whether or not it will 
the ability to post a naked binary object is a desirable feature.  The 
hope is that a stake in the ground on this smaller question is both 
possible without first resolving the larger issue, and if so, will help 
in the resolution of the larger issues.

I've also scheduled PaceUriOrItsSuccessor.  This is complete and hasn't 
yet drawn any competing proposals.

Also, I'm requesting that PaceUseBrokenLinkSyntaxEverywhere be closed. 
Its title leads one to believe that the proposal is not serious, and its 
creation was not announced on the mailing list.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Wed Jul 28 17:01: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 RAA04730
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 17:01: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 i6SKr5kP091528;
	Wed, 28 Jul 2004 13: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 i6SKr5NU091527;
	Wed, 28 Jul 2004 13:53: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 i6SKr5JQ091520
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 13:53:05 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net (ip195.198.145.31.iinet.com [198.145.31.195])
	(authenticated bits=0)
	by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i6SKsD1D016887;
	Wed, 28 Jul 2004 16:54:14 -0400
Message-ID: <4108122B.4000206@intertwingly.net>
Date: Wed, 28 Jul 2004 16:52:59 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Russell Beattie <russ@russellbeattie.com>
CC: atomlist <atom-syntax@imc.org>
Subject: Re: AtomME: Posting from a Java mobile phone via the Atom API
References: <BD2CAAA1.44B1%david@blojsom.com> <4107E77D.8090807@russellbeattie.com>
In-Reply-To: <4107E77D.8090807@russellbeattie.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


Russell Beattie wrote:
> 
> +1
> 
> I hadn't seen that addendum until now. I suggested a header alternative 
> to the HTTP verb months ago. It's easy to understand and easy to 
> implement. It's definitely my preferred option, rather than mess with 
> SOAP or an additional "action" tag.
> 
> However, right now the servers out there are using SOAP (or should be). 
> What I was suggesting is that anyone advocating hand-coding SOAP is more 
> than welcome to edit the J2ME code I published and implement it to see 
> how well it works with the current servers implementations. I think 
> we'll find that a simple additional header will be much easier on 
> everyone involved.

 From a Java client perspective, the essential change is to replace a 
conn.setRequestProperty with one or more xml.append statements.

> There was some concern in the list that some wireless carriers might 
> strip out the request headers. Part of the purpose of the J2ME 
> application sample was to see if that was the case. If it is, then we 
> have more problems because the security won't work either... 

There is a syntax defined for encoding this information in the body:

http://www.oasis-open.org/committees/wss/documents/WSS-Username-02-0223-merged.pdf

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Wed Jul 28 17:04: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 RAA04823
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 17: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 i6SKpEcv091109;
	Wed, 28 Jul 2004 13: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 i6SKpEEM091108;
	Wed, 28 Jul 2004 13:51: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 i6SKpDo3091092
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 13:51: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 i6SKn053008053
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 14:49:00 -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 <0I1K008OQXXH7N@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Wed, 28 Jul 2004 14:51:18 -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 <0I1K00FDKXXH46@mail.sun.net> for atom-syntax@imc.org; Wed,
 28 Jul 2004 14:51:17 -0600 (MDT)
Date: Wed, 28 Jul 2004 13:51:33 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceItemIDIsNewsML: Struggling for compromise
In-reply-to: <87fz7cxa1a.fsf@nwalsh.com>
To: Norman Walsh <ndw@nwalsh.com>
Cc: Atom Syntax <atom-syntax@imc.org>
Message-id: <E903E5A9-E0D7-11D8-BDEA-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: <20040726034817.11800.qmail@web41214.mail.yahoo.com>
 <09B394D6-DEBF-11D8-8C8C-000A95A51C9E@sun.com> <87fz7cxa1a.fsf@nwalsh.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 Jul 28, 2004, at 11:26 AM, Norman Walsh wrote:

> You might find RFC 3151 "A URN Namespace for Public Identifiers" a 
> little
> less troublesome along those lines.

And, since we're casting about in the space of registered URI schemes 
and URN namespaces:

I followed  http://www.iana.org/assignments/uri-schemes to RFC1738 to 
RFC1036, section 2.1.5.

    news:/ongoing/When/200x/2004/02/20/GenxStatus@www.tbray.org

Now, RFC1036 does "strongly discourage" the use of slashes.  But that 
aside, we have a perfectly legal URI in a registered scheme... No, I 
probably don't think this is a good idea, but it's no more obviously 
crazy than some of the others we've been offered. -Tim



From owner-atom-syntax@mail.imc.org  Wed Jul 28 17: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 RAA05635
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 17: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 i6SL6JDb094950;
	Wed, 28 Jul 2004 14:06:19 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6SL6Jlf094949;
	Wed, 28 Jul 2004 14:06: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 i6SL6IY3094924
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 14:06: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 CFCAA7C0F3; Thu, 29 Jul 2004 00:01:51 +0200 (CEST)
Date: Wed, 28 Jul 2004 23:10:25 +0200
To: elias@torrez.us
Subject: Re: Relative URI references
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <834420551.20040727005900@djpowell.net> <BB9A9F4A-DF7E-11D8-8C8C-000A95A51C9E@sun.com> <792475969.20040727224245@djpowell.net> <D83EF099-E0A3-11D8-8C8C-000A95A51C9E@sun.com> <m3isc840ot.fsf@bitsko.slc.ut.us> <099FB762-E0B1-11D8-8C8C-000A95A51C9E@sun.com> <opsbu6twvzuvpchu@quark> <905f7c9104072813395d8cac05@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: <opsbu83nyluvpchu@quark>
In-Reply-To: <905f7c9104072813395d8cac05@mail.gmail.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Wed, 28 Jul 2004 16:39:54 -0400, Elias Torres <eliast@gmail.com> wrote:

> I'd say that atom:id MUST be an absolute URI always, whether is
> dereferencable or not.

Sure. Spec text changed to:

   "atom:id MUST NOT under any circumstance be relative. It MUST
    always be a complete, opaque and absolute URI that doesn't
    require any post-processing to fulfil the above requirements
    for persistency and universally uniqueness."

-- 
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 Jul 28 17:23: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 RAA06131
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 17: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 i6SLDkAn096782;
	Wed, 28 Jul 2004 14:13:46 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6SLDkuJ096781;
	Wed, 28 Jul 2004 14:13:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SLDj2m096728;
	Wed, 28 Jul 2004 14:13:45 -0700 (PDT)
	(envelope-from jasnell@us.ibm.com)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11])
	by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i6SLDiu3177826;
	Wed, 28 Jul 2004 17:13:44 -0400
Received: from d03nm122.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 i6SLDhig377484;
	Wed, 28 Jul 2004 15:13:44 -0600
In-Reply-To: <905f7c9104072813395d8cac05@mail.gmail.com>
To: elias@torrez.us
Cc: "=?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?=" <asbjorn@tigerstaden.no>,
        Atom-Syntax <atom-syntax@imc.org>, owner-atom-syntax@mail.imc.org,
        Tim Bray <tim.bray@sun.com>
MIME-Version: 1.0
Subject: Re: Relative URI references
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
From: James M Snell <jasnell@us.ibm.com>
X-MIMETrack: S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/28/2004 02:09:52 PM,
	Serialize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/28/2004 02:09:52 PM,
	Serialize complete at 07/28/2004 02:09:52 PM,
	Itemize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/28/2004 02:09:53 PM,
	S/MIME Sign complete at 07/28/2004 02:09:53 PM,
	S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/28/2004 02:13:41 PM,
	S/MIME Sign complete at 07/28/2004 02:13:41 PM,
	Serialize by Router on D03NM122/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at
 07/28/2004 15:13:44,
	Serialize complete at 07/28/2004 15:13:44
Message-ID: <OF5C2820A5.7C4F2BBD-ON88256EDF.00743572-88256EDF.00749BFE@us.ibm.com>
Date: Wed, 28 Jul 2004 15:13:41 -0600
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z8752_boundary_sign
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>


This is an S/MIME signed message.

---------z8752_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 0074429288256EDF_="

This is a multipart message in MIME format.
--=_alternative 0074429288256EDF_=
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

+1 to atom:id ALWAYS being an absolute URI

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



Elias Torres <eliast@gmail.com>=20
Sent by: owner-atom-syntax@mail.imc.org
07/28/2004 01:39 PM
Please respond to
elias


To
"Asbj=F8rn Ulsberg" <asbjorn@tigerstaden.no>
cc
Tim Bray <tim.bray@sun.com>, Atom-Syntax <atom-syntax@imc.org>
Subject
Re: Relative URI references







I'd say that atom:id MUST be an absolute URI always, whether is
dereferencable or not.

Elias

On Wed, 28 Jul 2004 22:21:22 +0200, Asbj=F8rn Ulsberg
<asbjorn@tigerstaden.no> wrote:
>=20
> On Wed, 28 Jul 2004 09:13:18 -0700, Tim Bray <Tim.Bray@Sun.COM> wrote:
>=20
> > Candidate text for inclusion in our drafts would be welcome -Tim
>=20
> Specification text for atom:id exists in PaceRecommendIdScheme[1]:
>=20
>    "If atom:id is dereferencable, it MUST be an absolute URI and MUST
>     NOT be relative."
>=20
> Not sure if the wording is the best, so we might need to work on that,=20
but
> it at least captures the essence: Relative URI's should be forbidden in
> atom:id.
>=20
> =5F=5F=5F=5F
> [1] <url: http://intertwingly.net/wiki/pie/PaceRecommendIdScheme>
>=20
> --
> Asbj=F8rn Ulsberg         -=3D|=3D-        asbjornu@hotmail.com
> =ABHe's a loathsome offensive brute, yet I can't look away=BB
>=20
>



--=_alternative 0074429288256EDF_=
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable


<br><font size=3D2 face=3D"sans-serif">+1 to atom:id ALWAYS being an absolu=
te
URI</font>
<br>
<br><font size=3D2 face=3D"sans-serif">- James M Snell<br>
 &nbsp;jasnell@us.ibm.com<br>
 &nbsp;http://www.ibm.com<br>
 &nbsp;(877) 511-5082 / Office<br>
 &nbsp;930-1979 / Tie Line</font>
<br>
<br>
<br>
<table width=3D100%>
<tr valign=3Dtop>
<td width=3D40%><font size=3D1 face=3D"sans-serif"><b>Elias Torres &lt;elia=
st@gmail.com&gt;</b>
</font>
<br><font size=3D1 face=3D"sans-serif">Sent by: owner-atom-syntax@mail.imc.=
org</font>
<p><font size=3D1 face=3D"sans-serif">07/28/2004 01:39 PM</font>
<table border>
<tr valign=3Dtop>
<td bgcolor=3Dwhite>
<div align=3Dcenter><font size=3D1 face=3D"sans-serif">Please respond to<br>
elias</font></div></table>
<br>
<td width=3D59%>
<table width=3D100%>
<tr>
<td>
<div align=3Dright><font size=3D1 face=3D"sans-serif">To</font></div>
<td valign=3Dtop><font size=3D1 face=3D"sans-serif">&quot;Asbj=F8rn Ulsberg=
&quot;
&lt;asbjorn@tigerstaden.no&gt;</font>
<tr>
<td>
<div align=3Dright><font size=3D1 face=3D"sans-serif">cc</font></div>
<td valign=3Dtop><font size=3D1 face=3D"sans-serif">Tim Bray &lt;tim.bray@s=
un.com&gt;,
Atom-Syntax &lt;atom-syntax@imc.org&gt;</font>
<tr>
<td>
<div align=3Dright><font size=3D1 face=3D"sans-serif">Subject</font></div>
<td valign=3Dtop><font size=3D1 face=3D"sans-serif">Re: Relative URI refere=
nces</font></table>
<br>
<table>
<tr valign=3Dtop>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=3D2><tt><br>
I'd say that atom:id MUST be an absolute URI always, whether is<br>
dereferencable or not.<br>
<br>
Elias<br>
<br>
On Wed, 28 Jul 2004 22:21:22 +0200, Asbj=F8rn Ulsberg<br>
&lt;asbjorn@tigerstaden.no&gt; wrote:<br>
&gt; <br>
&gt; On Wed, 28 Jul 2004 09:13:18 -0700, Tim Bray &lt;Tim.Bray@Sun.COM&gt;
wrote:<br>
&gt; <br>
&gt; &gt; Candidate text for inclusion in our drafts would be welcome -Tim<=
br>
&gt; <br>
&gt; Specification text for atom:id exists in PaceRecommendIdScheme[1]:<br>
&gt; <br>
&gt; &nbsp; &nbsp;&quot;If atom:id is dereferencable, it MUST be an absolute
URI and MUST<br>
&gt; &nbsp; &nbsp; NOT be relative.&quot;<br>
&gt; <br>
&gt; Not sure if the wording is the best, so we might need to work on that,
but<br>
&gt; it at least captures the essence: Relative URI's should be forbidden
in<br>
&gt; atom:id.<br>
&gt; <br>
&gt; =5F=5F=5F=5F<br>
&gt; [1] &lt;url: http://intertwingly.net/wiki/pie/PaceRecommendIdScheme&gt=
;<br>
&gt; <br>
&gt; --<br>
&gt; Asbj=F8rn Ulsberg &nbsp; &nbsp; &nbsp; &nbsp; -=3D|=3D- &nbsp; &nbsp; =
&nbsp;
&nbsp;asbjornu@hotmail.com<br>
&gt; =ABHe's a loathsome offensive brute, yet I can't look away=BB<br>
&gt; <br>
&gt;<br>
<br>
</tt></font>
<br>
--=_alternative 0074429288256EDF_=--

---------z8752_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIIUOAIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIISWDCCAtow
ggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1
aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAy
MDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA629xc49NpAPz
cAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7glzJKgPkPzlTZZfznznGbmAWVnNBQ
lyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnwNclOnnP2sKufuPzbTImQTTi5c8JZNZcM
J0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEEBAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1Ud
DgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAPBgNVHRMBAf8EBTADAQH/MDEGA1UdJQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUH
AwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvu
jQupk2oCScMd3FIHLE7hOfu8YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14ke
McF9ViNdewEoBGiAycUq8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIC2jCCAkOgAwIB
AgIDAxS2MA0GCSqGSIb3DQEBBAUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwMTE0MjIw
NzExWhcNMTExMjMxMjIwNzExWjBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25h
bCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrb3Fzj02kA/NwCy5KFMiY
tFgyTJ6kMSQLVSs9uwVHIAVkqy/enDQwZ9b/7uCXMkqA+Q/OVNll/OfOcZuYBZWc0FCXI9qw60KO
J/rTd65FdF4dwp8cw8si0qjOJtYg8cm46fA1yU6ec/awq5+4/NtMiZBNOLlzwlk1lwwnRgXNNwID
AQABo4GqMIGnMBEGCWCGSAGG+EIBAQQEAwIAhzAOBgNVHQ8BAf8EBAMCAcYwHQYDVR0OBBYEFK5U
DpLqqDOpKyQtx8hvMNze80pAMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMA8GA1Ud
EwEB/wQFMAMBAf8wMQYDVR0lBCowKAYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYB
BQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAMnJ7c2YLyrY/PKlFl+7sm8NENfWtFxqdm+6NC6mTagJJ
wx3cUgcsTuE5+7xh9+/G0tTfLzA1qZAQ5GNMPXvmoB9+vJfKnC2JWMFQpIOUEJDXiR4xwX1WI117
ASgEaIDJxSrxHcuuV/hMIO9bgZ6C41MUVmdLTKBgBOImTuIPK8QwggMgMIICiaADAgECAgQ13vTP
MA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQL
EyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0MTUxWhcN
MTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMk
RXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKKlQRkrPFr
U18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkwrFEeO68r
1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOgYaRfMF0x
CzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBD
ZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAxODA4MjIx
NjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAdBgNV
HQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0HQQAEDTAL
GwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwlMQ0AppJu
f7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn00DbOyZY
sih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMgMIICiaADAgEC
AgQ13vTPMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0
MTUxWhcNMTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsG
A1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKK
lQRkrPFrU18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkw
rFEeO68r1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOg
YaRfMF0xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNl
Y3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAx
ODA4MjIxNjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAdBgNVHQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0H
QQAEDTALGwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwl
MQ0AppJuf7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn
00DbOyZYsih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMmMIIC
j6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIxNjM2NTRaMIGFMQsw
CQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEXMBUGA1UEAxMOSmFt
ZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkqhkiG9w0BCQEWEmph
c25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwKpbDG3zMatEuuOT
FYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSyd+7nwqAvbBfPj+0S
vcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7tBJlLrwDRCMoNlPuQ
Kg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQW
BBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOgFAwSamFzbmVs
bEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pAMCcGA1UdJQQgMB4G
CCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAZMKevB7dFfb9
23OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY8BjwVHxiYgG4xkxf
B1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOIzj3lz3xd+uOzqRFg
/Wsg/VMwggMmMIICj6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAy
BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNV
BAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIx
NjM2NTRaMIGFMQswCQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEX
MBUGA1UEAxMOSmFtZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkq
hkiG9w0BCQEWEmphc25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
wKpbDG3zMatEuuOTFYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSy
d+7nwqAvbBfPj+0SvcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7t
BJlLrwDRCMoNlPuQKg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQD
AgXgMB0GA1UdDgQWBBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcU
AgOgFAwSamFzbmVsbEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA
MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQAD
gYEAZMKevB7dFfb923OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY
8BjwVHxiYgG4xkxfB1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOI
zj3lz3xd+uOzqRFg/Wsg/VMxggG7MIIBtwIBATBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJ
bnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0g
Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwF+kzAJBgUrDgMCGgUAoIGiMBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDcyODIxMDk1M1owIwYJKoZIhvcNAQkEMRYE
FE7Ve5ySYCQ/BR29A2gOj7DB0SgLMEMGCSqGSIb3DQEJDzE2MDQwBwYFKw4DAh0wDgYIKoZIhvcN
AwICAgCAMAoGCCqGSIb3DQMHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGALe4cilUq
91sCmGXctwDfZrzukeWDvQBmxlo76lIW+6MsYH8UCql2+jYcGP9twN+d0JL2vwrVedC/hGLpuGAT
r4kA5FJ4Ch4r1WZ6NdxBG4elMtNQjzNQB8Fn+UXAtiU3HGzbizhYKAxjg42gKLd9IWcheZ173lXN
l+hep8jcVuAAAAAA

---------z8752_boundary_sign--



From owner-atom-syntax@mail.imc.org  Wed Jul 28 18: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 SAA11450
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 18:18: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 i6SM4c52009573;
	Wed, 28 Jul 2004 15: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 i6SM4cMu009567;
	Wed, 28 Jul 2004 15:04: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 i6SM4Z72009508
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 15:04:36 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net (ip2.198.145.31.iinet.com [198.145.31.2])
	(authenticated bits=0)
	by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i6SM5i5K020551
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 18:05:47 -0400
Message-ID: <410822EE.2010807@intertwingly.net>
Date: Wed, 28 Jul 2004 18:04:30 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 Syntax <atom-syntax@imc.org>
Subject: New AtomPubIssuesList for 2004/07/28
References: <41081011.2020700@intertwingly.net>
In-Reply-To: <41081011.2020700@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:

Oops, the subject line was wrong.

> http://www.intertwingly.net/wiki/pie/AtomPubIssuesList
> 
> Now that things are calming down again, I'm resuming the scheduling of 
> issues.  This round, I've scheduled two major areas (one in the format, 
> one in the protocol), and one minor item.
> 
> For the format, there is a number of issues related to autodiscovery. 
> Key to this is deciding if autodiscovery is something that the workgroup 
> wants to take on, and if so, should it be a separate RFC.  Part of this 
> discussion also involves the comparison of URIs, something that appears 
> at first to be deceptively simple, but in reality can be complicated if 
> we let it be.
> 
> For the protocol, I've scheduled PaceResource and 
> PaceSimpleResourcePosting.  In reality, there are quite a few related 
> issues, but it seems to me that the core issue is whether or not it will 
> the ability to post a naked binary object is a desirable feature.  The 
> hope is that a stake in the ground on this smaller question is both 
> possible without first resolving the larger issue, and if so, will help 
> in the resolution of the larger issues.
> 
> I've also scheduled PaceUriOrItsSuccessor.  This is complete and hasn't 
> yet drawn any competing proposals.
> 
> Also, I'm requesting that PaceUseBrokenLinkSyntaxEverywhere be closed. 
> Its title leads one to believe that the proposal is not serious, and its 
> creation was not announced on the mailing list.
> 
> - Sam Ruby
> 



From owner-atom-syntax@mail.imc.org  Wed Jul 28 18:20: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 SAA11608
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 18:20: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 i6SM9FAd011671;
	Wed, 28 Jul 2004 15:09: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 i6SM9EAU011670;
	Wed, 28 Jul 2004 15:09: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 i6SM9EEU011662
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 15:09:14 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net (ip2.198.145.31.iinet.com [198.145.31.2])
	(authenticated bits=0)
	by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i6SMAPoe020773;
	Wed, 28 Jul 2004 18:10:26 -0400
Message-ID: <41082408.903@intertwingly.net>
Date: Wed, 28 Jul 2004 18:09:12 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Relative URI references
References: <834420551.20040727005900@djpowell.net> <BB9A9F4A-DF7E-11D8-8C8C-000A95A51C9E@sun.com> <792475969.20040727224245@djpowell.net> <D83EF099-E0A3-11D8-8C8C-000A95A51C9E@sun.com> <m3isc840ot.fsf@bitsko.slc.ut.us> <099FB762-E0B1-11D8-8C8C-000A95A51C9E@sun.com> <opsbu6twvzuvpchu@quark>
In-Reply-To: <opsbu6twvzuvpchu@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 Wed, 28 Jul 2004 09:13:18 -0700, Tim Bray <Tim.Bray@Sun.COM> wrote:
> 
>> Candidate text for inclusion in our drafts would be welcome -Tim
> 
> Specification text for atom:id exists in PaceRecommendIdScheme[1]:
> 
>   "If atom:id is dereferencable, it MUST be an absolute URI and MUST
>    NOT be relative."
> 
> Not sure if the wording is the best, so we might need to work on that, 
> but  it at least captures the essence: Relative URI's should be 
> forbidden in  atom:id.

This seems rather extreme.  The original question was about xml:base. 
If this is the answer to xml:base, then this approach should be done 
throughout the spec.  If not, there should be some rationalle as to why 
ids are different.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Wed Jul 28 18:31:42 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12062
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 18:31: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 i6SMIwBx013657;
	Wed, 28 Jul 2004 15:18: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 i6SMIwmI013656;
	Wed, 28 Jul 2004 15:18: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 i6SMIv0T013647
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 15:18:58 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net (ip2.198.145.31.iinet.com [198.145.31.2])
	(authenticated bits=0)
	by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i6SMK68h021277;
	Wed, 28 Jul 2004 18:20:07 -0400
Message-ID: <4108264C.4050304@intertwingly.net>
Date: Wed, 28 Jul 2004 18:18:52 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <dorchard@bea.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Private extension support (was Re: Q: Put request should return
 Atom entry?
References: <32D5845A745BFB429CBDBADA57CD41AF09333C14@ussjex01.amer.bea.com>
In-Reply-To: <32D5845A745BFB429CBDBADA57CD41AF09333C14@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: <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


David Orchard wrote:

> What's ironic about atom:link as Sam talks about it is basically a
> wsdl:service element.  It contains an address.  WSDL uses a "binding"
> which indirectly refers to an interface, and atom:link has skipped the
> binding and gone directly to the interface.  Has the issue about
> bindings and links been resolved, ie is a reference to a resource
> required to support all bindings or at least one?

Sorta.

My tagline is "it's just data".  Sometimes as a conversation starter (or 
stopper) I say things like "I love everything about OO... everything 
except methods".

I want the ability to say "at this URL you are likely to find a resource 
of type text/calendar.  The only operations you can assume the server 
supports are GET, POST, PUT, and DELETE."  And stop there.

I think that titles and perhaps even rel attributes may prove helpful 
for programs to filter on and/or present for selection.

So, if it helps, feel free to think of links as services - without the 
ability to provide a set of bindings to custom operations.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Wed Jul 28 18:55: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 SAA13113
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 18:55: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 i6SMgxUa020444;
	Wed, 28 Jul 2004 15:42:59 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6SMgxYQ020443;
	Wed, 28 Jul 2004 15:42:59 -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 i6SMgwOW020436
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 15:42:58 -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 AC03A4F36F;
	Wed, 28 Jul 2004 18:43:01 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040729074056.03971e78@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Thu, 29 Jul 2004 07:43:12 +0900
To: Sam Ruby <rubys@intertwingly.net>,
        Atom-Syntax Syntax <atom-syntax@imc.org>
From: Martin Duerst <duerst@w3.org>
Subject: Re: New AtomPubIssuesList for 2004/07/28
In-Reply-To: <41081011.2020700@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: <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 16:44 04/07/28 -0400, Sam Ruby wrote:

>http://www.intertwingly.net/wiki/pie/AtomPubIssuesList

>I've also scheduled PaceUriOrItsSuccessor.  This is complete and hasn't 
>yet drawn any competing proposals.

I am ready to produce a full competing proposal (I have already
started at http://intertwingly.net/wiki/pie/PaceIRI) once the
issues with file names on the Wiki are fixed. Sam, you said you
would look into these, and fix it on a weekend, any success?

Regards,    Martin.



From owner-atom-syntax@mail.imc.org  Wed Jul 28 18:59: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 SAA13377
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 18:59: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 i6SMmPY1021800;
	Wed, 28 Jul 2004 15:48: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 i6SMmPNP021799;
	Wed, 28 Jul 2004 15:48:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6SMmNGq021762
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 15:48:24 -0700 (PDT)
	(envelope-from julian.reschke@gmx.de)
Received: (qmail 30862 invoked by uid 65534); 28 Jul 2004 22:48:23 -0000
Received: from pD9E5142B.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.20.43)
  by mail.gmx.net (mp014) with SMTP; 29 Jul 2004 00:48:23 +0200
X-Authenticated: #1915285
Message-ID: <41082D2F.9080005@gmx.de>
Date: Thu, 29 Jul 2004 00:48:15 +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: elias@torrez.us, Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Relative URI references
References: <834420551.20040727005900@djpowell.net> <BB9A9F4A-DF7E-11D8-8C8C-000A95A51C9E@sun.com> <792475969.20040727224245@djpowell.net> <D83EF099-E0A3-11D8-8C8C-000A95A51C9E@sun.com> <m3isc840ot.fsf@bitsko.slc.ut.us> <099FB762-E0B1-11D8-8C8C-000A95A51C9E@sun.com> <opsbu6twvzuvpchu@quark> <905f7c9104072813395d8cac05@mail.gmail.com> <opsbu83nyluvpchu@quark>
In-Reply-To: <opsbu83nyluvpchu@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:

>   "atom:id MUST NOT under any circumstance be relative. It MUST
>    always be a complete, opaque and absolute URI that doesn't
>    require any post-processing to fulfil the above requirements
>    for persistency and universally uniqueness."

1) Just point to the correct production in RFC2396 ot RFC2396bis,

2) what does it mean for a URI to be "opaque"?

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From owner-atom-syntax@mail.imc.org  Wed Jul 28 19:16:32 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14147
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 19:16: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 i6SN5xjR025934;
	Wed, 28 Jul 2004 16:05: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 i6SN5xwU025933;
	Wed, 28 Jul 2004 16:05: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 i6SN5w1w025921
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 16:05:58 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net (ip2.198.145.31.iinet.com [198.145.31.2])
	(authenticated bits=0)
	by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i6SN78mE023591;
	Wed, 28 Jul 2004 19:07:11 -0400
Message-ID: <41083152.4000507@intertwingly.net>
Date: Wed, 28 Jul 2004 19:05:54 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Martin Duerst <duerst@w3.org>
CC: Atom-Syntax Syntax <atom-syntax@imc.org>
Subject: Re: New AtomPubIssuesList for 2004/07/28
References: <4.2.0.58.J.20040729074056.03971e78@localhost>
In-Reply-To: <4.2.0.58.J.20040729074056.03971e78@localhost>
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


Martin Duerst wrote:
> At 16:44 04/07/28 -0400, Sam Ruby wrote:
> 
>> http://www.intertwingly.net/wiki/pie/AtomPubIssuesList
> 
>> I've also scheduled PaceUriOrItsSuccessor.  This is complete and 
>> hasn't yet drawn any competing proposals.
> 
> I am ready to produce a full competing proposal (I have already
> started at http://intertwingly.net/wiki/pie/PaceIRI) once the
> issues with file names on the Wiki are fixed. Sam, you said you
> would look into these, and fix it on a weekend, any success?

Fair enough... I'm put PaceUriOrItsSuccessor back on the revisit list 
and captured the need to reconcile it with PaceIRI.

I'm travelling at the moment, but I'll try to look into this when I get 
back home.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Wed Jul 28 19:35: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 TAA15023
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 19:35: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 i6SNOveg030132;
	Wed, 28 Jul 2004 16:24:57 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6SNOvKx030131;
	Wed, 28 Jul 2004 16:24:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SNOuSL030080
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 16:24: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 D1CFC7C0F3; Thu, 29 Jul 2004 02:20:22 +0200 (CEST)
Date: Thu, 29 Jul 2004 01:29:30 +0200
To: "Sam Ruby" <rubys@intertwingly.net>
Subject: Re: Relative URI references
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <834420551.20040727005900@djpowell.net> <BB9A9F4A-DF7E-11D8-8C8C-000A95A51C9E@sun.com> <792475969.20040727224245@djpowell.net> <D83EF099-E0A3-11D8-8C8C-000A95A51C9E@sun.com> <m3isc840ot.fsf@bitsko.slc.ut.us> <099FB762-E0B1-11D8-8C8C-000A95A51C9E@sun.com> <opsbu6twvzuvpchu@quark> <41082408.903@intertwingly.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: <opsbvfjgdbuvpchu@quark>
In-Reply-To: <41082408.903@intertwingly.net>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Wed, 28 Jul 2004 18:09:12 -0400, Sam Ruby <rubys@intertwingly.net>  
wrote:

> This seems rather extreme.  The original question was about xml:base. If  
> this is the answer to xml:base, then this approach should be done  
> throughout the spec.  If not, there should be some rationalle as to why  
> ids are different.

ID's are different because they need to be opaque and MUST never change.  
URI's everywhere else in Atom haven't got those requirements and  
restrictions on them. They can change, be dereferenced and whatever by  
whoever, whenever. This doesn't apply for atom:id, though. The single most  
facets of an ID is that it is unique and immutable.

Immutability is extremely hard to maintain if the ID itself is dynamic.  
There is of course a limit in how dynamic it can be, but just moving an  
entry from a location to another within the same site, will make the ID  
change if the relative ID isn't resolved and made absolute. If the site  
moves to a different domain, the ID will also change unless it is resolved  
and made absolute.

I can't think of one single good reason to have relative URI's in atom:id.  
Having different processing on different URI's might be bad, but then we  
should either disallow all relative URI's in Atom, or explicitly say where  
they are and aren't allowed. Where I think relative URI's are most useful,  
is within <content>. Thus could 'xml:base' be allowed on the <content>  
element and also relative URI's inside <content> be perfectly valid, but  
verywhere else in Atom should URI's be absolute.

I don't really care what consequences it has for the rest of the URI's in  
Atom that atom:id MUST be absolute. If all other URI's must be absolute as  
well then; fine. It's still much more important to have immutable and  
unique ID's than it is to save a few bytes in the referenced URI's. Imho,  
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 Jul 28 19:50: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 TAA15431
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 19:50: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 i6SNc0dQ033127;
	Wed, 28 Jul 2004 16:38: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 i6SNc0AX033126;
	Wed, 28 Jul 2004 16:38:00 -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 i6SNbwsQ033099
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 16:37: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 C0F7B7C0F3; Thu, 29 Jul 2004 02:33:31 +0200 (CEST)
Date: Thu, 29 Jul 2004 01:41:41 +0200
To: "Julian Reschke" <julian.reschke@gmx.de>
Subject: Re: Relative URI references
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <834420551.20040727005900@djpowell.net> <BB9A9F4A-DF7E-11D8-8C8C-000A95A51C9E@sun.com> <792475969.20040727224245@djpowell.net> <D83EF099-E0A3-11D8-8C8C-000A95A51C9E@sun.com> <m3isc840ot.fsf@bitsko.slc.ut.us> <099FB762-E0B1-11D8-8C8C-000A95A51C9E@sun.com> <opsbu6twvzuvpchu@quark> <905f7c9104072813395d8cac05@mail.gmail.com> <opsbu83nyluvpchu@quark> <41082D2F.9080005@gmx.de>
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: <opsbvf3rb0uvpchu@quark>
In-Reply-To: <41082D2F.9080005@gmx.de>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Thu, 29 Jul 2004 00:48:15 +0200, Julian Reschke <julian.reschke@gmx.de>  
wrote:

> 1) Just point to the correct production in RFC2396 ot RFC2396bis,

Where in the text would those references go, exactly?

> 2) what does it mean for a URI to be "opaque"?

«Opaque» is probably not the right word. What I mean is that the string[1]  
inside atom:id should be straight-forward to understand and do something  
useful with. To be able to use the string as an identifier, you should  
only have to extract it without any further processing. It's just a unique  
string.

At the second you begin to add a lot of processing and complex rules on  
what to do with atom:id if it's relative and so on, you will increase the  
possibility of having mutated, non-unique ID's significantly. If we agree  
that the main purpose of an ID is to identify the resource, and not «be»  
anything but a plain stupid string, we at least have a common ground we  
can move in the same direction from.

I hope that it's not more important for an ID to be an URI and thus allow  
for everything that is possible to do with every URI scheme in existance,  
than it is for an ID to be globally, and hopefully universally, unique and  
immutable.

____
[1] I refrain myself from using the term 'URI' since I believe URI's as  
ID's give us absolutely zip.

-- 
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 Jul 28 19:53: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 TAA15600
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 19:53: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 i6SNhQi7034452;
	Wed, 28 Jul 2004 16:43:26 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6SNhQe8034445;
	Wed, 28 Jul 2004 16:43:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SNhPr1034439
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 16:43:25 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6SNhVil005084
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 17:43:31 -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 <0I1L008R05WI7N@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Wed, 28 Jul 2004 17:43:31 -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 <0I1L00KQG5WI3K@mail.sun.net> for atom-syntax@imc.org; Wed,
 28 Jul 2004 17:43:30 -0600 (MDT)
Date: Wed, 28 Jul 2004 16:43:47 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: PaceBasicAtomID - maybe we're done
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <F803A7BC-E0EF-11D8-B732-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: <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 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.

  -Tim



From owner-atom-syntax@mail.imc.org  Wed Jul 28 19: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 TAA15782
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 19: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 i6SNm3lV035610;
	Wed, 28 Jul 2004 16:48:03 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6SNm3I6035609;
	Wed, 28 Jul 2004 16:48:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.206])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6SNm2Ne035593
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 16:48:02 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id 73so240225rnl
        for <atom-syntax@imc.org>; Wed, 28 Jul 2004 16:48:07 -0700 (PDT)
Received: by 10.38.88.7 with SMTP id l7mr64886rnb;
        Wed, 28 Jul 2004 16:48:07 -0700 (PDT)
Message-ID: <14be96d304072816484b8648df@mail.gmail.com>
Date: Wed, 28 Jul 2004 19:48:07 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: "Asbjørn Ulsberg" <asbjorn@tigerstaden.no>
Subject: Re: Relative URI references
Cc: Sam Ruby <rubys@intertwingly.net>, Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <opsbvfjgdbuvpchu@quark>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
References: <834420551.20040727005900@djpowell.net> <BB9A9F4A-DF7E-11D8-8C8C-000A95A51C9E@sun.com> <792475969.20040727224245@djpowell.net> <D83EF099-E0A3-11D8-8C8C-000A95A51C9E@sun.com> <m3isc840ot.fsf@bitsko.slc.ut.us> <099FB762-E0B1-11D8-8C8C-000A95A51C9E@sun.com> <opsbu6twvzuvpchu@quark> <41082408.903@intertwingly.net> <opsbvfjgdbuvpchu@quark>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6SNm2Ne035601
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 Thu, 29 Jul 2004 01:29:30 +0200, Asbjørn Ulsberg
<asbjorn@tigerstaden.no> wrote:
> ID's are different because they need to be opaque and MUST never change.

This is true but has no apparent relation to whether the opaque,
unique, unchanging ID is expressed as a relative URI.

> URI's everywhere else in Atom haven't got those requirements and
> restrictions on them. They can change, be dereferenced and whatever by
> whoever, whenever.

This is not true.  There is no requirement that any URI anywhere in
Atom be dereferenceable.  For example,
http://intertwingly.net/wiki/pie/PaceLinkParent contains an example of
undereferenceable URIs pointing to a parent entry.

> I can't think of one single good reason to have relative URI's in atom:id.

(paraphrasing Daniel Dennett) First it starts innocently with "I can
not conceive of X." But then the philosopher goes too far, sliding
into "No one can conceive of X." And then they go completely
overboard: "It is inconceiveable that X." I don"t have a quarrel with
the original premise, but I draw a different conclusion: "Try harder."

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Wed Jul 28 20:11: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 UAA16273
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 20:11:21 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6T00X0V038426;
	Wed, 28 Jul 2004 17:00: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 i6T00XU2038424;
	Wed, 28 Jul 2004 17:00:33 -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 i6T00W1P038395
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 17:00:32 -0700 (PDT)
	(envelope-from ken@bitsko.slc.ut.us)
Received: from localhost.localdomain (tara [127.0.0.1])
	by bitsko.slc.ut.us (8.12.8/8.12.8) with ESMTP id i6T00W53015938
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 19:00:32 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6T00WTh015934;
	Wed, 28 Jul 2004 19:00:32 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceBasicAtomID - maybe we're done
References: <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 28 Jul 2004 19:00:32 -0500
In-Reply-To: <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com>
Message-ID: <m3wu0n3cnz.fsf@bitsko.slc.ut.us>
Lines: 10
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: <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> 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

+1.  I very much like the wording on this one.

  -- Ken



From owner-atom-syntax@mail.imc.org  Wed Jul 28 20:25:51 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16817
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 20:25:50 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6T0EY9R041445;
	Wed, 28 Jul 2004 17: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 i6T0EYQx041444;
	Wed, 28 Jul 2004 17:14:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6T0EXiV041414
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 17:14:33 -0700 (PDT)
	(envelope-from asbjorn@tigerstaden.no)
Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19])
	by smtpgateway.itweb.no (Postfix) with ESMTP
	id 369A37C122; Thu, 29 Jul 2004 03:10:06 +0200 (CEST)
Date: Thu, 29 Jul 2004 02:18:24 +0200
To: "Sascha Carlin" <sc@itst.net>
Subject: Re: Date Options Survey
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <475BB4D1-DCF3-11D8-AFAD-000A95A51C9E@sun.com> <410383FF.8030603@itst.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: <opsbvhsytduvpchu@quark>
In-Reply-To: <410383FF.8030603@itst.net>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 25 Jul 2004 11:57:19 +0200, Sascha Carlin <sc@itst.net> wrote:

> * Include 3 dates in Atom core, 'dateline, 'issued' and 'modified'.
>
> * Make 'issued' and 'modified' REQ, 'dateline' OPT.

I would love to see this in the specification and not to mention; followed  
by the tool vendors, but my current faith tells me that is _never_ going  
to happen. Current tools don't even conform to the RSS 2.0 specification  
of 'pubDate'[1], which is much older than Atom.

Why the tool vendors think that «Its value is a date, indicating when the  
item was published» means «Either 'created' or 'published', possibly set  
to something completely different by the user», is beyond my  
comprehension. Why most tools also only provide one date is something I  
don't understand either.

So, requiring 'issued' and 'modified' will just generate heaps of bad data  
for years to come.

> 'dateline' defaults to 'issued', modified does for new entries, too. If  
> you modify the entry, 'issued' would still have the old value and  
> 'modified' would be updated.

As Laurent Le Meur writes[2], 'dateline' does not fit for the semantic  
placed on 'pubDate' and 'dc:date' in current tools. What for example  
Movable Type means with its single date, is 'created', 'sort-date' and  
'user-date' of the following reasons:

   1. 'created'

      When you create (press the [Save] button) an entry in Movable Type,
      the date gets set to that point in time on the server. When the
      entry returns, you get an «Authored on» field in the web form set
      to this date.

   2. 'sort-date'

      The «Authored on» field is modifyable for the user. At any point
      in time, the user may change this date, thus removing its previous
      'created' semantics. A good reason to change «Authored on» is to
      have the entries re-arranged in your feed or on the front page of
      your blog.

   3. 'user-date'

      As already mentioned, the «Authored on» field is modifyable. In
      addition to point 2., this field may be edited by the user to
      reflect just about anything. The user applies his or her very
      own semantic on the date by modifying it, without the possibility
      to tell anyone what he or she means with the date.

I will not express what I feel about this now, but regardless of my  
feelings, it's obvious that Movable Type neither supports RSS' or Atom's  
semantics with any of their dates. I think you will have a hard time  
managing to find a term for the MT-date in Dublin Core, at least. And  
neither 'created', 'issued', 'modified' or 'dateline' fits.

Other tools have different semantics applied to their date(s). They are  
very unlikely to fit with MT's semantic, and would make it even harder to  
create a good name for this date element. 'date' or 'display-date' would  
probably be the best term to use, but I would recommend the specification  
to say «SHOULD NOT use» on this element, as it is completely without any  
meaning, since it's a compound of many different dates and semantics.

I've made a separate suggestion to how we can solve this:

<url: http://www.imc.org/atom-syntax/mail-archive/msg07940.html>

The proposal is basically to require one date, but not say which one.  
Still, each date element would have either «SHOULD», «MAY» or «SHOULD NOT»  
associated with them, which orders the date in preference as to what we  
would like an Atom entry to contain. Requiring much more than «a date» at  
this time, is not feasible, I think.

> Programmatically this would mean that applications need to store at  
> least three dates:

I would really enjoy it if all tool vendors came running now, saying «We  
will support all of 'issued', 'modified', 'created', 'date' and 'dateline'  
in the next version of XYZ», but I doubt that will happen.

____
[1] <url:  
http://blogs.law.harvard.edu/tech/rss#ltpubdategtSubelementOfLtitemgt>
[2] <url: http://www.imc.org/atom-syntax/mail-archive/msg07955.html>

-- 
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 Jul 28 20:31: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 UAA17072
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 20:31: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 i6T0NE5I043388;
	Wed, 28 Jul 2004 17:23: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 i6T0NENw043387;
	Wed, 28 Jul 2004 17:23:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6T0NCK3043357
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 17:23: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 B25217C122; Thu, 29 Jul 2004 03:18:45 +0200 (CEST)
Date: Thu, 29 Jul 2004 02:27:06 +0200
To: "Tim Bray" <Tim.Bray@sun.com>
Subject: Re: PaceBasicAtomID - maybe we're done
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <F803A7BC-E0EF-11D8-B732-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: <opsbvh7gzvuvpchu@quark>
In-Reply-To: <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Wed, 28 Jul 2004 16:43:47 -0700, Tim Bray <Tim.Bray@Sun.COM> wrote:
>
> 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

+0.05. I don't have much faith in that readers of the Atom specification  
will be able to pick a good URI scheme themselves, and thus would like the  
specification to explicitly name a scheme that conforms to all of  
atom:id's requirements.

I like PaceRecommendIdScheme[1] better.

____
[1] <url: http://intertwingly.net/wiki/pie/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  Wed Jul 28 20: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 UAA17717
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 20: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 i6T0TxTY044694;
	Wed, 28 Jul 2004 17:29: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 i6T0TxNt044693;
	Wed, 28 Jul 2004 17:29:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6T0Twc4044645;
	Wed, 28 Jul 2004 17:29:58 -0700 (PDT)
	(envelope-from jasnell@us.ibm.com)
Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32])
	by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i6T0TwgM265548;
	Wed, 28 Jul 2004 20:29:58 -0400
Received: from d03nm122.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170])
	by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6T0Twav147172;
	Wed, 28 Jul 2004 18:29:58 -0600
In-Reply-To: <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com>
To: Tim Bray <Tim.Bray@Sun.COM>
Cc: Atom Syntax <atom-syntax@imc.org>, owner-atom-syntax@mail.imc.org
MIME-Version: 1.0
Subject: Re: PaceBasicAtomID - maybe we're done
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
From: James M Snell <jasnell@us.ibm.com>
X-MIMETrack: S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/28/2004 05:28:13 PM,
	Serialize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/28/2004 05:28:13 PM,
	Serialize complete at 07/28/2004 05:28:13 PM,
	Itemize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/28/2004 05:28:13 PM,
	S/MIME Sign complete at 07/28/2004 05:28:13 PM,
	S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/28/2004 05:29:54 PM,
	S/MIME Sign complete at 07/28/2004 05:29:54 PM,
	Serialize by Router on D03NM122/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at
 07/28/2004 18:29:57,
	Serialize complete at 07/28/2004 18:29:57
Message-ID: <OF6ECD8A48.78C05E2A-ON88256EE0.00029097-88256EE0.0002BD19@us.ibm.com>
Date: Wed, 28 Jul 2004 18:29:55 -0600
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z32214_boundary_sign
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>


This is an S/MIME signed message.

---------z32214_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 0002954588256EE0_="

This is a multipart message in MIME format.
--=_alternative 0002954588256EE0_=
Content-Type: text/plain; charset="US-ASCII"

+1 this works for me

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



Tim Bray <Tim.Bray@Sun.COM> 
Sent by: owner-atom-syntax@mail.imc.org
07/28/2004 04:43 PM

To
Atom Syntax <atom-syntax@imc.org>
cc

Subject
PaceBasicAtomID - maybe we're done







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.

  -Tim



--=_alternative 0002954588256EE0_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">+1 this works for me</font>
<br>
<br><font size=2 face="sans-serif">- James M Snell<br>
 &nbsp;jasnell@us.ibm.com<br>
 &nbsp;http://www.ibm.com<br>
 &nbsp;(877) 511-5082 / Office<br>
 &nbsp;930-1979 / Tie Line</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Tim Bray &lt;Tim.Bray@Sun.COM&gt;</b>
</font>
<br><font size=1 face="sans-serif">Sent by: owner-atom-syntax@mail.imc.org</font>
<p><font size=1 face="sans-serif">07/28/2004 04:43 PM</font>
<td width=59%>
<table width=100%>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td valign=top><font size=1 face="sans-serif">Atom Syntax &lt;atom-syntax@imc.org&gt;</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td valign=top>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td valign=top><font size=1 face="sans-serif">PaceBasicAtomID - maybe we're
done</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2><tt><br>
I just went back and revisited a *lot* of email and Wiki text on the <br>
subject of atom:id, and I think that a fairly clear rough consensus <br>
emerges from that. &nbsp;I've published what I think it is at <br>
http://intertwingly.net/wiki/pie/PaceBasicAtomID<br>
<br>
Bearing in mind the amount of work we've already put into this, and the
<br>
fact that debate on this subject is apt to create permathreads, please
<br>
seriously consider, if you think you could live with this language, <br>
resisting the urge to launch a debate about one phrase or another.<br>
<br>
 &nbsp;-Tim<br>
<br>
</tt></font>
<br>
--=_alternative 0002954588256EE0_=--

---------z32214_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIIUOAIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIISWDCCAtow
ggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1
aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAy
MDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA629xc49NpAPz
cAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7glzJKgPkPzlTZZfznznGbmAWVnNBQ
lyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnwNclOnnP2sKufuPzbTImQTTi5c8JZNZcM
J0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEEBAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1Ud
DgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAPBgNVHRMBAf8EBTADAQH/MDEGA1UdJQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUH
AwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvu
jQupk2oCScMd3FIHLE7hOfu8YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14ke
McF9ViNdewEoBGiAycUq8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIC2jCCAkOgAwIB
AgIDAxS2MA0GCSqGSIb3DQEBBAUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwMTE0MjIw
NzExWhcNMTExMjMxMjIwNzExWjBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25h
bCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrb3Fzj02kA/NwCy5KFMiY
tFgyTJ6kMSQLVSs9uwVHIAVkqy/enDQwZ9b/7uCXMkqA+Q/OVNll/OfOcZuYBZWc0FCXI9qw60KO
J/rTd65FdF4dwp8cw8si0qjOJtYg8cm46fA1yU6ec/awq5+4/NtMiZBNOLlzwlk1lwwnRgXNNwID
AQABo4GqMIGnMBEGCWCGSAGG+EIBAQQEAwIAhzAOBgNVHQ8BAf8EBAMCAcYwHQYDVR0OBBYEFK5U
DpLqqDOpKyQtx8hvMNze80pAMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMA8GA1Ud
EwEB/wQFMAMBAf8wMQYDVR0lBCowKAYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYB
BQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAMnJ7c2YLyrY/PKlFl+7sm8NENfWtFxqdm+6NC6mTagJJ
wx3cUgcsTuE5+7xh9+/G0tTfLzA1qZAQ5GNMPXvmoB9+vJfKnC2JWMFQpIOUEJDXiR4xwX1WI117
ASgEaIDJxSrxHcuuV/hMIO9bgZ6C41MUVmdLTKBgBOImTuIPK8QwggMgMIICiaADAgECAgQ13vTP
MA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQL
EyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0MTUxWhcN
MTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMk
RXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKKlQRkrPFr
U18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkwrFEeO68r
1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOgYaRfMF0x
CzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBD
ZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAxODA4MjIx
NjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAdBgNV
HQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0HQQAEDTAL
GwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwlMQ0AppJu
f7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn00DbOyZY
sih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMgMIICiaADAgEC
AgQ13vTPMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0
MTUxWhcNMTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsG
A1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKK
lQRkrPFrU18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkw
rFEeO68r1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOg
YaRfMF0xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNl
Y3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAx
ODA4MjIxNjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAdBgNVHQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0H
QQAEDTALGwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwl
MQ0AppJuf7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn
00DbOyZYsih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMmMIIC
j6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIxNjM2NTRaMIGFMQsw
CQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEXMBUGA1UEAxMOSmFt
ZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkqhkiG9w0BCQEWEmph
c25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwKpbDG3zMatEuuOT
FYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSyd+7nwqAvbBfPj+0S
vcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7tBJlLrwDRCMoNlPuQ
Kg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQW
BBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOgFAwSamFzbmVs
bEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pAMCcGA1UdJQQgMB4G
CCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAZMKevB7dFfb9
23OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY8BjwVHxiYgG4xkxf
B1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOIzj3lz3xd+uOzqRFg
/Wsg/VMwggMmMIICj6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAy
BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNV
BAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIx
NjM2NTRaMIGFMQswCQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEX
MBUGA1UEAxMOSmFtZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkq
hkiG9w0BCQEWEmphc25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
wKpbDG3zMatEuuOTFYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSy
d+7nwqAvbBfPj+0SvcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7t
BJlLrwDRCMoNlPuQKg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQD
AgXgMB0GA1UdDgQWBBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcU
AgOgFAwSamFzbmVsbEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA
MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQAD
gYEAZMKevB7dFfb923OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY
8BjwVHxiYgG4xkxfB1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOI
zj3lz3xd+uOzqRFg/Wsg/VMxggG7MIIBtwIBATBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJ
bnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0g
Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwF+kzAJBgUrDgMCGgUAoIGiMBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDcyOTAwMjgxM1owIwYJKoZIhvcNAQkEMRYE
FNGKHTfjABq7ez0ghoy2A2K7007lMEMGCSqGSIb3DQEJDzE2MDQwBwYFKw4DAh0wDgYIKoZIhvcN
AwICAgCAMAoGCCqGSIb3DQMHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGASPOqakRt
s9NEd49IeRmzWYuzMNLhlxF2wvVGtLdfrC/15j+1COMtHNllifkreFYylfRU7p2vbFmiuXnzECpt
r/x6Vdy8TybUphgC8AayZzd7R2B+AkcvEInMEv9XkMVV06y6rIzNtgcAXvusATnPgg2d8r+H5DaX
n7tfpOLum0YAAAAA

---------z32214_boundary_sign--



From owner-atom-syntax@mail.imc.org  Wed Jul 28 20:37:50 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17795
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 20:37:49 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6T0UO3C044784;
	Wed, 28 Jul 2004 17:30: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 i6T0UOoa044783;
	Wed, 28 Jul 2004 17:30:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from beta.verity.com (beta.verity.com [192.187.143.12])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6T0UN0m044757
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 17:30:23 -0700 (PDT)
	(envelope-from wunder@verity.com)
Received: from mx-rr.verity.com ([10.3.100.59])
	by beta.verity.com (8.9.3/8.9.3) with ESMTP id RAA20204
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 17:30:19 -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 RAA04226
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 17:30:18 -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); Wed, 28 Jul 2004 17:30:18 -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 <0I1L007PJ82G10@shazam.verity.com> for atom-syntax@imc.org; Wed,
 28 Jul 2004 17:30:17 -0700 (PDT)
Date: Wed, 28 Jul 2004 17:30:19 -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: PaceBasicAtomID - maybe we're done
In-reply-to: <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <5FAAF875FB78205F0CA9BCF7@[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: <F803A7BC-E0EF-11D8-B732-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


Is there a recommendation for how to generate feeds from databases
that cannot provide repeatable unique IDs? Specifically, people are
building RSS feeds from search results. That will not be possible
with Atom. Search indexes do not contain unique IDs.

Here is one example:

  <http://weblog.infoworld.com/udell/2003/08/01.html>

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Wed Jul 28 20:43:47 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18614
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 20:43:46 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6T0XaAS045511;
	Wed, 28 Jul 2004 17:33: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 i6T0Xakj045510;
	Wed, 28 Jul 2004 17:33: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 i6T0XZvh045501
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 17:33:35 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net (ip2.198.145.31.iinet.com [198.145.31.2])
	(authenticated bits=0)
	by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i6T0Yga3028425;
	Wed, 28 Jul 2004 20:34:48 -0400
Message-ID: <410845D9.4050609@intertwingly.net>
Date: Wed, 28 Jul 2004 20:33:29 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Relative URI references
References: <834420551.20040727005900@djpowell.net> <BB9A9F4A-DF7E-11D8-8C8C-000A95A51C9E@sun.com> <792475969.20040727224245@djpowell.net> <D83EF099-E0A3-11D8-8C8C-000A95A51C9E@sun.com> <m3isc840ot.fsf@bitsko.slc.ut.us> <099FB762-E0B1-11D8-8C8C-000A95A51C9E@sun.com> <opsbu6twvzuvpchu@quark> <41082408.903@intertwingly.net> <opsbvfjgdbuvpchu@quark>
In-Reply-To: <opsbvfjgdbuvpchu@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:
> 
> I can't think of one single good reason to have relative URI's in 
> atom:id.

If you look closely, you will see that I use relative URI's in my 
current Atom feed: http://www.intertwingly.net/blog/index.atom

I've also mentioned a reason why this might be a good idea here: 
http://www.intertwingly.net/blog/2004/03/30/Uniqueness

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Wed Jul 28 20:52: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 UAA19393
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 20: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 i6T0XJFL045440;
	Wed, 28 Jul 2004 17:33:19 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6T0XJSq045439;
	Wed, 28 Jul 2004 17:33: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 i6T0XIaJ045416
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 17:33: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 BD8527C122; Thu, 29 Jul 2004 03:28:50 +0200 (CEST)
Date: Thu, 29 Jul 2004 02:37:13 +0200
To: "Mark Pilgrim" <pilgrim@gmail.com>
Subject: Re: Relative URI references
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <834420551.20040727005900@djpowell.net> <BB9A9F4A-DF7E-11D8-8C8C-000A95A51C9E@sun.com> <792475969.20040727224245@djpowell.net> <D83EF099-E0A3-11D8-8C8C-000A95A51C9E@sun.com> <m3isc840ot.fsf@bitsko.slc.ut.us> <099FB762-E0B1-11D8-8C8C-000A95A51C9E@sun.com> <opsbu6twvzuvpchu@quark> <41082408.903@intertwingly.net> <opsbvfjgdbuvpchu@quark> <14be96d304072816484b8648df@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: <opsbviobnauvpchu@quark>
In-Reply-To: <14be96d304072816484b8648df@mail.gmail.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Wed, 28 Jul 2004 19:48:07 -0400, Mark Pilgrim <pilgrim@gmail.com> wrote:

>> ID's are different because they need to be opaque and MUST never change.
>
> This is true but has no apparent relation to whether the opaque,
> unique, unchanging ID is expressed as a relative URI.

So, the fact that the ID needs to be resolved before it is complete and  
useful, isn't apparent?

>> URI's everywhere else in Atom haven't got those requirements and
>> restrictions on them. They can change, be dereferenced and whatever by
>> whoever, whenever.
>
> This is not true.

Well okay. Not always, at least.

> There is no requirement that any URI anywhere in Atom be dereferenceable.

No. My point was that xml:id has higher requirements than other URI's in  
Atom. Other URI's are not immutable, for example.

>> I can't think of one single good reason to have relative URI's in  
>> atom:id.
>
> (paraphrasing Daniel Dennett) First it starts innocently with "I can
> not conceive of X." [...]

Instead of being philosophical: Do you have a compelling reason or use  
case for ever having a relative URI in atom:id?

-- 
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 Jul 28 20:53:57 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19449
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 20:53: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 i6T0ic3T048263;
	Wed, 28 Jul 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 i6T0ichr048261;
	Wed, 28 Jul 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 chromium.sabren.com (chromium.sabren.com [69.20.61.177])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6T0ibR3048197
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 17:44:37 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net (ip2.198.145.31.iinet.com [198.145.31.2])
	(authenticated bits=0)
	by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i6T0jndR029098;
	Wed, 28 Jul 2004 20:45:50 -0400
Message-ID: <41084874.4040806@intertwingly.net>
Date: Wed, 28 Jul 2004 20:44:36 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <Tim.Bray@Sun.COM>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceBasicAtomID - maybe we're done
References: <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com>
In-Reply-To: <F803A7BC-E0EF-11D8-B732-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:
> 
> 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.

IMHO, this does not fully solve the original problem that Dare was 
trying to express... I see this as primarily because the discussion 
wandered off into permathread land and what Dare was trying to express 
was lost.

Dare touched on the concern a bit here:

   http://www.imc.org/atom-syntax/mail-archive/msg07870.html

And then more fully explained it here:

   http://www.imc.org/atom-syntax/mail-archive/msg07877.html

I believe that what Dare really wants captured in the spec is what is 
expressed in tutorial terms here:

   http://diveintomark.org/archives/2004/05/28/howto-atom-id#multiple

Note: this one section has nothing to do with the scheme chosen.  And 
perhaps an example would help... take a look at the guids chosen in the 
following feed:

   http://feedster.com/search.php?q=atom&type=rss

Of course, Dare could tell me that I got all this wrong.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Wed Jul 28 20: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 UAA19816
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 20: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 i6T0ojnD049826;
	Wed, 28 Jul 2004 17:50: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 i6T0ojXM049825;
	Wed, 28 Jul 2004 17:50:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-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 i6T0oidm049819
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 17:50:44 -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 i6T0ooil027484
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 18:50:50 -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 <0I1L00G1390Q9Q@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Wed, 28 Jul 2004 18:50:50 -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 <0I1L009LS90PA1@mail.sun.net> for atom-syntax@imc.org; Wed,
 28 Jul 2004 18:50:50 -0600 (MDT)
Date: Wed, 28 Jul 2004 17:51:06 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceBasicAtomID - maybe we're done
In-reply-to: <41084874.4040806@intertwingly.net>
To: Sam Ruby <rubys@intertwingly.net>
Cc: Atom Syntax <atom-syntax@imc.org>
Message-id: <5F758DFA-E0F9-11D8-B732-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: <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com>
 <41084874.4040806@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 Jul 28, 2004, at 5:44 PM, Sam Ruby wrote:

> IMHO, this does not fully solve the original problem that Dare was 
> trying to express... I see this as primarily because the discussion 
> wandered off into permathread land and what Dare was trying to express 
> was lost.

OK... although the language in the Pace about dupe detection is pretty 
well straight from Dare.  So concretely, you're suggesting that we beef 
up the draft with some language explaining the use-case of the same 
entry in multiple different feeds. -Tim



From owner-atom-syntax@mail.imc.org  Wed Jul 28 21:02: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 VAA19931
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 21:02: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 i6T0tTuH050803;
	Wed, 28 Jul 2004 17: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 i6T0tTas050802;
	Wed, 28 Jul 2004 17:55: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.207])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6T0tRPZ050794
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 17:55:28 -0700 (PDT)
	(envelope-from eliast@gmail.com)
Received: by mproxy.gmail.com with SMTP id 78so142852rnk
        for <atom-syntax@imc.org>; Wed, 28 Jul 2004 17:55:33 -0700 (PDT)
Received: by 10.38.73.11 with SMTP id v11mr136871rna;
        Wed, 28 Jul 2004 17:55:33 -0700 (PDT)
Message-ID: <905f7c910407281755504266ba@mail.gmail.com>
Date: Wed, 28 Jul 2004 20:55:33 -0400
From: Elias Torres <eliast@gmail.com>
Reply-To: elias@torrez.us
To: Tim Bray <tim.bray@sun.com>
Subject: Re: PaceBasicAtomID - maybe we're done
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <F803A7BC-E0EF-11D8-B732-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


+0

I like the wording also, but if we vote yes on this pace we are
agreeing on giving up forever in making atom:id useful to most
applications because:

- Applications will not be able to see an atom:id and know it's one
- atom:ids will not be comparable in any way, except for strcmp()
- Versioning will be almost impossible to deduce from atom:id
- can't think of any more at this moment.

Tim, you are right that given the amount of time we gave this issue, I
think we should not revisit everything again, but first, I see no
major argument against picking a scheme, except for "best practices"
to use a generic URI on things that don't even relate to identifiers
and the fact that some people just don't like URNs, but besides that I
have not heard a real show stopper if we were to use ONE scheme.

I don't think any wording can satisfy what some of us are asking. We
want a format that people can count on when looking an ID, this needs
to be identifiable, comparable, immutable, universal, dereferencable
and include versioning and the current pace does not reflect that. If
no one else speaks up, then let's leave it as is and move on. Else I
would suggest you compromise with us unless again, someone finds a
real problem with restricting.

Regards,

Elias Torres

On Wed, 28 Jul 2004 16:43:47 -0700, Tim Bray <tim.bray@sun.com> wrote:
> 
> 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.
> 
>   -Tim
> 
>



From owner-atom-syntax@mail.imc.org  Wed Jul 28 21:11:29 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20149
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 21:11: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 i6T12ln1052463;
	Wed, 28 Jul 2004 18: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 i6T12lPT052462;
	Wed, 28 Jul 2004 18:02:47 -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 i6T12jBt052417
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 18:02:46 -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 i6T12k53016635
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 20:02:46 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6T12jPE016631;
	Wed, 28 Jul 2004 20:02:45 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceBasicAtomID - maybe we're done
References: <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com>
	<41084874.4040806@intertwingly.net>
	<5F758DFA-E0F9-11D8-B732-000A95A51C9E@sun.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 28 Jul 2004 20:02:45 -0500
In-Reply-To: <5F758DFA-E0F9-11D8-B732-000A95A51C9E@sun.com>
Message-ID: <m3smbb39sa.fsf@bitsko.slc.ut.us>
Lines: 28
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: <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> writes:

> On Jul 28, 2004, at 5:44 PM, Sam Ruby wrote:
> 
> > IMHO, this does not fully solve the original problem that Dare was
> > trying to express... I see this as primarily because the
> > discussion wandered off into permathread land and what Dare was
> > trying to express was lost.
> 
> OK... although the language in the Pace about dupe detection is
> pretty well straight from Dare.  So concretely, you're suggesting
> that we beef up the draft with some language explaining the use-case
> of the same entry in multiple different feeds.

I think the messages that Sam points to are ones where Dare is
discussing the symptoms of IDs changing (which isn't inherent to the
scheme used), where the Pace refers to a message from Dare that
addresses the root cause: that publishers don't do anything to prevent
the IDs from changing, regardless of scheme used.

Adding language explaining the "multiple places" use-case is good.

Here's the test cases I suggested, which includes the "multiple
places" assertion that can be added to the spec text:

    http://imc.org/atom-syntax/mail-archive/msg07923.html

  -- Ken



From owner-atom-syntax@mail.imc.org  Wed Jul 28 21:29: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 VAA21026
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 21:29: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 i6T1J966056071;
	Wed, 28 Jul 2004 18:19: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 i6T1J8Jw056069;
	Wed, 28 Jul 2004 18:19:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.201])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6T1J66l056039
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 18:19:07 -0700 (PDT)
	(envelope-from eliast@gmail.com)
Received: by mproxy.gmail.com with SMTP id 78so143713rnk
        for <atom-syntax@imc.org>; Wed, 28 Jul 2004 18:19:12 -0700 (PDT)
Received: by 10.38.78.1 with SMTP id a1mr124705rnb;
        Wed, 28 Jul 2004 18:19:12 -0700 (PDT)
Message-ID: <905f7c91040728181911a7bf44@mail.gmail.com>
Date: Wed, 28 Jul 2004 21:19:12 -0400
From: Elias Torres <eliast@gmail.com>
Reply-To: elias@torrez.us
To: Walter Underwood <wunder@verity.com>
Subject: Re: PaceBasicAtomID - maybe we're done
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <5FAAF875FB78205F0CA9BCF7@192.168.168.164>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com> <5FAAF875FB78205F0CA9BCF7@192.168.168.164>
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


Well it depends on what we decide ID means. But if the ID should be
mapped to the content then something like that would work:

urn:aURN_NS:feedster.org:search:atom:DATETIME

That would make unique and the contents of that entry should never
change, since it was a t the momment in time.

If the ID is a moving target, meaning that whatever it represents can
be always changing then:

urn:aURN_NS:feedster.org:search:atom would suffice. But I would
disagree. An atom:id should be unique and map always to the same
content it was generated for in the first place.

Elias Torres

On Wed, 28 Jul 2004 17:30:19 -0700, Walter Underwood <wunder@verity.com> wrote:
> 
> Is there a recommendation for how to generate feeds from databases
> that cannot provide repeatable unique IDs? Specifically, people are
> building RSS feeds from search results. That will not be possible
> with Atom. Search indexes do not contain unique IDs.
> 
> Here is one example:
> 
>   <http://weblog.infoworld.com/udell/2003/08/01.html>
> 
> wunder
> --
> Walter Underwood
> Principal Architect, Verity
> 
>



From owner-atom-syntax@mail.imc.org  Wed Jul 28 21:35: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 VAA21304
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 21:35: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 i6T1Ofqn057163;
	Wed, 28 Jul 2004 18:24: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 i6T1Of0h057162;
	Wed, 28 Jul 2004 18:24:41 -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 i6T1OeqS057136
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 18:24:40 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 38975 messnum 2075603 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 29 Jul 2004 01:24:40 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.183?) (83.70.33.112)
  by mail03.svc.cra.dublin.eircom.net (qp 38975) with SMTP; 29 Jul 2004 01:24:40 -0000
Message-ID: <410851D3.8080707@dehora.net>
Date: Thu, 29 Jul 2004 02:24:35 +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: Tim Bray <Tim.Bray@Sun.COM>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceBasicAtomID - maybe we're done
References: <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com>
In-Reply-To: <F803A7BC-E0EF-11D8-B732-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:

> 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.

+0.

Here's why. Regarding the text, I could definitely live without the 
retrieval discussion, as I'm not sure we're not confusing 
correlation with cause - the problem is not that http: URLs have 
retrieval semantics, but that http: URLs (which happen to have 
retrieval semantics) are more transient in the wild than many of us 
would wish.

Good job, thanks for doing this.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Wed Jul 28 22:47:17 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25726
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 22:47: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 i6T2bYX2073713;
	Wed, 28 Jul 2004 19:37: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 i6T2bYbl073712;
	Wed, 28 Jul 2004 19:37: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 i6T2bYT5073706
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 19:37: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 i6T2beil029834
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 20:37:40 -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 <0I1L00887DYRVI@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Wed, 28 Jul 2004 20:37:40 -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 <0I1L003PRDYRL2@mail.sun.net> for atom-syntax@imc.org; Wed,
 28 Jul 2004 20:37:39 -0600 (MDT)
Date: Wed, 28 Jul 2004 19:37:56 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceBasicAtomID - maybe we're done
In-reply-to: <905f7c910407281755504266ba@mail.gmail.com>
To: elias@torrez.us
Cc: Atom Syntax <atom-syntax@imc.org>
Message-id: <4C21C966-E108-11D8-B732-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: <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com>
 <905f7c910407281755504266ba@mail.gmail.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 Jul 28, 2004, at 5:55 PM, Elias Torres wrote:

> first, I see no
> major argument against picking a scheme,

I do.  Having reviewed all the arguments and re-read the suggestions 
and proposals, I think it is quite unlikely that this group will 
achieve consensus on any one scheme.

Of course, you can prove me wrong.  Pick a scheme, publish a proposal, 
and gather consensus behind it.  This has been attempted a couple of 
times and so far it hasn't worked.  But if it does, of course it would 
go in the draft. -Tim



From owner-atom-syntax@mail.imc.org  Wed Jul 28 23:03: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 XAA26415
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 23:03: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 i6T2r35U077715;
	Wed, 28 Jul 2004 19: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 i6T2r3WG077714;
	Wed, 28 Jul 2004 19: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.84])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6T2r3nE077707
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 19:53:03 -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 i6T2rA97016715;
	Wed, 28 Jul 2004 19:53:10 -0700 (PDT)
Received: from [192.168.1.101] (66-108-153-170.nyc.rr.com [66.108.153.170])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id i6T2r0w8026206;
	Wed, 28 Jul 2004 19:53:09 -0700 (PDT)
In-Reply-To: <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com>
References: <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4--1054247659; protocol="application/pkcs7-signature"
Message-Id: <6A45BF72-E10A-11D8-B75F-000A95DC3D90@mac.com>
Cc: Atom Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: PaceBasicAtomID - maybe we're done
Date: Wed, 28 Jul 2004 22:53:04 -0400
To: Tim Bray <Tim.Bray@Sun.COM>
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-4--1054247659
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 28 Jul 2004, at 7:43 pm, Tim Bray wrote:

> 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

You haven't actually mentioned whether it's a URI or not, and also 
[therefore] whether relative values are allowed.

(Also the idea that it's meant to be applied to different versions of 
the same entry isn't conveyed very well - some conceptual definition of 
an "entry" elsewhere might do that though)

Graham
--Apple-Mail-4--1054247659
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
9w0BCQUxDxcNMDQwNzI5MDI1MzA1WjAjBgkqhkiG9w0BCQQxFgQUpKC1Zzzfs/YoZo7e+SypSTq2
C3IweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAGSBsDaKXZq6rSsNFq9CapVb6
zzmL6xZuLZ3yvSQ2IjTJ6fWJn1TcpmQ1wpuRFUE5AO0irTJj98X3Mrqit2Md8RcRWA4cJwt83Hb3
yet4DqvvX2qHNg8euqoUxdTZysMZqNbrKPbMJWZCBslNi+QnsvGQm+PPDQRUP+Dl1HbnnplroqP5
Kjainj8+1ApLEGWcP06oJVxFHdsrqnySPVma5CE/VeWoB+5rUP7nj20UBKXgMxyL1rxnsLWPeJzJ
v/Ya76YOl/66tEuOwS+FS2j1rpjvR8/XT9t1xvLnU5CPmAmy2ykZ/nTCX1bHhTp6TMF7xf1frXqf
xMjJSVgQ65Vj9wAAAAAAAA==

--Apple-Mail-4--1054247659--



From owner-atom-syntax@mail.imc.org  Wed Jul 28 23:22: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 XAA27116
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 23:22: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 i6T3GG85083566;
	Wed, 28 Jul 2004 20:16: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 i6T3GGc7083565;
	Wed, 28 Jul 2004 20:16: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 i6T3GFbe083538
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 20:16:16 -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 i6T3GG53018161
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 22:16:17 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6T3GG27018157;
	Wed, 28 Jul 2004 22:16:16 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceBasicAtomID - maybe we're done
References: <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com>
	<6A45BF72-E10A-11D8-B75F-000A95DC3D90@mac.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 28 Jul 2004 22:16:16 -0500
In-Reply-To: <6A45BF72-E10A-11D8-B75F-000A95DC3D90@mac.com>
Message-ID: <m3oelz33lr.fsf@bitsko.slc.ut.us>
Lines: 31
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 i6T3GGbe083560
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


Graham <dtcd@mac.com> writes:

> On 28 Jul 2004, at 7:43 pm, Tim Bray wrote:
> 
> > 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
> 
> You haven't actually mentioned whether it's a URI or not, and also
> [therefore] whether relative values are allowed.

D'oh!  I missed that!

> (Also the idea that it's meant to be applied to different versions
> of the same entry isn't conveyed very well - some conceptual
> definition of an "entry" elsewhere might do that though)

Asbjørn, Arve, and I have been discussing different version schemes
with respect to the atom:entry identifier.  I think we have a proposal
ready to be put into a Pace that has minimal impact on the current
semantics and usage.

The gist is that the atom:entry/atom:id identifies the entry as whole
(all of its versions).  Each version may have a separate identifier
that identifies the version, located elsewhere in a non-core element.
Consumers should use the most current version of an entry from a feed
or other source with the same atom:id, where "current" will be based
on the outcome of the date discussion.

  -- Ken



From owner-atom-syntax@mail.imc.org  Wed Jul 28 23:42: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 XAA27870
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 23:42:58 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6T3Y7gb087766;
	Wed, 28 Jul 2004 20:34: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 i6T3Y7e7087765;
	Wed, 28 Jul 2004 20:34:07 -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 i6T3Y6Oq087748
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 20:34:07 -0700 (PDT)
	(envelope-from distobj@acm.org)
Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian))
	id 1Bq1h2-0006PD-00
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 23:34:56 -0400
Date: Wed, 28 Jul 2004 23:34:56 -0400
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceBasicAtomID - maybe we're done
Message-ID: <20040729033456.GM30868@markbaker.ca>
References: <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com>
User-Agent: Mutt/1.3.28i
From: Mark Baker <distobj@acm.org>
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 have to give it a -1 primarily for the "SHOULD consider another URI
scheme" statement, since that's strongly recommending what I consider to
be bad practice; having important identifiers which aren't
dereferencable.  I'd be content with "MAY".

FWIW, I looked up what the TAG had to say on this subject, and found;

"A URI owner SHOULD provide representations of the identified resource."
 -- http://www.w3.org/TR/webarch/#pr-describe-resource

Mark.



From owner-atom-syntax@mail.imc.org  Wed Jul 28 23:50: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 XAA28328
	for <atompub-archive@lists.ietf.org>; Wed, 28 Jul 2004 23:50: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 i6T3eTOO089506;
	Wed, 28 Jul 2004 20:40: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 i6T3eTbt089505;
	Wed, 28 Jul 2004 20:40: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 i6T3eSSG089498
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 20:40: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 i6T3eZil017318
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 21:40:35 -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 <0I1L00GESGVN9Q@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Wed, 28 Jul 2004 21:40:35 -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 <0I1L009WPGVML9@mail.sun.net> for atom-syntax@imc.org; Wed,
 28 Jul 2004 21:40:34 -0600 (MDT)
Date: Wed, 28 Jul 2004 20:40:49 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceBasicAtomID - maybe we're done
In-reply-to: <6A45BF72-E10A-11D8-B75F-000A95DC3D90@mac.com>
To: Graham <dtcd@mac.com>
Cc: Atom Syntax <atom-syntax@imc.org>
Message-id: <15709B6C-E111-11D8-B732-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: <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com>
 <6A45BF72-E10A-11D8-B75F-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 Jul 28, 2004, at 7:53 PM, Graham wrote:

>> 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
>
> You haven't actually mentioned whether it's a URI or not, and also 
> [therefore] whether relative values are allowed.

Oops, thinko, cut-&-paste error.  Heh, everyone else was so used to 
reading it that they missed the absence, as I did.  Off to fix it.  As 
for whether it's relative, I think we're still arguing about that.  
-Tim



From owner-atom-syntax@mail.imc.org  Thu Jul 29 01:26: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 BAA01560
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 01: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 i6T5DFno015478;
	Wed, 28 Jul 2004 22:13: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 i6T5DFAd015477;
	Wed, 28 Jul 2004 22:13: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 i6T5DDap015460
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 22:13:14 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 29 Jul 2004 15:19:09 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Thu, 29 Jul 2004 15:13:17 +1000
Subject: Re: PaceBasicAtomID - maybe we're done
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD2EC48D.234FD%eric.scheid@ironclad.net.au>
In-Reply-To: <m3oelz33lr.fsf@bitsko.slc.ut.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


On 29/7/04 1:16 PM, "Ken MacLeod" <ken@bitsko.slc.ut.us> wrote:

> The gist is that the atom:entry/atom:id identifies the entry as whole
> (all of its versions).  Each version may have a separate identifier
> that identifies the version, located elsewhere in a non-core element.
> Consumers should use the most current version of an entry from a feed
> or other source with the same atom:id, where "current" will be based
> on the outcome of the date discussion.

+1

this fits well with the idea "feed of versions of an entry" too

e.



From owner-atom-syntax@mail.imc.org  Thu Jul 29 01:37: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 BAA01932
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 01:37: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 i6T5RkQZ022757;
	Wed, 28 Jul 2004 22:27: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 i6T5Rkv8022756;
	Wed, 28 Jul 2004 22:27:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from relay.bbhmail.com (68-22-85-68.ded.ameritech.net [68.22.85.68])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6T5RjQx022746
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 22:27:45 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net ([65.85.192.194])
	by relay.bbhmail.com (8.12.8/8.12.8) with ESMTP id i6T5hs3D025701;
	Thu, 29 Jul 2004 01:43:55 -0400
Received: from *Unknown*-port25-SMSHGIBEAVERTON[10.42.1.200] by SMSHGIBEAVERTON[65.85.192.194]; Thu, 29 Jul 2004 01:07:41 -0000 (???)
Message-ID: <41088AC3.6030605@intertwingly.net>
Date: Thu, 29 Jul 2004 01:27:31 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <Tim.Bray@Sun.COM>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceBasicAtomID - maybe we're done
References: <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com> <41084874.4040806@intertwingly.net> <5F758DFA-E0F9-11D8-B732-000A95A51C9E@sun.com>
In-Reply-To: <5F758DFA-E0F9-11D8-B732-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 Jul 28, 2004, at 5:44 PM, Sam Ruby wrote:
> 
>> IMHO, this does not fully solve the original problem that Dare was 
>> trying to express... I see this as primarily because the discussion 
>> wandered off into permathread land and what Dare was trying to express 
>> was lost.
> 
> OK... although the language in the Pace about dupe detection is pretty 
> well straight from Dare.

Yes... after Dare was lead into the http vs non-http URI scheme 
discussion.  So I claim that you only captured a portion of his original 
concern.

> So concretely, you're suggesting that we beef 
> up the draft with some language explaining the use-case of the same 
> entry in multiple different feeds. -Tim

Yes.

- Sam Ruby




From owner-atom-syntax@mail.imc.org  Thu Jul 29 02: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 CAA18475
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 02: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 i6T6Kkrd055634;
	Wed, 28 Jul 2004 23:20:46 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6T6KkMP055633;
	Wed, 28 Jul 2004 23:20:46 -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 i6T6KjFp055558
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 23:20: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 566627C122; Thu, 29 Jul 2004 09:16:01 +0200 (CEST)
Date: Thu, 29 Jul 2004 08:24:27 +0200
To: "Sam Ruby" <rubys@intertwingly.net>
Subject: Re: Relative URI references
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <834420551.20040727005900@djpowell.net> <BB9A9F4A-DF7E-11D8-8C8C-000A95A51C9E@sun.com> <792475969.20040727224245@djpowell.net> <D83EF099-E0A3-11D8-8C8C-000A95A51C9E@sun.com> <m3isc840ot.fsf@bitsko.slc.ut.us> <099FB762-E0B1-11D8-8C8C-000A95A51C9E@sun.com> <opsbu6twvzuvpchu@quark> <41082408.903@intertwingly.net> <opsbvfjgdbuvpchu@quark> <410845D9.4050609@intertwingly.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: <opsbvyq1gcuvpchu@quark>
In-Reply-To: <410845D9.4050609@intertwingly.net>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Wed, 28 Jul 2004 20:33:29 -0400, Sam Ruby <rubys@intertwingly.net>  
wrote:

> If you look closely, you will see that I use relative URI's in my  
> current Atom feed: http://www.intertwingly.net/blog/index.atom

And the good reason to do this, is? Whenever an entry in that feed gets  
syndicated, moved or whatever, it will need to be resolved and made  
absolute. Why move that responsibility up to users of your feed or cause  
potential problems for yourself in the future, when they can be fixed with  
absolute URI's now?

Also, if you asked a million Bob's, they would not tell you that the ID's  
in that feed were relative. They would tell you that the ID's were an  
integer. Moving the responsibility of preserving uniqueness to consumers  
is imho a bad idea.

> I've also mentioned a reason why this might be a good idea here:  
> http://www.intertwingly.net/blog/2004/03/30/Uniqueness

Sorry, but I can't agree that this is a good idea. It might be if  
consumers find out somehow that «Hey, this possibly can't be unique!» and  
therefore concat the in-entry ID's with the domain they're fetched from,  
but if you place such a responsibility on consumers, what will happen when  
the feeds move? Will the producer suddenly change his mind and make the  
ID's absolute, to preserve them? If so, should the consumer pay attention  
to this, and stop concating the ID with the domain?

Allowing for relative URI's create a worms nest of problems we really  
can't have and don't need. I don't understand why that's a good idea.

-- 
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 Jul 29 02: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 CAA19246
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 02:40: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 i6T6WZxN061143;
	Wed, 28 Jul 2004 23:32: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 i6T6WZ1m061142;
	Wed, 28 Jul 2004 23:32: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 i6T6WYUH061106
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 23:32:35 -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 381787C122
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 09:27:56 +0200 (CEST)
Date: Thu, 29 Jul 2004 08:36:27 +0200
To: Atom-Syntax <atom-syntax@imc.org>
Subject: PaceRecommendIdScheme
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: <opsbvza1bkuvpchu@quark>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 haven't posted directly about this pace yet, so I'm doing it now:

<url: http://intertwingly.net/wiki/pie/PaceRecommendIdScheme>

== Proposal ==

Replace section 4.2.6 and 5.5 with:

=== 4.2.6  "atom:id" Element ===

The "atom:id" element's content conveys a permanent, universally unique  
identifier for the feed.  It MUST be universally unique, which means that  
it must be unique both at the time of creation and in the future. This  
means that it SHOULD contain the date and time of when the ID was  
created.  It MUST NOT change over time, even if the feed is relocated.  
atom:head elements MAY contain an atom:id element, but MUST NOT contain  
more than one.

The content of this element, when present, MUST be a URI. The URI scheme  
of atom:id 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. The recommended URI scheme for  
atom:id is [http://www.ietf.org/rfc/rfc3085.txt "NewsML ID"].

atom:id MUST NOT under any circumstance be relative. It MUST always be a  
complete, opaque and absolute URI that does not require any  
post-processing to fulfil the above requirements for persistency and  
universally uniqueness.

=== 5.5  "atom:id" Element ===

The "atom:id" element's content conveys a permanent, universally unique  
identifier for the entry.  It MUST be universally unique, which means that  
it must be unique both at the time of creation and in the future. This  
means that it SHOULD contain the date of when it was created.  If the  
entry is served dynamically, the ID MUST be created only once and then  
stored along with the entry. The ID MUST NOT be created dynamically.

It 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.

atom:entry MUST contain exactly one atom:id element.  The content of this  
element, MUST be a URI. The URI scheme of atom:id 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. The recommended URI scheme for atom:id is  
[http://www.ietf.org/rfc/rfc3085.txt "NewsML ID"].

atom:id MUST NOT under any circumstance be relative. It MUST always be a  
complete, opaque and absolute URI that does not require any  
post-processing to fulfil the above requirements for persistency and  
universally uniqueness.

-- 
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 Jul 29 02:41: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 CAA19336
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 02:41: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 i6T6VOHD060619;
	Wed, 28 Jul 2004 23:31: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 i6T6VOCA060618;
	Wed, 28 Jul 2004 23:31:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6T6VNx8060552
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 23:31: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 E90A97C1EE; Thu, 29 Jul 2004 09:26:44 +0200 (CEST)
To: elias@torrez.us
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceBasicAtomID - maybe we're done
References: <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com> <905f7c910407281755504266ba@mail.gmail.com>
Message-ID: <opsbvy80xauvpchu@quark>
Date: Thu, 29 Jul 2004 08:35:14 +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: <905f7c910407281755504266ba@mail.gmail.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Wed, 28 Jul 2004 20:55:33 -0400, Elias Torres <eliast@gmail.com> wrote:

> I don't think any wording can satisfy what some of us are asking. We
> want a format that people can count on when looking an ID, this needs
> to be identifiable, comparable, immutable, universal, dereferencable
> and include versioning and the current pace does not reflect that.

+1. I think, however, PaceRecommendIdScheme[1], reflects this, and at the  
same time allows for atom:id to be an HTTP URI. Thus, it doesn't leave  
anyone out in the cold, but for Bob and his friends, it explicitly names a  
scheme.

____
[1] <url: http://intertwingly.net/wiki/pie/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  Thu Jul 29 02:47: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 CAA19737
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 02:47: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 i6T6cukG064491;
	Wed, 28 Jul 2004 23:38: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 i6T6cusC064490;
	Wed, 28 Jul 2004 23:38:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6T6ctqW064469
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 23:38:56 -0700 (PDT)
	(envelope-from sewe@rbg.informatik.tu-darmstadt.de)
Received: from [212.227.126.179] (helo=mrelayng.kundenserver.de)
	by moutng.kundenserver.de with esmtp (Exim 3.35 #1)
	id 1Bq4Z3-0005Ba-00; Thu, 29 Jul 2004 08:38:53 +0200
Received: from [217.247.90.230] (helo=baron)
	by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1)
	id 1Bq4Z3-0002t2-00; Thu, 29 Jul 2004 08:38:53 +0200
Message-ID: <003201c47536$d5cbbf00$e65af7d9@baron>
From: "Andreas Sewe" <sewe@rbg.informatik.tu-darmstadt.de>
To: "Sam Ruby" <rubys@intertwingly.net>
Cc: "[Atom]" <atom-syntax@imc.org>
References: <834420551.20040727005900@djpowell.net> <BB9A9F4A-DF7E-11D8-8C8C-000A95A51C9E@sun.com> <792475969.20040727224245@djpowell.net> <D83EF099-E0A3-11D8-8C8C-000A95A51C9E@sun.com> <m3isc840ot.fsf@bitsko.slc.ut.us> <099FB762-E0B1-11D8-8C8C-000A95A51C9E@sun.com> <opsbu6twvzuvpchu@quark> <41082408.903@intertwingly.net>
Subject: Re: Relative URI references
Date: Thu, 29 Jul 2004 08:39:35 +0200
Organization: Fachbereich Informatik, TU Darmstadt
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
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: <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


Sam Ruby wrote:
> Asbjørn Ulsberg wrote:
>> Not sure if the wording is the best, so we might need to work on that,
>> but  it at least captures the essence: Relative URI's should be
>> forbidden in  atom:id.

> This seems rather extreme.  The original question was about xml:base.
> If this is the answer to xml:base, then this approach should be done
> throughout the spec.  If not, there should be some rationalle as to why
> ids are different.

Well, notably the XML Namespaces recommendation deprecates the use of relative
URI references, and I would argue that atom:id is a case comparable to xmlns,
given that both are to be considered opaque and not necessarily
dereferenceable.

Furthermore the XML Base recommendation [1] states:

> Namespaces in XML [XML Names] uses URI references, which as currently
> defined should not be resolved relative to the base URI defined by xml:base
> for the purposes of namespace identification. [...]

Since identification is exactly what atom:id is meant for, being not
dereferenceable, so I would say xml:base should not apply to atom:id. But then
again it would be even better when atom:id is limited to absolute URIs.

Regards,

Andreas Sewe

[1]: <http://www.w3.org/TR/xmlbase/>



From owner-atom-syntax@mail.imc.org  Thu Jul 29 02:53: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 CAA20049
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 02:53: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 i6T6gnKn066817;
	Wed, 28 Jul 2004 23:42: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 i6T6gnvp066816;
	Wed, 28 Jul 2004 23:42: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 i6T6gmtR066756
	for <atom-syntax@imc.org>; Wed, 28 Jul 2004 23:42: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 ACFFE7C122; Thu, 29 Jul 2004 09:38:11 +0200 (CEST)
Date: Thu, 29 Jul 2004 08:46:49 +0200
To: "Mark Baker" <distobj@acm.org>
Subject: Re: PaceBasicAtomID - maybe we're done
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com> <20040729033456.GM30868@markbaker.ca>
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: <opsbvzsbpguvpchu@quark>
In-Reply-To: <20040729033456.GM30868@markbaker.ca>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Wed, 28 Jul 2004 23:34:56 -0400, Mark Baker <distobj@acm.org> wrote:

> I have to give it a -1 primarily for the "SHOULD consider another URI
> scheme" statement, since that's strongly recommending what I consider to
> be bad practice; having important identifiers which aren't
> dereferencable.  I'd be content with "MAY".

In any case, you cannot expect atom:id to be dereferencable. Ever. So  
what's the real point of it being so in perhaps 33% of the cases? (Or  
more. Or less.)

-- 
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 Jul 29 03:41:43 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23278
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 03:41: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 i6T7UGmR089203;
	Thu, 29 Jul 2004 00:30:16 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6T7UG8e089202;
	Thu, 29 Jul 2004 00:30:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6T7UEoq089154
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 00:30:15 -0700 (PDT)
	(envelope-from julian.reschke@gmx.de)
Received: (qmail 24652 invoked by uid 65534); 29 Jul 2004 07:30:09 -0000
Received: from pD9E5142B.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.20.43)
  by mail.gmx.net (mp002) with SMTP; 29 Jul 2004 09:30:09 +0200
X-Authenticated: #1915285
Message-ID: <4108A77F.7030801@gmx.de>
Date: Thu, 29 Jul 2004 09:30:07 +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: Relative URI references
References: <834420551.20040727005900@djpowell.net> <BB9A9F4A-DF7E-11D8-8C8C-000A95A51C9E@sun.com> <792475969.20040727224245@djpowell.net> <D83EF099-E0A3-11D8-8C8C-000A95A51C9E@sun.com> <m3isc840ot.fsf@bitsko.slc.ut.us> <099FB762-E0B1-11D8-8C8C-000A95A51C9E@sun.com> <opsbu6twvzuvpchu@quark> <905f7c9104072813395d8cac05@mail.gmail.com> <opsbu83nyluvpchu@quark> <41082D2F.9080005@gmx.de> <opsbvf3rb0uvpchu@quark>
In-Reply-To: <opsbvf3rb0uvpchu@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 Thu, 29 Jul 2004 00:48:15 +0200, Julian Reschke 
> <julian.reschke@gmx.de>  wrote:
> 
>> 1) Just point to the correct production in RFC2396 ot RFC2396bis,
> 
> 
> Where in the text would those references go, exactly?

Such as...:

   "atom:id MUST be an absolute URI (see "absoluteURI", RFC2396, section
    3). ..."

>> 2) what does it mean for a URI to be "opaque"?
> 
> 
> «Opaque» is probably not the right word. What I mean is that the 
> string[1]  inside atom:id should be straight-forward to understand and 
> do something  useful with. To be able to use the string as an 
> identifier, you should  only have to extract it without any further 
> processing. It's just a unique  string.

If this is for detection of duplicates, the only thing the spec should 
say is how two given identifiers are to be compared. There are several 
layers of URI equivalence, and we'll need a layer that's works well with 
arbitrary schemes -- maybe simple character-by-character conversion is 
just fine.

> At the second you begin to add a lot of processing and complex rules on  
> what to do with atom:id if it's relative and so on, you will increase 
> the  possibility of having mutated, non-unique ID's significantly. If we 
> agree  that the main purpose of an ID is to identify the resource, and 
> not «be»  anything but a plain stupid string, we at least have a common 
> ground we  can move in the same direction from.

I absolutely agree that anything except an absoluteURI doesn't make 
sense here...

> I hope that it's not more important for an ID to be an URI and thus 
> allow  for everything that is possible to do with every URI scheme in 
> existance,  than it is for an ID to be globally, and hopefully 
> universally, unique and  immutable.

But for the ID to have all these attributes, it *needs* to be a URI (so 
some other syntactical construct we can all agree on), otherwise there's 
no way to avoid collsions).

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From owner-atom-syntax@mail.imc.org  Thu Jul 29 03:43: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 DAA23467
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 03:43: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 i6T7ZdNn091867;
	Thu, 29 Jul 2004 00:35: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 i6T7ZdJg091866;
	Thu, 29 Jul 2004 00:35: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 i6T7ZbPB091844
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 00:35:38 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 29 Jul 2004 17:41:26 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Thu, 29 Jul 2004 17:35:33 +1000
Subject: Re: Relative URI references
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Sam Ruby <rubys@intertwingly.net>, Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD2EE5E5.235DC%eric.scheid@ironclad.net.au>
In-Reply-To: <410845D9.4050609@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: <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/7/04 10:33 AM, "Sam Ruby" <rubys@intertwingly.net> wrote:

> If you look closely, you will see that I use relative URI's in my
> current Atom feed: http://www.intertwingly.net/blog/index.atom

I note that there are neither xml:base nor a http-header Location: to
establish what the base URI is, and since that same resource can be fetched
from both these URLs...

    http://intertwingly.net/blog/index.atom
    http://www.intertwingly.net/blog/index.atom

that means the <id>s in your feed can be different.

Hmmm ... I can also access that resource by the following URL, and similar
variations:

        http://foo:bar@intertwingly.net/blog/index.atom

Your relative URI id's are thus broken, IMHO.

If you can get this wrong, what do you think Bob will likely do?

e.



From owner-atom-syntax@mail.imc.org  Thu Jul 29 03: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 DAA24346
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 03:54: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 i6T7jaPN096830;
	Thu, 29 Jul 2004 00:45:36 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6T7jarM096829;
	Thu, 29 Jul 2004 00:45:36 -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 i6T7jZTm096782
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 00:45:35 -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 58D097C122
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 10:40:59 +0200 (CEST)
Date: Thu, 29 Jul 2004 09:49:53 +0200
To: Atom-Syntax <atom-syntax@imc.org>
Subject: PaceDates
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: <opsbv2pfapuvpchu@quark>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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've hacked the PaceDates a bit to accommodate the needs I have seen for  
dates in Atom, but also to cater for the existing practice. Alas, this  
leaves us with a pretty big bag of dates, but that won't be a problem if  
all of them are well specified, and if current practice is captured with  
at least one of the date constructs proposed:

<url: http://intertwingly.net/wiki/pie/PaceDates>

== Proposal ==

Replace or append to section 3.3, 4.13.6, 4.13.7 and 4.13.8 the following:

=== 3.3 Date Constructs ===

A Date Construct is an element whose child content is an RFC 3339  
Date-Time string [RFC 3339] which SHOULD be less than or equal to the  
variable "now". That means that a Date Construct SHOULD NOT contain a date  
in the future.

If a Date Construct does not exist, it MUST NOT be assumed to have the  
semantic or value of any other Date Construct.

=== 4.13.6 "atom:modified" Element ===

The "atom:modified" element is a Date Construct that indicates the time  
that the entry was last modified. atom:entry elements SHOULD contain an  
atom:modified element, but MUST NOT contain more than one. If no other  
Date Construct is available for the atom:entry, atom:modified MUST be  
present.

The content of an atom:modified element MUST according to RFC 3339 have a  
time zone whose value SHOULD be "+00:00" or "Z".

If an atom:entry is re-issued at several different locations,  
atom:modified MAY be altered to indicate this change in the entry's state.

An atom:modified date does only give a slight indication of modification.  
If atom:modified has not changed, it is safe to assume that the entry  
itself has not changed either. However, a change in atom:modified does not  
necessarily imply a change in the entry itself.

=== 4.13.7 "atom:issued" Element ===

The "atom:issued" element is a Date Construct, giving the date of formal  
issuance (e.g., publication) of the entry. atom:entry elements SHOULD  
contain an atom:issued element, but MUST NOT contain more than one. If no  
other Date Construct is available for the atom:entry, atom:issued MUST be  
present.

The content of an atom:issued element MUST according to RFC 3339 have a  
time zone whose value SHOULD be "+00:00" or "Z".

If an atom:entry is re-issued at several different locations, atom:issued  
MAY be altered to indicate this change in the entry's state.

=== 4.13.8 "atom:first-issued" Element ===

The "atom:first-issued" element is a Date Construct, giving the first date  
of formal issuance (e.g., publication) of the entry. atom:entry elements  
SHOULD contain an atom:first-issued element, but MUST NOT contain more  
than one. If no other Date Construct is available for the atom:entry,  
atom:first-issued MUST be present.

The content of an atom:issued element MUST according to RFC 3339 have a  
time zone whose value SHOULD be "+00:00" or "Z".

If an atom:entry is re-issued at several different locations, atom:first  
MUST NOT be altered to indicate this change in the entry's state.

=== 4.13.9 "atom:created" Element ===

The "atom:created" element is a Date construct that indicates the time  
that the entry was created. atom:entry elements SHOULD contain an  
atom:created element, but MUST NOT contain more than one. If no other Date  
Construct is available for the atom:entry, atom:created MUST be present.

The content of an atom:modified element MUST according to RFC 3339 have a  
time zone whose value SHOULD be "+00:00" or "Z".

=== 4.13.10 "atom:date" Element ===

The "atom:date" element is a Date Construct, giving the date associated  
with the entry. Typically, atom:date will be associated with the creation  
or availability of the resource, but its semantics is laregely up to the  
tools to define. atom:date exists for compatibility reasons and therefore  
SHOULD NOT be used. atom:entry elements MAY contain an atom:date element,  
but MUST NOT contain more than one. If no other Date Construct is  
available for the atom:entry, atom:date MUST be present.

The content of an atom:date element MUST according to RFC 3339 have a time  
zone whose value SHOULD be "+00:00" or "Z". The time zone MAY, however, be  
"-00:00" when the time is known to be correct UTC, but the time zone is  
unknown, or be '+hh:mm' when the time zone is known.

atom:date MAY change to order the entries in an Atom feed or on a front  
page of a website correctly. It MAY also change to convey the date the  
author wants associated with the 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  Thu Jul 29 09:39: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 JAA10707
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 09:39: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 i6TDRNpv021369;
	Thu, 29 Jul 2004 06:27: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 i6TDRNsf021368;
	Thu, 29 Jul 2004 06:27:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from relay.bbhmail.com (68-22-85-68.ded.ameritech.net [68.22.85.68])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TDRM99021361
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 06:27:22 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net ([65.85.192.194])
	by relay.bbhmail.com (8.12.8/8.12.8) with ESMTP id i6TDhP3D030897;
	Thu, 29 Jul 2004 09:43:27 -0400
Received: from *Unknown*-port25-SMSHGIBEAVERTON[10.42.1.200] by SMSHGIBEAVERTON[65.85.192.194]; Thu, 29 Jul 2004 09:07:14 -0000 (???)
Message-ID: <4108FB30.2030407@intertwingly.net>
Date: Thu, 29 Jul 2004 09:27:12 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Eric Scheid <eric.scheid@ironclad.net.au>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Relative URI references
References: <BD2EE5E5.235DC%eric.scheid@ironclad.net.au>
In-Reply-To: <BD2EE5E5.235DC%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:

> On 29/7/04 10:33 AM, "Sam Ruby" <rubys@intertwingly.net> wrote:
> 
>>If you look closely, you will see that I use relative URI's in my
>>current Atom feed: http://www.intertwingly.net/blog/index.atom
> 
> I note that there are neither xml:base nor a http-header Location: to
> establish what the base URI is, and since that same resource can be fetched
> from both these URLs...
> 
>     http://intertwingly.net/blog/index.atom
>     http://www.intertwingly.net/blog/index.atom
> 
> that means the <id>s in your feed can be different.

Good point.  At a minimum, that is worthy of an informative note.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Thu Jul 29 09:56: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 JAA11632
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 09: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 i6TDl0ZO025875;
	Thu, 29 Jul 2004 06: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 i6TDl01M025874;
	Thu, 29 Jul 2004 06:47:00 -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 i6TDl0a8025868
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 06:47:00 -0700 (PDT)
	(envelope-from distobj@acm.org)
Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian))
	id 1BqBG7-0007gY-00; Thu, 29 Jul 2004 09:47:47 -0400
Date: Thu, 29 Jul 2004 09:47:47 -0400
To: Asbj?rn Ulsberg <asbjorn@tigerstaden.no>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceBasicAtomID - maybe we're done
Message-ID: <20040729134747.GN30868@markbaker.ca>
References: <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com> <20040729033456.GM30868@markbaker.ca> <opsbvzsbpguvpchu@quark>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <opsbvzsbpguvpchu@quark>
User-Agent: Mutt/1.3.28i
From: Mark Baker <distobj@acm.org>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


On Thu, Jul 29, 2004 at 08:46:49AM +0200, Asbj?rn Ulsberg wrote:
> On Wed, 28 Jul 2004 23:34:56 -0400, Mark Baker <distobj@acm.org> wrote:
> 
> >I have to give it a -1 primarily for the "SHOULD consider another URI
> >scheme" statement, since that's strongly recommending what I consider to
> >be bad practice; having important identifiers which aren't
> >dereferencable.  I'd be content with "MAY".
> 
> In any case, you cannot expect atom:id to be dereferencable. Ever. So  
> what's the real point of it being so in perhaps 33% of the cases? (Or  
> more. Or less.)

The point is that there are those who wish to *demonstrate* that their
identifiers are persistent, and making them dereferencable is the lowest
cost, pervasively deployed means that exists for doing that.

Mark.



From owner-atom-syntax@mail.imc.org  Thu Jul 29 10: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 KAA14443
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 10:20:25 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TECIRa030692;
	Thu, 29 Jul 2004 07:12:18 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6TECIC9030691;
	Thu, 29 Jul 2004 07:12:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.196])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TECHao030685
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 07:12:17 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id 76so11095rnk
        for <atom-syntax@imc.org>; Thu, 29 Jul 2004 07:12:19 -0700 (PDT)
Received: by 10.38.9.72 with SMTP id 72mr1615rni;
        Thu, 29 Jul 2004 07:12:19 -0700 (PDT)
Message-ID: <14be96d30407290712a692568@mail.gmail.com>
Date: Thu, 29 Jul 2004 10:12:19 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Mark Baker <distobj@acm.org>
Subject: Re: PaceBasicAtomID - maybe we're done
Cc: Asbj?rn Ulsberg <asbjorn@tigerstaden.no>,
        Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <20040729134747.GN30868@markbaker.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com> <20040729033456.GM30868@markbaker.ca> <opsbvzsbpguvpchu@quark> <20040729134747.GN30868@markbaker.ca>
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 Thu, 29 Jul 2004 09:47:47 -0400, Mark Baker <distobj@acm.org> wrote:
> On Thu, Jul 29, 2004 at 08:46:49AM +0200, Asbj?rn Ulsberg wrote:
> > In any case, you cannot expect atom:id to be dereferencable. Ever. So
> > what's the real point of it being so in perhaps 33% of the cases? (Or
> > more. Or less.)
> 
> The point is that there are those who wish to *demonstrate* that their
> identifiers are persistent, and making them dereferencable is the lowest
> cost, pervasively deployed means that exists for doing that.

I'm not sure how making an ID dereferenceable demonstrates its persistence.

http://www.hoopla.com/500/paddock/00000002.html

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Thu Jul 29 10:23: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 KAA14565
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 10:23: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 i6TEDXfW031013;
	Thu, 29 Jul 2004 07:13: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 i6TEDXKR031012;
	Thu, 29 Jul 2004 07:13: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 i6TEDW6g031005
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 07:13:32 -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 6BA0F4EEE2;
	Thu, 29 Jul 2004 10:13:33 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040729172524.04af9780@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Thu, 29 Jul 2004 17:26:57 +0900
To: elias@torrez.us, Tim Bray <tim.bray@sun.com>
From: Martin Duerst <duerst@w3.org>
Subject: Re: PaceBasicAtomID - maybe we're done
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <905f7c910407281755504266ba@mail.gmail.com>
References: <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com>
 <F803A7BC-E0EF-11D8-B732-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>


At 20:55 04/07/28 -0400, Elias Torres wrote:

>Tim, you are right that given the amount of time we gave this issue, I
>think we should not revisit everything again, but first, I see no
>major argument against picking a scheme, except for "best practices"
>to use a generic URI on things that don't even relate to identifiers
>and the fact that some people just don't like URNs, but besides that I
>have not heard a real show stopper if we were to use ONE scheme.

Independence of different specs, flexibility for future developments,
and the possibility for people to choose something that suits their
needs don't count as arguments for you?

Regards,    Martin.



From owner-atom-syntax@mail.imc.org  Thu Jul 29 10:23: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 KAA14639
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 10:23: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 i6TEET4B031180;
	Thu, 29 Jul 2004 07:14: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 i6TEET86031179;
	Thu, 29 Jul 2004 07:14:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from relay.bbhmail.com (68-22-85-68.ded.ameritech.net [68.22.85.68])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TEETx3031173
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 07:14:29 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net ([65.85.192.194])
	by relay.bbhmail.com (8.12.8/8.12.8) with ESMTP id i6TEUY3D031381;
	Thu, 29 Jul 2004 10:30:35 -0400
Received: from *Unknown*-port25-SMSHGIBEAVERTON[10.42.1.200] by SMSHGIBEAVERTON[65.85.192.194]; Thu, 29 Jul 2004 09:54:22 -0000 (???)
Message-ID: <41090641.3020606@intertwingly.net>
Date: Thu, 29 Jul 2004 10:14:25 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Relative URI references
References: <834420551.20040727005900@djpowell.net> <BB9A9F4A-DF7E-11D8-8C8C-000A95A51C9E@sun.com> <792475969.20040727224245@djpowell.net> <D83EF099-E0A3-11D8-8C8C-000A95A51C9E@sun.com> <m3isc840ot.fsf@bitsko.slc.ut.us> <099FB762-E0B1-11D8-8C8C-000A95A51C9E@sun.com> <opsbu6twvzuvpchu@quark> <41082408.903@intertwingly.net> <opsbvfjgdbuvpchu@quark> <410845D9.4050609@intertwingly.net> <opsbvyq1gcuvpchu@quark>
In-Reply-To: <opsbvyq1gcuvpchu@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:
> 
>> I've also mentioned a reason why this might be a good idea here:  
>> http://www.intertwingly.net/blog/2004/03/30/Uniqueness
> 
> Sorry, but I can't agree that this is a good idea. It might be if  
> consumers find out somehow that «Hey, this possibly can't be unique!» 
> and  therefore concat the in-entry ID's with the domain they're fetched 
> from,

This is *NOT* a matter of consumers finding out "somehow" that «Hey, 
this possibly can't be unique!».  Please read section 3.1 of RFC 2396:

    Relative URI references are distinguished from absolute URI in that
    they do not begin with a scheme name.  Instead, the scheme is
    inherited from the base URI

A proposal to disallow relative URIs everywhere would be logically 
self-consistent.  I would prefer we did not go that way, but I could 
understand that postion.

I can also see an argument as to why certain elements are intrinsicly 
different and therefore need to be handled differently from the rest 
being brought forth.

But to disallow relative URIs in one element because Asbjørn is unable 
to see a good reason for them, and is unable or unwilling to understand 
that relative URIs can be distinguised from absolute URIs with a simple 
test: "is there a scheme present?"... well, sorry, I don't find that 
sufficient reason.

In any case, a rationalle of "The Atom specification should recommend an 
URI scheme to use for atom:id." is insufficient.  PaceRecommendIdScheme 
needs to be updated.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Thu Jul 29 10:24: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 KAA14682
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 10:24: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 i6TEDUBR030993;
	Thu, 29 Jul 2004 07: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 i6TEDULG030992;
	Thu, 29 Jul 2004 07:13: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 [18.29.0.30])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TEDTJH030985
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 07:13: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 DC2B04F0E8;
	Thu, 29 Jul 2004 10:13:26 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040729172140.05b23408@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Thu, 29 Jul 2004 17:29:14 +0900
To: Asbj=?ISO-2022-JP?B?GyRCj1MbKEI=?=n Ulsberg <asbjorn@tigerstaden.no>,
        Atom-Syntax <atom-syntax@imc.org>
From: Martin Duerst <duerst@w3.org>
Subject: Re: PaceRecommendIdScheme
In-Reply-To: <opsbvza1bkuvpchu@quark>
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: <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


At 08:36 04/07/29 +0200, Asbj$BS(Bn Ulsberg wrote:

>atom:entry MUST contain exactly one atom:id element.  The content of this
>element, MUST be a URI. The URI scheme of atom:id 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. The recommended URI scheme for atom:id is
>[http://www.ietf.org/rfc/rfc3085.txt "NewsML ID"].

Sorry, but like others, I find it totally inappropriate to pick out
one particular scheme. There are other schemes that work in quite a
similar way, and there are still other schemes that cover other
needs that other people may feel is important in their applications.
There may also be new schemes in the future that cover still
different requirements.

Also, at least the current definition of the newsml scheme is
tied to NewsML documents, and Atom isn't nor shouldn't be
restricted to such. Also, Atom should not put requirements or
restrictions on the newsml scheme and the NewsML community.

Giving examples may be okay, but there should be more than one
example. With the language above, there is a risk some blogging
tools hard-code newsml into their code. That would be bad.

Regards,    Martin.



From owner-atom-syntax@mail.imc.org  Thu Jul 29 11:14: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 LAA17694
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 11: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 i6TF42B1041351;
	Thu, 29 Jul 2004 08:04: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 i6TF42CG041350;
	Thu, 29 Jul 2004 08:04: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 i6TF42RH041339
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 08:04:02 -0700 (PDT)
	(envelope-from distobj@acm.org)
Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian))
	id 1BqCSa-00082p-00; Thu, 29 Jul 2004 11:04:44 -0400
Date: Thu, 29 Jul 2004 11:04:44 -0400
To: Mark Pilgrim <pilgrim@gmail.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Demonstrating persistence
Message-ID: <20040729150444.GO30868@markbaker.ca>
References: <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com> <20040729033456.GM30868@markbaker.ca> <opsbvzsbpguvpchu@quark> <20040729134747.GN30868@markbaker.ca> <14be96d30407290712a692568@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <14be96d30407290712a692568@mail.gmail.com>
User-Agent: Mutt/1.3.28i
From: Mark Baker <distobj@acm.org>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


On Thu, Jul 29, 2004 at 10:12:19AM -0400, Mark Pilgrim wrote:
> On Thu, 29 Jul 2004 09:47:47 -0400, Mark Baker <distobj@acm.org> wrote:
> > On Thu, Jul 29, 2004 at 08:46:49AM +0200, Asbj?rn Ulsberg wrote:
> > > In any case, you cannot expect atom:id to be dereferencable. Ever. So
> > > what's the real point of it being so in perhaps 33% of the cases? (Or
> > > more. Or less.)
> > 
> > The point is that there are those who wish to *demonstrate* that their
> > identifiers are persistent, and making them dereferencable is the lowest
> > cost, pervasively deployed means that exists for doing that.
> 
> I'm not sure how making an ID dereferenceable demonstrates its persistence.
> 
> http://www.hoopla.com/500/paddock/00000002.html

Picky, picky!

Of course, making the URI dereferencable isn't a sufficient condition
for persistence.  You also need to ensure that what it dereferences to
represents the resource it identifies.

Mark.



From owner-atom-syntax@mail.imc.org  Thu Jul 29 11:18: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 LAA18078
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 11:18: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 i6TFAxJZ042700;
	Thu, 29 Jul 2004 08:10: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 i6TFAxpK042699;
	Thu, 29 Jul 2004 08:10: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.199])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TFAwgH042687
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 08:10:58 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id 74so14935rnk
        for <atom-syntax@imc.org>; Thu, 29 Jul 2004 08:11:01 -0700 (PDT)
Received: by 10.38.2.75 with SMTP id 75mr41172rnb;
        Thu, 29 Jul 2004 08:11:01 -0700 (PDT)
Message-ID: <14be96d30407290811b87de58@mail.gmail.com>
Date: Thu, 29 Jul 2004 11:11:01 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Mark Baker <distobj@acm.org>
Subject: Re: Demonstrating persistence
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <20040729150444.GO30868@markbaker.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com> <20040729033456.GM30868@markbaker.ca> <opsbvzsbpguvpchu@quark> <20040729134747.GN30868@markbaker.ca> <14be96d30407290712a692568@mail.gmail.com> <20040729150444.GO30868@markbaker.ca>
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 Thu, 29 Jul 2004 11:04:44 -0400, Mark Baker <distobj@acm.org> wrote:
> On Thu, Jul 29, 2004 at 10:12:19AM -0400, Mark Pilgrim wrote:
> > On Thu, 29 Jul 2004 09:47:47 -0400, Mark Baker <distobj@acm.org> wrote:
> > > On Thu, Jul 29, 2004 at 08:46:49AM +0200, Asbj?rn Ulsberg wrote:
> > > > In any case, you cannot expect atom:id to be dereferencable. Ever. So
> > > > what's the real point of it being so in perhaps 33% of the cases? (Or
> > > > more. Or less.)
> > >
> > > The point is that there are those who wish to *demonstrate* that their
> > > identifiers are persistent, and making them dereferencable is the lowest
> > > cost, pervasively deployed means that exists for doing that.
> >
> > I'm not sure how making an ID dereferenceable demonstrates its persistence.
> >
> > http://www.hoopla.com/500/paddock/00000002.html
> 
> Picky, picky!
> 
> Of course, making the URI dereferencable isn't a sufficient condition
> for persistence.  You also need to ensure that what it dereferences to
> represents the resource it identifies.

It used to.

http://www.textism.com/article/494

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Thu Jul 29 11: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 LAA19030
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 11:39: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 i6TFRUjV046373;
	Thu, 29 Jul 2004 08:27: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 i6TFRUEL046372;
	Thu, 29 Jul 2004 08:27:30 -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 i6TFRUVw046366
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 08:27:30 -0700 (PDT)
	(envelope-from distobj@acm.org)
Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian))
	id 1BqCpQ-00086q-00
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 11:28:20 -0400
Date: Thu, 29 Jul 2004 11:28:20 -0400
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Demonstrating persistence
Message-ID: <20040729152820.GP30868@markbaker.ca>
References: <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com> <20040729033456.GM30868@markbaker.ca> <opsbvzsbpguvpchu@quark> <20040729134747.GN30868@markbaker.ca> <14be96d30407290712a692568@mail.gmail.com> <20040729150444.GO30868@markbaker.ca> <14be96d30407290811b87de58@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <14be96d30407290811b87de58@mail.gmail.com>
User-Agent: Mutt/1.3.28i
From: Mark Baker <distobj@acm.org>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


On Thu, Jul 29, 2004 at 11:11:01AM -0400, Mark Pilgrim wrote:
> http://www.textism.com/article/494

Sh*t happens.  Luckily, it doesn't happen very often.  For every example
like that, there's thousands of others who've had no problems.

I don't believe that's sufficient evidence to warrant SHOULD-strength
language against using dereferencable atom:ids.

Mark.



From owner-atom-syntax@mail.imc.org  Thu Jul 29 11:42: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 LAA19203
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 11:42: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 i6TFYDgg047460;
	Thu, 29 Jul 2004 08:34: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 i6TFYDHk047457;
	Thu, 29 Jul 2004 08:34:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.192])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TFYCYE047444
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 08:34:12 -0700 (PDT)
	(envelope-from eliast@gmail.com)
Received: by mproxy.gmail.com with SMTP id 77so13682rnk
        for <atom-syntax@imc.org>; Thu, 29 Jul 2004 08:34:14 -0700 (PDT)
Received: by 10.38.209.3 with SMTP id h3mr128740rng;
        Thu, 29 Jul 2004 08:34:14 -0700 (PDT)
Message-ID: <905f7c9104072908344269d033@mail.gmail.com>
Date: Thu, 29 Jul 2004 11:34:14 -0400
From: Elias Torres <eliast@gmail.com>
Reply-To: elias@torrez.us
To: Martin Duerst <duerst@w3.org>
Subject: Re: PaceBasicAtomID - maybe we're done
Cc: elias@torrez.us, Tim Bray <tim.bray@sun.com>,
        Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <4.2.0.58.J.20040729172524.04af9780@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com>
 <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com> <4.2.0.58.J.20040729172524.04af9780@localhost>
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


Very important issues you bring up. But let's look at an anology:

In databases we have primary keys, why are there different types of
primary keys? integers, guids, etc. Why not a VARCHAR(2048)? That for
sure will suit everone's needs. We're talking about an optional
element (atom:id) in a feed. If it doesn't suit "your" personal needs,
don't use it. What I'm try to suggest is that we find a scheme that
suits "80%" of the world, so those 80% can do really useful stuff with
those IDs.

If you don't like NewsML, tag, publicid, LSID don't use the field, its
optional. Why does one person want to impose on others what they
personally want to use for an id? Remember the id is only an id to the
public, not to their private systems. If you want to use an HTTP
URI/URL, hash it and make it urn:lsid:martinduerst:HASH:1 for us who
need something consistent. Internally or might as well through an
extension add your HTTP URI (which we could get already from the
atom:link elements, anyways.

If this is not reason enough and people feel I'm wasting the WG times,
I'll desist from pushing this scheme and we can move on, but I'm still
not technically convinced I'm wrong.

Regards,

Elias Torres

On Thu, 29 Jul 2004 17:26:57 +0900, Martin Duerst <duerst@w3.org> wrote:
> 
> At 20:55 04/07/28 -0400, Elias Torres wrote:
> 
> >Tim, you are right that given the amount of time we gave this issue, I
> >think we should not revisit everything again, but first, I see no
> >major argument against picking a scheme, except for "best practices"
> >to use a generic URI on things that don't even relate to identifiers
> >and the fact that some people just don't like URNs, but besides that I
> >have not heard a real show stopper if we were to use ONE scheme.
> 
> Independence of different specs, flexibility for future developments,
> and the possibility for people to choose something that suits their
> needs don't count as arguments for you?
> 
> Regards,    Martin.
> 
>



From owner-atom-syntax@mail.imc.org  Thu Jul 29 11: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 LAA20159
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 11: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 i6TFhWGl049027;
	Thu, 29 Jul 2004 08:43:32 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6TFhWp4049026;
	Thu, 29 Jul 2004 08:43: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 i6TFhVPo049009
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 08:43:31 -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 1BqD45-0001QL-VQ; Thu, 29 Jul 2004 15:43:30 +0000
Message-ID: <41091B20.7050106@franklinmint.fm>
Date: Thu, 29 Jul 2004 11:43:28 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mark Baker <distobj@acm.org>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Demonstrating persistence
References: <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com> <20040729033456.GM30868@markbaker.ca> <opsbvzsbpguvpchu@quark> <20040729134747.GN30868@markbaker.ca> <14be96d30407290712a692568@mail.gmail.com> <20040729150444.GO30868@markbaker.ca> <14be96d30407290811b87de58@mail.gmail.com> <20040729152820.GP30868@markbaker.ca>
In-Reply-To: <20040729152820.GP30868@markbaker.ca>
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 Baker wrote:
> 
> I don't believe that's sufficient evidence to warrant SHOULD-strength
> language against using dereferencable atom:ids.
> 

The Pace says

"...implementors SHOULD consider using another URI scheme ... which does 
not imply information-retrieval semantics."

While that wording is certainly diplomatic, I'm not sure it's a good use 
of RFC2119 terms.

Does it mean "SHOULD adopt"?

Robert Sayre



From owner-atom-syntax@mail.imc.org  Thu Jul 29 12:29: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 MAA22856
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 12: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 i6TGJC5M055802;
	Thu, 29 Jul 2004 09: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 i6TGJCtk055801;
	Thu, 29 Jul 2004 09:19:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TGJCXG055786
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 09:19:12 -0700 (PDT)
	(envelope-from antone@geckotribe.com)
Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134])
          by comcast.net (sccrmhc13) with SMTP
          id <2004072916190901600i3o02e>; Thu, 29 Jul 2004 16:19:10 +0000
Date: Thu, 29 Jul 2004 10:19:09 -0600
Subject: Re: PaceBasicAtomID - maybe we're done
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: <905f7c9104072908344269d033@mail.gmail.com>
Message-Id: <05257EAE-E17B-11D8-9043-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 Thursday, July 29, 2004, at 09:34  AM, Elias Torres wrote:
> Very important issues you bring up. But let's look at an anology:
>
> In databases we have primary keys, why are there different types of
> primary keys? integers, guids, etc. Why not a VARCHAR(2048)? That for
> sure will suit everone's needs.
I'm either not following your analogy, or I disagree. VARCHAR(2048) 
would NOT be suitable for everyone's needs. First, it would cause 
sortability issues for people who want to do numeric sorts on their 
primary key. Does record 20 sort before or after record 100? In a text 
sort, it sorts after. Second, doing joins on VARCHAR(2048) would 
require a tremendous amount of memory--at least on some systems.  
Third, VARCHAR(2048) would be impossible on any system that uses a 
single byte to indicate the length of the data.  There are plenty of 
reasons of various kinds for using different kinds of primary keys. 
Relating that to atom:id, are we confident that some particular scheme 
for generating ID's will work fine for virtually everyone?  Though on 
its face it may seems like a simple question, like VARCHAR(2048), there 
may be drawbacks that aren't immediately apparent.

> We're talking about an optional
> element (atom:id) in a feed. If it doesn't suit "your" personal needs,
> don't use it. What I'm try to suggest is that we find a scheme that
> suits "80%" of the world, so those 80% can do really useful stuff with
> those IDs.
Feed id's are optional, but entry id's are mandatory, so we'd best not 
pick a scheme that's too burdensome or unsuitable for a large number of 
people.



From owner-atom-syntax@mail.imc.org  Thu Jul 29 12:31:04 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23011
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 12:31:04 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TGM7gm057077;
	Thu, 29 Jul 2004 09:22:07 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6TGM7xd057076;
	Thu, 29 Jul 2004 09:22:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.200])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TGM6M0057070
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 09:22:07 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id 74so19944rnk
        for <atom-syntax@imc.org>; Thu, 29 Jul 2004 09:22:09 -0700 (PDT)
Received: by 10.38.2.75 with SMTP id 75mr51811rnb;
        Thu, 29 Jul 2004 09:22:09 -0700 (PDT)
Message-ID: <14be96d304072909225fc91ee6@mail.gmail.com>
Date: Thu, 29 Jul 2004 12:22:09 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Mark Baker <distobj@acm.org>
Subject: Re: Demonstrating persistence
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <20040729152820.GP30868@markbaker.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com> <20040729033456.GM30868@markbaker.ca> <opsbvzsbpguvpchu@quark> <20040729134747.GN30868@markbaker.ca> <14be96d30407290712a692568@mail.gmail.com> <20040729150444.GO30868@markbaker.ca> <14be96d30407290811b87de58@mail.gmail.com> <20040729152820.GP30868@markbaker.ca>
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 Thu, 29 Jul 2004 11:28:20 -0400, Mark Baker <distobj@acm.org> wrote:
> 
> On Thu, Jul 29, 2004 at 11:11:01AM -0400, Mark Pilgrim wrote:
> > http://www.textism.com/article/494
> 
> Sh*t happens.  Luckily, it doesn't happen very often.  For every example
> like that, there's thousands of others who've had no problems.

...Yet.

Look, so far I've heard many outrageous claims from the "http:// URIs
to rule them all" camp.  That they're dereferenceable.  (Sometimes,
but there's no way to tell without trying.)  That they're "supported"
by applications that are installed on my computer.  (Only if they're
dereferenceable.)  That they're persistent.  (Not all the time, and
it's not always your fault.)  That they're persistent *because*
they're dereferenceable.  (Provably false.)

I think the major obstacle to our understanding each other is the
first one.  Sometimes, http:// URIs are dereferenceable.  Sometimes
they're not.  You point at that as if it were a feature and say,
"Look, they're a floor wax *and* a dessert topping, isn't that great?"
 And I say, "Um, no, that sucks."  Anything else we say to each other
is really beside the point; we're already talking past each other.

If you want to use "http://" URIs as IDs, I think Atom should let you.
 I don't want to, and I think Atom should let me too.  Stating the
requirements (globally unique, unchanging even under all the
conditions which Ken listed out) is enough; mandating or even
recommending one scheme over another does not advance our goals.

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Thu Jul 29 12:32: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 MAA23138
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 12:32: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 i6TGKAJv055985;
	Thu, 29 Jul 2004 09:20: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 i6TGKAf4055984;
	Thu, 29 Jul 2004 09:20:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from dns01.mail.yahoo.co.jp (dns01.mail.yahoo.co.jp [211.14.15.204])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6TGK8xA055926
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 09:20:09 -0700 (PDT)
	(envelope-from torumyax@yahoo.co.jp)
Received: from unknown (HELO yahoo.co.jp) (43.244.78.169 with poptime)
  by dns01.mail.yahoo.co.jp with SMTP; 29 Jul 2004 16:19:57 -0000
X-Apparently-From: <torumyax@yahoo.co.jp>
Date: Fri, 30 Jul 2004 01:50:14 +0900
From: Toru Marumoto <torumyax@yahoo.co.jp>
Subject: Re: Relative URI references
To: Atom-Syntax <atom-syntax@imc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: TuruKame 3.06
In-Reply-To: <410845D9.4050609@intertwingly.net>
References: <410845D9.4050609@intertwingly.net>
Message-Id: <C8C4758C1EC8CCtorumyax@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




Sam Ruby wrote:

>If you look closely, you will see that I use relative URI's in my 
>current Atom feed: http://www.intertwingly.net/blog/index.atom

Oh, that's why I couldn't read your article with my Atom aggregator..;-)

I think there is a risk of using relatibve URI's *without providing
 a base url in the feed*.

what if you use some online aggregator services, such as Blogline.com?
what if you wanted to transform atom into html using XSLT [1] locally?
what if the feed was to be served via RSS/Atom search engines?

I tested on several aggregators, and sadly they failed to point to the 
right address.

[1]http://www.witha.jp/HepCat/files/default.xsl.txt


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  Thu Jul 29 12:59:52 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24832
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 12:59: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 i6TGqhSJ062504;
	Thu, 29 Jul 2004 09:52: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 i6TGqh5Y062503;
	Thu, 29 Jul 2004 09:52:43 -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 i6TGqhF8062492
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 09:52:43 -0700 (PDT)
	(envelope-from jarober@gosmalltalk.com)
Received: from victoria (pcp01741172pcs.howard01.md.comcast.net[68.54.83.139])
          by comcast.net (sccrmhc12) with ESMTP
          id <2004072916524101200fnqdfe>; Thu, 29 Jul 2004 16:52:41 +0000
Received: from james2.gosmalltalk.com (james [10.55.1.103])
	by victoria (8.11.0/8.11.0) with ESMTP id i6TGqeR05100
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 12:52:40 -0400
Message-Id: <6.1.2.0.2.20040729125130.043eaec0@www.gosmalltalk.com>
X-Sender: jarober@gosmalltalk.com@www.gosmalltalk.com
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Thu, 29 Jul 2004 12:52:34 -0400
To: atom-syntax@imc.org
From: James Robertson <jarober@gosmalltalk.com>
Subject: Re: Relative URI references
In-Reply-To: <C8C4758C1EC8CCtorumyax@yahoo.co.jp>
References: <410845D9.4050609@intertwingly.net>
 <C8C4758C1EC8CCtorumyax@yahoo.co.jp>
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>


Umm, what failed to point to the right address?  I just tested that feed in 
BottomFeeder, and I didn't see any obvious problems


> >If you look closely, you will see that I use relative URI's in my
> >current Atom feed: http://www.intertwingly.net/blog/index.atom
>
>Oh, that's why I couldn't read your article with my Atom aggregator..;-)
>
>I think there is a risk of using relatibve URI's *without providing
>  a base url in the feed*.
>
>what if you use some online aggregator services, such as Blogline.com?
>what if you wanted to transform atom into html using XSLT [1] locally?
>what if the feed was to be served via RSS/Atom search engines?
>
>I tested on several aggregators, and sadly they failed to point to the
>right address.
>
>[1]http://www.witha.jp/HepCat/files/default.xsl.txt
>
>
>Toru Marumoto
>      see you on the web!
>________________________________
>
>--------------------------------
>__________________________________________________
>GANBARE! NIPPON!
>Yahoo! JAPAN JOC OFFICIAL INTERNET PORTAL SITE
>http://mail.ganbare-nippon.yahoo.co.jp/

<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  Thu Jul 29 13: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 NAA24964
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 13: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 i6TGsap8063048;
	Thu, 29 Jul 2004 09:54: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 i6TGsaU5063047;
	Thu, 29 Jul 2004 09:54:36 -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 i6TGsZ4G063041
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 09:54:36 -0700 (PDT)
	(envelope-from distobj@acm.org)
Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian))
	id 1BqEBj-00005f-00
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 12:55:27 -0400
Date: Thu, 29 Jul 2004 12:55:26 -0400
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Demonstrating persistence
Message-ID: <20040729165526.GQ30868@markbaker.ca>
References: <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com> <20040729033456.GM30868@markbaker.ca> <opsbvzsbpguvpchu@quark> <20040729134747.GN30868@markbaker.ca> <14be96d30407290712a692568@mail.gmail.com> <20040729150444.GO30868@markbaker.ca> <14be96d30407290811b87de58@mail.gmail.com> <20040729152820.GP30868@markbaker.ca> <14be96d304072909225fc91ee6@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <14be96d304072909225fc91ee6@mail.gmail.com>
User-Agent: Mutt/1.3.28i
From: Mark Baker <distobj@acm.org>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


On Thu, Jul 29, 2004 at 12:22:09PM -0400, Mark Pilgrim wrote:
> If you want to use "http://" URIs as IDs, I think Atom should let you.
>  I don't want to, and I think Atom should let me too.

Great, me too!  I want equal treatment for all schemes.  And to me, that
means not recommending for or against a scheme just because it happens
to be associated with an application protocol, as the pace currently
does by using "SHOULD" against the use of http URIs.  Hence my
suggestion to change it to "MAY".

So, I think that brings us full-circle.  I don't expect I'll have
anything more to say on this subject.

Cheers,

Mark.



From owner-atom-syntax@mail.imc.org  Thu Jul 29 13:01:54 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24989
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 13:01: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 i6TGnb6t062027;
	Thu, 29 Jul 2004 09:49: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 i6TGnblU062026;
	Thu, 29 Jul 2004 09:49: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 ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TGnaLc061989
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 09:49: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 B29F97C0F3; Thu, 29 Jul 2004 19:44:54 +0200 (CEST)
Date: Thu, 29 Jul 2004 18:53:21 +0200
To: "Mark Baker" <distobj@acm.org>
Subject: Re: Demonstrating persistence
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com> <20040729033456.GM30868@markbaker.ca> <opsbvzsbpguvpchu@quark> <20040729134747.GN30868@markbaker.ca> <14be96d30407290712a692568@mail.gmail.com> <20040729150444.GO30868@markbaker.ca> <14be96d30407290811b87de58@mail.gmail.com> <20040729152820.GP30868@markbaker.ca>
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: <opsbwru7hnuvpchu@quark>
In-Reply-To: <20040729152820.GP30868@markbaker.ca>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Thu, 29 Jul 2004 11:28:20 -0400, Mark Baker <distobj@acm.org> wrote:

>> http://www.textism.com/article/494
>
> Sh*t happens.

Well, it proves that dereferencability of ID breaks either the  
dereferencability or the ID itself when something moves. And both entries  
and feedsw will move. All the time. Changing the ID to reflect the new  
location of the entry is a critical break of the specification (and of any  
idea of persistent ID's), and not changing it breaks dereferencibility.

How is dereferencable ID's good, when it only takes one relocation of an  
entry to break everything?

> Luckily, it doesn't happen very often.

Uhm. Okay? Entries doesn't move often? Not as often as they don't move,  
but that's not a part of the equation either. Proof that entries move,  
which they do, should be enough to discourage dereferencable ID's.

> For every example like that, there's thousands of others who've had
> no problems.

That only proves that these thousands of users never have moved their  
entries. Everyone that ever moves anything will eventually get themselves  
into serious trouble. They can of course do HTTP redirects from the old  
location to the new one, but that requires the user to have 100% control  
over the old location for the lifetime of the ID of the entry. And that's  
not feasible. For anyone.

> I don't believe that's sufficient evidence to warrant SHOULD-strength
> language against using dereferencable atom:ids.

I disagree.

-- 
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 Jul 29 13:15: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 NAA25985
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 13:15: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 i6TH1lpF064460;
	Thu, 29 Jul 2004 10:01: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 i6TH1lEh064459;
	Thu, 29 Jul 2004 10:01:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TH1koJ064441;
	Thu, 29 Jul 2004 10:01:46 -0700 (PDT)
	(envelope-from jasnell@us.ibm.com)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11])
	by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i6TH17u3357916;
	Thu, 29 Jul 2004 13:01:08 -0400
Received: from d03nm122.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 i6TH17cq411930;
	Thu, 29 Jul 2004 11:01:07 -0600
In-Reply-To: <14be96d304072909225fc91ee6@mail.gmail.com>
To: Mark Pilgrim <pilgrim@gmail.com>
Cc: Atom-Syntax <atom-syntax@imc.org>, Mark Baker <distobj@acm.org>,
        owner-atom-syntax@mail.imc.org
MIME-Version: 1.0
Subject: Re: Demonstrating persistence
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
From: James M Snell <jasnell@us.ibm.com>
X-MIMETrack: S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/29/2004 09:57:38 AM,
	Serialize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/29/2004 09:57:38 AM,
	Serialize complete at 07/29/2004 09:57:38 AM,
	Itemize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/29/2004 09:57:38 AM,
	S/MIME Sign complete at 07/29/2004 09:57:38 AM,
	S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/29/2004 10:01:03 AM,
	S/MIME Sign complete at 07/29/2004 10:01:03 AM,
	Serialize by Router on D03NM122/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at
 07/29/2004 11:01:07,
	Serialize complete at 07/29/2004 11:01:07
Message-ID: <OF12C5B193.918D0DBF-ON88256EE0.005CD9DB-88256EE0.005D7AF9@us.ibm.com>
Date: Thu, 29 Jul 2004 11:01:03 -0600
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z58969_boundary_sign
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>


This is an S/MIME signed message.

---------z58969_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 005D2AA888256EE0_="

This is a multipart message in MIME format.
--=_alternative 005D2AA888256EE0_=
Content-Type: text/plain; charset="US-ASCII"

Mark Pilgrim wrote on 07/29/2004 09:22:09 AM:

> 
> On Thu, 29 Jul 2004 11:28:20 -0400, Mark Baker <distobj@acm.org> wrote:
> > 
> > On Thu, Jul 29, 2004 at 11:11:01AM -0400, Mark Pilgrim wrote:
> > > http://www.textism.com/article/494
> > 
> > Sh*t happens.  Luckily, it doesn't happen very often.  For every 
example
> > like that, there's thousands of others who've had no problems.
> 
> ...Yet.
> 
> Look, so far I've heard many outrageous claims from the "http:// URIs
> to rule them all" camp.  That they're dereferenceable.  (Sometimes,
> but there's no way to tell without trying.)  That they're "supported"
> by applications that are installed on my computer.  (Only if they're
> dereferenceable.)  That they're persistent.  (Not all the time, and
> it's not always your fault.)  That they're persistent *because*
> they're dereferenceable.  (Provably false.)
> 
> I think the major obstacle to our understanding each other is the
> first one.  Sometimes, http:// URIs are dereferenceable.  Sometimes
> they're not.  You point at that as if it were a feature and say,
> "Look, they're a floor wax *and* a dessert topping, isn't that great?"
>  And I say, "Um, no, that sucks."  Anything else we say to each other
> is really beside the point; we're already talking past each other.
> 
> If you want to use "http://" URIs as IDs, I think Atom should let you.
>  I don't want to, and I think Atom should let me too.  Stating the
> requirements (globally unique, unchanging even under all the
> conditions which Ken listed out) is enough; mandating or even
> recommending one scheme over another does not advance our goals.
> 

+1 on not picking one scheme.  +1 on stating that ID's may be ANY URI 
syntax that meets the requirements of being unique and unchanging. 

> -- 
> Cheers,
> -Mark
> 


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

--=_alternative 005D2AA888256EE0_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>Mark Pilgrim wrote on 07/29/2004 09:22:09 AM:<br>
<br>
&gt; <br>
&gt; On Thu, 29 Jul 2004 11:28:20 -0400, Mark Baker &lt;distobj@acm.org&gt;
wrote:<br>
&gt; &gt; <br>
&gt; &gt; On Thu, Jul 29, 2004 at 11:11:01AM -0400, Mark Pilgrim wrote:<br>
&gt; &gt; &gt; http://www.textism.com/article/494<br>
&gt; &gt; <br>
&gt; &gt; Sh*t happens. &nbsp;Luckily, it doesn't happen very often. &nbsp;For
every example<br>
&gt; &gt; like that, there's thousands of others who've had no problems.<br>
&gt; <br>
&gt; ...Yet.<br>
&gt; <br>
&gt; Look, so far I've heard many outrageous claims from the &quot;http://
URIs<br>
&gt; to rule them all&quot; camp. &nbsp;That they're dereferenceable. &nbsp;(Sometimes,<br>
&gt; but there's no way to tell without trying.) &nbsp;That they're &quot;supported&quot;<br>
&gt; by applications that are installed on my computer. &nbsp;(Only if
they're<br>
&gt; dereferenceable.) &nbsp;That they're persistent. &nbsp;(Not all the
time, and<br>
&gt; it's not always your fault.) &nbsp;That they're persistent *because*<br>
&gt; they're dereferenceable. &nbsp;(Provably false.)<br>
&gt; <br>
&gt; I think the major obstacle to our understanding each other is the<br>
&gt; first one. &nbsp;Sometimes, http:// URIs are dereferenceable. &nbsp;Sometimes<br>
&gt; they're not. &nbsp;You point at that as if it were a feature and say,<br>
&gt; &quot;Look, they're a floor wax *and* a dessert topping, isn't that
great?&quot;<br>
&gt; &nbsp;And I say, &quot;Um, no, that sucks.&quot; &nbsp;Anything else
we say to each other<br>
&gt; is really beside the point; we're already talking past each other.<br>
&gt; <br>
&gt; If you want to use &quot;http://&quot; URIs as IDs, I think Atom should
let you.<br>
&gt; &nbsp;I don't want to, and I think Atom should let me too. &nbsp;Stating
the<br>
&gt; requirements (globally unique, unchanging even under all the<br>
&gt; conditions which Ken listed out) is enough; mandating or even<br>
&gt; recommending one scheme over another does not advance our goals.<br>
&gt; </tt></font>
<br>
<br><font size=2><tt>+1 on not picking one scheme. &nbsp;+1 on stating
that ID's may be ANY URI syntax that meets the requirements of being unique
and unchanging. </tt></font>
<br><font size=2><tt><br>
&gt; -- <br>
&gt; Cheers,<br>
&gt; -Mark<br>
&gt; <br>
</tt></font>
<br>
<br><font size=2 face="sans-serif">- James M Snell<br>
 &nbsp;jasnell@us.ibm.com<br>
 &nbsp;http://www.ibm.com<br>
 &nbsp;(877) 511-5082 / Office<br>
 &nbsp;930-1979 / Tie Line</font>
<br>
--=_alternative 005D2AA888256EE0_=--

---------z58969_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIIUOAIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIISWDCCAtow
ggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1
aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAy
MDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA629xc49NpAPz
cAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7glzJKgPkPzlTZZfznznGbmAWVnNBQ
lyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnwNclOnnP2sKufuPzbTImQTTi5c8JZNZcM
J0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEEBAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1Ud
DgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAPBgNVHRMBAf8EBTADAQH/MDEGA1UdJQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUH
AwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvu
jQupk2oCScMd3FIHLE7hOfu8YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14ke
McF9ViNdewEoBGiAycUq8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIC2jCCAkOgAwIB
AgIDAxS2MA0GCSqGSIb3DQEBBAUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwMTE0MjIw
NzExWhcNMTExMjMxMjIwNzExWjBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25h
bCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrb3Fzj02kA/NwCy5KFMiY
tFgyTJ6kMSQLVSs9uwVHIAVkqy/enDQwZ9b/7uCXMkqA+Q/OVNll/OfOcZuYBZWc0FCXI9qw60KO
J/rTd65FdF4dwp8cw8si0qjOJtYg8cm46fA1yU6ec/awq5+4/NtMiZBNOLlzwlk1lwwnRgXNNwID
AQABo4GqMIGnMBEGCWCGSAGG+EIBAQQEAwIAhzAOBgNVHQ8BAf8EBAMCAcYwHQYDVR0OBBYEFK5U
DpLqqDOpKyQtx8hvMNze80pAMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMA8GA1Ud
EwEB/wQFMAMBAf8wMQYDVR0lBCowKAYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYB
BQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAMnJ7c2YLyrY/PKlFl+7sm8NENfWtFxqdm+6NC6mTagJJ
wx3cUgcsTuE5+7xh9+/G0tTfLzA1qZAQ5GNMPXvmoB9+vJfKnC2JWMFQpIOUEJDXiR4xwX1WI117
ASgEaIDJxSrxHcuuV/hMIO9bgZ6C41MUVmdLTKBgBOImTuIPK8QwggMgMIICiaADAgECAgQ13vTP
MA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQL
EyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0MTUxWhcN
MTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMk
RXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKKlQRkrPFr
U18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkwrFEeO68r
1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOgYaRfMF0x
CzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBD
ZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAxODA4MjIx
NjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAdBgNV
HQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0HQQAEDTAL
GwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwlMQ0AppJu
f7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn00DbOyZY
sih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMgMIICiaADAgEC
AgQ13vTPMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0
MTUxWhcNMTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsG
A1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKK
lQRkrPFrU18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkw
rFEeO68r1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOg
YaRfMF0xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNl
Y3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAx
ODA4MjIxNjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAdBgNVHQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0H
QQAEDTALGwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwl
MQ0AppJuf7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn
00DbOyZYsih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMmMIIC
j6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIxNjM2NTRaMIGFMQsw
CQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEXMBUGA1UEAxMOSmFt
ZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkqhkiG9w0BCQEWEmph
c25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwKpbDG3zMatEuuOT
FYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSyd+7nwqAvbBfPj+0S
vcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7tBJlLrwDRCMoNlPuQ
Kg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQW
BBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOgFAwSamFzbmVs
bEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pAMCcGA1UdJQQgMB4G
CCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAZMKevB7dFfb9
23OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY8BjwVHxiYgG4xkxf
B1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOIzj3lz3xd+uOzqRFg
/Wsg/VMwggMmMIICj6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAy
BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNV
BAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIx
NjM2NTRaMIGFMQswCQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEX
MBUGA1UEAxMOSmFtZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkq
hkiG9w0BCQEWEmphc25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
wKpbDG3zMatEuuOTFYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSy
d+7nwqAvbBfPj+0SvcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7t
BJlLrwDRCMoNlPuQKg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQD
AgXgMB0GA1UdDgQWBBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcU
AgOgFAwSamFzbmVsbEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA
MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQAD
gYEAZMKevB7dFfb923OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY
8BjwVHxiYgG4xkxfB1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOI
zj3lz3xd+uOzqRFg/Wsg/VMxggG7MIIBtwIBATBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJ
bnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0g
Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwF+kzAJBgUrDgMCGgUAoIGiMBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDcyOTE2NTczOFowIwYJKoZIhvcNAQkEMRYE
FKx351hWbuGqQWCs3y4RGX9NYb3IMEMGCSqGSIb3DQEJDzE2MDQwBwYFKw4DAh0wDgYIKoZIhvcN
AwICAgCAMAoGCCqGSIb3DQMHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAbLV5uBDl
tUQMjFjZsN7VF7ZRMihKJAUyhrYdKMww4Lu+D7rtLHMgPOEKAQLbvDAZcAdDY6DGByXvhmtId40+
FjeZNxi+9NM0QSw93jQM19Puw8Hsz6TjXIEZOIdkfcnIAz1QZ4widn/CEJWLdbU1vtaODha+jzGg
2zPrfCv9Iz0AAAAA

---------z58969_boundary_sign--



From owner-atom-syntax@mail.imc.org  Thu Jul 29 14:04: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 OAA28619
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 14:04: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 i6THsUle073972;
	Thu, 29 Jul 2004 10: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 i6THsUEK073971;
	Thu, 29 Jul 2004 10:54:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6THsTSV073943
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 10:54: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 4536C7C122; Thu, 29 Jul 2004 20:49:52 +0200 (CEST)
Date: Thu, 29 Jul 2004 19:58:33 +0200
To: "Sam Ruby" <rubys@intertwingly.net>
Subject: Re: Relative URI references
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <834420551.20040727005900@djpowell.net> <BB9A9F4A-DF7E-11D8-8C8C-000A95A51C9E@sun.com> <792475969.20040727224245@djpowell.net> <D83EF099-E0A3-11D8-8C8C-000A95A51C9E@sun.com> <m3isc840ot.fsf@bitsko.slc.ut.us> <099FB762-E0B1-11D8-8C8C-000A95A51C9E@sun.com> <opsbu6twvzuvpchu@quark> <41082408.903@intertwingly.net> <opsbvfjgdbuvpchu@quark> <410845D9.4050609@intertwingly.net> <opsbvyq1gcuvpchu@quark> <41090641.3020606@intertwingly.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: <opsbwuvv06uvpchu@quark>
In-Reply-To: <41090641.3020606@intertwingly.net>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Thu, 29 Jul 2004 10:14:25 -0400, Sam Ruby <rubys@intertwingly.net>  
wrote:

> This is *NOT* a matter of consumers finding out "somehow" that «Hey,  
> this possibly can't be unique!».  Please read section 3.1 of RFC 2396:
>
>     Relative URI references are distinguished from absolute URI in that
>     they do not begin with a scheme name.  Instead, the scheme is
>     inherited from the base URI

Do we reference RFC 2396 and this particular paragraph, regarding  
resolution of atom:id, in the specification, so Bob will easilly find this  
out? No we don't. We probably should. I still don't think that's enough.

> A proposal to disallow relative URIs everywhere would be logically  
> self-consistent.  I would prefer we did not go that way, but I could  
> understand that postion.

I don't see why we need to forbid relative URI's for all Atom elements,  
but if consistency is that important, then okay.

> I can also see an argument as to why certain elements are intrinsicly  
> different and therefore need to be handled differently from the rest  
> being brought forth.

I'm not sure what the specific use case for xml:base and relative URI's  
is, but I think that it's more useful on <content> than any other element  
inside Atom. This would have to be confirmed with and by the tool vendors,  
though.

> But to disallow relative URIs in one element because Asbjørn is unable  
> to see a good reason for them, and is unable or unwilling to understand  
> that relative URIs can be distinguised from absolute URIs with a simple  
> test: "is there a scheme present?"... well, sorry, I don't find that  
> sufficient reason.

Okay. Good point. What do you expect Bob to do, both as a consumer and  
producer, when the feed of the entry which has relative ID's in it, moves?

And would you place a high bet on that Bob is able to provide a correct  
Content-Location header or xml:base to even make the relative atom:id  
resolvable?

> In any case, a rationalle of "The Atom specification should recommend an  
> URI scheme to use for atom:id." is insufficient.  PaceRecommendIdScheme  
> needs to be updated.

I need a better rationale in the pace?

-- 
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 Jul 29 14:21:44 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29483
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 14: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 i6TI5qYi076151;
	Thu, 29 Jul 2004 11: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 i6TI5qgu076150;
	Thu, 29 Jul 2004 11:05:52 -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 i6TI5pvs076134
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 11:05:51 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net (ip195.198.145.31.iinet.com [198.145.31.195])
	(authenticated bits=0)
	by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i6TI715N013556;
	Thu, 29 Jul 2004 14:07:01 -0400
Message-ID: <41093C7E.5090707@intertwingly.net>
Date: Thu, 29 Jul 2004 14:05:50 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Relative URI references
References: <834420551.20040727005900@djpowell.net> <BB9A9F4A-DF7E-11D8-8C8C-000A95A51C9E@sun.com> <792475969.20040727224245@djpowell.net> <D83EF099-E0A3-11D8-8C8C-000A95A51C9E@sun.com> <m3isc840ot.fsf@bitsko.slc.ut.us> <099FB762-E0B1-11D8-8C8C-000A95A51C9E@sun.com> <opsbu6twvzuvpchu@quark> <41082408.903@intertwingly.net> <opsbvfjgdbuvpchu@quark> <410845D9.4050609@intertwingly.net> <opsbvyq1gcuvpchu@quark> <41090641.3020606@intertwingly.net> <opsbwuvv06uvpchu@quark>
In-Reply-To: <opsbwuvv06uvpchu@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:

>> A proposal to disallow relative URIs everywhere would be logically  
>> self-consistent.  I would prefer we did not go that way, but I could  
>> understand that postion.
> 
> I don't see why we need to forbid relative URI's for all Atom elements,  
> but if consistency is that important, then okay.

[snip]

>> But to disallow relative URIs in one element because Asbjørn is 
>> unable  to see a good reason for them, and is unable or unwilling to 
>> understand  that relative URIs can be distinguised from absolute URIs 
>> with a simple  test: "is there a scheme present?"... well, sorry, I 
>> don't find that  sufficient reason.
> 
> Okay. Good point. What do you expect Bob to do, both as a consumer and  
> producer, when the feed of the entry which has relative ID's in it, moves?
> 
> And would you place a high bet on that Bob is able to provide a correct  
> Content-Location header or xml:base to even make the relative atom:id  
> resolvable?

If Bob uses relative URIs and moves his feed, then he will need to 
update his relative URIs to match.  All such relative URIs, not just 
<atom:id>.  If you want to argue that relative URIs are mostly OK, but 
not for the id tag, you need to focus on arguments that support that 
point.  Good examples of such arguments can be found at:

http://www.imc.org/atom-syntax/mail-archive/msg08013.html

>> In any case, a rationalle of "The Atom specification should recommend 
>> an  URI scheme to use for atom:id." is insufficient.  
>> PaceRecommendIdScheme  needs to be updated.
> 
> I need a better rationale in the pace?

The current rationale supports the following statement, and not much else:

    The recommended URI scheme for atom:id is "NewsML ID"

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Thu Jul 29 14:36: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 OAA00407
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 14:36: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 i6TITAvZ080810;
	Thu, 29 Jul 2004 11: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 i6TITA3D080809;
	Thu, 29 Jul 2004 11:29:10 -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 i6TIT97c080740
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 11:29:09 -0700 (PDT)
	(envelope-from torumyax@yahoo.co.jp)
Received: from unknown (HELO yahoo.co.jp) (43.244.5.32 with poptime)
  by dns02.mail.yahoo.co.jp with SMTP; 29 Jul 2004 18:28:58 -0000
X-Apparently-From: <torumyax@yahoo.co.jp>
Date: Fri, 30 Jul 2004 03:59:15 +0900
From: Toru Marumoto <torumyax@yahoo.co.jp>
Subject: Re: Relative URI references
To: atom-syntax@imc.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: TuruKame 3.06
In-Reply-To: <6.1.2.0.2.20040729125130.043eaec0@www.gosmalltalk.com>
References: <6.1.2.0.2.20040729125130.043eaec0@www.gosmalltalk.com>
Message-Id: <C9C4759E24A941torumyax@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




I've tested in the latest version of SharpReader,RSSBandit,Headline-Reader(ja),HepCat(ja)... and so on.
Oh, and Bloglines too. 

>Umm, what failed to point to the right address?  I just tested that feed in 
>BottomFeeder, and I didn't see any obvious problems
>

>> >If you look closely, you will see that I use relative URI's in my
>> >current Atom feed: http://www.intertwingly.net/blog/index.atom


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  Thu Jul 29 14:45: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 OAA00961
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 14:45: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 i6TIXHjG081533;
	Thu, 29 Jul 2004 11:33: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 i6TIXHJ9081532;
	Thu, 29 Jul 2004 11:33: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 i6TIXGgI081506
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 11:33: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 9614C7C0F3; Thu, 29 Jul 2004 21:28:39 +0200 (CEST)
Date: Thu, 29 Jul 2004 20:37:27 +0200
To: "Julian Reschke" <julian.reschke@gmx.de>
Subject: Re: Relative URI references
References: <834420551.20040727005900@djpowell.net> <BB9A9F4A-DF7E-11D8-8C8C-000A95A51C9E@sun.com> <792475969.20040727224245@djpowell.net> <D83EF099-E0A3-11D8-8C8C-000A95A51C9E@sun.com> <m3isc840ot.fsf@bitsko.slc.ut.us> <099FB762-E0B1-11D8-8C8C-000A95A51C9E@sun.com> <opsbu6twvzuvpchu@quark> <905f7c9104072813395d8cac05@mail.gmail.com> <opsbu83nyluvpchu@quark> <41082D2F.9080005@gmx.de> <opsbvf3rb0uvpchu@quark> <4108A77F.7030801@gmx.de>
Cc: Atom-Syntax <atom-syntax@imc.org>
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: <opsbwwopqruvpchu@quark>
In-Reply-To: <4108A77F.7030801@gmx.de>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Thu, 29 Jul 2004 09:30:07 +0200, Julian Reschke <julian.reschke@gmx.de>  
wrote:

> Such as...:
>
>    "atom:id MUST be an absolute URI (see "absoluteURI", RFC2396, section
>     3). ..."

Done.

> If this is for detection of duplicates, the only thing the spec should  
> say is how two given identifiers are to be compared.

Okay. I know there exist some specification text on this over at W3C, I  
just don't know where.

> I absolutely agree that anything except an absoluteURI doesn't make  
> sense here...

Great.

> But for the ID to have all these attributes, it *needs* to be a URI (so  
> some other syntactical construct we can all agree on), otherwise there's  
> no way to avoid collsions).

That's probably true, yes.

-- 
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 Jul 29 14:48:33 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01149
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 14:48: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 i6TIbZmQ082482;
	Thu, 29 Jul 2004 11: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 i6TIbZ5h082481;
	Thu, 29 Jul 2004 11:37: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 i6TIbYfW082472
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 11:37: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 25F497C0F3; Thu, 29 Jul 2004 21:32:58 +0200 (CEST)
Date: Thu, 29 Jul 2004 20:41:48 +0200
To: "Sam Ruby" <rubys@intertwingly.net>
Subject: Re: Relative URI references
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <834420551.20040727005900@djpowell.net> <BB9A9F4A-DF7E-11D8-8C8C-000A95A51C9E@sun.com> <792475969.20040727224245@djpowell.net> <D83EF099-E0A3-11D8-8C8C-000A95A51C9E@sun.com> <m3isc840ot.fsf@bitsko.slc.ut.us> <099FB762-E0B1-11D8-8C8C-000A95A51C9E@sun.com> <opsbu6twvzuvpchu@quark> <41082408.903@intertwingly.net> <opsbvfjgdbuvpchu@quark> <410845D9.4050609@intertwingly.net> <opsbvyq1gcuvpchu@quark> <41090641.3020606@intertwingly.net> <opsbwuvv06uvpchu@quark> <41093C7E.5090707@intertwingly.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: <opsbwwvyu4uvpchu@quark>
In-Reply-To: <41093C7E.5090707@intertwingly.net>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Thu, 29 Jul 2004 14:05:50 -0400, Sam Ruby <rubys@intertwingly.net>  
wrote:

> If Bob uses relative URIs and moves his feed, then he will need to  
> update his relative URIs to match.

I'm not sure what you're thinking of here. Should he change the xml:base  
or Content-Location header to match the new location of the feed? If so,  
that will genereate new ID's for all entries in the feed.

> All such relative URIs, not just <atom:id>.  If you want to argue that
> relative URIs are mostly OK, but not for the id tag, you need to focus
> on arguments that support that point.

I'm trying. :-o

> The current rationale supports the following statement, and not much  
> else:
>
>     The recommended URI scheme for atom:id is "NewsML ID"

Okay, I'll try to elaborate a bit more on why it is needed.

-- 
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 Jul 29 15:00: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 PAA01603
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 15:00: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 i6TImYCt084182;
	Thu, 29 Jul 2004 11: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 i6TImYgj084181;
	Thu, 29 Jul 2004 11:48:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TImW88084154
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 11:48:33 -0700 (PDT)
	(envelope-from asbjorn@tigerstaden.no)
Received: from quark (19.80-202-164.nextgentel.com [80.202.164.19])
	by smtpgateway.itweb.no (Postfix) with ESMTP
	id 2A08A7C0F3; Thu, 29 Jul 2004 21:43:56 +0200 (CEST)
Date: Thu, 29 Jul 2004 20:52:47 +0200
To: "Martin Duerst" <duerst@w3.org>
Subject: Re: PaceRecommendIdScheme
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <4.2.0.58.J.20040729172140.05b23408@localhost>
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: <opsbwxd9apuvpchu@quark>
In-Reply-To: <4.2.0.58.J.20040729172140.05b23408@localhost>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Thu, 29 Jul 2004 17:29:14 +0900, Martin Duerst <duerst@w3.org> wrote:

> Sorry, but like others, I find it totally inappropriate to pick out
> one particular scheme.

Okay.

> There are other schemes that work in quite a similar way, and there
> are still other schemes that cover other needs that other people may
> feel is important in their applications.

No one refuses anyone to use any other scheme. I just want to recommend  
one so Bob and his friends can find it easilly, and thus at a lesser cost  
and higher probability be able to generate universally unique and  
immutable ID's.

> There may also be new schemes in the future that cover still
> different requirements.

Sure. That goes for absolutely all specifications referenced from ours.  
Specifications will be superseded and replaced with newer and better  
specifications in the future. We can't prevent that. We also don't forbid  
anyone to use such a future scheme either, as long as it generates a valid  
URI.

> Also, at least the current definition of the newsml scheme is
> tied to NewsML documents, and Atom isn't nor shouldn't be
> restricted to such.

That's not a big problem. As Laurent Le Meur writes[1]:

   As the IPTC has already thought about a modification of the wording
   of the RFC3085 (there is an ambiguity in some wording), removing the
   express association between this URN and NewsML NewsItems could
   perhaps be studied by the IPTC, if NewsML URN are of interest for a
   broad range of users.

> Also, Atom should not put requirements or restrictions on the newsml
> scheme and the NewsML community.

Why would it? If the NewsML community agrees and maybe even encourages  
Atom's usage of NewsML URI's, why should we refrain from using it?

> Giving examples may be okay, but there should be more than one
> example.

Sure. Dare has said that he will provide some examples soon.

> With the language above, there is a risk some blogging tools hard-code
> newsml into their code. That would be bad.

Although I don't necessarily think that it's a very good idea; why would  
that be bad, exactly?

____
[1] <url: http://www.imc.org/atom-syntax/mail-archive/msg07933.html>

-- 
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 Jul 29 15: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 PAA04480
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 15:37: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 i6TJON0Y091375;
	Thu, 29 Jul 2004 12: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 i6TJONC0091374;
	Thu, 29 Jul 2004 12:24: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-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 i6TJOMg2091356
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 12:24: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 i6TJOOil020135
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 13:24:24 -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 <0I1M0047COKNOM@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Thu, 29 Jul 2004 13:24:24 -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 <0I1M003JMOKNL2@mail.sun.net> for atom-syntax@imc.org; Thu,
 29 Jul 2004 13:24:23 -0600 (MDT)
Date: Thu, 29 Jul 2004 12:24:36 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: PaceFeedEquivalence
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <ED9ED1C6-E194-11D8-B732-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: <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


While the objective is fine, I don't believe we need a separate section 
on Feed Equivalence.  I propose:

(1) a note in both the Format and Protocol specs saying "when testing 
URIs for equivalence, implementors should consider the discussion in 
RFC2396bis section 6."  (currently 
http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#comparison).
(2) a note in section 4.2.6 of the format draft saying "since the same 
feed may be served from different URIs, and feeds may be accessed other 
than by dereferencing a URI, the <atom:id> in <atom:head> may be used 
to test whether two feeds are the same."

-Tim



From owner-atom-syntax@mail.imc.org  Thu Jul 29 15:45: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 PAA04950
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 15:45: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 i6TJY3au093173;
	Thu, 29 Jul 2004 12:34:03 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6TJY3pZ093172;
	Thu, 29 Jul 2004 12:34:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-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 i6TJY0lh093156
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 12:34:02 -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 i6TJY4il025003
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 13:34:04 -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 <0I1M00D9KP0SG1@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Thu, 29 Jul 2004 13:34:04 -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 <0I1M003PAP0RL2@mail.sun.net> for atom-syntax@imc.org; Thu,
 29 Jul 2004 13:34:03 -0600 (MDT)
Date: Thu, 29 Jul 2004 12:34:20 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: PaceAutoDisco - separate draft?
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <49FAF6B9-E196-11D8-B732-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: <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


For those who haven't seen MarkP's write-up at 
http://diveintomark.org/rfc/draft-pilgrim-atom-autodiscovery-02.html, 
go have a look; I'd forgotten how long it is, but it doesn't seem 
padded.  Paul tells me that there's no process barrier to us adopting 
it as a WG draft.  So here are the questions; I think a few of them 
have easy-to-reach consensus positions, which I've proposed in square 
brackets:

1. Do we as a WG do anything about feed discovery? [Yes]

2. Do we basically agree with the content of Mark's draft? [Yes]

3. Do we try to roll Mark's material into one of our existing drafts, 
or do we adopt it as a separate committee draft? [Separate draft, it's 
too long to roll in].

(Er Mark, you OK with being editor?)

3. Do we need to point to the autodiscovery draft from either/both of 
the protocol and format drafts?  [Yes and No, i.e. yes from the 
protocol, no from the format].

  -Tim



From owner-atom-syntax@mail.imc.org  Thu Jul 29 15:53: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 PAA05208
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 15:53: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 i6TJhAEq094720;
	Thu, 29 Jul 2004 12: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 i6TJhAaY094719;
	Thu, 29 Jul 2004 12:43:10 -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 i6TJhA2u094712
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 12:43: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 i6TJeu53009251
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 13:40:56 -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 <0I1M003UDPG15Y@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Thu, 29 Jul 2004 13:43:14 -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 <0I1M00LQUPG1XL@mail.sun.net> for atom-syntax@imc.org; Thu,
 29 Jul 2004 13:43:13 -0600 (MDT)
Date: Thu, 29 Jul 2004 12:43:30 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: PaceLinkReflection - Close it
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <91CEA9B5-E197-11D8-B732-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: <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 Pace baffled me until I mentally reworded the key sentence, which 
should say something like:

If there is an <atom:link rel="alternate"> element inside a feed's 
<atom:head>, and the the <atom:link>'s href= points to an HTML page, 
then the HTML page SHOULD have a autodiscovery link element that 
reflects back to the Atom feed.

I don't agree at all.  I think it's quite possible to publish a feed 
describing changes to someone else's web site, without asking them, and 
I don't think this can possibly impose any obligation on the web site 
to point to the feed.

Close this one. -Tim



From owner-atom-syntax@mail.imc.org  Thu Jul 29 16:04: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 QAA05787
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 16:04: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 i6TJoDWC095890;
	Thu, 29 Jul 2004 12:50: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 i6TJoDtX095889;
	Thu, 29 Jul 2004 12:50: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 i6TJoCd0095883
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 12:50:12 -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 i6TJlx53012496
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 13:47: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 <0I1M004VKPRSOM@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Thu, 29 Jul 2004 13:50:17 -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 <0I1M003VGPRSL2@mail.sun.net> for atom-syntax@imc.org; Thu,
 29 Jul 2004 13:50:16 -0600 (MDT)
Date: Thu, 29 Jul 2004 12:50:33 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: PaceResource -1, PaceSimpleResourcePosting +1
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <8DCDED78-E198-11D8-B732-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: <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 think given that the mechanism in PaceSimpleResourcePosting, 
PaceResource (and all the alternatives it describes) are just no longer 
necessary.

Having said that, PaceSimpleResourcePosting contains a bunch of stray 
language about PUT and Delete and WebDAV and so on that really falls 
under other issues.

There's another issue down the road: if we do a SOAP interface, there's 
going to have to be something in it to distinguish between posting an 
entry and posting something that's not an entry.

My preferred outcome on this would be to
1. close PaceResource, and
2. approve the direct-POST mechanism in PaceSimpleResourcePosting and 
ask the protocol-draft editors to find a smooth way to work it into 
that document.

  -Tim



From owner-atom-syntax@mail.imc.org  Thu Jul 29 16:06: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 QAA05965
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 16:06: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 i6TJpMC4096116;
	Thu, 29 Jul 2004 12:51: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 i6TJpMYQ096115;
	Thu, 29 Jul 2004 12:51:22 -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 i6TJpMFX096097
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 12:51:22 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040729195121.11529.qmail@web41201.mail.yahoo.com>
Received: from [207.46.238.137] by web41201.mail.yahoo.com via HTTP; Thu, 29 Jul 2004 12:51:21 PDT
Date: Thu, 29 Jul 2004 12:51:21 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: PaceDateline
To: "Asbjørn_Ulsberg" <asbjorn@tigerstaden.no>
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <opsbs5vvfhuvpchu@quark>
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>



--- Asbjørn_Ulsberg <asbjorn@tigerstaden.no> wrote:
>> 
> Would you build support for a revisioning model into
> RSS Bandit before, or  
> only after, users make requests for it?
> 

RSS Bandit is an Open Source project. It is all about
scratching an itch. If no one has an itch for
revisioning support in RSS Bandit then it won't get
implemented. 

=====
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  Thu Jul 29 16:20: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 QAA06787
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 16: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 i6TK4Q7g098641;
	Thu, 29 Jul 2004 13:04: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 i6TK4QMu098640;
	Thu, 29 Jul 2004 13:04:26 -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 i6TK4Pmq098617
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 13:04:26 -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 <2004072920042501100t61jhe>; Thu, 29 Jul 2004 20:04:25 +0000
Received: from james2.gosmalltalk.com (james [10.55.1.103])
	by victoria (8.11.0/8.11.0) with ESMTP id i6TK4OR05514
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 16:04:24 -0400
Message-Id: <6.1.2.0.2.20040729160356.04398ec0@www.gosmalltalk.com>
X-Sender: jarober@gosmalltalk.com@www.gosmalltalk.com
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Thu, 29 Jul 2004 16:04:18 -0400
To: atom-syntax@imc.org
From: James Robertson <jarober@gosmalltalk.com>
Subject: Re: Relative URI references
In-Reply-To: <C9C4759E24A941torumyax@yahoo.co.jp>
References: <6.1.2.0.2.20040729125130.043eaec0@www.gosmalltalk.com>
 <C9C4759E24A941torumyax@yahoo.co.jp>
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>


ok, but what's the problem?  I'm seeing content, and the links look ok....

At 02:59 PM 7/29/2004, you wrote:



>I've tested in the latest version of 
>SharpReader,RSSBandit,Headline-Reader(ja),HepCat(ja)... and so on.
>Oh, and Bloglines too.
>
> >Umm, what failed to point to the right address?  I just tested that feed in
> >BottomFeeder, and I didn't see any obvious problems
> >
>
> >> >If you look closely, you will see that I use relative URI's in my
> >> >current Atom feed: http://www.intertwingly.net/blog/index.atom
>
>
>Toru Marumoto
>      see you on the web!
>________________________________
>
>--------------------------------
>__________________________________________________
>GANBARE! NIPPON!
>Yahoo! JAPAN JOC OFFICIAL INTERNET PORTAL SITE
>http://mail.ganbare-nippon.yahoo.co.jp/

<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  Thu Jul 29 16:23:34 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06948
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 16: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 i6TKBNlZ099957;
	Thu, 29 Jul 2004 13:11:23 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6TKBNbV099956;
	Thu, 29 Jul 2004 13:11: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 i6TKBMWd099939
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 13:11: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 5EF4E7C122; Thu, 29 Jul 2004 23:06:45 +0200 (CEST)
Date: Thu, 29 Jul 2004 22:15:51 +0200
To: "Eric Scheid" <eric.scheid@ironclad.net.au>
Subject: Re: PaceDates
References: <BD2EF074.23632%eric.scheid@ironclad.net.au>
Cc: Atom-Syntax <atom-syntax@imc.org>
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: <opsbw08piyuvpchu@quark>
In-Reply-To: <BD2EF074.23632%eric.scheid@ironclad.net.au>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Thu, 29 Jul 2004 18:20:36 +1000, Eric Scheid  
<eric.scheid@ironclad.net.au> wrote:

> insert ", including addition, changes, or deletions of child elements of  
> the entry, including namespaced extensions."

I changed it into this:

   The "atom:modified" element is a Date Construct that indicates the time
   that the entry was last modified. "Modification" of an entry includes
   addition, changes, or deletions of child elements of the entry, both
   in and outside of the Atom namespace.

>> The content of an atom:modified element MUST according to RFC 3339 have  
>> a time zone whose value SHOULD be "+00:00" or "Z".
>
> why does RFC 3339 say the timezone should be UTC?

Because UTC dates are a lot more manageable than local ones.

> why not "-00:00"?

That is UTC. The only difference is that the local timezone is unknown. If  
you think the specification text could make this clearer, please feel free  
to suggest what such language might look like.

>> If an atom:entry is re-issued at several different locations,
>> atom:modified MAY be altered to indicate this change in the entry's  
>> state.
>
> huh? So if an entry is posted at msdn.blogs.com, and then some moments  
> later also appears at blogs.msdn.com, it might have a different
> atom:modified? Why?

Not sure why and how that sentence got there, so I removed it.

>> An atom:modified date does only give a slight indication of  
>> modification. If atom:modified has not changed, it is safe to assume
>> that the entry itself has not changed either. However, a change in
>> atom:modified does  not necessarily imply a change in the entry
>> itself.
>
> Where did this come from?

This paragraph is provided by Ken, and he explains it like this:

'modified' can change for pretty much any darn reason local to the system,  
and may not involve any real change to the item. Specifically, that time  
changes whenever the user hits «save» on the item, even if they made no  
changes at all.

It changes if the item is copied from one filesystem to another, without  
remembering to preserve the modification times, or when exported from one  
database and imported into another, if the modified-time is system  
generated.

Does that make sense? Could we put it in any other language to make that  
more easilly understandable?

> btw, is atom:entry/id a MUST?

Yes. At least in the current specification, and all paces on atom:id I've  
read. I don't think anyone wants atom:entr/atom:id optional.

> no mention as to whether this is mutable

If everyone could agree that 'issued' means 'first-issued' just as  
'created' means 'first-created' (I have the view that you can only create  
and issue something once), we can say that 'issued' is immutable, and drop  
'first-issued'. But I don't think people can agree to that.

We should probably, in any case, say whether 'issued' is mutable or not.

> conflict of precedence here ... if no other date constructs are available
> then the entry MUST have first-issued ... and MUST have atom:issued too  
> (see above), and MUST have atom:modified too (see above).

Yes. Luckily, you understand what I'm trying to say:

> I know what you're trying to say: atom:entry MUST contain at least one of
> atom:modified, atom:issued, [...].

Correct.

> I suggest you gather all the date constructs under point 4.13.6, and then
> numbered sub-points for each date element (ie. 4.13.6.1 for modified,
> 4.13.6.2 for issued, etc).

Good idea. Done. Would it be a good idea to group the dates in a <dates>  
element, btw?

>> atom:entry elements SHOULD contain an atom:created element, but MUST NOT
>> contain more than one. If no other Date Construct is available for the
>> atom:entry, atom:created MUST be present.
>
> SHOULD is too strong.

Hm. Okay. Changed to MAY.

>> === 4.13.10 "atom:date" Element ===
>
> I assume you've renamed 'dateline' to 'date', so +1

Yes. As Laurent Le Meur wrote[1], «dateline» isn't really a good term for  
what's really a «display date» or «custom date».

> why the deprecation of 'date'?

Because it's a wildcard date. No one knows what the publisher's mean with  
it, so we should encourage them to move over to the more tightly specified  
dates 'issued', 'created' or 'modified'. They may provide atom:date for as  
long as they want, but I think that the use of such ambiguous elements  
should be discouraged.

>> The content of an atom:date element MUST according to RFC 3339 have a  
>> time zone whose value SHOULD be "+00:00" or "Z". The time zone MAY,
>> however,  be "-00:00" when the time is known to be correct UTC, but the
>> time zone is unknown, or be '+hh:mm' when the time zone is known.
>
> conflict of MUST and MAY here.

It may look like it, but "-00:00" is also a timezone. Not sure how I can  
express this with better language. Please feel free to make suggestions.

> what happened to atom:updated?

Who wants it, really? I know that Dare have written several times that he  
has never seen or heard a use case for it, but if the consensus is that  
this date should be available, then okay. I think that major changes  
should be signified with another mechanism than a date, though.

____
[1] <url: http://www.imc.org/atom-syntax/mail-archive/msg07955.html>

-- 
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 Jul 29 16:38: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 QAA07787
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 16: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 i6TKGtBm001041;
	Thu, 29 Jul 2004 13:16: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 i6TKGt3A001040;
	Thu, 29 Jul 2004 13:16: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 i6TKGquk001032
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 13:16: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 1BqHKf-0001P6-RB; Thu, 29 Jul 2004 20:16:54 +0000
Message-ID: <41095B35.8040406@franklinmint.fm>
Date: Thu, 29 Jul 2004 16:16:53 -0400
From: Robert Sayre <mint@franklinmint.fm>
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
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: PaceResource -1, PaceSimpleResourcePosting +1
References: <8DCDED78-E198-11D8-B732-000A95A51C9E@sun.com>
In-Reply-To: <8DCDED78-E198-11D8-B732-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:

> 
> Having said that, PaceSimpleResourcePosting contains a bunch of stray 
> language about PUT and Delete and WebDAV and so on that really falls 
> under other issues.

> 2. approve the direct-POST mechanism in PaceSimpleResourcePosting and 
> ask the protocol-draft editors to find a smooth way to work it into that 
> document.

+1, as long as the group is comfortable with lots of editing. If so, 
I'll summarize any discrepancies in an email to the list.

Robert Sayre



From owner-atom-syntax@mail.imc.org  Thu Jul 29 16: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 QAA08398
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 16: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 i6TKcU25005454;
	Thu, 29 Jul 2004 13:38: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 i6TKcUsa005453;
	Thu, 29 Jul 2004 13:38: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 i6TKcTIY005446
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 13:38:29 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id 76so34257rnk
        for <atom-syntax@imc.org>; Thu, 29 Jul 2004 13:38:33 -0700 (PDT)
Received: by 10.38.88.29 with SMTP id l29mr1009rnb;
        Thu, 29 Jul 2004 13:38:33 -0700 (PDT)
Message-ID: <14be96d30407291338435fdef6@mail.gmail.com>
Date: Thu, 29 Jul 2004 16:38:33 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Tim Bray <tim.bray@sun.com>
Subject: Re: PaceFeedEquivalence
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <ED9ED1C6-E194-11D8-B732-000A95A51C9E@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <ED9ED1C6-E194-11D8-B732-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 Thu, 29 Jul 2004 12:24:36 -0700, Tim Bray <tim.bray@sun.com> wrote:
> 
> While the objective is fine, I don't believe we need a separate section
> on Feed Equivalence.  I propose:
> 
> (1) a note in both the Format and Protocol specs saying "when testing
> URIs for equivalence, implementors should consider the discussion in
> RFC2396bis section 6."  (currently
> http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#comparison).

Note that this is the first time we are actively tying ourselves to
2396bis (as opposed to PaceUriOrItsSuccessor, which only allowed us to
inherit it when it was ready).

Furthermore, are you rejecting Norman Walsh's proposal that "matches"
and "matching" be more specifically defined as per Section 6.2.1
"Simple String Comparison" of 2396bis?

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Thu Jul 29 16:51:42 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08507
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 16:51:41 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TKdPUc005740;
	Thu, 29 Jul 2004 13:39: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 i6TKdPI8005739;
	Thu, 29 Jul 2004 13:39: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 i6TKdNQI005721
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 13:39:24 -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 13AB87C0F3; Thu, 29 Jul 2004 23:34:47 +0200 (CEST)
Date: Thu, 29 Jul 2004 22:43:59 +0200
To: "Tim Bray" <Tim.Bray@sun.com>
Subject: Re: PaceAutoDisco - separate draft?
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <49FAF6B9-E196-11D8-B732-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: <opsbw2jltduvpchu@quark>
In-Reply-To: <49FAF6B9-E196-11D8-B732-000A95A51C9E@sun.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Thu, 29 Jul 2004 12:34:20 -0700, Tim Bray <Tim.Bray@Sun.COM> wrote:

> 3. Do we try to roll Mark's material into one of our existing drafts, or  
> do we adopt it as a separate committee draft? [Separate draft, it's too  
> long to roll in].

The biggest problem with the draft isn't imho that it's too long, but that  
it doesn't fit naturally anywhere in the current format or protocol  
specifications. This was brought to my attention by Arve Bersvendsen, and  
I agree with him in that Atom would be served by having yet another  
specification directed towards «Introspection and Discovery-services».

Mark's autodiscovery document would fit nicely into such a specification,  
and it would be extendible when other related mechanisms needs to be  
specified somewhere. Squeezing everything into the format or protocol  
specification isn't the best solution, I think.

> 3. Do we need to point to the autodiscovery draft from either/both of  
> the protocol and format drafts?  [Yes and No, i.e. yes from the  
> protocol, no from the format].

I would hope that both the format and protocol specifications could point  
to the «Introspection and Discovery-services» specification, and vice  
versa. They are all tightly related.

-- 
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 Jul 29 16: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 QAA08546
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 16: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 i6TKhfXE006450;
	Thu, 29 Jul 2004 13:43: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 i6TKhfuH006444;
	Thu, 29 Jul 2004 13:43:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.202])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TKheHJ006424
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 13:43:40 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id 74so40798rnk
        for <atom-syntax@imc.org>; Thu, 29 Jul 2004 13:43:39 -0700 (PDT)
Received: by 10.38.162.60 with SMTP id k60mr87418rne;
        Thu, 29 Jul 2004 13:43:39 -0700 (PDT)
Message-ID: <14be96d304072913431f16d0df@mail.gmail.com>
Date: Thu, 29 Jul 2004 16:43:39 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Tim Bray <tim.bray@sun.com>
Subject: Re: PaceAutoDisco - separate draft?
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <49FAF6B9-E196-11D8-B732-000A95A51C9E@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <49FAF6B9-E196-11D8-B732-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 Thu, 29 Jul 2004 12:34:20 -0700, Tim Bray <tim.bray@sun.com> wrote:
> 
> For those who haven't seen MarkP's write-up at
> http://diveintomark.org/rfc/draft-pilgrim-atom-autodiscovery-02.html,
> go have a look; I'd forgotten how long it is, but it doesn't seem
> padded.  Paul tells me that there's no process barrier to us adopting
> it as a WG draft.  So here are the questions; I think a few of them
> have easy-to-reach consensus positions, which I've proposed in square
> brackets:
> 
> 1. Do we as a WG do anything about feed discovery? [Yes]
> 
> 2. Do we basically agree with the content of Mark's draft? [Yes]
> 
> 3. Do we try to roll Mark's material into one of our existing drafts,
> or do we adopt it as a separate committee draft? [Separate draft, it's
> too long to roll in].
> 
> (Er Mark, you OK with being editor?)

Yes.  Or I'm willing to have it rolled into the format spec with me as
co-editor.

I have also published a corresponding conformance test suite [1],
which I believe is still fully functional despite a recent server
upheaval.  What does the IETF do with such things?  Anything?

[1] http://diveintomark.org/tests/client/autodiscovery/

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Thu Jul 29 16:51: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 QAA08579
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 16: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 i6TKcq04005637;
	Thu, 29 Jul 2004 13:38: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 i6TKcqqd005636;
	Thu, 29 Jul 2004 13:38:52 -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 i6TKcpvi005615
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 13:38:51 -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 i6TKco53030752
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 15:38:50 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6TKcnaO030748;
	Thu, 29 Jul 2004 15:38:49 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceResource -1, PaceSimpleResourcePosting +1
References: <8DCDED78-E198-11D8-B732-000A95A51C9E@sun.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 29 Jul 2004 15:38:49 -0500
In-Reply-To: <8DCDED78-E198-11D8-B732-000A95A51C9E@sun.com>
Message-ID: <m37jsm35wm.fsf@bitsko.slc.ut.us>
Lines: 27
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: <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> writes:

> [...] PaceSimpleResourcePosting contains a bunch of stray language
> about PUT and Delete [...] and so on that really falls under other
> issues.

> My preferred outcome on this would be to
> [...]
> 2. approve the direct-POST mechanism in PaceSimpleResourcePosting
> and ask the protocol-draft editors to find a smooth way to work it
> into that document.

+1 to PaceSimpleResourcePosting as-is, -1 to removing PUT/DELETE from
it.

PUT and DELETE allow a posted resource to be updated or deleted later
using the Atom editing client.  Supporting only POST means the editing
client must create new resources every time a diagram, audio clip, or
other entry-referenced resource is changed.

  -- Ken

PS. John and I were working on merging PaceNonEntryResources and
PaceSimpleResourcePosting.  The only remaining item was the ability
for the client to manage "static" resources in specified locations,
like templates and stylesheets, as available in existing APIs like the
BloggerAPI.  I can hold on to that and put it in a new Pace.



From owner-atom-syntax@mail.imc.org  Thu Jul 29 16: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 QAA08670
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 16: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 i6TKi6JI006517;
	Thu, 29 Jul 2004 13: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 i6TKi6Zt006516;
	Thu, 29 Jul 2004 13:44:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from vspmail.nscp.aoltw.net (h-64-236-139-249.aoltw.net [64.236.139.249])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TKi6Ue006500
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 13:44:06 -0700 (PDT)
	(envelope-from jpanzer@AOL.NET)
Received: from h-10-169-146-121.nscp.aoltw.net (h-10-169-146-121.nscp.aoltw.net [10.169.146.121])
	by vspmail.nscp.aoltw.net (8.11.6/8.11.6) with ESMTP id i6TKmws23053;
	Thu, 29 Jul 2004 13:49:02 -0700
Date: Thu, 29 Jul 2004 13:43:34 -0700
From: "John Panzer" <jpanzer@AOL.NET>
Subject: Re: PaceResource -1, PaceSimpleResourcePosting +1
To: mint@franklinmint.fm
cc: "Tim Bray" <Tim.Bray@Sun.COM>, "Atom Syntax" <atom-syntax@imc.org>
In-Reply-To: <41095B35.8040406@franklinmint.fm>
Message-ID: <41096176.20101@AOL.NET>
References: <8DCDED78-E198-11D8-B732-000A95A51C9E@sun.com> <41095B35.8040406@franklinmint.fm>
X-Mailer: AOL Communicator (20030919.3 Win)
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 wrote on 7/29/2004, 1:16 PM:

 >
 > Tim Bray wrote:
 >
 > >
 > > Having said that, PaceSimpleResourcePosting contains a bunch of stray
 > > language about PUT and Delete and WebDAV and so on that really falls
 > > under other issues.
 >
 > > 2. approve the direct-POST mechanism in PaceSimpleResourcePosting and
 > > ask the protocol-draft editors to find a smooth way to work it into
 > that
 > > document.
 >
 > +1, as long as the group is comfortable with lots of editing. If so,
 > I'll summarize any discrepancies in an email to the list.
 >
 > Robert Sayre
 >

+1.  I added the PUT/DELETE language to try to synchronize with other 
proposals.  If the consensus is to separate the issues, that's great.

-John




From owner-atom-syntax@mail.imc.org  Thu Jul 29 16:54: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 QAA08711
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 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 i6TKgMs5006230;
	Thu, 29 Jul 2004 13:42: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 i6TKgM1F006229;
	Thu, 29 Jul 2004 13:42: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 i6TKgL2R006212
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 13:42: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 77DAD7C0F3; Thu, 29 Jul 2004 23:37:44 +0200 (CEST)
Date: Thu, 29 Jul 2004 22:46:56 +0200
To: "Tim Bray" <Tim.Bray@sun.com>
Subject: Re: PaceLinkReflection - Close it
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <91CEA9B5-E197-11D8-B732-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: <opsbw2oir2uvpchu@quark>
In-Reply-To: <91CEA9B5-E197-11D8-B732-000A95A51C9E@sun.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Thu, 29 Jul 2004 12:43:30 -0700, Tim Bray <Tim.Bray@Sun.COM> wrote:

> If there is an <atom:link rel="alternate"> element inside a feed's  
> <atom:head>, and the the <atom:link>'s href= points to an HTML page,  
> then the HTML page SHOULD have a autodiscovery link element that  
> reflects back to the Atom feed.

This wording makes more sense, yes.

> I don't agree at all.  I think it's quite possible to publish a feed  
> describing changes to someone else's web site, without asking them, and  
> I don't think this can possibly impose any obligation on the web site to  
> point to the feed.

But SHOULD just says SHOULD. There's still a step up to MUST, and I think  
it's useful to encourage implementors to provide two-way references  
between all representations. I don't think it's a great loss if this pace  
is closed, though, but it would be a nice addition.

-- 
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 Jul 29 16:54: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 QAA08747
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 16:54: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 i6TKjcHl006828;
	Thu, 29 Jul 2004 13:45: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 i6TKjcgE006826;
	Thu, 29 Jul 2004 13:45: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 i6TKjcS5006803
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 13:45:38 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040729204537.97375.qmail@web41202.mail.yahoo.com>
Received: from [131.107.3.84] by web41202.mail.yahoo.com via HTTP; Thu, 29 Jul 2004 13:45:37 PDT
Date: Thu, 29 Jul 2004 13:45:37 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: PaceBasicAtomID - maybe we're done
To: Ken MacLeod <ken@bitsko.slc.ut.us>, Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <m3smbb39sa.fsf@bitsko.slc.ut.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>



--- Ken MacLeod <ken@bitsko.slc.ut.us> wrote:
>
> > > IMHO, this does not fully solve the original
> problem that Dare was
> > > trying to express... I see this as primarily
> because the
> > > discussion wandered off into permathread land
> and what Dare was
> > > trying to express was lost.
> > 
> > OK... although the language in the Pace about dupe
> detection is
> > pretty well straight from Dare.  So concretely,
> you're suggesting
> > that we beef up the draft with some language
> explaining the use-case
> > of the same entry in multiple different feeds.
> 
> I think the messages that Sam points to are ones
> where Dare is
> discussing the symptoms of IDs changing (which isn't
> inherent to the
> scheme used), where the Pace refers to a message
> from Dare that
> addresses the root cause: that publishers don't do
> anything to prevent
> the IDs from changing, regardless of scheme used.
> 
> Adding language explaining the "multiple places"
> use-case is good.
> 
> Here's the test cases I suggested, which includes
> the "multiple
> places" assertion that can be added to the spec
> text:
> 
>    
>
http://imc.org/atom-syntax/mail-archive/msg07923.html

+1 

I'd like to see something akin to Ken's tests in the
Atom specification although written in a more scenario
oriented and user friendly manner. 

Besides that I think the language in Tim's draft is
fine. 

=====
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 Jul 29 16:59: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 QAA09020
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 16:59: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 i6TKlFSr007091;
	Thu, 29 Jul 2004 13:47: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 i6TKlF0P007090;
	Thu, 29 Jul 2004 13:47: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.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TKlDm1007084
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 13:47:14 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id 76so34702rnk
        for <atom-syntax@imc.org>; Thu, 29 Jul 2004 13:47:18 -0700 (PDT)
Received: by 10.38.88.29 with SMTP id l29mr2183rnb;
        Thu, 29 Jul 2004 13:47:18 -0700 (PDT)
Message-ID: <14be96d304072913474dccacec@mail.gmail.com>
Date: Thu, 29 Jul 2004 16:47:18 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Toru Marumoto <torumyax@yahoo.co.jp>
Subject: Re: Relative URI references
Cc: atom-syntax@imc.org
In-Reply-To: <C9C4759E24A941torumyax@yahoo.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <6.1.2.0.2.20040729125130.043eaec0@www.gosmalltalk.com> <C9C4759E24A941torumyax@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


My Universal Feed Parser [1] supports relative URIs correctly.  That
plus BottomFeeder gives us two independent implementations, which
counts as rough consensus and running code.  We have test cases [2] so
the non-compliant applications can catch up.

[1] http://feedparser.org/
[2] http://diveintomark.org/tests/client/base/

-Mark

On Fri, 30 Jul 2004 03:59:15 +0900, Toru Marumoto <torumyax@yahoo.co.jp> wrote:
> 
> 
> I've tested in the latest version of SharpReader,RSSBandit,Headline-Reader(ja),HepCat(ja)... and so on.
> Oh, and Bloglines too.
> 
> 
> 
> >Umm, what failed to point to the right address?  I just tested that feed in
> >BottomFeeder, and I didn't see any obvious problems
> >
> 
> >> >If you look closely, you will see that I use relative URI's in my
> >> >current Atom feed: http://www.intertwingly.net/blog/index.atom
> 
> Toru Marumoto
>      see you on the web!
> ________________________________
> 
> --------------------------------
> __________________________________________________
> GANBARE! NIPPON!
> Yahoo! JAPAN JOC OFFICIAL INTERNET PORTAL SITE
> http://mail.ganbare-nippon.yahoo.co.jp/
> 
> 


-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Thu Jul 29 17:06: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 RAA09436
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 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 i6TKqT4m007924;
	Thu, 29 Jul 2004 13: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 i6TKqTDh007923;
	Thu, 29 Jul 2004 13:52:29 -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 i6TKqSgn007917
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 13:52:29 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net (ip195.198.145.31.iinet.com [198.145.31.195])
	(authenticated bits=0)
	by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i6TKrf5h021011;
	Thu, 29 Jul 2004 16:53:42 -0400
Message-ID: <4109638F.8010002@intertwingly.net>
Date: Thu, 29 Jul 2004 16:52:31 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <Tim.Bray@Sun.COM>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceResource -1, PaceSimpleResourcePosting +1
References: <8DCDED78-E198-11D8-B732-000A95A51C9E@sun.com>
In-Reply-To: <8DCDED78-E198-11D8-B732-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:
> 
> There's another issue down the road: if we do a SOAP interface, there's 
> going to have to be something in it to distinguish between posting an 
> entry and posting something that's not an entry.

If SOAP 1.1, then content type will be text/xml (preferably with a 
charset specified), and SOAPAction should be set.

If SOAP 1.2, then content type will be application/soap+xml and 
SOAPAction should be set.

If PaceAtomActionHeader, then Atom-Action should be set.

  = = =

But as you say, this is down the road.  Do we need a fallback?  Should 
we cater to the least common denominator?  Is WSDL 1.1 of value today? 
These issues will eventually need to be pried apart and looked at.  But 
preferably not today.

My intent for posting the above is *not* to reopen those threads at this 
point but merely to indicate that supporting POST of binary objects 
without a wrapper is not inconsistent with future support for any of the 
above - with one possible exception: posting atom entries (literally) as 
text/xml using soap 1.1 over a gateway that drops custom headers. 
Perhaps this can be handled, perhaps this combination is not required, 
at any case, I don't think that any of the above should be a reason not 
to support direct posting of simple resources.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Thu Jul 29 17:06: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 RAA09457
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 17:06: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 i6TKtZfR008501;
	Thu, 29 Jul 2004 13: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 i6TKtZpe008500;
	Thu, 29 Jul 2004 13:55:35 -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 i6TKtXGC008482
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 13:55:34 -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 i6TKtX53030943
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 15:55:33 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6TKtWup030939;
	Thu, 29 Jul 2004 15:55:32 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceResource -1, PaceSimpleResourcePosting +1
References: <8DCDED78-E198-11D8-B732-000A95A51C9E@sun.com>
	<m37jsm35wm.fsf@bitsko.slc.ut.us>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 29 Jul 2004 15:55:32 -0500
In-Reply-To: <m37jsm35wm.fsf@bitsko.slc.ut.us>
Message-ID: <m33c3a354r.fsf@bitsko.slc.ut.us>
Lines: 27
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


Ken MacLeod <ken@bitsko.slc.ut.us> writes:

> PS. John and I were working on merging PaceNonEntryResources and
> PaceSimpleResourcePosting.  The only remaining item was the ability
> for the client to manage "static" resources in specified locations,
> like templates and stylesheets, as available in existing APIs like
> the BloggerAPI.  I can hold on to that and put it in a new Pace.

Ignore this part.  John and I had already decided to separate the
issue on our way to merging the Paces.

The only remaining portions to be merged were wording and
clarifications.

For example, PaceSimpleResourcePosting doesn't "name" the URI that is
returned from posting the resource.  It's 99% equivalent to the
EditURI returned from posting an atom:entry, except that it's not an
atom:entry resource at the URI.

I suggest the editors also look at PaceNonEntryResources and use their
judgement as to what would help in incorporating
PaceSimpleResourcePosting.

I can then withdraw PaceNonEntryResources or the chairs can call it
closed.

  -- Ken



From owner-atom-syntax@mail.imc.org  Thu Jul 29 17:08: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 RAA09592
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 17:08: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 i6TKu1tW008576;
	Thu, 29 Jul 2004 13:56: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 i6TKu1ZI008575;
	Thu, 29 Jul 2004 13:56: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 i6TKu0in008564
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 13:56:00 -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 i6TKrl53013900
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 14:53:47 -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 <0I1M006VUSTGHS@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Thu, 29 Jul 2004 14:56:05 -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 <0I1M00CV1STCE1@mail.sun.net> for atom-syntax@imc.org; Thu,
 29 Jul 2004 14:56:00 -0600 (MDT)
Date: Thu, 29 Jul 2004 13:56:17 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceFeedEquivalence
In-reply-to: <14be96d30407291338435fdef6@mail.gmail.com>
To: Mark Pilgrim <pilgrim@gmail.com>
Cc: Atom Syntax <atom-syntax@imc.org>
Message-id: <BC5132DE-E1A1-11D8-B732-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: <ED9ED1C6-E194-11D8-B732-000A95A51C9E@sun.com>
 <14be96d30407291338435fdef6@mail.gmail.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 Jul 29, 2004, at 1:38 PM, Mark Pilgrim wrote:

>> (1) a note in both the Format and Protocol specs saying "when testing
>> URIs for equivalence, implementors should consider the discussion in
>> RFC2396bis section 6."  (currently
>> http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#comparison).
>
> Note that this is the first time we are actively tying ourselves to
> 2396bis (as opposed to PaceUriOrItsSuccessor, which only allowed us to
> inherit it when it was ready).

Good point... it's just that 2396bis has this useful section 6 that 
goes on and on about exactly this issue, which isn't in 2396classic at 
all.  On the other hand if we were nearly done, and 2396bis wasn't, I'd 
be in favor of nuking this section to get us across the finish line.

> Furthermore, are you rejecting Norman Walsh's proposal that "matches"
> and "matching" be more specifically defined as per Section 6.2.1
> "Simple String Comparison" of 2396bis?

Yes.  If I have two pointers to feeds:

http://www.example.com:80/feed.atom
http://www.Example.COM/feed.atom

I guarantee that some apps, in particular web spiders, are going to get 
very aggressive about schema-specific normalization and regard these as 
equivalent, and I don't see any reason to rule this out.  Norm?  -Tim



From owner-atom-syntax@mail.imc.org  Thu Jul 29 17:18: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 RAA10081
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 17:18: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 i6TL7n5M010534;
	Thu, 29 Jul 2004 14:07: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 i6TL7nBY010533;
	Thu, 29 Jul 2004 14:07: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 i6TL7mbn010515
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 14:07: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 (sccrmhc13) with SMTP
          id <2004072921074701600i4bspe>; Thu, 29 Jul 2004 21:07:47 +0000
Date: Thu, 29 Jul 2004 15:07:47 -0600
Subject: Re: PaceDates
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: <opsbw08piyuvpchu@quark>
Message-Id: <57BCFB8C-E1A3-11D8-9043-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 i6TL7nbn010528
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 Thursday, July 29, 2004, at 02:15  PM, Asbjørn Ulsberg wrote:
> On Thu, 29 Jul 2004 18:20:36 +1000, Eric Scheid 
> <eric.scheid@ironclad.net.au> wrote:
>> I suggest you gather all the date constructs under point 4.13.6, and 
>> then
>> numbered sub-points for each date element (ie. 4.13.6.1 for modified,
>> 4.13.6.2 for issued, etc).
> Good idea. Done. Would it be a good idea to group the dates in a 
> <dates> element, btw?

I don't see any value in grouping under a <date> element.  Anyone else? 
  If there's no value in it, then let's be less verbose.  I DO like the 
idea of grouping the date elements within the spec--I think it improves 
spec readability.

>> why the deprecation of 'date'?
>
> Because it's a wildcard date. No one knows what the publisher's mean 
> with it, so we should encourage them to move over to the more tightly 
> specified dates 'issued', 'created' or 'modified'. They may provide 
> atom:date for as long as they want, but I think that the use of such 
> ambiguous elements should be discouraged.

-1.  The subjective date is not only for legacy support--it also 
enables the author to indicate a date related to the CONTENT or MEANING 
of the entry, as opposed to timestamping the events that occurred in 
the process of PUBLISHING the entry.

>>> The content of an atom:date element MUST according to RFC 3339 have 
>>> a time zone whose value SHOULD be "+00:00" or "Z". The time zone >>> MAY,
>>> however,  be "-00:00" when the time is known to be correct UTC, but 
>>> the
>>> time zone is unknown, or be '+hh:mm' when the time zone is known.

My impression was that it is MORE accurate to use "-00:00" than 
"+00:00" or "Z" when normalizing from some other timezone to UTC.  
Doesn't "+00:00" or "Z" imply that UTC IS the "origin" timezone?  When 
it is said that "-00:00" means that the origin timezone is unknown, I 
think that means that either the clock of the computer that generated 
the timestamp is set to UTC, thought it may not be located in that 
timezone, or that the timestamp has been normalized to UTC, thus 
discarding the originally known timezone information.  I can't imagine 
that it means "I looked at the clock with the local time and computed 
the UTC time, but I have no clue what timezone I'm in."  If your clock 
reads local time and you can compute UTC, you DO know what timezone 
you're in.

I don't think it's terribly important whether "+00:00", "-00:00" or "Z" 
is used, but if we ARE going to encourage one or two over the other(s), 
then let's be sure we're doing the most correct thing.




From owner-atom-syntax@mail.imc.org  Thu Jul 29 17: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 RAA10124
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 17: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 i6TL869Q010599;
	Thu, 29 Jul 2004 14:08:06 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6TL86Lh010598;
	Thu, 29 Jul 2004 14:08: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 i6TL85Ja010581
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 14:08:05 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net (ip195.198.145.31.iinet.com [198.145.31.195])
	(authenticated bits=0)
	by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i6TL9DhH021695;
	Thu, 29 Jul 2004 17:09:18 -0400
Message-ID: <41096733.3040309@intertwingly.net>
Date: Thu, 29 Jul 2004 17:08:03 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: James Robertson <jarober@gosmalltalk.com>
CC: atom-syntax@imc.org
Subject: Re: Relative URI references
References: <6.1.2.0.2.20040729125130.043eaec0@www.gosmalltalk.com> <C9C4759E24A941torumyax@yahoo.co.jp> <6.1.2.0.2.20040729160356.04398ec0@www.gosmalltalk.com>
In-Reply-To: <6.1.2.0.2.20040729160356.04398ec0@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: <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


James Robertson wrote:
> 
> ok, but what's the problem?  I'm seeing content, and the links look ok....

The links (note: I said links, not ids) don't look OK in bloglines:

http://www.bloglines.com/preview?siteid=123923

> At 02:59 PM 7/29/2004, you wrote:
> 
>> I've tested in the latest version of 
>> SharpReader,RSSBandit,Headline-Reader(ja),HepCat(ja)... and so on.
>> Oh, and Bloglines too.
>>
>> >Umm, what failed to point to the right address?  I just tested that 
>> feed in
>> >BottomFeeder, and I didn't see any obvious problems
>>
>> >> >If you look closely, you will see that I use relative URI's in my
>> >> >current Atom feed: http://www.intertwingly.net/blog/index.atom
>>
>> Toru Marumoto
>>      see you on the web!

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Thu Jul 29 17:20: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 RAA10157
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 17:20: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 i6TLA41C010940;
	Thu, 29 Jul 2004 14:10: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 i6TLA4HX010939;
	Thu, 29 Jul 2004 14:10:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mta02-svc.ntlworld.com (mta02-svc.ntlworld.com [62.253.162.42])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TLA2K6010901
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 14:10:03 -0700 (PDT)
	(envelope-from djpowell@djpowell.net)
Received: from cpc1-stke1-5-0-cust6.bagu.cable.ntl.com ([81.97.134.6])
          by mta02-svc.ntlworld.com
          (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP
          id <20040729210833.DWZS10435.mta02-svc.ntlworld.com@cpc1-stke1-5-0-cust6.bagu.cable.ntl.com>;
          Thu, 29 Jul 2004 22:08:33 +0100
Date: Thu, 29 Jul 2004 22:10:02 +0100
From: David Powell <djpowell@djpowell.net>
X-Mailer: The Bat! (v2.12 RC/4) Business
Reply-To: David Powell <djpowell@djpowell.net>
X-Priority: 3 (Normal)
Message-ID: <1364877593.20040729221002@djpowell.net>
To: =?ISO-8859-1?B?QXNiavhybiBVbHNiZXJn?= <asbjorn@tigerstaden.no>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceDates
In-Reply-To: <opsbv2pfapuvpchu@quark>
References: <opsbv2pfapuvpchu@quark>
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


[Sorry if you get this twice. I sent it a few hours ago but it seems
to have gone missing]

This looks like a very good compromise. I agree with everything but
I have a few minor issues with a few of the SHOULDs and SHOULD NOTs
related to atom:date...

> A Date Construct is an element whose child content is an RFC 3339
> Date-Time string [RFC 3339] which SHOULD be less than or equal to
> the variable "now". That means that a Date Construct SHOULD NOT
> contain a date in the future.

I realize that this is only a SHOULD, but I think that there are
sensible reasons for allowing atom:date to be in the future. How about
a feed of upcoming events, or weather forecasts (such as these
concrete examples [1])? I don't think that this recommendation
improves interoperability, so I don't think that we need to recommend
it.


> The "atom:date" element is a Date Construct, giving the date
> associated with the entry. Typically, atom:date will be associated
> with the creation or availability of the resource, but its semantics
> is largely up to the tools to define. atom:date exists for
> compatibility reasons and therefore SHOULD NOT be used.

This is not how I see atom:date at all. I see it as a piece of
metadata that a publisher wants to associate with the content of the
entry, rather than a date associated with the publishing process like
the other dates are. I see it as a useful field that is present for
more reasons that backwards compatibility.

-1 to the SHOULD NOT.

Also I don't like the use of the word "tools" in that paragraph, I'd
prefer "publisher". This is a field that allows the user to associate
a date with an entry if they want to. I don't think that tools should
generate it, other than perhaps to propose Now() as a default.

> The content of an atom:date element MUST according to RFC 3339 have
> a time zone whose value SHOULD be "+00:00" or "Z".

I disagree with the SHOULD. In fact I think that this date is more
useful if it includes the timezone of the publisher, but I'd prefer it
if we stayed silent and not recommend either option. It is up to the
publisher.


> atom:date MAY change to order the entries in an Atom feed or on a
> front page of a website correctly.

This implies that atom:date should be used to indicate the sort order,
but I'd rather we didn't say anything about that - it is up to the
User-Agent to decide on a sort order. So, I'd rather just drop that
sentence.

I'd prefer the atom:date section to look something more like this:


  The "atom:date" element is a Date Construct, giving the date
  associated with the entry. Typically, atom:date will be associated
  with the creation or availability of the resource, but its semantics
  is largely up to the publisher to define. atom:entry elements MAY
  contain an atom:date element, but MUST NOT contain more than one. If
  no other Date Construct is available for the atom:entry, atom:date
  MUST be present.
  
  The content of an atom:date element MUST according to RFC 3339 have
  a time zone. The time zone may be "+00:00" or "Z" to represent UTC;
  a local offset when the time zone is known; or "-00:00" when the
  time is known to be correct UTC, but the time zone is unknown.
  
  atom:date MAY change to convey the date the author wants associated
  with the entry.


It would be good to get Tim's travel journal example in the document
somewhere because that explains it pretty well.


[1]  http://www.anti-mega.com/weather/

-- 
Dave




From owner-atom-syntax@mail.imc.org  Thu Jul 29 17:25:51 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10376
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 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 i6TL5YnU010195;
	Thu, 29 Jul 2004 14:05: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 i6TL5YnR010194;
	Thu, 29 Jul 2004 14:05:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.204])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TL5X7e010187
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 14:05:33 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id 73so30440rnl
        for <atom-syntax@imc.org>; Thu, 29 Jul 2004 14:05:37 -0700 (PDT)
Received: by 10.38.162.30 with SMTP id k30mr23093rne;
        Thu, 29 Jul 2004 14:05:37 -0700 (PDT)
Message-ID: <14be96d3040729140553887d37@mail.gmail.com>
Date: Thu, 29 Jul 2004 17:05:37 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Tim Bray <tim.bray@sun.com>
Subject: URI equivalence (was Re: PaceFeedEquivalence)
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <ED9ED1C6-E194-11D8-B732-000A95A51C9E@sun.com>
 <14be96d30407291338435fdef6@mail.gmail.com> <BC5132DE-E1A1-11D8-B732-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 Thu, 29 Jul 2004 13:56:17 -0700, Tim Bray <tim.bray@sun.com> wrote:
> http://www.example.com:80/feed.atom
> http://www.Example.COM/feed.atom

This has been discussed on-list before [1], but no language has made
it into a spec draft.

By a startling coincidence, less than 8 hours ago I opened an issue
tracker [2] on this exact issue for the feed validator.  My current
test cases are based on the examples in section 3.2.3 of RFC 2616 [3].
 Obviously I would be willing to amend the test cases to correspond
with whatever "URI equivalence" rules we state in the Atom spec.

[1] http://www.imc.org/atom-syntax/mail-archive/msg07662.html
[2] http://sourceforge.net/tracker/index.php?func=detail&aid=1000249&group_id=99943&atid=626803
[3] http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.3

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Thu Jul 29 17: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 RAA10441
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 17:26: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 i6TLARah011022;
	Thu, 29 Jul 2004 14:10: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 i6TLARcV011020;
	Thu, 29 Jul 2004 14:10: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 i6TLAQJX010997
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 14:10: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 F03017C130; Fri, 30 Jul 2004 00:05:49 +0200 (CEST)
Date: Thu, 29 Jul 2004 23:15:07 +0200
To: "David Powell" <dipowell@djpowell.net>
Subject: Re: PaceDates
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <20040729182950.TQJJ29220.mta03-svc.ntlworld.com@Inbox>
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: <opsbw3zhqruvpchu@quark>
In-Reply-To: <20040729182950.TQJJ29220.mta03-svc.ntlworld.com@Inbox>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Thu, 29 Jul 2004 19:27:36 +0100, David Powell <dipowell@djpowell.net>  
wrote:

> I realise that this is only a SHOULD, but I think that there are  
> sensible reasons for allowing atom:date to be in the future.

I think the consensus is that it's not.

> How about a feed of upcomming events, or weather forecasts

If these are compelling use cases Atom needs to support, we should embrace  
Dublin Core's 'available'[1] date that I think should cover these use  
cases pretty well.

> I don't think that this recommendation improves interoperability

The point of the text is that you shouldn't put something out on the web  
if it's not meant to be out on the web yet. e.g. atom:issued should never  
have a future date if the entry already available to its intended  
audience. This applies for all the other dates provided as well, I think,  
but if we embrace 'available', that text might be moved or changed.

> This is not how I see atom:date at all.  I see it as a piece of metadata  
> that a publisher wants to associate with the content of the
> entry, rather than a date associated with the publishing process like  
> the other dates are.

I can almost agree with that, besides that the current tools don't  
separate subjective from objective, internal from external or  
publisher-provided from process-provided. They mix all of these terms  
together, and most of them do it in one date. That's why the element is  
called 'date', and nothing more meaningful.

> I see it as a useful field that is present for more reasons that  
> backwards
> compatibility.

atom:date exists purely to cater for the date the current publishing tools  
provide for their entries. Please see BlogToolDateSurvey[2] for details.

> -1 to the SHOULD NOT.

Why? atom:Date is a semanticless date. It means absolutely nothing.  
There's no way to know what a publisher meant with it, unless you do some  
kind of feed-origin-tool-sniffing and then apply the correct semantic on  
the element based upon what type of tool published the entry. If you want  
to do that, okay, but I think all such sort of behaviour should be  
discouraged.

Publishers should strive to use one of the more meaningful Dublin Core  
dates instead. What is the future use case for not meaning anything in  
particular with the date associated with an entry? If there are use cases  
and semantics that aren't covered by the other dates specified in that  
pace, please let me know, and we can try to find some that do, but  
atom:date is only provided for compatibility reasons.

> Also I don't like the use of the word "tools" in that paragraph, I'd  
> prefer "publisher".

I agree. Changed.

> This is a place that allows the user to associate a date with an entry
> if they want to.

Some tools do this, others don't.

> I don't think that tools should generate it, other than perhaps to
> propose Now() as a default.

Movable Type does this, and will preserve that 'Now()' forever, if the  
user doesn't change it. Therefore, this date can both be purely  
tool-provided or publisher-provided from entry to entry. There's no way to  
tell the difference.

>> The content of an atom:date element MUST according to RFC 3339 have a
>> time zone whose value SHOULD be "+00:00" or "Z".
>
> I disagree with the SHOULD.  In fact I think that this date is more  
> useful if it includes the timezone of the publisher

I agree, so I've changed it.

>> atom:date MAY change to order the entries in an Atom feed or on a
>> front page of a website correctly.
>
> This implies that atom:date should be used to indicate the sort order,  
> but I'd rather we didn't say anything about that - it is up to the  
> User-Agent to decide on a sort order.  So, I'd rather just drop that  
> sentence.

Good point. Sentence dropped.

> I'd prefer the atom:date section to look something more like this:
>
> [...]

Could you read through the pace again now, as I've done some big changes  
according to yours and Eric's suggestions?

> It would be good to get Tim's travel journal example in the document  
> somewhere because that explains it pretty well.

What does his example explain, exactly?

____
[1] <url: http://dublincore.org/documents/dcmi-terms/#available>
[2] <url: http://intertwingly.net/wiki/pie/BlogToolDateSurvey>

-- 
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 Jul 29 17:52: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 RAA11466
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 17:52: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 i6TLfnqO016395;
	Thu, 29 Jul 2004 14:41: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 i6TLfnPv016394;
	Thu, 29 Jul 2004 14:41:49 -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 i6TLfmo3016376
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 14:41:48 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040729214148.92298.qmail@web41214.mail.yahoo.com>
Received: from [131.107.3.84] by web41214.mail.yahoo.com via HTTP; Thu, 29 Jul 2004 14:41:48 PDT
Date: Thu, 29 Jul 2004 14:41:48 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Relative URI references
To: Sam Ruby <rubys@intertwingly.net>,
        Eric Scheid <eric.scheid@ironclad.net.au>
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <4108FB30.2030407@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:
>
> > I note that there are neither xml:base nor a
> http-header Location: to
> > establish what the base URI is, and since that
> same resource can be fetched
> > from both these URLs...
> > 
> >     http://intertwingly.net/blog/index.atom
> >     http://www.intertwingly.net/blog/index.atom
> > 
> > that means the <id>s in your feed can be
> different.
> 
> Good point.  At a minimum, that is worthy of an
> informative note.

This seems like an excellent reason to ban relative
URIs in atom:id elements. Or are aggregator
implementers expected to do perform scheme specific
URI comparisons when checking to see if two entries
are identical? 

=====
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  Thu Jul 29 17:58: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 RAA11614
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 17:58: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 i6TLnK2F017951;
	Thu, 29 Jul 2004 14: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 i6TLnKR1017950;
	Thu, 29 Jul 2004 14:49:20 -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 i6TLnJ2J017934
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 14:49:19 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040729214914.25165.qmail@web41211.mail.yahoo.com>
Received: from [207.46.238.143] by web41211.mail.yahoo.com via HTTP; Thu, 29 Jul 2004 14:49:14 PDT
Date: Thu, 29 Jul 2004 14:49:14 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Relative URI references
To: Toru Marumoto <torumyax@yahoo.co.jp>, atom-syntax@imc.org
In-Reply-To: <C9C4759E24A941torumyax@yahoo.co.jp>
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>



--- Toru Marumoto <torumyax@yahoo.co.jp> wrote:
> 
> I've tested in the latest version of
>
SharpReader,RSSBandit,Headline-Reader(ja),HepCat(ja)...
> and so on.
> Oh, and Bloglines too. 

I didn't implement xml:base support in RSS Bandit
since it would have been a hassle and I couldn't find
anyone who was using it besides Sam's Atom feed which
isn't listed on his feeds page so I doubt anyone
actually is subscribed to it. 

Once Atom hits 1.0 and how xml:base is to be utilized
in the spec is clearly spelled out I'll add support
for it to RSS Bandit. 

=====
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  Thu Jul 29 17:58: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 RAA11632
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 17:58:30 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TLlmus017482;
	Thu, 29 Jul 2004 14:47: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 i6TLlmXp017481;
	Thu, 29 Jul 2004 14:47:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TLlmWK017448
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 14:47:48 -0700 (PDT)
	(envelope-from antone@geckotribe.com)
Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134])
          by comcast.net (rwcrmhc13) with SMTP
          id <2004072921474201500drim4e>; Thu, 29 Jul 2004 21:47:47 +0000
Date: Thu, 29 Jul 2004 15:47:42 -0600
Subject: Re: PaceDates
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: <1364877593.20040729221002@djpowell.net>
Message-Id: <EB08F534-E1A8-11D8-9043-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 i6TLlmWK017476
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 Thursday, July 29, 2004, at 03:10  PM, David Powell wrote:
>> The "atom:date" element is a Date Construct, giving the date
>> associated with the entry. Typically, atom:date will be associated
>> with the creation or availability of the resource, but its semantics
>> is largely up to the tools to define. atom:date exists for
>> compatibility reasons and therefore SHOULD NOT be used.
>
> This is not how I see atom:date at all. I see it as a piece of
> metadata that a publisher wants to associate with the content of the
> entry, rather than a date associated with the publishing process like
> the other dates are. I see it as a useful field that is present for
> more reasons that backwards compatibility.
[snip]
> I'd prefer the atom:date section to look something more like this:
>
>   The "atom:date" element is a Date Construct, giving the date
>   associated with the entry. Typically, atom:date will be associated
>   with the creation or availability of the resource, but its semantics
>   is largely up to the publisher to define.

I think the distinction between atom:date and other dates as we've both 
expressed it just now it a good start for spec text.  For example:

'The "atom:date" element is a Date Construct giving a date associated 
with the contents of the entry, which might not be related to events in 
the publishing process...'

We don't want to state that it ISN'T related to events in the 
publishing process, because often it will be, or at least it will 
coincide with those dates.  But saying "might not be related..." 
uncouples the meaning of this date from the publishing process.


On Thursday, July 29, 2004, at 03:15  PM, Asbjørn Ulsberg wrote:
> On Thu, 29 Jul 2004 19:27:36 +0100, David Powell 
> <dipowell@djpowell.net> wrote:
>> I realise that this is only a SHOULD, but I think that there are 
>> sensible reasons for allowing atom:date to be in the future.
>
> I think the consensus is that it's not.
Disagreed.  I haven't noticed much general opposition to future 
subjective dates.  But maybe I just haven't been listening.

>> How about a feed of upcomming events, or weather forecasts
>
> If these are compelling use cases Atom needs to support, we should 
> embrace Dublin Core's 'available'[1] date that I think should cover 
> these use cases pretty well.
Disagreed again.  A weather forecast for next week is made "available" 
before next week.  Next week's date seems appropriate for atom:date in 
these kinds of cases.  This might be a different usage from how date 
fields in existing formats and blogging tools are used, but given that 
we're providing separate places for dates related to the publishing 
process, it feels like the right thing to do with this element.

>> I see it as a useful field that is present for more reasons that 
>> backwards
>> compatibility.
> atom:date exists purely to cater for the date the current publishing 
> tools provide for their entries. Please see BlogToolDateSurvey[2] for 
> details.
>> This is a place that allows the user to associate a date with an entry
>> if they want to.
> Some tools do this, others don't.
Perhaps your conception of atom:date is as nothing but a dumping ground 
for bad data when no better data exists, but there are other potential 
uses for subjective dates, as has been pointed out here and in previous 
discussion.  I for one don't have a problem with it being used both for 
user-selected dates and for sticking whatever date is available when 
all the more tightly specified dates are unknown.



From owner-atom-syntax@mail.imc.org  Thu Jul 29 18:07: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 SAA12323
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 18:07:14 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TLvsRS019379;
	Thu, 29 Jul 2004 14:57: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 i6TLvsOn019378;
	Thu, 29 Jul 2004 14:57:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TLvrRL019363
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 14:57:53 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net (ip2.198.145.31.iinet.com [198.145.31.2])
	(authenticated bits=0)
	by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i6TLx61Q023939;
	Thu, 29 Jul 2004 17:59:07 -0400
Message-ID: <410972DF.7070105@intertwingly.net>
Date: Thu, 29 Jul 2004 17:57:51 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Dare Obasanjo <kpako@yahoo.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Relative URI references
References: <20040729214148.92298.qmail@web41214.mail.yahoo.com>
In-Reply-To: <20040729214148.92298.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: <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:
> 
>>>I note that there are neither xml:base nor a
>>http-header Location: to
>>>establish what the base URI is, and since that
>>same resource can be fetched
>>>from both these URLs...
>>>
>>>    http://intertwingly.net/blog/index.atom
>>>    http://www.intertwingly.net/blog/index.atom
>>>
>>>that means the <id>s in your feed can be
>>different.
>>
>>Good point.  At a minimum, that is worthy of an
>>informative note.
> 
> This seems like an excellent reason to ban relative
> URIs in atom:id elements. Or are aggregator
> implementers expected to do perform scheme specific
> URI comparisons when checking to see if two entries
> are identical? 

I think that you are asking an orthogonal question.

It is the possibility of ids being in schemes like HTTP that would 
introduce the possibility of scheme specific URI comparisons, not the 
ability for URIs to be expressed as being relative to xml:base.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Thu Jul 29 18: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 SAA12704
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 18:10: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 i6TM2sjX020114;
	Thu, 29 Jul 2004 15: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 i6TM2sCr020113;
	Thu, 29 Jul 2004 15:02:54 -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 i6TM2s7D020086
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 15:02:54 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040729220253.20824.qmail@web41203.mail.yahoo.com>
Received: from [131.107.76.139] by web41203.mail.yahoo.com via HTTP; Thu, 29 Jul 2004 15:02:53 PDT
Date: Thu, 29 Jul 2004 15:02:53 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Relative URI references
To: Sam Ruby <rubys@intertwingly.net>
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <410972DF.7070105@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 is the possibility of ids being in schemes like
> HTTP that would 
> introduce the possibility of scheme specific URI
> comparisons, not the 
> ability for URIs to be expressed as being relative
> to xml:base.

If the consensus is that HTTP URLs should be allowed
for IDs then relative URIs should be banned. If a
specific URI scheme is mandated then it should be one
that doesn't have a relative URI scheme. Either way
relative URIs for IDs are a bad idea. 


=====
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  Thu Jul 29 18:16: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 SAA13368
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 18:16: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 i6TM97Ge021080;
	Thu, 29 Jul 2004 15:09: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 i6TM97Z1021079;
	Thu, 29 Jul 2004 15:09: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 i6TM93dp021064
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 15:09:06 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net (ip2.198.145.31.iinet.com [198.145.31.2])
	(authenticated bits=0)
	by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i6TMAE26024467;
	Thu, 29 Jul 2004 18:10:17 -0400
Message-ID: <41097577.5010200@intertwingly.net>
Date: Thu, 29 Jul 2004 18:08:55 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceDates
References: <20040729182950.TQJJ29220.mta03-svc.ntlworld.com@Inbox> <opsbw3zhqruvpchu@quark>
In-Reply-To: <opsbw3zhqruvpchu@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 Thu, 29 Jul 2004 19:27:36 +0100, David Powell 
> <dipowell@djpowell.net>  wrote:
> 
>> I realise that this is only a SHOULD, but I think that there are  
>> sensible reasons for allowing atom:date to be in the future.
> 
> I think the consensus is that it's not.

*sigh*

RSS 2.0, Blogger, MovableType, LiveJournal, etc would indicate otherwise.

I really, really, really would like to see dates being viewed as a way 
to model what is actually being used, as opposed to a PROCRUSTEAN BED[1].

- Sam Ruby

[1] http://www.bartleby.com/61/85/P0578500.html






From owner-atom-syntax@mail.imc.org  Thu Jul 29 18:25: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 SAA14094
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 18:25: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 i6TMGpHm022323;
	Thu, 29 Jul 2004 15:16: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 i6TMGpeb022317;
	Thu, 29 Jul 2004 15:16:51 -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 i6TMGphR022295
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 15:16:51 -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 <20040729221651013003jo2ke>; Thu, 29 Jul 2004 22:16:51 +0000
Date: Thu, 29 Jul 2004 16:16:51 -0600
Subject: Re: Propose partial consensus on dates
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: <20040723003152.38089.qmail@web41203.mail.yahoo.com>
Message-Id: <FD916D54-E1AC-11D8-9043-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 Thursday, July 22, 2004, at 06:31  PM, Dare Obasanjo wrote:
> --- Antone Roundy <antone@geckotribe.com> wrote:
>> were you supporting updated as defined by Sam
>> (including the word
>> "substantive") or were you intending to say +1 to an
>> updated date when
>> the last change of ANY kind was made (removing the
>> word "substantive")?
>
> I was saying +1 to having a single date field for
> indicating the last time an item was changed. I doubt
> aggregators or content producers will try to
> differentiate between last-time-a-type-was-fixed and
> last-time-a-major-revision-was-made when displaying
> content to the user.

Okay, I thought I understood, but your response to DateSurvey[1] got me 
wondering again.  You've indicated -1 to "Modified: the most recent 
date on which any aspect of the entry's content changed" and +1 to 
"Updated: the most recent date on which the publisher wishes to draw 
attention to the entry's having changed".  Is it that you want a Date 
Construct that could contain EITHER "modified" OR "updated" (as defined 
above) without specifying which of the two it is?

I don't suppose supporting "updated" REQUIRES "content producers ... to 
differentiate between last-time-a-type-was-fixed and 
last-time-a-major-revision-was-made"--they could either draw attention 
to every typo fix, or never bump Updated, no matter how drastic the 
change--but it certainly leaves the door open for content producers who 
wish to do that.

I guess I'm just having trouble seeing how "modified" could get a -1 if 
"updated" is getting +1.  A 0 for "modified" I could understand, but 
what pain is it going to cause, given that supporting "updated" already 
at least allows, even if not requiring, the distinction to be made?

[1] http://www.intertwingly.net/wiki/pie/DateSurvey



From owner-atom-syntax@mail.imc.org  Thu Jul 29 18:30: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 SAA14292
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 18:30: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 i6TMOWvS023531;
	Thu, 29 Jul 2004 15:24: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 i6TMOWOn023530;
	Thu, 29 Jul 2004 15:24: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 i6TMOVQk023516
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 15:24:32 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net (ip2.198.145.31.iinet.com [198.145.31.2])
	(authenticated bits=0)
	by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i6TMPjMc025083;
	Thu, 29 Jul 2004 18:25:46 -0400
Message-ID: <4109791E.1080509@intertwingly.net>
Date: Thu, 29 Jul 2004 18:24:30 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Dare Obasanjo <kpako@yahoo.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Relative URI references
References: <20040729220253.20824.qmail@web41203.mail.yahoo.com>
In-Reply-To: <20040729220253.20824.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:

> --- Sam Ruby <rubys@intertwingly.net> wrote:
> 
>>It is the possibility of ids being in schemes like
>>HTTP that would 
>>introduce the possibility of scheme specific URI
>>comparisons, not the 
>>ability for URIs to be expressed as being relative
>>to xml:base.
> 
> If the consensus is that HTTP URLs should be allowed
> for IDs then relative URIs should be banned. If a
> specific URI scheme is mandated then it should be one
> that doesn't have a relative URI scheme. Either way
> relative URIs for IDs are a bad idea. 

 From RFC 2396, section 1.4, paragraph 2:

     This document defines a scheme-independent `relative' form of URI
     reference that can be used in conjunction with a `base' URI (of a
     hierarchical scheme) to produce another URI.

HTTP may make scheme specific URI comparisons harder, but it certainly 
does not make relative URI resolution any easier or harder.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Thu Jul 29 18:35: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 SAA14506
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 18:35: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 i6TMOt13023611;
	Thu, 29 Jul 2004 15:24: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 i6TMOtmO023610;
	Thu, 29 Jul 2004 15:24:55 -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 i6TMOsxf023581
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 15:24:55 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 13507 messnum 7743063 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 29 Jul 2004 22:24:54 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.33.112)
  by mail01.svc.cra.dublin.eircom.net (qp 13507) with SMTP; 29 Jul 2004 22:24:54 -0000
Message-ID: <41097934.60107@dehora.net>
Date: Thu, 29 Jul 2004 23:24:52 +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: Relative URI references
References: <20040729220253.20824.qmail@web41203.mail.yahoo.com>
In-Reply-To: <20040729220253.20824.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:


> If the consensus is that HTTP URLs should be allowed
> for IDs then relative URIs should be banned. 

+1. This is a no-brainer.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Thu Jul 29 18:41: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 SAA14816
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 18:41: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 i6TMYCYY024960;
	Thu, 29 Jul 2004 15:34:12 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6TMYC0b024959;
	Thu, 29 Jul 2004 15:34:12 -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 i6TMYBp2024939
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 15:34:12 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 16004 messnum 6493246 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 29 Jul 2004 22:34:11 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.33.112)
  by mail12.svc.cra.dublin.eircom.net (qp 16004) with SMTP; 29 Jul 2004 22:34:11 -0000
Message-ID: <41097B60.2090705@dehora.net>
Date: Thu, 29 Jul 2004 23:34:08 +0100
From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520
X-Accept-Language: en-gb, en, en-us
MIME-Version: 1.0
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Relative URI references
References: <20040729220253.20824.qmail@web41203.mail.yahoo.com> <4109791E.1080509@intertwingly.net>
In-Reply-To: <4109791E.1080509@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:

>  From RFC 2396, section 1.4, paragraph 2:
> 
>     This document defines a scheme-independent `relative' form of URI
>     reference that can be used in conjunction with a `base' URI (of a
>     hierarchical scheme) to produce another URI.
> 
> HTTP may make scheme specific URI comparisons harder, but it certainly 
> does not make relative URI resolution any easier or harder.

I don't see what benefit there is in introducing a processing model 
to determine what are essentially surrogate ids when the ids can 
simply be declared - it strikes me as error prone. Why enable this 
for Atom ids?

cheers
Bill



From owner-atom-syntax@mail.imc.org  Thu Jul 29 18:48:21 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15184
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 18:48:20 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TMdKZg025755;
	Thu, 29 Jul 2004 15: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 i6TMdK5N025754;
	Thu, 29 Jul 2004 15:39:20 -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 i6TMdKp1025732
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 15:39: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 PAA05899
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 15:39: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 PAA16094
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 15:39:19 -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); Thu, 29 Jul 2004 15:39:19 -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 <0I1M00I96XLG01@shazam.verity.com> for atom-syntax@imc.org; Thu,
 29 Jul 2004 15:39:19 -0700 (PDT)
Date: Thu, 29 Jul 2004 15:39:19 -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: PaceFeedEquivalence
In-reply-to: <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: 
 <1707B577AB07F8E28C4E2559@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: <ED9ED1C6-E194-11D8-B732-000A95A51C9E@sun.com>
 <14be96d30407291338435fdef6@mail.gmail.com>
 <BC5132DE-E1A1-11D8-B732-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 Thursday, July 29, 2004 1:56 PM -0700 Tim Bray <Tim.Bray@Sun.COM> wrote:
>
> Yes.  If I have two pointers to feeds:
>
> http://www.example.com:80/feed.atom
> http://www.Example.COM/feed.atom
>
> I guarantee that some apps, in particular web spiders, are going to get
> very aggressive about schema-specific normalization and regard these as
> equivalent, and I don't see any reason to rule this out.  Norm?  -Tim

I'm not Norm, but I can confirm that. Normalization is done very
early, including %-escapes, ".." in paths, trimming fragments,
deleting session IDs, ...

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Thu Jul 29 18:48: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 SAA15207
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 18:48:26 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TMfkdo026127;
	Thu, 29 Jul 2004 15:41: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 i6TMfkxA026126;
	Thu, 29 Jul 2004 15:41:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web41207.mail.yahoo.com (web41207.mail.yahoo.com [66.218.93.40])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6TMfj9r026111
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 15:41:45 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040729224145.19444.qmail@web41207.mail.yahoo.com>
Received: from [131.107.3.85] by web41207.mail.yahoo.com via HTTP; Thu, 29 Jul 2004 15:41:45 PDT
Date: Thu, 29 Jul 2004 15:41:45 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Relative URI references
To: Sam Ruby <rubys@intertwingly.net>
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <4109791E.1080509@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:
> > 
> > If the consensus is that HTTP URLs should be
> allowed
> > for IDs then relative URIs should be banned. If a
> > specific URI scheme is mandated then it should be
> one
> > that doesn't have a relative URI scheme. Either
> way
> > relative URIs for IDs are a bad idea. 
> 
>  From RFC 2396, section 1.4, paragraph 2:
> 
>      This document defines a scheme-independent
> `relative' form of URI
>      reference that can be used in conjunction with
> a `base' URI (of a
>      hierarchical scheme) to produce another URI.
> 
> HTTP may make scheme specific URI comparisons
> harder, but it certainly 
> does not make relative URI resolution any easier or
> harder.

Why do you keep bringing up HTTP? The issue I have is
with relative URIs for IDs. I don't care if Atom
mandates HTTP, FTP or NNTP as the URI scheme for IDs
in this case, relative URIs should not be allowed in
any 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 - 100MB free storage!
http://promotions.yahoo.com/new_mail 



From owner-atom-syntax@mail.imc.org  Thu Jul 29 18:54: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 SAA15537
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 18:54: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 i6TMdCBB025721;
	Thu, 29 Jul 2004 15:39:12 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6TMdCm4025720;
	Thu, 29 Jul 2004 15:39: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 (mail.gmx.net [213.165.64.20])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6TMdBIS025690
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 15:39:11 -0700 (PDT)
	(envelope-from julian.reschke@gmx.de)
Received: (qmail 22078 invoked by uid 65534); 29 Jul 2004 22:39:10 -0000
Received: from pD9FF02CF.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.2.207)
  by mail.gmx.net (mp027) with SMTP; 30 Jul 2004 00:39:10 +0200
X-Authenticated: #1915285
Message-ID: <41097C88.1030300@gmx.de>
Date: Fri, 30 Jul 2004 00:39: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: Dare Obasanjo <kpako@yahoo.com>
CC: Sam Ruby <rubys@intertwingly.net>, Atom Syntax <atom-syntax@imc.org>
Subject: Re: Relative URI references
References: <20040729220253.20824.qmail@web41203.mail.yahoo.com>
In-Reply-To: <20040729220253.20824.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:

>>It is the possibility of ids being in schemes like
>>HTTP that would 
>>introduce the possibility of scheme specific URI
>>comparisons, not the 
>>ability for URIs to be expressed as being relative
>>to xml:base.
> 
> 
> If the consensus is that HTTP URLs should be allowed
> for IDs then relative URIs should be banned. If a

What would be a relative HTTP URL (example?). As far as I understand, a 
relatve URI 
(<http://greenbytes.de/tech/webdav/rfc2396.html#rfc.section.5>) never 
starts with a scheme name, thus it's scheme is determined by the base 
URI it's resolved with...

> specific URI scheme is mandated then it should be one
> that doesn't have a relative URI scheme. Either way
> relative URIs for IDs are a bad idea. 

+1.

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760



From owner-atom-syntax@mail.imc.org  Thu Jul 29 18:57: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 SAA15645
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 18:57: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 i6TMnAnP027660;
	Thu, 29 Jul 2004 15:49:10 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6TMnAm9027659;
	Thu, 29 Jul 2004 15:49:10 -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 i6TMnAFN027633
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 15:49:10 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040729224910.37432.qmail@web41211.mail.yahoo.com>
Received: from [131.107.3.70] by web41211.mail.yahoo.com via HTTP; Thu, 29 Jul 2004 15:49:10 PDT
Date: Thu, 29 Jul 2004 15:49:10 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Propose partial consensus on dates
To: Antone Roundy <antone@geckotribe.com>, atom-syntax@imc.org
In-Reply-To: <FD916D54-E1AC-11D8-9043-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:
>
> >
> > I was saying +1 to having a single date field for
> > indicating the last time an item was changed. I
> doubt
> > aggregators or content producers will try to
> > differentiate between last-time-a-type-was-fixed
> and
> > last-time-a-major-revision-was-made when
> displaying
> > content to the user.
> 
> Okay, I thought I understood, but your response to
> DateSurvey[1] got me 
> wondering again.  You've indicated -1 to "Modified:
> the most recent 
> date on which any aspect of the entry's content
> changed" and +1 to 
> "Updated: the most recent date on which the
> publisher wishes to draw 
> attention to the entry's having changed".  Is it
> that you want a Date 
> Construct that could contain EITHER "modified" OR
> "updated" (as defined 
> above) without specifying which of the two it is?
> 
...
> 
> I guess I'm just having trouble seeing how
> "modified" could get a -1 if 
> "updated" is getting +1.  A 0 for "modified" I could
> understand, but 
> what pain is it going to cause, given that
> supporting "updated" already 
> at least allows, even if not requiring, the
> distinction to be made?
> 
> [1] http://www.intertwingly.net/wiki/pie/DateSurvey

I couldn't see a scenario where having modified added
value. In a world where modified & updated exists then
content producers and aggregators are now being asked
to differentiate between last-time-a-type-was-fixed
and last-time-a-major-revision-was-made when
displaying content which at best would be very
arbitrary and would vary from tool to tool. 

If only modified exists then it isn't at all useful
since a reader can't tell if the change was an
insignificant change such as moving some whitespace
around or a significant one. 

If only updated exists, then readers can assume that
this date is always significant while content
producers are no worse off than if modified existed
(since they'll still have to make the decision as to
whether the change is significant enough to call
attention to or not). 

Thus I don't see modified adding any value. If it
doesn't add any value then it shouldn't be in 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 - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail



From owner-atom-syntax@mail.imc.org  Thu Jul 29 19: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 TAA16199
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 19: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 i6TMvEBQ029378;
	Thu, 29 Jul 2004 15:57: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 i6TMvEJb029377;
	Thu, 29 Jul 2004 15:57:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from beta.verity.com (beta.verity.com [192.187.143.12])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TMvABj029350
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 15:57:13 -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 PAA06881
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 15:57:10 -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 PAA18418
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 15:57:09 -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); Thu, 29 Jul 2004 15:57:09 -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 <0I1M00IKIYF701@shazam.verity.com> for atom-syntax@imc.org; Thu,
 29 Jul 2004 15:57:09 -0700 (PDT)
Date: Thu, 29 Jul 2004 15:57:10 -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: Date Options Analysis: Issued
In-reply-to: <opsbtb2mnquvpchu@quark>
To: Atom-Syntax <atom-syntax@imc.org>
Message-id: 
 <9380611B31E34A21867566DE@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: <D72A9E13D73D4464964DA4DED2881E.MAI@journurl.com>
 <opsbtb2mnquvpchu@quark>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6TMvDBj029372
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 Tuesday, July 27, 2004 10:19 PM +0200 Asbjørn Ulsberg <asbjorn@tigerstaden.no> wrote:
>
> It is, but I've come to the conclusion that it's better to have
> optional  high-quality dates in the entries, than having required
> low-quality ones.

It isn't high-quality and low-quality, it is professional and
casual publishing. I can't afford an editorial staff to do the
picky stuff for me. A professional publication can afford it.

How about an immutable='true' attribute? That allows professional
publishers to assert their policy of immutable issuance dates.

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Thu Jul 29 19:11: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 TAA16573
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 19:11: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 i6TN3cO8030412;
	Thu, 29 Jul 2004 16:03: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 i6TN3ctM030411;
	Thu, 29 Jul 2004 16:03:38 -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 i6TN3Yje030376
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 16:03:37 -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 QAA07245
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 16:00:47 -0700 (PDT)
Received: from mx-rr.verity.com (mx-rr.verity.com [10.3.100.59])
	by mx-rr.verity.com (8.9.3/8.9.3) with SMTP id QAA19072
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 16:00:40 -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); Thu, 29 Jul 2004 16:00:39 -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 <0I1M00IM3YL201@shazam.verity.com> for atom-syntax@imc.org; Thu,
 29 Jul 2004 16:00:39 -0700 (PDT)
Date: Thu, 29 Jul 2004 16:00:41 -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: PaceDateline
In-reply-to: <41027CC9.5060202@intertwingly.net>
To: Atom-Syntax <atom-syntax@imc.org>
Message-id: 
 <1788281A1F1403DDA7A98201@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: <41027456.5040109@intertwingly.net> <opsbndknqruvpchu@quark>
 <41027CC9.5060202@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 Saturday, July 24, 2004 11:14 AM -0400 Sam Ruby <rubys@intertwingly.net> wrote:
>
> The presumption is that dateline will be defined as a profile of ISO 8601.

This is completely different from Tim Bray's proposal of dateline
as a natural language string. That is also NewsML's spec for the
date portion.

-1 on the Pace.

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Thu Jul 29 19:29:46 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17728
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 19:29:45 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TNNYfJ034415;
	Thu, 29 Jul 2004 16:23:34 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6TNNYgm034414;
	Thu, 29 Jul 2004 16:23:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from 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 i6TNNYD8034407
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 16:23:34 -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 i6TNLJ53019193
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 17:21:19 -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 <0I1M0043GZNFOM@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Thu, 29 Jul 2004 17:23:39 -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 <0I1M00CQPZNEE1@mail.sun.net> for atom-syntax@imc.org; Thu,
 29 Jul 2004 17:23:39 -0600 (MDT)
Date: Thu, 29 Jul 2004 16:23:51 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceDateline
In-reply-to: 
 <1788281A1F1403DDA7A98201@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
To: Walter Underwood <wunder@verity.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
Message-id: <59E1CBD6-E1B6-11D8-B732-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: <41027456.5040109@intertwingly.net> <opsbndknqruvpchu@quark>
 <41027CC9.5060202@intertwingly.net>
 <1788281A1F1403DDA7A98201@adsl-64-166-133-244.dsl.snfc21.pacbell.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 Jul 29, 2004, at 4:00 PM, Walter Underwood wrote:

>
> --On Saturday, July 24, 2004 11:14 AM -0400 Sam Ruby 
> <rubys@intertwingly.net> wrote:
>>
>> The presumption is that dateline will be defined as a profile of ISO 
>> 8601.
>
> This is completely different from Tim Bray's proposal of dateline
> as a natural language string. That is also NewsML's spec for the
> date portion.

I do *not* propose that dateline should be a natural language string, 
it should be a formal date. -Tim



From owner-atom-syntax@mail.imc.org  Thu Jul 29 19:35: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 TAA18120
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 19:35: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 i6TNS6Pu035261;
	Thu, 29 Jul 2004 16:28: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 i6TNS6bP035260;
	Thu, 29 Jul 2004 16:28:06 -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 i6TNS5sd035233
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 16:28:05 -0700 (PDT)
	(envelope-from antone@geckotribe.com)
Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134])
          by comcast.net (sccrmhc12) with SMTP
          id <2004072923280501200fpl6se>; Thu, 29 Jul 2004 23:28:05 +0000
Date: Thu, 29 Jul 2004 17:28:05 -0600
Subject: Re: Propose partial consensus on dates
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: <20040729224910.37432.qmail@web41211.mail.yahoo.com>
Message-Id: <F16AC9FD-E1B6-11D8-9043-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 Thursday, July 29, 2004, at 04:49  PM, Dare Obasanjo wrote:
> If only modified exists then it isn't at all useful
> since a reader can't tell if the change was an
> insignificant change such as moving some whitespace
> around or a significant one.
>
> If only updated exists, then readers can assume that
> this date is always significant while content
> producers are no worse off than if modified existed
> (since they'll still have to make the decision as to
> whether the change is significant enough to call
> attention to or not).

Okay, I think that clears up my misunderstanding for the most part.

The risk I see in having only Updated is that some people are probably 
going to bump it every time they fix a typo, which, if that does happen 
very often, will result in readers NOT being able to assume that the 
date is always significant.  Modified might serve as a bucket to siphon 
off less useful data which otherwise would pollute Updated.

> I couldn't see a scenario where having modified added
> value. In a world where modified & updated exists then
> content producers and aggregators are now being asked
> to differentiate between last-time-a-type-was-fixed
> and last-time-a-major-revision-was-made when
> displaying content which at best would be very
> arbitrary and would vary from tool to tool.

...but there's still one thing I don't understand.  What is going to be 
more arbitrary if we have both?  The value in Updated is likely to be 
more dependable (as an indicator of significant change), as noted 
above.  Even if (with only Updated) people WOULDN'T pollute Updated 
with data that would have gone into Modified, if it existed, I don't 
see people's decisions regarding whether to call a change significant 
or trivial being more arbitrary if both exist.

So I'm guessing that you're saying one of more of the following:

* that interleaving entries that have only modified, entries that have 
only updated, and entries that have both, possibly from different 
feeds, will have arbitrary results.

* that deciding whether to sort by Modified or Updated (only 
considering one of the two) will be an arbitrary decision.

The latter I don't see a problem with--pick one or let the user decide. 
  But the former is a reasonable argument.  Aggregators would probably 
have to generate a sort field which contained the user's preferred 
sorting date for entries that had both, and whichever (if either) of 
the other two existed for entries that only had one.



From owner-atom-syntax@mail.imc.org  Thu Jul 29 19:40: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 TAA18391
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 19:40: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 i6TNWGkS036084;
	Thu, 29 Jul 2004 16:32: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 i6TNWGwM036082;
	Thu, 29 Jul 2004 16:32:16 -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 i6TNWEuk036037
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 16:32:14 -0700 (PDT)
	(envelope-from wunder@verity.com)
Received: from mx-rr.verity.com ([10.3.100.59])
	by beta.verity.com (8.9.3/8.9.3) with ESMTP id QAA08990
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 16:32: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 QAA23105
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 16:32: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); Thu, 29 Jul 2004 16:32: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 <0I1N00IY401N01@shazam.verity.com> for atom-syntax@imc.org; Thu,
 29 Jul 2004 16:32:13 -0700 (PDT)
Date: Thu, 29 Jul 2004 16:32: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: PaceDateline
In-reply-to: <59E1CBD6-E1B6-11D8-B732-000A95A51C9E@sun.com>
To: Atom-Syntax <atom-syntax@imc.org>
Message-id: 
 <0E4B8C53E13F9761527AC190@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: <41027456.5040109@intertwingly.net> <opsbndknqruvpchu@quark>
 <41027CC9.5060202@intertwingly.net>
 <1788281A1F1403DDA7A98201@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
 <59E1CBD6-E1B6-11D8-B732-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 Thursday, July 29, 2004 4:23 PM -0700 Tim Bray <Tim.Bray@sun.com> wrote:
>
> I do *not* propose that dateline should be a natural language string,
> it should be a formal date. -Tim

Dang, I meant to double-check that before hitting send. Sorry.

Well, author-expressed dates have been dropped on the floor,
along with the LiveJournal dates. I'll post a date format thingy
in a moment.

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Thu Jul 29 19:48: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 TAA18754
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 19:48:36 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TNenD9037869;
	Thu, 29 Jul 2004 16:40: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 i6TNenaG037868;
	Thu, 29 Jul 2004 16:40:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from chromium.sabren.com (chromium.sabren.com [69.20.61.177])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TNemHX037861
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 16:40:48 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net (ip2.198.145.31.iinet.com [198.145.31.2])
	(authenticated bits=0)
	by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i6TNfq5x028474;
	Thu, 29 Jul 2004 19:42:02 -0400
Message-ID: <41098AF3.9070507@intertwingly.net>
Date: Thu, 29 Jul 2004 19:40:35 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Dare Obasanjo <kpako@yahoo.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Relative URI references
References: <20040729224145.19444.qmail@web41207.mail.yahoo.com>
In-Reply-To: <20040729224145.19444.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: <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:
> 
>>>If the consensus is that HTTP URLs should be
>>allowed
>>>for IDs then relative URIs should be banned. If a
>>>specific URI scheme is mandated then it should be
>>one
>>>that doesn't have a relative URI scheme. Either
>>way
>>>relative URIs for IDs are a bad idea. 
>> From RFC 2396, section 1.4, paragraph 2:
>>
>>     This document defines a scheme-independent
>>`relative' form of URI
>>     reference that can be used in conjunction with
>>a `base' URI (of a
>>     hierarchical scheme) to produce another URI.
>>
>>HTTP may make scheme specific URI comparisons
>>harder, but it certainly 
>>does not make relative URI resolution any easier or
>>harder.
> 
> Why do you keep bringing up HTTP? The issue I have is
> with relative URIs for IDs. I don't care if Atom
> mandates HTTP, FTP or NNTP as the URI scheme for IDs
> in this case, relative URIs should not be allowed in
> any case. 

*sigh*

Recap: The original reason you gave for not wanting relative URIs was 
because it implied scheme specific comparisons.  My reply was: no, it is 
not relative URIs that implies that, but HTTP.  Then you gave HTTP as a 
reason why relative relative URIs should be banned.  Again, I said no, 
the HTTP scheme has no problem with relative URIs.

I certainly get that that you don't want relative URIs in IDs.  I'm 
presume that you have a reason behind this desire.  But if so, the 
arguments you have put forward related to scheme specific comparisons 
and HTTP aren't it.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Thu Jul 29 20: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 UAA19811
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 20:11: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 i6U037Ah042259;
	Thu, 29 Jul 2004 17:03: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 i6U037vq042258;
	Thu, 29 Jul 2004 17:03: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 i6U036Yv042233
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 17:03: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 RAA10667
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 17:03:07 -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 QAA25358
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 16:46:35 -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); Thu, 29 Jul 2004 16:46:34 -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 <0I1N00I7P0PI01@shazam.verity.com> for atom-syntax@imc.org; Thu,
 29 Jul 2004 16:46:34 -0700 (PDT)
Date: Thu, 29 Jul 2004 16:46:29 -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: Date attributes
To: atom-syntax@imc.org
Message-id: 
 <A68FDE280885438C182E4696@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
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 is not about which dates we allow: issued, modified, whatever.

We've dropped a couple of issues:

1. Dates with an unknown timezone. We know these are in the
   LiveJournal database, and they may be elsewhere.
2. Author preference for how the date is expressed. This is not
   localization, this is part of the author's creative expression.

Provide an attribute to signal that the time zone is unknown.
Use the string inside the element for the optional, author-preferred
format. No string means no author preference.

<date.munged clock-timezone-unknown='true'
  date='2004-07-29T13:01:00-00:00'>Sol 90 of Mars Spirit Rover
Mission</date.munged>

<date.unmunged date='2004-07-29T13:02:00+00:00'/>

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Thu Jul 29 20: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 UAA19912
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 20:15: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 i6U01B3p041920;
	Thu, 29 Jul 2004 17:01:11 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6U01Bsn041919;
	Thu, 29 Jul 2004 17:01: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 i6U01BdD041894
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 17:01: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 <20040730000109013003fag6e>; Fri, 30 Jul 2004 00:01:10 +0000
Date: Thu, 29 Jul 2004 18:01:10 -0600
Subject: Re: PaceDateline
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: <0E4B8C53E13F9761527AC190@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
Message-Id: <906AC391-E1BB-11D8-9043-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 Thursday, July 29, 2004, at 05:32  PM, Walter Underwood wrote:
> --On Thursday, July 29, 2004 4:23 PM -0700 Tim Bray <Tim.Bray@sun.com> 
> wrote:
>> I do *not* propose that dateline should be a natural language string,
>> it should be a formal date. -Tim
>
> Dang, I meant to double-check that before hitting send. Sorry.
>
> Well, author-expressed dates have been dropped on the floor,
> along with the LiveJournal dates. I'll post a date format thingy
> in a moment.
>
Author SELECTED dates have not been dropped--there's widespread support 
for having a Date Construct for which the author can CHOOSE an 
arbitrary date.  It's only the FORMAT of the EXPRESSION of that date 
that we seem to have strong consensus for constraining.  I presume that 
LiveJournal dates can be formatted accordingly.



From owner-atom-syntax@mail.imc.org  Thu Jul 29 20:42:45 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21323
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 20:42:44 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6U0aMWs048780;
	Thu, 29 Jul 2004 17:36: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 i6U0aMdP048779;
	Thu, 29 Jul 2004 17:36:22 -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 i6U0aMP9048753
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 17:36:22 -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 RAA11962
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 17:33: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 RAA29578
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 17:33:27 -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); Thu, 29 Jul 2004 17:33: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 <0I1N00IS32VO01@shazam.verity.com> for atom-syntax@imc.org; Thu,
 29 Jul 2004 17:33:26 -0700 (PDT)
Date: Thu, 29 Jul 2004 17:33:24 -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: PaceDateline
In-reply-to: <906AC391-E1BB-11D8-9043-003065EA6144@geckotribe.com>
To: atom-syntax@imc.org
Message-id: 
 <9F7CB834D067894AC700575B@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: <906AC391-E1BB-11D8-9043-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 Thursday, July 29, 2004 6:01 PM -0600 Antone Roundy <antone@geckotribe.com> wrote:
>
> Author SELECTED dates have not been dropped--there's widespread support
> for having a Date Construct for which the author can CHOOSE an arbitrary
> date.  It's only the FORMAT of the EXPRESSION of that date that we seem
> to have strong consensus for constraining.  I presume that LiveJournal
> dates can be formatted accordingly.

In other words, author-expressions for dates have been dropped.

Formatting LiveJournal dates does not help. They are from an
unsynchronized clock (unknown time zone). Dates within a blog
can be compared, but dates from different blogs cannot be, unless
they are more than 28 hours apart.

Labeling these dates allows them to be used for ordering when
it is safe, and avoided when it is not safe.

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Thu Jul 29 20:43:42 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21458
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 20:43:42 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6U0as5I048879;
	Thu, 29 Jul 2004 17: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 i6U0asjc048878;
	Thu, 29 Jul 2004 17:36:54 -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 i6U0asRK048851
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 17:36:54 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040730003655.50135.qmail@web41203.mail.yahoo.com>
Received: from [24.19.155.139] by web41203.mail.yahoo.com via HTTP; Thu, 29 Jul 2004 17:36:55 PDT
Date: Thu, 29 Jul 2004 17:36:55 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Relative URI references
To: Sam Ruby <rubys@intertwingly.net>
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <41098AF3.9070507@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:
> 
> Recap: The original reason you gave for not wanting
> relative URIs was 
> because it implied scheme specific comparisons.  My
> reply was: no, it is 
> not relative URIs that implies that, but HTTP.  Then
> you gave HTTP as a 
> reason why relative relative URIs should be banned. 
> Again, I said no, 
> the HTTP scheme has no problem with relative URIs.

This has nothing to do with HTTP. It has everything to
do with relative URIs. 

Here's a thought experiment

1.) I subscribe to a feed via
ftp://dare@ftp.example.com/mainfeed.xml and another
via ftp://ftp.example.com/categoryfeed.xml

2.) The set of entries in mainfeed.xml is a superset
of the set of entries in categoryfeed.xml 

3.) Each entry uses a relative URI as the atom:id. 

4.) How do I tell that the many entries in
categoryfeed.xml have the same ID as those in
mainfeed.xml without doing scheme specific comparisons
after resolving xml:base rules? 

BONUS QUESTION
5.) What does this have to do with HTTP? 

> I certainly get that that you don't want relative
> URIs in IDs.  I'm 
> presume that you have a reason behind this desire. 
> But if so, the 
> arguments you have put forward related to scheme
> specific comparisons 
> and HTTP aren't it.

Hopefully it is clearer to you 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!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail 



From owner-atom-syntax@mail.imc.org  Thu Jul 29 21:14:34 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22983
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 21:14: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 i6U12Rko053946;
	Thu, 29 Jul 2004 18:02:27 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6U12RcK053945;
	Thu, 29 Jul 2004 18:02:27 -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 i6U12J5b053824
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 18:02:24 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 30 Jul 2004 11:07:29 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Fri, 30 Jul 2004 11:01:35 +1000
Subject: Re: Demonstrating persistence
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD2FDB0F.2381E%eric.scheid@ironclad.net.au>
In-Reply-To: <41091B20.7050106@franklinmint.fm>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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 30/7/04 1:43 AM, "Robert Sayre" <mint@franklinmint.fm> wrote:

> "...implementors SHOULD consider using another URI scheme ... which does
> not imply information-retrieval semantics."
> 
> While that wording is certainly diplomatic, I'm not sure it's a good use
> of RFC2119 terms.

Disagree. SHOULD is used for situations where you MAY, but only if you think
really carefully about what you are doing lest you break something; (or
situations where you will break something so you better be darn sure).

e.



From owner-atom-syntax@mail.imc.org  Thu Jul 29 21: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 VAA23068
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 21:16:03 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6U16q80054596;
	Thu, 29 Jul 2004 18:06:52 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6U16qYC054595;
	Thu, 29 Jul 2004 18:06:52 -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 i6U16pQN054588
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 18:06:52 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net (ip2.198.145.31.iinet.com [198.145.31.2])
	(authenticated bits=0)
	by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i6U187vM032240;
	Thu, 29 Jul 2004 21:08:07 -0400
Message-ID: <41099F2B.4090003@intertwingly.net>
Date: Thu, 29 Jul 2004 21:06:51 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <wunder@verity.com>
CC: atom-syntax@imc.org
Subject: Re: Date attributes
References: <A68FDE280885438C182E4696@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
In-Reply-To: <A68FDE280885438C182E4696@adsl-64-166-133-244.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:

> 
> This is not about which dates we allow: issued, modified, whatever.
> 
> We've dropped a couple of issues:
> 
> 1. Dates with an unknown timezone. We know these are in the
>   LiveJournal database, and they may be elsewhere.
> 2. Author preference for how the date is expressed. This is not
>   localization, this is part of the author's creative expression.
> 
> Provide an attribute to signal that the time zone is unknown.
> Use the string inside the element for the optional, author-preferred
> format. No string means no author preference.
> 
> <date.munged clock-timezone-unknown='true'
>  date='2004-07-29T13:01:00-00:00'>Sol 90 of Mars Spirit Rover
> Mission</date.munged>

If you look at ISO 8601[1], section 5.3.1, you will see that there is a 
syntax for defining local times: one simply omits the time zone information.

Another reference worth reading is in the XML Schema Part 2: 
Datatypes[2].  Note for those that have an allergy to XML Schema in 
general: what vocabularies such as RelaxNG are based on XML Schema Part 
2... it is XML Schema Part 1 that is controversial.

If we decide to pursue an author preference for expression (to be 
honest, I'm ambivalent on this), I'd prefer that this be in a "title" 
attribute.  Combining these two together, the example above would look 
like this:

<date.munged title="Sol 90 of Mars Spirit Rover 
Mission">2004-07-29T13:01:00</date.munged>

- Sam Ruby

[1] http://lists.ebxml.org/archives/ebxml-core/200104/pdf00005.pdf
[2] http://www.w3.org/TR/xmlschema-2/#dateTime



From owner-atom-syntax@mail.imc.org  Thu Jul 29 21:28:13 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23436
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 21:28:12 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6U1HrxE056918;
	Thu, 29 Jul 2004 18:17: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 i6U1Hr4P056916;
	Thu, 29 Jul 2004 18:17: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 i6U1HrJN056909
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 18:17:53 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net (ip2.198.145.31.iinet.com [198.145.31.2])
	(authenticated bits=0)
	by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i6U1J7sT032748;
	Thu, 29 Jul 2004 21:19:08 -0400
Message-ID: <4109A1BF.6070905@intertwingly.net>
Date: Thu, 29 Jul 2004 21:17:51 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Dare Obasanjo <kpako@yahoo.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Relative URI references
References: <20040730003655.50135.qmail@web41203.mail.yahoo.com>
In-Reply-To: <20040730003655.50135.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:

> 
> --- Sam Ruby <rubys@intertwingly.net> wrote:
> 
>>Recap: The original reason you gave for not wanting
>>relative URIs was 
>>because it implied scheme specific comparisons.  My
>>reply was: no, it is 
>>not relative URIs that implies that, but HTTP.  Then
>>you gave HTTP as a 
>>reason why relative relative URIs should be banned. 
>>Again, I said no, 
>>the HTTP scheme has no problem with relative URIs.
> 
> This has nothing to do with HTTP. It has everything to
> do with relative URIs. 
> 
> Here's a thought experiment
> 
> 1.) I subscribe to a feed via
> ftp://dare@ftp.example.com/mainfeed.xml and another
> via ftp://ftp.example.com/categoryfeed.xml
> 
> 2.) The set of entries in mainfeed.xml is a superset
> of the set of entries in categoryfeed.xml 
> 
> 3.) Each entry uses a relative URI as the atom:id. 

Stop there.  If we don't to keep the URI comparison rules simple, it 
isn't possible to do that in a valid way.  One of those would need to be 
absolute.

> 4.) How do I tell that the many entries in
> categoryfeed.xml have the same ID as those in
> mainfeed.xml without doing scheme specific comparisons
> after resolving xml:base rules? 

If the URI comparison rules are simple, then one simply compares the 
URIs after resolving xml:base rules.

> BONUS QUESTION
> 5.) What does this have to do with HTTP? 

Nothing.  I guess I jumped to the wrong conclusion when you posed the 
issue as having to do with scheme specific URI comparisons.

>>I certainly get that that you don't want relative
>>URIs in IDs.  I'm 
>>presume that you have a reason behind this desire. 
>>But if so, the 
>>arguments you have put forward related to scheme
>>specific comparisons 
>>and HTTP aren't it.
> 
> Hopefully it is clearer to you now. 

Yes, thanks for clarifying.

What I see is an argument that since relative URIs can't be used in some 
circumstances, they should be disallowed in all circumstances. 
PaceAtomIDIsNewsML takes this argument one step further and disallows 
both http and ftp as valid URI schemes for ID values.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Thu Jul 29 21:30:03 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23509
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 21:30:02 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6U1M2fQ057595;
	Thu, 29 Jul 2004 18:22: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 i6U1M2eM057594;
	Thu, 29 Jul 2004 18:22: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 i6U1M2al057582
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 18:22:02 -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 esmtp (Exim 4.34)
	id 1BqM61-0005gl-27; Fri, 30 Jul 2004 01:22:05 +0000
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Thu, 29 Jul 2004 21:22:04 -0400
Subject: Re: Demonstrating persistence
From: Robert Sayre <mint@franklinmint.fm>
To: Eric Scheid <eric.scheid@ironclad.net.au>,
        Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD2F1AFC.147A2%mint@franklinmint.fm>
In-Reply-To: <BD2FDB0F.2381E%eric.scheid@ironclad.net.au>
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: <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 7/29/04 9:01 PM, "Eric Scheid" <eric.scheid@ironclad.net.au> wrote:

> 
> On 30/7/04 1:43 AM, "Robert Sayre" <mint@franklinmint.fm> wrote:
> 
>> "...implementors SHOULD consider using another URI scheme ... which does
>> not imply information-retrieval semantics."
>> 
>> While that wording is certainly diplomatic, I'm not sure it's a good use
>> of RFC2119 terms.
> 
> Disagree. SHOULD is used for situations where you MAY, but only if you think
> really carefully about what you are doing lest you break something; (or
> situations where you will break something so you better be darn sure).

What does the Pace say implementors SHOULD do?

Robert Sayre



From owner-atom-syntax@mail.imc.org  Thu Jul 29 21:34: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 VAA23707
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 21:34: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 i6U1PhMD058031;
	Thu, 29 Jul 2004 18:25:43 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6U1PhT2058030;
	Thu, 29 Jul 2004 18:25:43 -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 i6U1PhJX058021
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 18:25: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 SAA14184
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 18:25:43 -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 SAA04411
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 18:21:37 -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); Thu, 29 Jul 2004 18:21:37 -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 <0I1N00ICE53Y01@shazam.verity.com> for atom-syntax@imc.org; Thu,
 29 Jul 2004 18:21:36 -0700 (PDT)
Date: Thu, 29 Jul 2004 18:21:34 -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: Date attributes
In-reply-to: <41099F2B.4090003@intertwingly.net>
To: atom-syntax@imc.org
Message-id: 
 <94D84EE38E8CA9B1170DF0F5@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: <41099F2B.4090003@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 Thursday, July 29, 2004 9:06 PM -0400 Sam Ruby <rubys@intertwingly.net> wrote:
> If we decide to pursue an author preference for expression (to be honest,
> I'm ambivalent on this), I'd prefer that this be in a "title" attribute.
> Combining these two together, the example above would look like this:
>
> <date.munged title="Sol 90 of Mars Spirit Rover Mission">2004-07-29T13:01:00</date.munged>

I put it in the content because we've been leaning toward leaving room
for markup within text. There is no way we can allow markup within the
ISO 8601 date.

> If you look at ISO 8601[1], section 5.3.1, you will see that there is a
> syntax for defining local times: one simply omits the time zone information.

I'll check it out, but we've been settling on a very limited subset
of ISO 8601, and I fully agree with that. Even though things are
legitimately published on "2004-07", that is a royal pain for clients.

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Thu Jul 29 21:47: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 VAA24231
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 21:47:12 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6U1Z7Ew059635;
	Thu, 29 Jul 2004 18:35: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 i6U1Z7hd059634;
	Thu, 29 Jul 2004 18:35: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 i6U1Z3Zp059618
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 18:35:06 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 30 Jul 2004 11:40:52 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Fri, 30 Jul 2004 11:34:57 +1000
Subject: Re: PaceDates
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD2FE2E1.23922%eric.scheid@ironclad.net.au>
In-Reply-To: <opsbw08piyuvpchu@quark>
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 i6U1Z7Zp059629
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 30/7/04 6:15 AM, "Asbjørn Ulsberg" <asbjorn@tigerstaden.no> wrote:
>> insert ", including addition, changes, or deletions of child elements of
>> the entry, including namespaced extensions."
> 
> I changed it into this:
> 
>  The "atom:modified" element is a Date Construct that indicates the time
>  that the entry was last modified. "Modification" of an entry includes
>  addition, changes, or deletions of child elements of the entry, both
>  in and outside of the Atom namespace.

+1

>>> The content of an atom:modified element MUST according to RFC 3339 have
>>> a time zone whose value SHOULD be "+00:00" or "Z".
>> 
>> why not "-00:00"?
> 
> That is UTC. The only difference is that the local timezone is unknown. If
> you think the specification text could make this clearer, please feel free
> to suggest what such language might look like.

my point is you've SHOULD'd against it.

append: <<, or "-00:00" if the UTC time is known but the local time zone is
unknown (eg. as a centralised hosting service might know)>>

>> why the deprecation of 'date'?
> 
> Because it's a wildcard date. No one knows what the publisher's mean with
> it, so we should encourage them to move over to the more tightly specified
> dates 'issued', 'created' or 'modified'. They may provide atom:date for as
> long as they want, but I think that the use of such ambiguous elements
> should be discouraged.

<summary> is also a wildcard element - it contains arbitrary, subjective,
and mutable content, and no one will know a priori whether it will be a
truncated first paragraph, a hand written summary, a machine written
summary, a bunch of keywords mushed together.

Nonetheless, it's a very useful thing. Ditto 'dateline' aka 'date'. It's
content, and it's valuable.

The medium is not the message, the message is the message. Content is the
reason.

>> what happened to atom:updated?
> 
> Who wants it, really? I know that Dare have written several times that he
> has never seen or heard a use case for it, but if the consensus is that
> this date should be available, then okay. I think that major changes
> should be signified with another mechanism than a date, though.

I want it. I asked Brent Simmons (of NNW fame) and he'd love to have it.
Others can see the utility of it. People are hacking current values of
<pubDate> to get the same effect today because they don't have it. 'updated'
would also be used when an entry has major changes made in lieu of munging
'issued', which I thought was a goal of yours.

e.




From owner-atom-syntax@mail.imc.org  Thu Jul 29 21:57: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 VAA24799
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 21:57: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 i6U1nhsF062145;
	Thu, 29 Jul 2004 18:49: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 i6U1nhT6062144;
	Thu, 29 Jul 2004 18:49:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6U1nekj062130
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 18:49:42 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 30 Jul 2004 11:55:36 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Fri, 30 Jul 2004 11:49:42 +1000
Subject: Re: PaceDates
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD2FE656.2392A%eric.scheid@ironclad.net.au>
In-Reply-To: <opsbw3zhqruvpchu@quark>
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 i6U1nhkj062139
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 30/7/04 7:15 AM, "Asbjørn Ulsberg" <asbjorn@tigerstaden.no> wrote:
>>> [issued SHOULD be past tense]
>>
>> I realise that this is only a SHOULD, but I think that there are
>> sensible reasons for allowing atom:date to be in the future.
> 
> I think the consensus is that it's not.

disagree there is consensus ... the question of future dates being an issue
hasn't been discussed at all, or only in passing.

>> How about a feed of upcoming events, or weather forecasts
> 
> If these are compelling use cases Atom needs to support, we should embrace
> Dublin Core's 'available'[1] date that I think should cover these use
> cases pretty well.

those feeds are better dated using the (so called deprecated) 'date'
element, not the 'issued' element. A weather feed in particular should have
the date the information was released in the 'issued' date, just so readers
can know that it's 48 hours old and thus unreliable.

> The point of the text is that you shouldn't put something out on the web
> if it's not meant to be out on the web yet

some may use it as a soft embargo date, meaning its not actually official
until that date arrives. if you happen to see it before that date then you
are getting a 'sneak preview'.

One of my client sites has several thousand pages, which they publish by
baking them to static files. A complete site reload takes several hours.
They'd like to put an issued date on their press releases. They don't know
if the press release would be at the beginning of the reload process, or
towards the end. Thus they'll start the reload at midnight, it'll finish
about 6am, and the press release is officially issued at 8am (not 6pm the
prior night).

e.




From owner-atom-syntax@mail.imc.org  Thu Jul 29 21:58: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 VAA24865
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 21:58: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 i6U1mjIP061993;
	Thu, 29 Jul 2004 18:48: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 i6U1mjZh061992;
	Thu, 29 Jul 2004 18:48:45 -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 i6U1miSE061978
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 18:48:44 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net (ip2.198.145.31.iinet.com [198.145.31.2])
	(authenticated bits=0)
	by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i6U1nxAS001812;
	Thu, 29 Jul 2004 21:50:00 -0400
Message-ID: <4109A8FB.7080706@intertwingly.net>
Date: Thu, 29 Jul 2004 21:48:43 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <wunder@verity.com>
CC: atom-syntax@imc.org
Subject: Re: Date attributes
References: <41099F2B.4090003@intertwingly.net> <94D84EE38E8CA9B1170DF0F5@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
In-Reply-To: <94D84EE38E8CA9B1170DF0F5@adsl-64-166-133-244.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 Thursday, July 29, 2004 9:06 PM -0400 Sam Ruby 
> <rubys@intertwingly.net> wrote:
> 
>> If we decide to pursue an author preference for expression (to be honest,
>> I'm ambivalent on this), I'd prefer that this be in a "title" attribute.
>> Combining these two together, the example above would look like this:
>>
>> <date.munged title="Sol 90 of Mars Spirit Rover 
>> Mission">2004-07-29T13:01:00</date.munged>
> 
> I put it in the content because we've been leaning toward leaving room
> for markup within text. There is no way we can allow markup within the
> ISO 8601 date.
> 
>> If you look at ISO 8601[1], section 5.3.1, you will see that there is a
>> syntax for defining local times: one simply omits the time zone 
>> information.
> 
> I'll check it out, but we've been settling on a very limited subset
> of ISO 8601, and I fully agree with that. Even though things are
> legitimately published on "2004-07", that is a royal pain for clients.

Agreed.  I fully support the notion of a limited subset.  RFC 3339 looks 
really good, though for interoperability I would prefer to not take 
advange of the following:

       NOTE: ISO 8601 defines date and time separated by "T".
       Applications using this syntax may choose, for the sake of
       readability, to specify a full-date and full-time separated by
       (say) a space character.

And I'm mildly concerned about the following:

       NOTE: Per [ABNF] and ISO8601, the "T" and "Z" characters in this
       syntax may alternatively be lower case "t" or "z" respectively.

But my real point is that if we see a valid requirement the need to 
express local times without offsets, then we should consider widening 
the profile *slightly* (i.e., making the offset optional) instead of 
introducing the following as an attribute:

       clock-timezone-unknown='true'

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Thu Jul 29 22: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 WAA25116
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 22:04: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 i6U1shNW062970;
	Thu, 29 Jul 2004 18:54: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 i6U1shdP062969;
	Thu, 29 Jul 2004 18:54:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6U1sb7R062948
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 18:54:39 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 30 Jul 2004 12:00:33 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Fri, 30 Jul 2004 11:54:36 +1000
Subject: Re: Propose partial consensus on dates
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD2FE77C.2392C%eric.scheid@ironclad.net.au>
In-Reply-To: <20040729224910.37432.qmail@web41211.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 30/7/04 8:49 AM, "Dare Obasanjo" <kpako@yahoo.com> wrote:

> I couldn't see a scenario where having modified added
> value.

some aggregators load entries into their own database/model, and would
prefer to avoid the dump/parse/reload everytime they see that entry (ie.
until if falls off the bottom of the feed) if the XML says it hasn't
actually changed.

'modified' is useful for machines, 'updated' is useful for humans.

e.



From owner-atom-syntax@mail.imc.org  Thu Jul 29 22: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 WAA25143
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 22:05:12 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6U1tsHq063191;
	Thu, 29 Jul 2004 18: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 i6U1tsBd063190;
	Thu, 29 Jul 2004 18:55:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6U1tmJX063164
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 18:55:52 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 30 Jul 2004 12:01:36 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Fri, 30 Jul 2004 11:55:41 +1000
Subject: Re: PaceDates
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD2FE7BD.2392E%eric.scheid@ironclad.net.au>
In-Reply-To: <EB08F534-E1A8-11D8-9043-003065EA6144@geckotribe.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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 30/7/04 7:47 AM, "Antone Roundy" <antone@geckotribe.com> wrote:

> I think the distinction between atom:date and other dates as we've both
> expressed it just now it a good start for spec text.  For example:
> 
> 'The "atom:date" element is a Date Construct giving a date associated
> with the contents of the entry, which might not be related to events in
> the publishing process...'
> 
> We don't want to state that it ISN'T related to events in the
> publishing process, because often it will be, or at least it will
> coincide with those dates.  But saying "might not be related..."
> uncouples the meaning of this date from the publishing process.

+1



From owner-atom-syntax@mail.imc.org  Thu Jul 29 22:20:38 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25739
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 22: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 i6U2AnY6065973;
	Thu, 29 Jul 2004 19:10:49 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6U2Anck065972;
	Thu, 29 Jul 2004 19:10:49 -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 i6U2AmPG065944
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 19:10: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 <2004073002104401400dq37je>; Fri, 30 Jul 2004 02:10:50 +0000
Date: Thu, 29 Jul 2004 20:10:45 -0600
Subject: Re: Relative URI references
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: <4109A1BF.6070905@intertwingly.net>
Message-Id: <AA8A6A9C-E1CD-11D8-9043-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 Thursday, July 29, 2004, at 07:17  PM, Sam Ruby wrote:
>> 1.) I subscribe to a feed via
>> ftp://dare@ftp.example.com/mainfeed.xml and another
>> via ftp://ftp.example.com/categoryfeed.xml
>> 2.) The set of entries in mainfeed.xml is a superset
>> of the set of entries in categoryfeed.xml
>> 3.) Each entry uses a relative URI as the atom:id.
>
> Stop there.  If we don't to keep the URI comparison rules simple, it 
> isn't possible to do that in a valid way.  One of those would need to 
> be absolute.

...unless at least one of them specified xml:base explicitly, for 
example, in the first:

<feed xmlns="..." xml:base="ftp://ftp.example.com/">
...
<entry id="relative/path/to/something">
...

Right?  Or they could both specify xml:base explicitly:

<feed xmlns="..." xml:base="http://www.example.com/myblog/">
...
<entry id="relative/path/to/something">
...



From owner-atom-syntax@mail.imc.org  Thu Jul 29 22:45: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 WAA26741
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 22:45: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 i6U2YvFS070460;
	Thu, 29 Jul 2004 19:34: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 i6U2YvMX070459;
	Thu, 29 Jul 2004 19:34: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 i6U2Yua3070450
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 19:34:56 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net (ip2.198.145.31.iinet.com [198.145.31.2])
	(authenticated bits=0)
	by chromium.sabren.com (8.12.11/8.12.11) with ESMTP id i6U2aCOn003745;
	Thu, 29 Jul 2004 22:36:12 -0400
Message-ID: <4109B3CF.4080002@intertwingly.net>
Date: Thu, 29 Jul 2004 22:34:55 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Antone Roundy <antone@geckotribe.com>
CC: atom-syntax@imc.org
Subject: Re: Relative URI references
References: <AA8A6A9C-E1CD-11D8-9043-003065EA6144@geckotribe.com>
In-Reply-To: <AA8A6A9C-E1CD-11D8-9043-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 Thursday, July 29, 2004, at 07:17  PM, Sam Ruby wrote:
> 
>>> 1.) I subscribe to a feed via
>>> ftp://dare@ftp.example.com/mainfeed.xml and another
>>> via ftp://ftp.example.com/categoryfeed.xml
>>> 2.) The set of entries in mainfeed.xml is a superset
>>> of the set of entries in categoryfeed.xml
>>> 3.) Each entry uses a relative URI as the atom:id.
>>
>> Stop there.  If we don't to keep the URI comparison rules simple, it 
>> isn't possible to do that in a valid way.  One of those would need to 
>> be absolute.
> 
> ...unless at least one of them specified xml:base explicitly, for 
> example, in the first:
> 
> <feed xmlns="..." xml:base="ftp://ftp.example.com/">
> ...
> <entry id="relative/path/to/something">
> ...
> 
> Right?  Or they could both specify xml:base explicitly:
> 
> <feed xmlns="..." xml:base="http://www.example.com/myblog/">
> ...
> <entry id="relative/path/to/something">
> ...

+1

- Sam Ruby




From owner-atom-syntax@mail.imc.org  Thu Jul 29 22:55: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 WAA27108
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 22:55: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 i6U2ij4t072196;
	Thu, 29 Jul 2004 19: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 i6U2ijKM072195;
	Thu, 29 Jul 2004 19:44: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 i6U2iEaj072106
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 19:44:14 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040730024416.47458.qmail@web41214.mail.yahoo.com>
Received: from [24.19.155.139] by web41214.mail.yahoo.com via HTTP; Thu, 29 Jul 2004 19:44:16 PDT
Date: Thu, 29 Jul 2004 19:44:16 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Propose partial consensus on dates
To: Eric Scheid <eric.scheid@ironclad.net.au>,
        Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <BD2FE77C.2392C%eric.scheid@ironclad.net.au>
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>



--- Eric Scheid <eric.scheid@ironclad.net.au> wrote:

> 
> On 30/7/04 8:49 AM, "Dare Obasanjo"
> <kpako@yahoo.com> wrote:
> 
> > I couldn't see a scenario where having modified
> added
> > value.
> 
> some aggregators load entries into their own
> database/model, and would
> prefer to avoid the dump/parse/reload everytime they
> see that entry (ie.
> until if falls off the bottom of the feed) if the
> XML says it hasn't
> actually changed.
> 
> 'modified' is useful for machines, 'updated' is
> useful for humans.

How does modified help here if you already have
updated? I am an aggregator author and if I was going
to do what you describe I'd use the updated value not
the modified value. Why would I reparse the entry if
no significant changes had been made? 


=====
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  Thu Jul 29 23:23: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 XAA28498
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 23:23: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 i6U3B1xx077658;
	Thu, 29 Jul 2004 20:11: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 i6U3B1gf077657;
	Thu, 29 Jul 2004 20:11:01 -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 i6U3B0O6077624
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 20:11:00 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040730031102.57711.qmail@web41212.mail.yahoo.com>
Received: from [67.168.158.222] by web41212.mail.yahoo.com via HTTP; Thu, 29 Jul 2004 20:11:02 PDT
Date: Thu, 29 Jul 2004 20:11:02 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Relative URI references
To: Sam Ruby <rubys@intertwingly.net>, Antone Roundy <antone@geckotribe.com>
Cc: atom-syntax@imc.org
In-Reply-To: <4109B3CF.4080002@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:
>
> > ...unless at least one of them specified xml:base
> explicitly, for 
> > example, in the first:
> > 
> > <feed xmlns="..."
> xml:base="ftp://ftp.example.com/">
> > ...
> > <entry id="relative/path/to/something">
> > ...
> > 
> > Right?  Or they could both specify xml:base
> explicitly:
> > 
> > <feed xmlns="..."
> xml:base="http://www.example.com/myblog/">
> > ...
> > <entry id="relative/path/to/something">
> > ...
> 
> +1

I'm not sure what this +1 is supposed to indicate. The
entire xml:base support thing in Atom seems like a
misfeature. The primary reason for needing something
like xml:base in syndication formats is to know how to
resolve relative URIs in [X]HTML content. 
Everywhere else it appears is overkill and
unncecessary complexity. More importantly it doesn't
even seem that most recent draft satisfies the only
real use case for using xml:base in the Atom
syndication format. 

Exactly what is served by the fact that you can use
relative URIs in IDs besides causing potential
problems in for feed consumers? Who is crying out for
the functionality of using relative URIs as values for
 atom:id or atom:link? On the other hand, it is a
major problem in RSS and Atom feeds today to determine
authoritatively how to resolve relative links in
content yet no one seems interested in discussing that
or tackling it in 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!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 



From owner-atom-syntax@mail.imc.org  Thu Jul 29 23:37: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 XAA29084
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 23:37: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 i6U3RMqK080622;
	Thu, 29 Jul 2004 20:27: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 i6U3RMkw080621;
	Thu, 29 Jul 2004 20:27:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from pop.ironclad.net.au ([203.30.247.15])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6U3RKD2080606
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 20:27:21 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] by pop.ironclad.net.au
 with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 30 Jul 2004 13:24:15 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Fri, 30 Jul 2004 13:11:02 +1000
Subject: Re: Propose partial consensus on dates
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD2FF966.239AB%eric.scheid@ironclad.net.au>
In-Reply-To: <20040730024416.47458.qmail@web41214.mail.yahoo.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


On 30/7/04 12:44 PM, "Dare Obasanjo" <kpako@yahoo.com> wrote:

>>> I couldn't see a scenario where having modified added value.
>>> 
>> some aggregators load entries into their own database/model, and would prefer
>> to avoid the dump/parse/reload everytime they see that entry (ie. until if
>> falls off the bottom of the feed) if the XML says it hasn't actually changed.
>> 
>> 'modified' is useful for machines, 'updated' is useful for humans.
>> 
> How does modified help here if you already have updated? I am an aggregator
> author and if I was going to do what you describe I'd use the updated value
> not the modified value.

consider this sequence:

    07:50 entry created
    07:59 entry published
    08:15 typo noticed, fixed, published
    09:30 feedback arrives, major change, updated
    10:15 fubar on a link URL, fixed, published

not too unusual.

if you retrieved the feed every hour on the hour, then you would see each
distinct version ... but if you only key off <updated> then you won't know
that the link in the 09:30 version is broken (nor would you have refreshed
your cache with the typo correction of 08:15).

>Why would I re-parse the entry if no significant changes had been made?

<significant to machines> != <significant to humans>

A typo isn't significant, including typos in URLs (unless it was so
egregious that it would possibly justify a footnote). The typos in URLs I'm
thinking of would be stupid things like "htp://www.example.com/foo.html" or
"www.example.com/foo.html" or even "http://www.example.com/foo.html ".

Are you saying you would ignore such corrections?

e.



From owner-atom-syntax@mail.imc.org  Thu Jul 29 23:38: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 XAA29169
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 23:38: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 i6U3RSWD080651;
	Thu, 29 Jul 2004 20:27: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 i6U3RSrT080650;
	Thu, 29 Jul 2004 20:27: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.201])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6U3RReU080636
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 20:27:28 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id 74so31487rnl
        for <atom-syntax@imc.org>; Thu, 29 Jul 2004 20:27:34 -0700 (PDT)
Received: by 10.38.71.15 with SMTP id t15mr23449rna;
        Thu, 29 Jul 2004 20:27:34 -0700 (PDT)
Message-ID: <3f1451f50407292027201f90e1@mail.gmail.com>
Date: Thu, 29 Jul 2004 23:27:34 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Tim Bray <tim.bray@sun.com>
Subject: Re: PaceFeedEquivalence
Cc: Mark Pilgrim <pilgrim@gmail.com>, Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <ED9ED1C6-E194-11D8-B732-000A95A51C9E@sun.com>
 <14be96d30407291338435fdef6@mail.gmail.com> <BC5132DE-E1A1-11D8-B732-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 Thu, 29 Jul 2004 13:56:17 -0700, Tim Bray <tim.bray@sun.com> wrote:
> Yes.  If I have two pointers to feeds:
> 
> http://www.example.com:80/feed.atom
> http://www.Example.COM/feed.atom
> 
> I guarantee that some apps, in particular web spiders, are going to get
> very aggressive about schema-specific normalization and regard these as
> equivalent, and I don't see any reason to rule this out.  Norm?  -Tim

This example is not relevant for several reasons.

First, "Simple String Comparison" is the strictest form
of URI comparison that you can do. That is, 
as a means of determining if two atom:ids are the same
it is the strictest test possible. Your example, 
and all other ways of comparing URIs, will be looser than
"Simple String Comparison". And that means that no
matter how you compare the URIs in practice, you will
always find the ones that are the same. I believe that
would be plus for interoperability.

That is, if I am a producer and I produce two feeds
with the same entry in each but they 
have atom:ids of

   http://www.example.com:80/feed.atom

and

   http://www.Example.COM/feed.atom

respectively then as a producer I should not be suprised
if an aggregator treats them as different entries.

Second, the assertion about spiders is a bit 
odd, are you asserting there are spiders out 
there that know nothing of the Atom format
yet will try to determine the equivalence of 
'entries' based on atom:id? Or are you asserting 
there are spiders that will know of the Atom format 
and will knowingly ignore the specification?

    -joe

-- 
Joe Gregorio        http://bitworking.org



From owner-atom-syntax@mail.imc.org  Thu Jul 29 23: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 XAA00219
	for <atompub-archive@lists.ietf.org>; Thu, 29 Jul 2004 23:59:51 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6U3ngVS084865;
	Thu, 29 Jul 2004 20:49: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 i6U3ng32084864;
	Thu, 29 Jul 2004 20:49:42 -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 i6U3ngw9084846
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 20:49:42 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040730034944.38503.qmail@web41208.mail.yahoo.com>
Received: from [67.168.190.24] by web41208.mail.yahoo.com via HTTP; Thu, 29 Jul 2004 20:49:44 PDT
Date: Thu, 29 Jul 2004 20:49:44 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Propose partial consensus on dates
To: Eric Scheid <eric.scheid@ironclad.net.au>,
        Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <BD2FF966.239AB%eric.scheid@ironclad.net.au>
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>



--- Eric Scheid <eric.scheid@ironclad.net.au> wrote:

> 
> On 30/7/04 12:44 PM, "Dare Obasanjo"
> <kpako@yahoo.com> wrote:
> 
> >>> I couldn't see a scenario where having modified
> added value.
> >>> 
> >> some aggregators load entries into their own
> database/model, and would prefer
> >> to avoid the dump/parse/reload everytime they see
> that entry (ie. until if
> >> falls off the bottom of the feed) if the XML says
> it hasn't actually changed.
> >> 
> >> 'modified' is useful for machines, 'updated' is
> useful for humans.
> >> 
> > How does modified help here if you already have
> updated? I am an aggregator
> > author and if I was going to do what you describe
> I'd use the updated value
> > not the modified value.
> 
> consider this sequence:
> 
>     07:50 entry created
>     07:59 entry published
>     08:15 typo noticed, fixed, published
>     09:30 feedback arrives, major change, updated
>     10:15 fubar on a link URL, fixed, published
> 
> not too unusual.
> 
> if you retrieved the feed every hour on the hour,
> then you would see each
> distinct version ... but if you only key off
> <updated> then you won't know
> that the link in the 09:30 version is broken (nor
> would you have refreshed
> your cache with the typo correction of 08:15).
> 
> >Why would I re-parse the entry if no significant
> changes had been made?
> 
> <significant to machines> != <significant to humans>
> 
> A typo isn't significant, including typos in URLs
> (unless it was so
> egregious that it would possibly justify a
> footnote). The typos in URLs I'm
> thinking of would be stupid things like
> "htp://www.example.com/foo.html" or
> "www.example.com/foo.html" or even
> "http://www.example.com/foo.html ".
> 
> Are you saying you would ignore such corrections?

So we're back to debating the difference between
significant and insignificant changes? We might as
well start arguing about how many angels can dance on
the head of a pin. 

Fixing a bad hyperlink in a post is a significant
change to me and it is a change that affects humans
consuming the content not just machines. 

=====
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  Fri Jul 30 00:12:34 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01017
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 00: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 i6U43gAq087279;
	Thu, 29 Jul 2004 21:03: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 i6U43gml087278;
	Thu, 29 Jul 2004 21:03: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.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6U43flM087267
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 21:03:41 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id 74so32218rnl
        for <atom-syntax@imc.org>; Thu, 29 Jul 2004 21:03:48 -0700 (PDT)
Received: by 10.38.71.15 with SMTP id t15mr26363rna;
        Thu, 29 Jul 2004 21:03:48 -0700 (PDT)
Message-ID: <14be96d3040729210371142bef@mail.gmail.com>
Date: Fri, 30 Jul 2004 00:03:48 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Relative URI references
Cc: Sam Ruby <rubys@intertwingly.net>, Antone Roundy <antone@geckotribe.com>,
        atom-syntax@imc.org
In-Reply-To: <20040730031102.57711.qmail@web41212.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <20040730031102.57711.qmail@web41212.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 Thu, 29 Jul 2004 20:11:02 -0700 (PDT), Dare Obasanjo <kpako@yahoo.com> wrote:
> On the other hand, it is a
> major problem in RSS and Atom feeds today to determine
> authoritatively how to resolve relative links in
> content yet no one seems interested in discussing that
> or tackling it in the spec.

This is what I've implemented:

http://feedparser.org/docs/resolving-relative-links.html

Is this what you've implemented?  If not, what did you do differently?
 Maybe I'll update my code, and my documentation.  Then let's talk
about how to express it in the spec.

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Fri Jul 30 00:17: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 AAA01229
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 00:17: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 i6U4AcqI088667;
	Thu, 29 Jul 2004 21:10: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 i6U4AcXO088666;
	Thu, 29 Jul 2004 21:10:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6U4Ab7m088659
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 21:10:37 -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 i6U4Ahil024242
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 22:10:43 -0600 (MDT)
Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0I1N00424CXVOM@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Thu, 29 Jul 2004 22:10:43 -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 <0I1N003GTCXUL2@mail.sun.net> for atom-syntax@imc.org; Thu,
 29 Jul 2004 22:10:42 -0600 (MDT)
Date: Thu, 29 Jul 2004 21:10:59 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceFeedEquivalence
In-reply-to: <3f1451f50407292027201f90e1@mail.gmail.com>
To: Joe Gregorio <joe.gregorio@gmail.com>
Cc: Atom Syntax <atom-syntax@imc.org>, Mark Pilgrim <pilgrim@gmail.com>
Message-id: <763E5EDA-E1DE-11D8-B278-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: <ED9ED1C6-E194-11D8-B732-000A95A51C9E@sun.com>
 <14be96d30407291338435fdef6@mail.gmail.com>
 <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com>
 <3f1451f50407292027201f90e1@mail.gmail.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 Jul 29, 2004, at 8:27 PM, Joe Gregorio wrote:

>> http://www.example.com:80/feed.atom
>> http://www.Example.COM/feed.atom
>>
>> I guarantee that some apps, in particular web spiders, are going to 
>> get
>> very aggressive about schema-specific normalization and regard these 
>> as
>> equivalent, and I don't see any reason to rule this out.  Norm?  -Tim
>
> First, "Simple String Comparison" is the strictest form
> of URI comparison that you can do. That is,
> as a means of determining if two atom:ids are the same
> it is the strictest test possible. Your example,
> and all other ways of comparing URIs, will be looser than
> "Simple String Comparison". And that means that no
> matter how you compare the URIs in practice, you will
> always find the ones that are the same. I believe that
> would be plus for interoperability.

Please try again Joe.  I must be having a stupid evening, I read that 
paragraph three times and I can't figure out what you're trying to say.

> That is, if I am a producer and I produce two feeds
> with the same entry in each but they
> have atom:ids of
>
>    http://www.example.com:80/feed.atom
> and
>    http://www.Example.COM/feed.atom
>
> respectively then as a producer I should not be suprised
> if an aggregator treats them as different entries.

Right, and as a producer that would be bad practice.  The interesting 
(and not uncommon in my experience) case is when you pick those up on 
two different servers and are wondering if they're really the same.  
We're not going to *force* people to be heroic about doing 
scheme-specific comparison, but there's no point writing rules against 
it.

> Second, the assertion about spiders is a bit
> odd, are you asserting there are spiders out
> there that know nothing of the Atom format
> yet will try to determine the equivalence of
> 'entries' based on atom:id? Or are you asserting
> there are spiders that will know of the Atom format
> and will knowingly ignore the specification?

I am 100% certain that there will be atom-savvy spiders, based on the 
fact that there are already RSS-savvy spiders.  Large scale spiders 
(I've written two) go to immense lengths to spot duplicate URLs because 
there are a lot of them out there, and you can do immense amounts of 
computation in the time it takes to fetch one, so it's very 
cost-effective.  I guarantee that every serious search-engine spider on 
the planet is already doing this kind of HTTP-specific smart 
comparison.  There's no earthly reason to write a rule against it.  It 
would also be unreasonable to *require* anything smarter than string 
comparison, but as URIs get passed around the infrastructure, shit 
happens, and we shouldn't get in the way of cleanup attempts. -Tim



From owner-atom-syntax@mail.imc.org  Fri Jul 30 00:23: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 AAA01629
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 00: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 i6U4DggJ089382;
	Thu, 29 Jul 2004 21:13: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 i6U4Dgjx089381;
	Thu, 29 Jul 2004 21:13: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-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 i6U4DfhZ089367
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 21:13:42 -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 i6U4Dmil025074
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 22:13:48 -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 <0I1N00629D30HS@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Thu, 29 Jul 2004 22:13:48 -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 <0I1N003H6D2ZL2@mail.sun.net> for atom-syntax@imc.org; Thu,
 29 Jul 2004 22:13:47 -0600 (MDT)
Date: Thu, 29 Jul 2004 21:14:04 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Relative URI references
In-reply-to: <20040730031102.57711.qmail@web41212.mail.yahoo.com>
To: Dare Obasanjo <kpako@yahoo.com>
Cc: Antone Roundy <antone@geckotribe.com>, Sam Ruby <rubys@intertwingly.net>,
        atom-syntax@imc.org
Message-id: <E4DE80FC-E1DE-11D8-B278-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: <20040730031102.57711.qmail@web41212.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


I mostly agree with Dare on this one.  Putting a relative URI inside 
<atom:id> feels like bad practice to me, because there might not be an 
xml:base, and thus when you move a feed, or get it from different DNS 
aliases, you'll change the effective atom:id; and the whole reason the 
atom:id exists is to mitigate the effect of such cases.

I'm fine with relative URI references everywhere else atom specifies a 
URI, in fact I suspect there are going to be many cases where they are 
actually best practices. -Tim



From owner-atom-syntax@mail.imc.org  Fri Jul 30 00: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 AAA01713
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 00:24: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 i6U4G9Xr089771;
	Thu, 29 Jul 2004 21:16: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 i6U4G9Sa089770;
	Thu, 29 Jul 2004 21:16:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.47])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6U4G9P0089764
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 21:16:09 -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 i6U4GGGQ025240;
	Thu, 29 Jul 2004 21:16:16 -0700 (PDT)
Received: from [192.168.2.4] (68-174-94-134.ucwphilly.rr.com [68.174.94.134])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id i6U4GFLv019796;
	Thu, 29 Jul 2004 21:16:15 -0700 (PDT)
In-Reply-To: <4109B3CF.4080002@intertwingly.net>
References: <AA8A6A9C-E1CD-11D8-9043-003065EA6144@geckotribe.com> <4109B3CF.4080002@intertwingly.net>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5--962851166; protocol="application/pkcs7-signature"
Message-Id: <36D3E646-E1DF-11D8-B75F-000A95DC3D90@mac.com>
Cc: Atom Syntax <atom-syntax@imc.org>
From: Graham <dtcd@mac.com>
Subject: Re: Relative URI references
Date: Fri, 30 Jul 2004 00:16:20 -0400
To: Sam Ruby <rubys@intertwingly.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-5--962851166
Content-Type: text/plain;
	charset=ISO-2022-JP;
	format=flowed
Content-Transfer-Encoding: 7bit

Allowing relative URIs in atom:id and trusting people to get it right $B"a(B 
Removing paragraph about atom:id not working and trusting people to get 
it right

Graham
--Apple-Mail-5--962851166
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
9w0BCQUxDxcNMDQwNzMwMDQxNjIyWjAjBgkqhkiG9w0BCQQxFgQUSLG0U0DRU4BiDw6UpgI/8YJG
/qcweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1
bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAfiFeB6dDnrtoya+DnQNLQGDx
xhkdy2YGNNDhqEwM/hZVLBNYy1GkSeL2WiHZpblF8/ETCqGzHftY6k5001IBonHVAGTX6N28yuQb
lFLDkleUirhFtCrrnH6cFINT+fWxOJ6FRsT07YjOiyFXAzK5D8w1fzCxg/1nkbgLouzW1VWAcrtu
77YSibF3cCMJ/L1pDiwsqATxC3CNTXfVWM8MI9t81vzoepFLkjf+GSu5NEkigA0H5t4ryEfbfFyu
Wne8fa0fIhexok6xLmJRZ0Ls3PjOD5Tzpeuv1KKaaKUF02N/sqzUQGnr1fr9ejonRblbqAYqpQEc
3ZKihX5HDF2vCwAAAAAAAA==

--Apple-Mail-5--962851166--



From owner-atom-syntax@mail.imc.org  Fri Jul 30 00:46:30 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02518
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 00: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 i6U4ZG99093632;
	Thu, 29 Jul 2004 21:35: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 i6U4ZGEU093631;
	Thu, 29 Jul 2004 21:35:16 -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 i6U4ZEbO093586
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 21:35:15 -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 1305333 for atom-syntax@imc.org; Fri, 30 Jul 2004 14:35:09 +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 1424101 for atom-syntax@imc.org; Fri, 30 Jul 2004 14:35:08 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Fri, 30 Jul 2004 14:32:45 +1000
Subject: Re: Propose partial consensus on dates
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD300C8D.239EC%eric.scheid@ironclad.net.au>
In-Reply-To: <20040730034944.38503.qmail@web41208.mail.yahoo.com>
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 i6U4ZFbO093626
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 30/7/04 1:49 PM, "Dare Obasanjo" <kpako@yahoo.com> wrote:

> So we're back to debating the difference between
> significant and insignificant changes? We might as
> well start arguing about how many angels can dance on
> the head of a pin.

The difference is simple: it's significant if the publisher says it is,
while modified is there are *any* changes. Can't be any simpler.

We don¹t have endless debates as to what constitutes a "summary", so why do
we need to do the same for "update"? It's a subjective content-related
element, same as <title> and even <date> (aka <dateline>).

> Fixing a bad hyperlink in a post is a significant
> change to me and it is a change that affects humans
> consuming the content not just machines.

some pedants would argue that fixing "there" to be "their" is a significant
change. 

e.




From owner-atom-syntax@mail.imc.org  Fri Jul 30 01:24: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 BAA04048
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 01:24: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 i6U5DqjN004819;
	Thu, 29 Jul 2004 22:13: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 i6U5Dpc0004817;
	Thu, 29 Jul 2004 22:13:51 -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 i6U5Dplw004742
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 22:13:51 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040730051353.77810.qmail@web41204.mail.yahoo.com>
Received: from [67.170.16.45] by web41204.mail.yahoo.com via HTTP; Thu, 29 Jul 2004 22:13:53 PDT
Date: Thu, 29 Jul 2004 22:13:53 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Relative URI references
To: Mark Pilgrim <pilgrim@gmail.com>
Cc: Sam Ruby <rubys@intertwingly.net>, Antone Roundy <antone@geckotribe.com>,
        atom-syntax@imc.org
In-Reply-To: <14be96d3040729210371142bef@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:
>
> On Thu, 29 Jul 2004 20:11:02 -0700 (PDT), Dare
> Obasanjo <kpako@yahoo.com> wrote:
> > On the other hand, it is a
> > major problem in RSS and Atom feeds today to
> determine
> > authoritatively how to resolve relative links in
> > content yet no one seems interested in discussing
> that
> > or tackling it in the spec.
> 
> This is what I've implemented:
> 
>
http://feedparser.org/docs/resolving-relative-links.html
> 
> Is this what you've implemented?  If not, what did
> you do differently?
>  Maybe I'll update my code, and my documentation. 
> Then let's talk
> about how to express it in the spec.

Nope, I haven't implemented xml:base support yet. if I
do it'll probably look like that. Except I don't see
where in your documentation you describe the
precedence of html:BASE[0] in your equation. 

My big beef with xml:base in Atom is twofold 

1.) Besides content I don't see the reason for having
xml:base support for any other elements besides adding
complexity to Atom feed consumers [especially those
using streaming parsers like SAX-based ones] 

2.) There is no spec text that unambiguously lets me
know that if the content type is text/html I should
use the xml:base of the content construct as the base
URI for resolving relative links. 

[0] http://www.w3.org/TR/REC-html40/struct/links.html#h-12.4

=====
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  Fri Jul 30 01:39: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 BAA04623
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 01: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 i6U5UVla012078;
	Thu, 29 Jul 2004 22:30: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 i6U5UVvW012077;
	Thu, 29 Jul 2004 22:30:31 -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 i6U5UVuA012067
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 22:30:31 -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 A6EBC4EEF6;
	Fri, 30 Jul 2004 01:30:35 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040730141558.04c81560@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Fri, 30 Jul 2004 14:19:51 +0900
To: Tim Bray <Tim.Bray@Sun.COM>, Mark Pilgrim <pilgrim@gmail.com>
From: Martin Duerst <duerst@w3.org>
Subject: Re: PaceFeedEquivalence
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com>
References: <14be96d30407291338435fdef6@mail.gmail.com>
 <ED9ED1C6-E194-11D8-B732-000A95A51C9E@sun.com>
 <14be96d30407291338435fdef6@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 13:56 04/07/29 -0700, Tim Bray wrote:

>On Jul 29, 2004, at 1:38 PM, Mark Pilgrim wrote:
>
>>>(1) a note in both the Format and Protocol specs saying "when testing
>>>URIs for equivalence, implementors should consider the discussion in
>>>RFC2396bis section 6."  (currently
>>>http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#comparison).
>>
>>Note that this is the first time we are actively tying ourselves to
>>2396bis (as opposed to PaceUriOrItsSuccessor, which only allowed us to
>>inherit it when it was ready).
>
>Good point... it's just that 2396bis has this useful section 6 that goes 
>on and on about exactly this issue, which isn't in 2396classic at all.  On 
>the other hand if we were nearly done, and 2396bis wasn't, I'd be in favor 
>of nuking this section to get us across the finish line.

I think that section is very useful (and there is an equivalent section
in the IRI draft). However, I think what we need for consistent
behavior is a clear decision on what equivalence we are going to use,
not a pointer to an on-and-ongoing discussion.


>>Furthermore, are you rejecting Norman Walsh's proposal that "matches"
>>and "matching" be more specifically defined as per Section 6.2.1
>>"Simple String Comparison" of 2396bis?
>
>Yes.  If I have two pointers to feeds:
>
>http://www.example.com:80/feed.atom
>http://www.Example.COM/feed.atom
>
>I guarantee that some apps, in particular web spiders, are going to get 
>very aggressive about schema-specific normalization and regard these as 
>equivalent, and I don't see any reason to rule this out.  Norm?  -Tim

I think web spiders might be allowed to do this. And for those cases
where a resolution is involved, the two above will obviously get us
the same result. However, for namespaces, we have to follow the Namespace
spec, and e.g. for atom:id, simple string comparison is much more
appropriate in my view.

Regards,     Martin.




From owner-atom-syntax@mail.imc.org  Fri Jul 30 01:40: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 BAA04657
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 01:40: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 i6U5ULpY011995;
	Thu, 29 Jul 2004 22: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 i6U5ULbf011994;
	Thu, 29 Jul 2004 22:30:21 -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 i6U5UL5Z011986
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 22:30:21 -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 59B5D4F122;
	Fri, 30 Jul 2004 01:30:26 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040730124943.04b067c0@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Fri, 30 Jul 2004 13:01:23 +0900
To: Mark Baker <distobj@acm.org>, Atom-Syntax <atom-syntax@imc.org>
From: Martin Duerst <duerst@w3.org>
Subject: Re: Demonstrating persistence
In-Reply-To: <20040729152820.GP30868@markbaker.ca>
References: <14be96d30407290811b87de58@mail.gmail.com>
 <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com>
 <20040729033456.GM30868@markbaker.ca>
 <opsbvzsbpguvpchu@quark>
 <20040729134747.GN30868@markbaker.ca>
 <14be96d30407290712a692568@mail.gmail.com>
 <20040729150444.GO30868@markbaker.ca>
 <14be96d30407290811b87de58@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 11:28 04/07/29 -0400, Mark Baker wrote:

>On Thu, Jul 29, 2004 at 11:11:01AM -0400, Mark Pilgrim wrote:
> > http://www.textism.com/article/494
>
>Sh*t happens.  Luckily, it doesn't happen very often.  For every example
>like that, there's thousands of others who've had no problems.

And I very much hope that this one gets figured out in a way that
makes it clear to all the registries and registrars and whoever
else involved that that's not something that's allowed to happen.


>I don't believe that's sufficient evidence to warrant SHOULD-strength
>language against using dereferencable atom:ids.

And it's possible to construct similar problems with other schemes.
Many id-only schemes rely on DNS. So if there is a dispute about
who owns a DNS name at a certain time, both sides may be minting
ids from this name. Some other id-only schemes rely on explicit
assignement, and of course there it's also possible that the
assignement authority messes up things.

And of course with any kind of scheme, it's always possible that
somebody completely unrelated attacks you by using exactly the
same ids that you use. In that case, the resolvability may provide
an easy way for people to test who really is in controll (assuming
that IP routing isn't messed up at the same time).

Regards,    Martin.



From owner-atom-syntax@mail.imc.org  Fri Jul 30 01:40:17 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04660
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 01:40: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 i6U5UZAt012120;
	Thu, 29 Jul 2004 22:30: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 i6U5UZJU012119;
	Thu, 29 Jul 2004 22:30:35 -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 i6U5UYW0012108
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 22:30:34 -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 5A4D74EEF6;
	Fri, 30 Jul 2004 01:30:39 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040730142059.04e8fcb0@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Fri, 30 Jul 2004 14:30:24 +0900
To: Asbj=?ISO-2022-JP?B?GyRCj1MbKEI=?=n Ulsberg <asbjorn@tigerstaden.no>
From: Martin Duerst <duerst@w3.org>
Subject: Re: PaceRecommendIdScheme
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <opsbwxd9apuvpchu@quark>
References: <4.2.0.58.J.20040729172140.05b23408@localhost>
 <4.2.0.58.J.20040729172140.05b23408@localhost>
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: <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


At 20:52 04/07/29 +0200, Asbj$BS(Bn Ulsberg wrote:

>On Thu, 29 Jul 2004 17:29:14 +0900, Martin Duerst <duerst@w3.org> wrote:

>>There are other schemes that work in quite a similar way, and there
>>are still other schemes that cover other needs that other people may
>>feel is important in their applications.
>
>No one refuses anyone to use any other scheme. I just want to recommend
>one so Bob and his friends can find it easilly, and thus at a lesser cost
>and higher probability be able to generate universally unique and
>immutable ID's.

My guess is that if we just recomment a scheme, then we will
just get something hard-coded, with some assumptions that easily
may break the properties we need. We really have to get the
message out there that it's not the scheme that counts, it's
how the ids are created and maintained properly.


>>Also, at least the current definition of the newsml scheme is
>>tied to NewsML documents, and Atom isn't nor shouldn't be
>>restricted to such.
>
>That's not a big problem. As Laurent Le Meur writes[1]:
>
>   As the IPTC has already thought about a modification of the wording
>   of the RFC3085 (there is an ambiguity in some wording), removing the
>   express association between this URN and NewsML NewsItems could
>   perhaps be studied by the IPTC, if NewsML URN are of interest for a
>   broad range of users.

How long do you think it might take the IPTC to 'perhaps study if
NewsML URN are of interest for a broad range of users'? Do you
want to wait that long for the Atom spec to finish? I don't.


>>Also, Atom should not put requirements or restrictions on the newsml
>>scheme and the NewsML community.
>
>Why would it? If the NewsML community agrees and maybe even encourages
>Atom's usage of NewsML URI's, why should we refrain from using it?

Nobody is telling anybody that we should refrain from using it.
But if we make it the only scheme, or the 'recommended' scheme,
we are bound to put additional requirements and pressure on that
scheme, which may not work out well in the long range.

As a (theoretical) example, assume that currently newsml:
would be allowed to point to anything, but for certain
reasons, the IPTC wanted to change the definition so that
new ids created would only refer to NewsML items. As long
as Atom isn't depending on newsml:, they could do that
rather easily according to their needs. But if we start
to heavily rely on newsml:, we wouldn't like them to make
any kind of such change. So in essence, we infer on their
ability to move newsml: to where they want it to go for
their needs.


>>With the language above, there is a risk some blogging tools hard-code
>>newsml into their code. That would be bad.
>
>Although I don't necessarily think that it's a very good idea; why would
>that be bad, exactly?

Because some people may want to use different ids, or may
want to use different ids because their content comes from
somewhere else and already has an id.


Regards,    Martin.



From owner-atom-syntax@mail.imc.org  Fri Jul 30 01:40: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 BAA04697
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 01:40:17 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6U5UST3012039;
	Thu, 29 Jul 2004 22:30: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 i6U5US6c012038;
	Thu, 29 Jul 2004 22:30:28 -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 i6U5URXc012028
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 22:30:27 -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 5074F4F001;
	Fri, 30 Jul 2004 01:30:32 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040730141415.04b525c8@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Fri, 30 Jul 2004 14:15:06 +0900
To: Mark Pilgrim <pilgrim@gmail.com>, Tim Bray <tim.bray@sun.com>
From: Martin Duerst <duerst@w3.org>
Subject: Re: URI equivalence (was Re: PaceFeedEquivalence)
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <14be96d3040729140553887d37@mail.gmail.com>
References: <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com>
 <ED9ED1C6-E194-11D8-B732-000A95A51C9E@sun.com>
 <14be96d30407291338435fdef6@mail.gmail.com>
 <BC5132DE-E1A1-11D8-B732-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>


Hello Mark,

It would be good if your test cases were available without having
to log in on sourceforge.

Regards,    Martin.

At 17:05 04/07/29 -0400, Mark Pilgrim wrote:

>On Thu, 29 Jul 2004 13:56:17 -0700, Tim Bray <tim.bray@sun.com> wrote:
> > http://www.example.com:80/feed.atom
> > http://www.Example.COM/feed.atom
>
>This has been discussed on-list before [1], but no language has made
>it into a spec draft.
>
>By a startling coincidence, less than 8 hours ago I opened an issue
>tracker [2] on this exact issue for the feed validator.  My current
>test cases are based on the examples in section 3.2.3 of RFC 2616 [3].
>  Obviously I would be willing to amend the test cases to correspond
>with whatever "URI equivalence" rules we state in the Atom spec.
>
>[1] http://www.imc.org/atom-syntax/mail-archive/msg07662.html
>[2] 
>http://sourceforge.net/tracker/index.php?func=detail&aid=1000249&group_id=9 
>9943&atid=626803
>[3] http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.3
>
>--
>Cheers,
>-Mark



From owner-atom-syntax@mail.imc.org  Fri Jul 30 01: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 BAA05084
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 01: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 i6U5l5nb023543;
	Thu, 29 Jul 2004 22: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 i6U5l5na023542;
	Thu, 29 Jul 2004 22:47:05 -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 i6U5l5vk023533
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 22:47:05 -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 1B0D54EECC;
	Fri, 30 Jul 2004 01:47:10 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040730143145.04b4fda0@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Fri, 30 Jul 2004 14:45:24 +0900
To: elias@torrez.us
From: Martin Duerst <duerst@w3.org>
Subject: Re: PaceBasicAtomID - maybe we're done
Cc: Tim Bray <tim.bray@sun.com>, Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <905f7c9104072908344269d033@mail.gmail.com>
References: <4.2.0.58.J.20040729172524.04af9780@localhost>
 <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com>
 <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com>
 <4.2.0.58.J.20040729172524.04af9780@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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 11:34 04/07/29 -0400, Elias Torres wrote:

>Very important issues you bring up. But let's look at an anology:
>
>In databases we have primary keys, why are there different types of
>primary keys? integers, guids, etc. Why not a VARCHAR(2048)? That for
>sure will suit everone's needs.

Well, this is a very nice analogy, but it's probably backwards.
What we are asking is that everybody can select the scheme they
want, the scheme they think they understand best, and know best
how to create and maintain ids with a high chance of persistency.
Being able to chose different schemes is like being able to
chose different primary keys.


>We're talking about an optional
>element (atom:id) in a feed. If it doesn't suit "your" personal needs,
>don't use it. What I'm try to suggest is that we find a scheme that
>suits "80%" of the world, so those 80% can do really useful stuff with
>those IDs.
>
>If you don't like NewsML, tag, publicid, LSID don't use the field, its
>optional. Why does one person want to impose on others what they
>personally want to use for an id?

I have never said that everybody should use http:, and I haven't
seen anybody else on this list proposing that http: should be the
only scheme that should be allowed, or even the recommended one.
So I'm not sure whom you are criticising with the sentence above.

Also, people have already expressed their likes for NewsML,
tag, lsid, and so on, and your proposal to limit things to
a single scheme would mean that most of these people couldn't
use their favorite scheme.


>Remember the id is only an id to the
>public, not to their private systems. If you want to use an HTTP
>URI/URL, hash it and make it urn:lsid:martinduerst:HASH:1 for us who
>need something consistent.

If I think that on the system I'm setting up, I can guarantee
persistence of http: as well or better than persistence of some
other scheme, why do you think you can tell me that it will
not be consistent? How do you know? Why do you think that you
know better than me? Why do you think you need to tell me
(and others) what will work best for me?

Regards,   Martin.


> > At 20:55 04/07/28 -0400, Elias Torres wrote:
> >
> > >Tim, you are right that given the amount of time we gave this issue, I
> > >think we should not revisit everything again, but first, I see no
> > >major argument against picking a scheme, except for "best practices"
> > >to use a generic URI on things that don't even relate to identifiers
> > >and the fact that some people just don't like URNs, but besides that I
> > >have not heard a real show stopper if we were to use ONE scheme.



From owner-atom-syntax@mail.imc.org  Fri Jul 30 02:02: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 CAA08024
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 02:02: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 i6U5ssE8027451;
	Thu, 29 Jul 2004 22: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 i6U5ssYL027450;
	Thu, 29 Jul 2004 22:54:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6U5sr2O027440
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 22:54:53 -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 i6U5t0il026484
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 23:55:01 -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 <0I1N003Q6HRO5Y@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Thu, 29 Jul 2004 23:55:00 -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 <0I1N00KH3HRN3Q@mail.sun.net> for atom-syntax@imc.org; Thu,
 29 Jul 2004 23:55:00 -0600 (MDT)
Date: Thu, 29 Jul 2004 22:55:16 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Relative URI references
In-reply-to: <20040730051353.77810.qmail@web41204.mail.yahoo.com>
To: Dare Obasanjo <kpako@yahoo.com>
Cc: Antone Roundy <antone@geckotribe.com>, Mark Pilgrim <pilgrim@gmail.com>,
        atom-syntax@imc.org, Sam Ruby <rubys@intertwingly.net>
Message-id: <07EE61EA-E1ED-11D8-B278-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: <20040730051353.77810.qmail@web41204.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 Jul 29, 2004, at 10:13 PM, Dare Obasanjo wrote:
> 1.) Besides content I don't see the reason for having
> xml:base support for any other elements besides adding
> complexity to Atom feed consumers [especially those
> using streaming parsers like SAX-based ones]
>
> 2.) There is no spec text that unambiguously lets me
> know that if the content type is text/html I should
> use the xml:base of the content construct as the base
> URI for resolving relative links.

Well, this is one of my major beefs with RSS.  When I first published 
my RSS feed, I carefully used relative URIs for everything, which works 
really well since I have a complete copy of 'ongoing' on my laptop and 
all the pointers to "/ongoing/this/that/foo" work perfectly both at 
"www.tbray.org" and "localhost".  Of course, I got complaints from the 
feedvalidator, and NetNewsWire broke in several irritating ways since 
its opinion of the base URI to use in resolving these differed from 
what I thought the obvious right answer was.

So, on #1 I flatly disagree, and on #2, if that's true that's a bug in 
the spec. -Tim



From owner-atom-syntax@mail.imc.org  Fri Jul 30 02: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 CAA09624
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 02: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 i6U5sYsO027197;
	Thu, 29 Jul 2004 22:54:34 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6U5sYBh027196;
	Thu, 29 Jul 2004 22:54:34 -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 i6U5sWTx027140
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 22:54:33 -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 i6U5sZ53004655
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 00:54:35 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6U5sY0q004651;
	Fri, 30 Jul 2004 00:54:34 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom Syntax <atom-syntax@imc.org>
Subject: Aggregator date test cases
References: <BD2FF966.239AB%eric.scheid@ironclad.net.au>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 30 Jul 2004 00:54:34 -0500
In-Reply-To: <BD2FF966.239AB%eric.scheid@ironclad.net.au>
Message-ID: <m3d62e11lx.fsf@bitsko.slc.ut.us>
Lines: 152
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


Given my interpretation of the dates in the format-01 spec, here are
some test cases based on those interpretations.  I am hoping that
others who are proposing new dates or different interpretations would
take and adapt these so that we have a better idea of what is being
proposed.

Here are my interpretations of the format-01 dates, as far as my
understanding of them dating back to when Atom started.  It's not that
*my* interpretations are any more right than anyone elses, but the
spec simply doesn't say what interpreation was decided.

format-01:modified

    System modification time.  This will change any time the user
    saves the entry (even if there are no differences), any time the
    entry is copied or restored without preserving the modification
    time, or for any number of other reasons.  However, publishing
    systems should take care that this date does not change
    non-deterministically, as that will cause increased bandwith,
    consumer processing, and possibly repeated displays of the entry
    to the user.  This is more accurately the "last modified" time, as
    from the HTTP header for the entry EditURI resource.

format-01:issued
    This date should not be confused with the Dublin Core date of the
    same local-name.  This date as used by current Atom 0.3
    implementations and unchanged in format-01 is more accurately the
    "display date", a date the publishing system or user says should
    be displayed for this entry when it is presented.  The user or
    publishing system might change this date at any time, but there is
    no significance specified or associated with it changing.

format-01:created
    This is for publishers purposes.  Consumers may ignore it.


Here are some of the tests:

= Consumer tests =

CONSUMER-IGNORES-CREATED

    Subscribe to test feed [[ note to editor: reference test feed with
    creation date 1958-11-14... ]].  Confirm the date '1958-11-14'
    does not appear in any prominent location for the entry (it is ok
    if the date appears in an "advanced", "properties", or "view
    source" location).


CONSUMER-DISPLAY-DATE

    Subscribe to test feed [[ note to editor: reference dynamic test
    feed with format-01:issued 1979-03-17... ]].  Confirm the date
    '1979-03-17' appears as the displayed date for the entry.  Refresh
    the feed or wait for the feed refresh interval to pass, the date
    will have changed.  Confirm the date '1980-03-17' as the displayed
    date for the entry in the summary and/or entry views.

    Note: The consumer may or may not visibly indicate to the user
    that the entry has changed, this is not considered part of this
    test.  The tester should check the date in the summary view, if
    available, as well as re-select or navigate to the entry after it
    updates to check the new display date.

    [[ Note to test implementor: The dynamic feed should return a
    different result the second time the feed is accessed from the
    same host or to the same URI (whichever seems easier).  The
    format-01:modified datetime should be set to a datetime on or
    after the 1980-03-17 datetime to cause the "change of the entry"
    to be recognized. ]]

    [[ Note to WG: This is disputed, the RSS Bandit implementation
    preserves the first date and does not overwrite it.  Confirm
    intent. ]]

CONSUMER-DOES-NOT-SEE-MODIFIED

    Subscribe to test feed [[ note to editor: reference test with
    format-01:modified 1970-01-01 ]].  If the consumer does not
    intentionally display modification dates, confirm the date
    '1970-01-01' does not appear in any prominent location for the
    entry (it is ok if the date appears in an "advanced",
    "properties", or "view source" location, or if the consumer
    normally displays modification dates in addition to the display
    date).


CONSUMER-SEES-MODIFIED-AND-CONTENT-CHANGE

    Subscribe to test feed [[ note to editor: reference dynamic test
    feed with format-01:modified 1965-03-11... ]].  Confirm the
    content contains "This is 1965-03-11."  Refresh the feed or wait
    for the feed refresh interval to pass, the content will have
    changed.  Confirm the content contains "This is 1966-03-11."

    Note: The consumer may or may not visibly indicate to the user
    that the entry has changed, this is not considered part of this
    test.  The tester should re-select the entry after it updates to
    check the new content.

    [[ Note to test implementor: The dynamic feed should return a
    different result the second time the feed is accessed from the
    same host or to the same URI (whichever seems easier).  The
    format-01:modified datetime should be set to 1966-03-11 to cause
    the "change of the entry" to be recognized. ]]


CONSUMER-DOES-NOT-SEE-MODIFIED-CHANGE-WITHOUT-CONTENT

    Subscribe to test feed [[ note to editor: reference dynamic test
    feed with format-01:modified 1967-11-27... ]].  Confirm the
    content contains "This is 1967-11-27."  Refresh the feed or wait
    for the feed refresh interval to pass, the "modification date" has
    changed but the stored content should not have changed.  Confirm
    the content still contains "This is 1967-11-27."  If the consumer
    always indicates change when the Atom format-01:modified date
    changes, confirm that the change is indicated; if the consumer
    takes a further step to see if the content changes before
    indicating change, confirm that no change is indicated (because
    the content has not changed).

    [[ Note to test implementor: The dynamic feed should return a
    different result the second time the feed is accessed from the
    same host or to the same URI (whichever seems easier).  The
    format-01:modified datetime should be set to 1968-11-27 to cause
    the "change of the entry" to be recognized; however, some
    consumers may still perform other tests before indicating
    change. ]]


CONSUMER-DOES-NOT-SEE-CHANGE

    Subscribe to test feed [[ note to editor: reference dynamic test
    feed with format-01:modified 2000-06-14... ]].  Confirm the
    content contains "This is 2000-06-14."  Refresh the feed or wait
    for the feed refresh interval to pass, the stored content should
    not have changed.  Confirm the content still contains "This is
    2000-06-14."  If the consumer would normally indicate that an
    entry changes, confirm that it does not indicate that this entry
    has changed.

    [[ Note to test implementor: The dynamic feed should return a
    different result the second time the feed is accessed from the
    same host or to the same URI (whichever seems easier).  The
    format-01:modified datetime should be not be changed so that the
    "change of the entry" is *not* recognized.  The content of the
    second request should be different than the first. ]]


= Publisher tests =

Will follow later, sleep now.



From owner-atom-syntax@mail.imc.org  Fri Jul 30 02: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 CAA19079
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 02: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 i6U667Fr034239;
	Thu, 29 Jul 2004 23:06: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 i6U667CI034238;
	Thu, 29 Jul 2004 23:06:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6U666hP034148
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 23:06: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 7B6117C0F3; Fri, 30 Jul 2004 09:01:23 +0200 (CEST)
Date: Fri, 30 Jul 2004 08:09:51 +0200
To: "Antone Roundy" <antone@geckotribe.com>
Subject: Re: Relative URI references
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <AA8A6A9C-E1CD-11D8-9043-003065EA6144@geckotribe.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: <opsbxsqppwuvpchu@quark>
In-Reply-To: <AA8A6A9C-E1CD-11D8-9043-003065EA6144@geckotribe.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Thu, 29 Jul 2004 20:10:45 -0600, Antone Roundy <antone@geckotribe.com>  
wrote:

>> Stop there.  If we don't to keep the URI comparison rules simple, it  
>> isn't possible to do that in a valid way.  One of those would need to  
>> be absolute.
>
> ...unless at least one of them specified xml:base explicitly, for  
> example, in the first:

Why does xml:base help? Either xml:base or a Content-Location header would  
be needed to do relative resolution in any case. That does still not  
change the fact that whenever the feed or entries move, the URI base would  
change, thus creating new ID's. Allowing for relative URI's in atom:id  
basically allows for dynamic ID's, like those generated with now().  
Dynamic ID's is far beyond «a bad idea», 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 Jul 30 02:29: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 CAA20260
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 02: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 i6U6IkpG039981;
	Thu, 29 Jul 2004 23: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 i6U6IkQq039980;
	Thu, 29 Jul 2004 23:18:46 -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 i6U6Ijj1039931
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 23:18: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 645017C0F3; Fri, 30 Jul 2004 09:13:59 +0200 (CEST)
Date: Fri, 30 Jul 2004 08:22:29 +0200
To: "Sam Ruby" <rubys@intertwingly.net>
Subject: Re: PaceDates
References: <20040729182950.TQJJ29220.mta03-svc.ntlworld.com@Inbox> <opsbw3zhqruvpchu@quark> <41097577.5010200@intertwingly.net>
Cc: Atom-Syntax <atom-syntax@imc.org>
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: <opsbxtbrdbuvpchu@quark>
In-Reply-To: <41097577.5010200@intertwingly.net>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Thu, 29 Jul 2004 18:08:55 -0400, Sam Ruby <rubys@intertwingly.net>  
wrote:

>>> I realise that this is only a SHOULD, but I think that there are   
>>> sensible reasons for allowing atom:date to be in the future.
>>
>>  I think the consensus is that it's not.
>
> *sigh*

Okay. So it isn't consensus.

> RSS 2.0, Blogger, MovableType, LiveJournal, etc would indicate otherwise.

They allow for it, but for what reason? Either way, I've moved this  
«should not be in the future» into each date construct, and allowed for  
atom:date to be future.

If or when publishing tools move from the highly non-semantic atom:date to  
the more meaningful ones, it should be explicit what a future date  
actually does. If it's there to make the entry «unavailable», then the  
entry itself shouldn't be available. Hiding entries should not be up to  
the aggregators, but the publishing tools. If there are other use cases to  
have future dates, please let me know.

-- 
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 Jul 30 02:33: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 CAA20468
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 02:33: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 i6U6PG30042890;
	Thu, 29 Jul 2004 23:25: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 i6U6PGFB042889;
	Thu, 29 Jul 2004 23:25:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6U6PFXM042836
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 23:25: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 39F157C0F3; Fri, 30 Jul 2004 09:20:29 +0200 (CEST)
Date: Fri, 30 Jul 2004 08:29:00 +0200
To: "Eric Scheid" <eric.scheid@ironclad.net.au>
Subject: Re: PaceDates
References: <BD2FE620.23929%eric.scheid@ironclad.net.au>
Cc: Atom-Syntax <atom-syntax@imc.org>
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: <opsbxtmmcguvpchu@quark>
In-Reply-To: <BD2FE620.23929%eric.scheid@ironclad.net.au>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 30 Jul 2004 11:48:48 +1000, Eric Scheid  
<eric.scheid@ironclad.net.au> wrote:

> disagree there is consensus ... the question of future dates being an  
> issue hasn't been discussed at all, or only in passing.

It has been discussed in #atom, and the ones discussing it seemed to agree  
that future dates were more of a bug than a feature. At least for the more  
formal dates of 'issued', 'modified' and 'created'.

> those feeds are better dated using the (so called deprecated) 'date'
> element, not the 'issued' element. A weather feed in particular should  
> have the date the information was released in the 'issued' date, just
> so readers can know that it's 48 hours old and thus unreliable.

Not so sure about that. What makes the weather report an un-issuable item?  
Why can't 'issued' be set to when the report is published to the web?

>> The point of the text is that you shouldn't put something out on the web
>> if it's not meant to be out on the web yet
>
> some may use it as a soft embargo date, meaning its not actually official
> until that date arrives. if you happen to see it before that date then  
> you are getting a 'sneak preview'.

Where is this semantic explained? Who is supposed to understand this? No  
aggregator can, at least.

> One of my client sites has several thousand pages, which they publish by
> baking them to static files. A complete site reload takes several hours.
> They'd like to put an issued date on their press releases. They don't  
> know if the press release would be at the beginning of the reload  
> process,
> or towards the end. Thus they'll start the reload at midnight, it'll
> finish about 6am, and the press release is officially issued at 8am (not
> 6pm the prior night).

So because the publishing process takes so long time, the 'issued' is set  
in the future? Well, that's okay if you have a fairly accurate feeling  
about when the entries will become available. Remember that the  
specification says «SHOULD NOT», not «MUST NOT» («MAY» for atom:date now,  
btw). So future dates are allowed, but shouldn't be encouraged.

-- 
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 Jul 30 02:41:34 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20736
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 02:41: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 i6U6Y8lL046818;
	Thu, 29 Jul 2004 23:34: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 i6U6Y8GB046817;
	Thu, 29 Jul 2004 23:34: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 i6U6Y7rV046762
	for <atom-syntax@imc.org>; Thu, 29 Jul 2004 23:34: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 CAC607C0F3; Fri, 30 Jul 2004 09:29:21 +0200 (CEST)
Date: Fri, 30 Jul 2004 08:37:54 +0200
To: "Antone Roundy" <antone@geckotribe.com>
Subject: Re: PaceDates
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <EB08F534-E1A8-11D8-9043-003065EA6144@geckotribe.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: <opsbxt1gjeuvpchu@quark>
In-Reply-To: <EB08F534-E1A8-11D8-9043-003065EA6144@geckotribe.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Thu, 29 Jul 2004 15:47:42 -0600, Antone Roundy <antone@geckotribe.com>  
wrote:

> 'The "atom:date" element is a Date Construct giving a date associated  
> with the contents of the entry, which might not be related to events in  
> the publishing process...'

+1 and thus implemented.

> Disagreed.  I haven't noticed much general opposition to future  
> subjective dates.  But maybe I just haven't been listening.

Okay. I've changed the pace accordingly, to discourage future dates in the  
formal publishing-process related dates, but allow for it in atom:date.

> Disagreed again.  A weather forecast for next week is made "available"  
> before next week.  Next week's date seems appropriate for atom:date in  
> these kinds of cases.

Yes, that's probably correct.

> Perhaps your conception of atom:date is as nothing but a dumping ground  
> for bad data when no better data exists

Partly, yes. The reason for this is that there is no way to sum up the  
current date usage with one term or one conception. There is absolutely no  
shared semantics between the tools on what the date actually is, and  
that's why atom:date use should be discouraged, and tools should move over  
to the more semantically meaningful ones.

> but there are other potential uses for subjective dates, as has been
> pointed out here and in previous  discussion.

Yes, atom:date may of course be used as a subjective date element, but how  
do we capture that essence in the specification text and still support  
non-subjective dates as a means to cater for current usage? The date can  
today be both subjective and objective. Can we somehow state that  
atom:date SHOULD NOT be objective or tool-specified, and that objective  
dates should share the semantics of 'issued', 'modified' or 'created' and  
thus use those elements instead?

> I for one don't have a problem with it being used both for user-
> selected dates and for sticking whatever date is available when
> all the more tightly specified dates are unknown.

I agree, but as the current situation is so chaotic, I'm not sure how to  
solve this specification-wise.

-- 
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 Jul 30 03: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 DAA21681
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 03:08: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 i6U70Xbc058709;
	Fri, 30 Jul 2004 00:00: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 i6U70Xiw058708;
	Fri, 30 Jul 2004 00:00:33 -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 i6U70UYh058595
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 00:00: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 1305762 for atom-syntax@imc.org; Fri, 30 Jul 2004 17:00:18 +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 1424736 for atom-syntax@imc.org; Fri, 30 Jul 2004 17:00:18 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Fri, 30 Jul 2004 17:00:14 +1000
Subject: Re: PaceDates
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <BD302F1E.23A49%eric.scheid@ironclad.net.au>
In-Reply-To: <opsbxtmmcguvpchu@quark>
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 i6U70WYh058697
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 30/7/04 4:29 PM, "Asbjørn Ulsberg" <asbjorn@tigerstaden.no> wrote:

>> those feeds are better dated using the (so called deprecated) 'date'
>> element, not the 'issued' element. A weather feed in particular should
>> have the date the information was released in the 'issued' date, just
>> so readers can know that it's 48 hours old and thus unreliable.
> 
> Not so sure about that. What makes the weather report an un-issuable item?
> Why can't 'issued' be set to when the report is published to the web?

that's what I said, isn't it? I'm saying the weather report, as issued by
the BoM this afternoon, for this coming Sunday should have:

    <issued>2004-07-30T16:00+10:00</issued>
    <date>2004-08-01T00:00+10:00</date>

e.




From owner-atom-syntax@mail.imc.org  Fri Jul 30 07:55:19 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01237
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 07:55: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 i6UBdgaV054471;
	Fri, 30 Jul 2004 04:39: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 i6UBdgvT054470;
	Fri, 30 Jul 2004 04:39:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web41510.mail.yahoo.com (web41510.mail.yahoo.com [66.218.93.93])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6UBdfcZ054462
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 04:39:41 -0700 (PDT)
	(envelope-from randymorin@yahoo.com)
Message-ID: <20040730113937.83000.qmail@web41510.mail.yahoo.com>
Received: from [24.43.182.164] by web41510.mail.yahoo.com via HTTP; Fri, 30 Jul 2004 04:39:37 PDT
Date: Fri, 30 Jul 2004 04:39:37 -0700 (PDT)
From: Randy Charles Morin <randymorin@yahoo.com>
Reply-To: randy@kbcafe.com
Subject: Re: PaceLinkReflection - Close it 
To: Atomlist <atom-syntax@imc.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-881801535-1091187577=:80264"
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>


--0-881801535-1091187577=:80264
Content-Type: text/plain; charset=us-ascii

Asbjorn write:
>But SHOULD just says SHOULD.
Agreed. Keep it. 
 
Tim, please reword to your liking.
Thanks,
 
Randy

		
---------------------------------
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
--0-881801535-1091187577=:80264
Content-Type: text/html; charset=us-ascii

<DIV>Asbjorn write:</DIV>
<DIV>&gt;<FONT face="Courier New">But SHOULD just says SHOULD.</FONT></DIV>
<DIV>Agreed. Keep it. </DIV>
<DIV>&nbsp;</DIV>
<DIV>Tim, please reword to your liking.</DIV>
<DIV>Thanks,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Randy</DIV><p>
		<hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/mail_us/taglines/10/*http://promotions.yahoo.com/new_mail/static/efficiency.html">New and Improved Yahoo! Mail</a> - Send 10MB messages!
--0-881801535-1091187577=:80264--



From owner-atom-syntax@mail.imc.org  Fri Jul 30 08:30: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 IAA02466
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 08:30: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 i6UCJMxw056858;
	Fri, 30 Jul 2004 05:19: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 i6UCJMv8056857;
	Fri, 30 Jul 2004 05:19:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail06.svc.cra.dublin.eircom.net (mail06.svc.cra.dublin.eircom.net [159.134.118.22])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6UCJLtI056841
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 05:19:21 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 68157 messnum 2855266 invoked from network[62.77.172.85/62-77-172-85.customer.eircom.net]); 30 Jul 2004 12:15:45 -0000
Received: from 62-77-172-85.customer.eircom.net (HELO ?200.200.200.30?) (62.77.172.85)
  by mail06.svc.cra.dublin.eircom.net (qp 68157) with SMTP; 30 Jul 2004 12:15:45 -0000
Message-ID: <410A3BEF.7010801@dehora.net>
Date: Fri, 30 Jul 2004 13:15: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: Dare Obasanjo <kpako@yahoo.com>
CC: Sam Ruby <rubys@intertwingly.net>, Antone Roundy <antone@geckotribe.com>,
        atom-syntax@imc.org
Subject: Re: Relative URI references
References: <20040730031102.57711.qmail@web41212.mail.yahoo.com>
In-Reply-To: <20040730031102.57711.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:


> I'm not sure what this +1 is supposed to indicate. The
> entire xml:base support thing in Atom seems like a
> misfeature. 

+1. for ids. I can appreciate it may be useful for linking

cheers
Bill



From owner-atom-syntax@mail.imc.org  Fri Jul 30 08: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 IAA02728
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 08: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 i6UCP43M057366;
	Fri, 30 Jul 2004 05:25: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 i6UCP4hs057365;
	Fri, 30 Jul 2004 05:25:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.204])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UCP30s057359
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 05:25:03 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id 74so77720rnk
        for <atom-syntax@imc.org>; Fri, 30 Jul 2004 05:25:04 -0700 (PDT)
Received: by 10.38.2.75 with SMTP id 75mr207534rnb;
        Fri, 30 Jul 2004 05:25:04 -0700 (PDT)
Message-ID: <14be96d304073005255215e0d1@mail.gmail.com>
Date: Fri, 30 Jul 2004 08:25:04 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Martin Duerst <duerst@w3.org>
Subject: Re: URI equivalence (was Re: PaceFeedEquivalence)
Cc: Tim Bray <tim.bray@sun.com>, Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <4.2.0.58.J.20040730141415.04b525c8@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com>
 <ED9ED1C6-E194-11D8-B732-000A95A51C9E@sun.com>
 <14be96d30407291338435fdef6@mail.gmail.com>
 <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com> <4.2.0.58.J.20040730141415.04b525c8@localhost>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


On Fri, 30 Jul 2004 14:15:06 +0900, Martin Duerst <duerst@w3.org> wrote:
> It would be good if your test cases were available without having
> to log in on sourceforge.

http://feedvalidator.org/testcases/atom/must/

The specific tests in question are

http://feedvalidator.org/testcases/atom/must/entry_id_duplicate_value_2.xml
http://feedvalidator.org/testcases/atom/must/entry_id_duplicate_value_3.xml
http://feedvalidator.org/testcases/atom/must/entry_id_duplicate_value_4.xml
http://feedvalidator.org/testcases/atom/must/entry_id_duplicate_value_5.xml
http://feedvalidator.org/testcases/atom/must/entry_id_duplicate_value_6.xml
http://feedvalidator.org/testcases/atom/must/entry_id_duplicate_value_7.xml
http://feedvalidator.org/testcases/atom/must/entry_id_duplicate_value_8.xml

Note that I'm not sure the last one is a valid test.  I would
appreciate any guidance you might have on that.

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Fri Jul 30 10:14:48 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08383
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 10:14: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 i6UE6ExQ066036;
	Fri, 30 Jul 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 i6UE6EVK066035;
	Fri, 30 Jul 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 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 i6UE6DlD066029
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 07:06: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 i6UE3u53027133
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 08:03: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 <0I1O004L64IFOM@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Fri, 30 Jul 2004 08:06:16 -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 <0I1O00F1S4IF46@mail.sun.net> for atom-syntax@imc.org; Fri,
 30 Jul 2004 08:06:15 -0600 (MDT)
Date: Fri, 30 Jul 2004 07:06:31 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceLinkReflection - Close it
In-reply-to: <20040730113937.83000.qmail@web41510.mail.yahoo.com>
To: randy@kbcafe.com
Cc: Atomlist <atom-syntax@imc.org>
Message-id: <A8BDAFDA-E231-11D8-B278-000A95A51C9E@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.618)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
References: <20040730113937.83000.qmail@web41510.mail.yahoo.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6UE6ElD066030
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 Jul 30, 2004, at 4:39 AM, Randy Charles Morin wrote:

> Asbjorn write:
> >But SHOULD just says SHOULD.
> Agreed. Keep it.
>   
> Tim, please reword to your liking.

No.  It is entirely silly to say that because I set up a screen-scraper 
feed today pointing at kbcafe or the New York Times or the NSA, that 
they have any obligation in the world, no matter how slight, to point 
to me.  There is no case whatsoever for a SHOULD, this whole idea is 
just wrong. -Tim



From owner-atom-syntax@mail.imc.org  Fri Jul 30 10:24: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 KAA09584
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 10:24: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 i6UEGauF066760;
	Fri, 30 Jul 2004 07:16: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 i6UEGag1066759;
	Fri, 30 Jul 2004 07:16:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web41502.mail.yahoo.com (web41502.mail.yahoo.com [66.218.93.85])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6UEGYNm066748
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 07:16:36 -0700 (PDT)
	(envelope-from randymorin@yahoo.com)
Message-ID: <20040730141631.5294.qmail@web41502.mail.yahoo.com>
Received: from [66.46.139.106] by web41502.mail.yahoo.com via HTTP; Fri, 30 Jul 2004 07:16:31 PDT
Date: Fri, 30 Jul 2004 07:16:31 -0700 (PDT)
From: Randy Charles Morin <randymorin@yahoo.com>
Reply-To: randy@kbcafe.com
Subject: Re: PaceLinkReflection - Close it
To: Tim Bray <Tim.Bray@Sun.COM>
Cc: Atomlist <atom-syntax@imc.org>
In-Reply-To: <A8BDAFDA-E231-11D8-B278-000A95A51C9E@sun.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-275535965-1091196991=:4029"
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>


--0-275535965-1091196991=:4029
Content-Type: text/plain; charset=us-ascii

Tim, 
Nobody is saying that. But, if you could setup that feed for kbcafe anyway, I could really use the extra bandwidth ;)
 
I think there's a lot of value in encouraging reflection. It allows my browser [1] to automagically do some cool stuff in the background, w/out requiring me to cut and paste URLs or make assumptions about feed equivalence, etc. One of the reason we are doing Atom is because RSS 2.0 wasn't tight enough. Why would be loose about feed reflection and equivalence?
MHO and thanks for taking up my Paces, I really thought they were dead,
 
Randy
http://www.kbcafe.com
 
[1] - http://www.kbcafe.com/juice/

Tim Bray <Tim.Bray@Sun.COM> wrote:
On Jul 30, 2004, at 4:39 AM, Randy Charles Morin wrote:

> Asbjorn write:
> >But SHOULD just says SHOULD.
> Agreed. Keep it.
>  
> Tim, please reword to your liking.

No. It is entirely silly to say that because I set up a screen-scraper 
feed today pointing at kbcafe or the New York Times or the NSA, that 
they have any obligation in the world, no matter how slight, to point 
to me. There is no case whatsoever for a SHOULD, this whole idea is 
just wrong. -Tim

		
---------------------------------
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
--0-275535965-1091196991=:4029
Content-Type: text/html; charset=us-ascii

<DIV>Tim, </DIV>
<DIV>Nobody is saying that. But, if you could setup that feed for kbcafe anyway, I could really&nbsp;use the extra bandwidth ;)</DIV>
<DIV>&nbsp;</DIV>
<DIV>I think there's a lot of value in&nbsp;encouraging reflection. It allows my browser [1] to automagically do some cool stuff in the background, w/out requiring me to cut and paste URLs or make assumptions about feed equivalence, etc. One of the reason we are doing Atom is because RSS 2.0 wasn't tight enough. Why would be loose about feed reflection and equivalence?</DIV>
<DIV>MHO and thanks for taking up my Paces, I really thought they were dead,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Randy</DIV>
<DIV><A href="http://www.kbcafe.com">http://www.kbcafe.com</A></DIV>
<DIV>&nbsp;</DIV>
<DIV>[1] - <A href="http://www.kbcafe.com/juice/">http://www.kbcafe.com/juice/</A><BR><BR><B><I>Tim Bray &lt;Tim.Bray@Sun.COM&gt;</I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">On Jul 30, 2004, at 4:39 AM, Randy Charles Morin wrote:<BR><BR>&gt; Asbjorn write:<BR>&gt; &gt;But SHOULD just says SHOULD.<BR>&gt; Agreed. Keep it.<BR>&gt; &nbsp;<BR>&gt; Tim, please reword to your liking.<BR><BR>No. It is entirely silly to say that because I set up a screen-scraper <BR>feed today pointing at kbcafe or the New York Times or the NSA, that <BR>they have any obligation in the world, no matter how slight, to point <BR>to me. There is no case whatsoever for a SHOULD, this whole idea is <BR>just wrong. -Tim<BR></BLOCKQUOTE><p>
		<hr size=1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/mail_us/taglines/50x/*http://promotions.yahoo.com/new_mail/static/efficiency.html">Yahoo! Mail</a> - 50x more storage than other providers!
--0-275535965-1091196991=:4029--



From owner-atom-syntax@mail.imc.org  Fri Jul 30 10:36: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 KAA10798
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 10:35: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 i6UENspF067434;
	Fri, 30 Jul 2004 07:23:54 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6UENsAJ067433;
	Fri, 30 Jul 2004 07:23:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UENr47067425
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 07:23:53 -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 i6UENuil028706
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 08:23: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 <0I1O004JN5BVOM@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Fri, 30 Jul 2004 08:23:56 -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 <0I1O00CIY5BRE1@mail.sun.net> for atom-syntax@imc.org; Fri,
 30 Jul 2004 08:23:52 -0600 (MDT)
Date: Fri, 30 Jul 2004 07:24:09 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceLinkReflection - Close it
In-reply-to: <20040730141631.5294.qmail@web41502.mail.yahoo.com>
To: randy@kbcafe.com
Cc: Atomlist <atom-syntax@imc.org>
Message-id: <1EDD60B7-E234-11D8-B278-000A95A51C9E@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.618)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
References: <20040730141631.5294.qmail@web41502.mail.yahoo.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6UENr47067426
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 Jul 30, 2004, at 7:16 AM, Randy Charles Morin wrote:

> Tim,
>  Nobody is saying that.

Yes, that's exactly what the Pace says.  It says that if there's an 
atom feed with <atom:link rel="alternate"> anywhere in the universe, 
authored by anybody, accurate or not, friendly or not, pointing at some 
HTML page, than that HTML page SHOULD point back at the atom feed.  
Which I think is entirely unreasonable.

> I think there's a lot of value in encouraging reflection.

There's a lot of value in feed autodiscovery, thus the discussion 
around MarkP's RFC.  But the decision as to which feed is 
autodiscovered out of some HTML is entirely up to the author of the 
HTML.  You would be silly not to use autodiscovery if you were able and 
you had a feed you wanted to promote.  But you have no obligation 
("SHOULD") whatever. -Tim




From owner-atom-syntax@mail.imc.org  Fri Jul 30 10:45: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 KAA11530
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 10:45: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 i6UEbTmb068372;
	Fri, 30 Jul 2004 07: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 i6UEbTXr068371;
	Fri, 30 Jul 2004 07:37:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web41506.mail.yahoo.com (web41506.mail.yahoo.com [66.218.93.89])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6UEbTlS068359
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 07:37:29 -0700 (PDT)
	(envelope-from randymorin@yahoo.com)
Message-ID: <20040730143726.11105.qmail@web41506.mail.yahoo.com>
Received: from [66.46.139.106] by web41506.mail.yahoo.com via HTTP; Fri, 30 Jul 2004 07:37:26 PDT
Date: Fri, 30 Jul 2004 07:37:26 -0700 (PDT)
From: Randy Charles Morin <randymorin@yahoo.com>
Reply-To: randy@kbcafe.com
Subject: Re: PaceLinkReflection - Close it
To: Tim Bray <Tim.Bray@Sun.COM>
Cc: Atomlist <atom-syntax@imc.org>
In-Reply-To: <1EDD60B7-E234-11D8-B278-000A95A51C9E@sun.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1891945403-1091198246=:9379"
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>


--0-1891945403-1091198246=:9379
Content-Type: text/plain; charset=us-ascii

What if I included context like this...
 
Where the feed and Web page are published together, the feed should point to the Web page and the Web page to the feed.
 
We can work on exact wording later, just an idea for now.
Thanks,
 
Randy
http://www.kbcafe.com

Tim Bray <Tim.Bray@Sun.COM> wrote:

On Jul 30, 2004, at 7:16 AM, Randy Charles Morin wrote:

> Tim,
> Nobody is saying that.

Yes, that's exactly what the Pace says. It says that if there's an 
atom feed with anywhere in the universe, 
authored by anybody, accurate or not, friendly or not, pointing at some 
HTML page, than that HTML page SHOULD point back at the atom feed. 
Which I think is entirely unreasonable.

> I think there's a lot of value in encouraging reflection.

There's a lot of value in feed autodiscovery, thus the discussion 
around MarkP's RFC. But the decision as to which feed is 
autodiscovered out of some HTML is entirely up to the author of the 
HTML. You would be silly not to use autodiscovery if you were able and 
you had a feed you wanted to promote. But you have no obligation 
("SHOULD") whatever. -Tim


		
---------------------------------
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
--0-1891945403-1091198246=:9379
Content-Type: text/html; charset=us-ascii

<DIV>What if I included context like this...</DIV>
<DIV>&nbsp;</DIV>
<DIV>Where the feed and Web page are published together, the feed should point to the Web page and the Web page to the feed.</DIV>
<DIV>&nbsp;</DIV>
<DIV>We can work on exact wording later, just an idea for now.</DIV>
<DIV>Thanks,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Randy</DIV>
<DIV><A href="http://www.kbcafe.com">http://www.kbcafe.com</A><BR><BR><B><I>Tim Bray &lt;Tim.Bray@Sun.COM&gt;</I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid"><BR>On Jul 30, 2004, at 7:16 AM, Randy Charles Morin wrote:<BR><BR>&gt; Tim,<BR>&gt; Nobody is saying that.<BR><BR>Yes, that's exactly what the Pace says. It says that if there's an <BR>atom feed with <atom:link rel="alternate">anywhere in the universe, <BR>authored by anybody, accurate or not, friendly or not, pointing at some <BR>HTML page, than that HTML page SHOULD point back at the atom feed. <BR>Which I think is entirely unreasonable.<BR><BR>&gt; I think there's a lot of value in&nbsp;encouraging reflection.<BR><BR>There's a lot of value in feed autodiscovery, thus the discussion <BR>around MarkP's RFC. But the decision as to which feed is <BR>autodiscovered out of some HTML is entirely up to the author of the <BR>HTML. You would be silly not to use autodiscovery if you were able and <BR>you had a feed you wanted to promote. But you have no obligation <BR>("SHOULD") wha!
 tever.
 -Tim<BR><BR></BLOCKQUOTE></atom:link><p>
		<hr size=1>Do you Yahoo!?<br>
Yahoo! Mail is new and improved - <a href="http://us.rd.yahoo.com/mail_us/taglines/new/*http://promotions.yahoo.com/new_mail">Check it out!</a>
--0-1891945403-1091198246=:9379--



From owner-atom-syntax@mail.imc.org  Fri Jul 30 11:17: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 LAA14007
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 11:17: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 i6UF08Gp069528;
	Fri, 30 Jul 2004 08:00: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 i6UF08XC069527;
	Fri, 30 Jul 2004 08:00:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from localhost.localdomain (68-22-85-68.ded.ameritech.net [68.22.85.68])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UF07wb069521
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 08:00:07 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net ([65.85.192.194])
	by localhost.localdomain (8.12.8/8.12.8) with ESMTP id i6UEsVgm031259;
	Fri, 30 Jul 2004 10:54:33 -0400
Received: from *Unknown*-port10-SMSHGIBEAVERTON[10.42.1.27] by SMSHGIBEAVERTON[65.85.192.194]; Fri, 30 Jul 2004 10:39:50 -0000 (???)
Message-ID: <410A626E.1030700@intertwingly.net>
Date: Fri, 30 Jul 2004 10:59:58 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <Tim.Bray@Sun.COM>
CC: Atomlist <atom-syntax@imc.org>
Subject: Re: PaceLinkReflection - Close it
References: <20040730141631.5294.qmail@web41502.mail.yahoo.com> <1EDD60B7-E234-11D8-B278-000A95A51C9E@sun.com>
In-Reply-To: <1EDD60B7-E234-11D8-B278-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:
> 
>> I think there's a lot of value in encouraging reflection.
> 
> There's a lot of value in feed autodiscovery, thus the discussion around 
> MarkP's RFC.  But the decision as to which feed is autodiscovered out of 
> some HTML is entirely up to the author of the HTML.  You would be silly 
> not to use autodiscovery if you were able and you had a feed you wanted 
> to promote.  But you have no obligation ("SHOULD") whatever. -Tim

There is a lot of value in ETAGS, but the word is not getting out to 
everywhere it SHOULD.  This is an optional feature of HTTP, one that is 
crucial to the use case of feeds.

In this case, there is a lot of information out there on the internet on 
this topic.  Some of it is quite good, others are vague, contradictory, 
and none of it is authoritative.

I'm not sure how best to solve this problem, but putting a SHOULD in the 
document is the best solution I've seen to date.

For reference, here is the definition of SHOULD in RFC 2119:

    SHOULD   This word, or the adjective "RECOMMENDED", mean that there
    may exist valid reasons in particular circumstances to ignore a
    particular item, but the full implications must be understood and
    carefully weighed before choosing a different course.

Even though there doesn't appear that RFC 2119 treats SHOULD any 
different than RECOMMENDED, is there a difference in connotation that 
would help here?

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Fri Jul 30 11:26: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 LAA14427
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 11:26: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 i6UFAeKR070591;
	Fri, 30 Jul 2004 08:10:40 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6UFAedR070590;
	Fri, 30 Jul 2004 08:10:40 -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 i6UFAdFg070576
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 08:10:40 -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 <200407301510370110004p9ne>; Fri, 30 Jul 2004 15:10:37 +0000
Date: Fri, 30 Jul 2004 09:10:36 -0600
Subject: Re: Relative URI references
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: <opsbxsqppwuvpchu@quark>
Message-Id: <9BFE6EB2-E23A-11D8-BDD2-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 i6UFAeFg070585
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 Friday, July 30, 2004, at 12:09  AM, Asbjørn Ulsberg wrote:
> On Thu, 29 Jul 2004 20:10:45 -0600, Antone Roundy 
> <antone@geckotribe.com> wrote:
>>> Stop there.  If we don't to keep the URI comparison rules simple, it 
>>> isn't possible to do that in a valid way.  One of those would need 
>>> to be absolute.
>>
>> ...unless at least one of them specified xml:base explicitly, for 
>> example, in the first:
>
> Why does xml:base help? Either xml:base or a Content-Location header 
> would be needed to do relative resolution in any case. That does still 
> not change the fact that whenever the feed or entries move, the URI 
> base would change, thus creating new ID's. Allowing for relative URI's 
> in atom:id basically allows for dynamic ID's, like those generated 
> with now(). Dynamic ID's is far beyond «a bad idea», imho.
>
This has nothing to do with the entries moving.  As long as xml:base 
continues to point to the old base URI, the atom:id's won't be changed. 
  What you're talking about it the problem with atom:id being 
deferencable, not with using xml:base to avoid repeating the same base 
portion of the URI in each id (or whatever other reasons it might be 
used for).

For the record, I'm not arguing either way on whether relative URIs 
should be allowed in atom:id.  The question of how to do relative URIs 
for entries that appear in feeds in multiple locations came up, and I 
suggested a solution--no editorializing was intended.



From owner-atom-syntax@mail.imc.org  Fri Jul 30 11:45: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 LAA15185
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 11:45: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 i6UFVOkY072588;
	Fri, 30 Jul 2004 08:31: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 i6UFVOAh072587;
	Fri, 30 Jul 2004 08:31: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 i6UFVNhj072580
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 08:31: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 i6UFVQil000353
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 09:31:26 -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 <0I1O006TO8GDHS@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Fri, 30 Jul 2004 09:31: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 <0I1O00FLQ8GD46@mail.sun.net> for atom-syntax@imc.org; Fri,
 30 Jul 2004 09:31:25 -0600 (MDT)
Date: Fri, 30 Jul 2004 08:31:42 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceLinkReflection - Close it
In-reply-to: <410A626E.1030700@intertwingly.net>
To: Sam Ruby <rubys@intertwingly.net>
Cc: Atomlist <atom-syntax@imc.org>
Message-id: <8F1E1DF1-E23D-11D8-B278-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: <20040730141631.5294.qmail@web41502.mail.yahoo.com>
 <1EDD60B7-E234-11D8-B278-000A95A51C9E@sun.com>
 <410A626E.1030700@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 Jul 30, 2004, at 7:59 AM, Sam Ruby wrote:

>>> I think there's a lot of value in encouraging reflection.
>> There's a lot of value in feed autodiscovery, thus the discussion 
>> around MarkP's RFC.  But the decision as to which feed is 
>> autodiscovered out of some HTML is entirely up to the author of the 
>> HTML.  You would be silly not to use autodiscovery if you were able 
>> and you had a feed you wanted to promote.  But you have no obligation 
>> ("SHOULD") whatever. -Tim
...
> I'm not sure how best to solve this problem, but putting a SHOULD in 
> the document is the best solution I've seen to date.

OK, but someone has to come up with language to make it clear that this 
is a recommended good practice only in the case where the publisher 
wants to direct traffic to the feed.  I am quite convinced that there 
will be lots of parasitic, "third voice", or "opposing viewpoints" 
feeds out there in the world, and the SHOULD clearly doesn't apply to 
them.   -Tim



From owner-atom-syntax@mail.imc.org  Fri Jul 30 11:58: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 LAA15876
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 11:58: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 i6UFjtDx074218;
	Fri, 30 Jul 2004 08:45: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 i6UFjtlp074217;
	Fri, 30 Jul 2004 08:45: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.203])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UFjtM6074209
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 08:45:55 -0700 (PDT)
	(envelope-from joe.gregorio@gmail.com)
Received: by mproxy.gmail.com with SMTP id 73so61486rnl
        for <atom-syntax@imc.org>; Fri, 30 Jul 2004 08:45:49 -0700 (PDT)
Received: by 10.38.92.11 with SMTP id p11mr39076rnb;
        Fri, 30 Jul 2004 08:45:49 -0700 (PDT)
Message-ID: <3f1451f504073008454ca5f9b6@mail.gmail.com>
Date: Fri, 30 Jul 2004 11:45:49 -0400
From: Joe Gregorio <joe.gregorio@gmail.com>
To: Tim Bray <tim.bray@sun.com>
Subject: Re: PaceFeedEquivalence
Cc: Atom Syntax <atom-syntax@imc.org>, Mark Pilgrim <pilgrim@gmail.com>
In-Reply-To: <763E5EDA-E1DE-11D8-B278-000A95A51C9E@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <ED9ED1C6-E194-11D8-B732-000A95A51C9E@sun.com>
 <14be96d30407291338435fdef6@mail.gmail.com>
 <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com>
 <3f1451f50407292027201f90e1@mail.gmail.com> <763E5EDA-E1DE-11D8-B278-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 Thu, 29 Jul 2004 21:10:59 -0700, Tim Bray <tim.bray@sun.com> wrote:
> On Jul 29, 2004, at 8:27 PM, Joe Gregorio wrote:
> 
> >> http://www.example.com:80/feed.atom
> >> http://www.Example.COM/feed.atom
> >>
> >> I guarantee that some apps, in particular web spiders, are going to
> >> get
> >> very aggressive about schema-specific normalization and regard these
> >> as
> >> equivalent, and I don't see any reason to rule this out.  Norm?  -Tim
> >
> > First, "Simple String Comparison" is the strictest form
> > of URI comparison that you can do. That is,
> > as a means of determining if two atom:ids are the same
> > it is the strictest test possible. Your example,
> > and all other ways of comparing URIs, will be looser than
> > "Simple String Comparison". And that means that no
> > matter how you compare the URIs in practice, you will
> > always find the ones that are the same. I believe that
> > would be plus for interoperability.
> 
> Please try again Joe.  I must be having a stupid evening, I read that
> paragraph three times and I can't figure out what you're trying to say.
> 

> I am 100% certain that there will be atom-savvy spiders, based on the
> fact that there are already RSS-savvy spiders.  Large scale spiders
> (I've written two) go to immense lengths to spot duplicate URLs because
> there are a lot of them out there, and you can do immense amounts of
> computation in the time it takes to fetch one, so it's very
> cost-effective.  I guarantee that every serious search-engine spider on
> the planet is already doing this kind of HTTP-specific smart
> comparison.  There's no earthly reason to write a rule against it.  It
> would also be unreasonable to *require* anything smarter than string
> comparison, but as URIs get passed around the infrastructure, shit
> happens, and we shouldn't get in the way of cleanup attempts. -Tim
> 

I'll answer both of the above with a question: What kind of 
URI normalizations should be used when comparing
atom:id URIs for equivalence?

"Case Normalization"
"Percent-Encoding Normalization"
"Path Segment Normalization"
"Scheme-based Normalization"
"Protocol-based Normalization"

That is for the *consumer* side of 
atom:id. On the producer side should
we suggest/require the canonical form
of URIs[1]? And if so should we
augment that canonicalization
to include a unicode normalization form?

    -joe

[1] http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#canonical-form

-- 
Joe Gregorio        http://bitworking.org



From owner-atom-syntax@mail.imc.org  Fri Jul 30 12:23: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 MAA17052
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 12:23: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 i6UGC4rN076202;
	Fri, 30 Jul 2004 09:12: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 i6UGC4eO076201;
	Fri, 30 Jul 2004 09:12:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from localhost.localdomain (68-22-85-68.ded.ameritech.net [68.22.85.68])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UGC3HH076195
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 09:12:03 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net ([65.85.192.194])
	by localhost.localdomain (8.12.8/8.12.8) with ESMTP id i6UG6Sgm031520;
	Fri, 30 Jul 2004 12:06:28 -0400
Received: from *Unknown*-port10-SMSHGIBEAVERTON[10.42.1.27] by SMSHGIBEAVERTON[65.85.192.194]; Fri, 30 Jul 2004 11:51:46 -0000 (???)
Message-ID: <410A734D.4020402@intertwingly.net>
Date: Fri, 30 Jul 2004 12:11:57 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <Tim.Bray@Sun.COM>
CC: Atomlist <atom-syntax@imc.org>
Subject: Re: PaceLinkReflection - Close it
References: <20040730141631.5294.qmail@web41502.mail.yahoo.com> <1EDD60B7-E234-11D8-B278-000A95A51C9E@sun.com> <410A626E.1030700@intertwingly.net> <8F1E1DF1-E23D-11D8-B278-000A95A51C9E@sun.com>
In-Reply-To: <8F1E1DF1-E23D-11D8-B278-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 Jul 30, 2004, at 7:59 AM, Sam Ruby wrote:
> 
>>>> I think there's a lot of value in encouraging reflection.
>>>
>>> There's a lot of value in feed autodiscovery, thus the discussion 
>>> around MarkP's RFC.  But the decision as to which feed is 
>>> autodiscovered out of some HTML is entirely up to the author of the 
>>> HTML.  You would be silly not to use autodiscovery if you were able 
>>> and you had a feed you wanted to promote.  But you have no obligation 
>>> ("SHOULD") whatever. -Tim
> 
> ...
> 
>> I'm not sure how best to solve this problem, but putting a SHOULD in 
>> the document is the best solution I've seen to date.
> 
> OK, but someone has to come up with language to make it clear that this 
> is a recommended good practice only in the case where the publisher 
> wants to direct traffic to the feed.  I am quite convinced that there 
> will be lots of parasitic, "third voice", or "opposing viewpoints" feeds 
> out there in the world, and the SHOULD clearly doesn't apply to them.   

Just thinking it through out loud.

Person X is controversial.  Person Y presents an alternative view.
X.atom has a <link rel="alternate" href="X.html"> in atom:head
Y.atom has a <link rel="alternate" href="Y.html"> in atom:head
Y.atom has a <a href="X.html"> in atom:content

What should the recommendations be?

X.html should have a <link rel="alternate" href="X.atom"> in html:head
Y.html should have a <link rel="alternate" href="Y.atom"> in html:head

Nothing more.  In particular, X has no obligation, however slight, to 
include any reference to Y.

If we can agree to that general concept, we can work on the wording. 
The pace said:

   the atom:feed element with type="alternate" points to an HTML page

Well, atom:feed elements don't have a type attribute.  And "points to" 
is a bit vague.  In the current draft, we are specifically talking about 
the URI contained in the atom:link element defined in section 4.2.2 
where the type is "text/html" or "application/xhtml+xml" and the 
rel="alternate".  The resource that that URI identifies SHOULD contain 
an autodiscovery link specifying this feed.

- Sam Ruby




From owner-atom-syntax@mail.imc.org  Fri Jul 30 13:29:39 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20720
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 13:29: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 i6UHKNNv080451;
	Fri, 30 Jul 2004 10: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 i6UHKNa3080450;
	Fri, 30 Jul 2004 10:20:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from localhost.localdomain (68-22-85-68.ded.ameritech.net [68.22.85.68])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UHKMGj080444
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 10:20:22 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net ([65.85.192.194])
	by localhost.localdomain (8.12.8/8.12.8) with ESMTP id i6UHElgm031774
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 13:14:48 -0400
Received: from *Unknown*-port10-SMSHGIBEAVERTON[10.42.1.27] by SMSHGIBEAVERTON[65.85.192.194]; Fri, 30 Jul 2004 13:00:06 -0000 (???)
Message-ID: <410A8357.3030403@intertwingly.net>
Date: Fri, 30 Jul 2004 13:20:23 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Atomlist <atom-syntax@imc.org>
Subject: Re: PaceLinkReflection - Close it
References: <20040730141631.5294.qmail@web41502.mail.yahoo.com> <1EDD60B7-E234-11D8-B278-000A95A51C9E@sun.com> <410A626E.1030700@intertwingly.net> <8F1E1DF1-E23D-11D8-B278-000A95A51C9E@sun.com> <410A734D.4020402@intertwingly.net>
In-Reply-To: <410A734D.4020402@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:

> 
> Tim Bray wrote:
> 
>> On Jul 30, 2004, at 7:59 AM, Sam Ruby wrote:
>>
>>>>> I think there's a lot of value in encouraging reflection.
>>>>
>>>>
>>>> There's a lot of value in feed autodiscovery, thus the discussion 
>>>> around MarkP's RFC.  But the decision as to which feed is 
>>>> autodiscovered out of some HTML is entirely up to the author of the 
>>>> HTML.  You would be silly not to use autodiscovery if you were able 
>>>> and you had a feed you wanted to promote.  But you have no 
>>>> obligation ("SHOULD") whatever. -Tim
>>
>>
>> ...
>>
>>> I'm not sure how best to solve this problem, but putting a SHOULD in 
>>> the document is the best solution I've seen to date.
>>
>>
>> OK, but someone has to come up with language to make it clear that 
>> this is a recommended good practice only in the case where the 
>> publisher wants to direct traffic to the feed.  I am quite convinced 
>> that there will be lots of parasitic, "third voice", or "opposing 
>> viewpoints" feeds out there in the world, and the SHOULD clearly 
>> doesn't apply to them.   
> 
> 
> Just thinking it through out loud.
> 
> Person X is controversial.  Person Y presents an alternative view.
> X.atom has a <link rel="alternate" href="X.html"> in atom:head
> Y.atom has a <link rel="alternate" href="Y.html"> in atom:head
> Y.atom has a <a href="X.html"> in atom:content
> 
> What should the recommendations be?
> 
> X.html should have a <link rel="alternate" href="X.atom"> in html:head
> Y.html should have a <link rel="alternate" href="Y.atom"> in html:head
> 
> Nothing more.  In particular, X has no obligation, however slight, to 
> include any reference to Y.
> 
> If we can agree to that general concept, we can work on the wording. The 
> pace said:
> 
>   the atom:feed element with type="alternate" points to an HTML page
> 
> Well, atom:feed elements don't have a type attribute.  And "points to" 
> is a bit vague.  In the current draft, we are specifically talking about 
> the URI contained in the atom:link element defined in section 4.2.2 
> where the type is "text/html" or "application/xhtml+xml" and the 
> rel="alternate".  The resource that that URI identifies SHOULD contain 
> an autodiscovery link specifying this feed.

On further reflection, the last sentence should read:

The URI SHOULD identify a resource that contains an autodiscovery link 
specifying this feed.

Hopefully, this addresses Tim's concern.  Only people who produce feeds 
have a (weak) obligation.  And if they fail to meet that obligation, 
then it is their failing, not the producer of any other resource.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Fri Jul 30 13:32:46 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20776
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 13:32: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 i6UHLxTB080915;
	Fri, 30 Jul 2004 10:21: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 i6UHLx6g080914;
	Fri, 30 Jul 2004 10:21: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 i6UHLwua080906
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 10:21:59 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id 74so97927rnk
        for <atom-syntax@imc.org>; Fri, 30 Jul 2004 10:21:56 -0700 (PDT)
Received: by 10.38.9.5 with SMTP id 5mr212146rni;
        Fri, 30 Jul 2004 10:21:56 -0700 (PDT)
Message-ID: <14be96d3040730102157e3a17e@mail.gmail.com>
Date: Fri, 30 Jul 2004 13:21:56 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Joe Gregorio <joe.gregorio@gmail.com>
Subject: Re: PaceFeedEquivalence
Cc: Tim Bray <tim.bray@sun.com>, Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <3f1451f504073008454ca5f9b6@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <ED9ED1C6-E194-11D8-B732-000A95A51C9E@sun.com>
 <14be96d30407291338435fdef6@mail.gmail.com>
 <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com>
 <3f1451f50407292027201f90e1@mail.gmail.com> <763E5EDA-E1DE-11D8-B278-000A95A51C9E@sun.com> <3f1451f504073008454ca5f9b6@mail.gmail.com>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


On Fri, 30 Jul 2004 11:45:49 -0400, Joe Gregorio <joe.gregorio@gmail.com> wrote:
> What kind of
> URI normalizations should be used when comparing
> atom:id URIs for equivalence?

All of them except protocol normalization, which requires resource
retrieval to verify equivalence.

> "Case Normalization"

See http://feedvalidator.org/testcases/atom/must/entry_id_duplicate_value_5.xml

> "Percent-Encoding Normalization"

See http://feedvalidator.org/testcases/atom/must/entry_id_duplicate_value_6.xml
and http://feedvalidator.org/testcases/atom/must/entry_id_duplicate_value_7.xml

> "Path Segment Normalization"

See http://feedvalidator.org/testcases/atom/must/entry_id_duplicate_value_2.xml

> "Scheme-based Normalization"

See http://feedvalidator.org/testcases/atom/must/entry_id_duplicate_value_3.xml
and http://feedvalidator.org/testcases/atom/must/entry_id_duplicate_value_4.xml

> "Protocol-based Normalization"

No, because this requires retrieval.

Also, I wonder about
http://feedvalidator.org/testcases/atom/must/entry_id_duplicate_value_8.xml
where two URIs differ only by Unicode normalization form after being
un-percent-encoded.  Are these two URIs the same or different?

> That is for the *consumer* side of
> atom:id. On the producer side should
> we suggest/require the canonical form
> of URIs[1]?

I can definitely see us adding informational messages to the feed
validator to check for variations of these.

> And if so should we
> augment that canonicalization
> to include a unicode normalization form?

An excellent question.  Tim?

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Fri Jul 30 13:35: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 NAA20898
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 13:35:07 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UHRjbK081585;
	Fri, 30 Jul 2004 10: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 i6UHRjld081584;
	Fri, 30 Jul 2004 10:27: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 i6UHRipI081577
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 10:27:44 -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 KAA02311
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 10:27:43 -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 KAA18272
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 10:27:42 -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, 30 Jul 2004 10:27:41 -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 <0I1O00IAPDU301@shazam.verity.com> for atom-syntax@imc.org; Fri,
 30 Jul 2004 10:27:41 -0700 (PDT)
Date: Fri, 30 Jul 2004 10:27:39 -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: PaceDates
In-reply-to: <opsbxt1gjeuvpchu@quark>
To: Atom-Syntax <atom-syntax@imc.org>
Message-id: 
 <0923D16D8E7A4D65D7927A8A@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: <EB08F534-E1A8-11D8-9043-003065EA6144@geckotribe.com>
 <opsbxt1gjeuvpchu@quark>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6UHRipI081579
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 Friday, July 30, 2004 8:37 AM +0200 Asbjørn Ulsberg <asbjorn@tigerstaden.no> wrote:
>> Disagreed.  I haven't noticed much general opposition to future
>> subjective dates.  But maybe I just haven't been listening.
>
> Okay. I've changed the pace accordingly, to discourage future dates in
> the  formal publishing-process related dates, but allow for it in atom:date.

We cannot talk about future dates without choosing a reference
clock. Server or client? HTTP header dates? An NTP stratum 1 clock?

NNTP got this wrong, using a client date to select server-dated
items, so articles are consistently missed or double-fetched,
depending on the sign of the clock skew.

Without a reference clock, "there's no future, we mean it, man".

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Fri Jul 30 13:37: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 NAA21004
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 13:37: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 i6UHRQ0u081554;
	Fri, 30 Jul 2004 10:27: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 i6UHRPpb081553;
	Fri, 30 Jul 2004 10:27:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from dns03.mail.yahoo.co.jp (dns03.mail.yahoo.co.jp [211.14.15.206])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6UHROYN081539
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 10:27:24 -0700 (PDT)
	(envelope-from torumyax@yahoo.co.jp)
Received: from unknown (HELO yahoo.co.jp) (210.151.150.2 with poptime)
  by dns03.mail.yahoo.co.jp with SMTP; 30 Jul 2004 17:27:05 -0000
X-Apparently-From: <torumyax@yahoo.co.jp>
From: Toru Marumoto <torumyax@yahoo.co.jp>
To: atom-syntax@imc.org
Subject: Re: Relative URI references
Date: Sat, 31 Jul 2004 02:26:53 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: TuruKame 3.63
In-Reply-To: <14be96d304072913474dccacec@mail.gmail.com>
References: <14be96d304072913474dccacec@mail.gmail.com>
Message-Id: <58C4765A67D790torumyax@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



>
>My Universal Feed Parser [1] supports relative URIs correctly.  That
>plus BottomFeeder gives us two independent implementations, which
>counts as rough consensus and running code.  

Actually, I just tested in BottomFeeder. I see it's having some problem handling relative
URIs. When I try to navigate to the original page, a dialog shows up; "No Link Provided".
I tested other atom feeds that uses abusolute URIs, and there was no problem.

I just don't see any benefits of using relative URIs in atom:link. IMHO, of cource.



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 Jul 30 13:43: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 NAA21139
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 13:43: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 i6UHRppf081594;
	Fri, 30 Jul 2004 10:27: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 i6UHRpY1081593;
	Fri, 30 Jul 2004 10:27:51 -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 i6UHRpGt081587
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 10:27:51 -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 i6UHRs4Q030396;
	Fri, 30 Jul 2004 10:27:54 -0700
Received: from ussjex01.amer.bea.com ([172.16.120.50]) by ussjfe01.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Fri, 30 Jul 2004 10:27:54 -0700
Subject: RE: Relative URI references
Date: Fri, 30 Jul 2004 10:27:54 -0700
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF094A7B27@ussjex01.amer.bea.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
Thread-Topic: Relative URI references
Thread-Index: AcR1tzsmgwBL9d5cTdKneqFCRkNKVQAousug
From: "David Orchard" <dorchard@bea.com>
To: "Sam Ruby" <rubys@intertwingly.net>, "Dare Obasanjo" <kpako@yahoo.com>
Cc: "Atom Syntax" <atom-syntax@imc.org>
X-OriginalArrivalTime: 30 Jul 2004 17:27:54.0611 (UTC) FILETIME=[8C4B8430:01C4765A]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6UHRpGt081588
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


Sam,

Scheme specific comparisons of URIs already happen.  Rfc 2616 has
section 3.2.3 which describes http specific URI comparison algorithms.

Cat's already out of the bag.

Dave

> -----Original Message-----
> From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-
> syntax@mail.imc.org] On Behalf Of Sam Ruby
> Sent: Thursday, July 29, 2004 2:58 PM
> To: Dare Obasanjo
> Cc: Atom Syntax
> Subject: Re: Relative URI references
> 
> 
> Dare Obasanjo wrote:
> 
> >
> > --- Sam Ruby <rubys@intertwingly.net> wrote:
> >
> >>>I note that there are neither xml:base nor a
> >>http-header Location: to
> >>>establish what the base URI is, and since that
> >>same resource can be fetched
> >>>from both these URLs...
> >>>
> >>>    http://intertwingly.net/blog/index.atom
> >>>    http://www.intertwingly.net/blog/index.atom
> >>>
> >>>that means the <id>s in your feed can be
> >>different.
> >>
> >>Good point.  At a minimum, that is worthy of an
> >>informative note.
> >
> > This seems like an excellent reason to ban relative
> > URIs in atom:id elements. Or are aggregator
> > implementers expected to do perform scheme specific
> > URI comparisons when checking to see if two entries
> > are identical?
> 
> I think that you are asking an orthogonal question.
> 
> It is the possibility of ids being in schemes like HTTP that would
> introduce the possibility of scheme specific URI comparisons, not the
> ability for URIs to be expressed as being relative to xml:base.
> 
> - Sam Ruby




From owner-atom-syntax@mail.imc.org  Fri Jul 30 13:47: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 NAA21284
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 13: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 i6UHdHed082435;
	Fri, 30 Jul 2004 10:39: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 i6UHdHav082434;
	Fri, 30 Jul 2004 10:39:17 -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 i6UHdHpr082427
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 10:39:17 -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 <2004073017391501500jrsgoe>; Fri, 30 Jul 2004 17:39:15 +0000
Date: Fri, 30 Jul 2004 11:39:14 -0600
Subject: Re: PaceLinkReflection - Close it
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: <8F1E1DF1-E23D-11D8-B278-000A95A51C9E@sun.com>
Message-Id: <5FF58E00-E24F-11D8-BDD2-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 Friday, July 30, 2004, at 09:31  AM, Tim Bray wrote:
> On Jul 30, 2004, at 7:59 AM, Sam Ruby wrote:
>>>> I think there's a lot of value in encouraging reflection.
>>> There's a lot of value in feed autodiscovery, thus the discussion 
>>> around MarkP's RFC.  But the decision as to which feed is 
>>> autodiscovered out of some HTML is entirely up to the author of the 
>>> HTML.  You would be silly not to use autodiscovery if you were able 
>>> and you had a feed you wanted to promote.  But you have no 
>>> obligation ("SHOULD") whatever. -Tim
> ...
>> I'm not sure how best to solve this problem, but putting a SHOULD in 
>> the document is the best solution I've seen to date.
>
> OK, but someone has to come up with language to make it clear that 
> this is a recommended good practice only in the case where the 
> publisher wants to direct traffic to the feed.  I am quite convinced 
> that there will be lots of parasitic, "third voice", or "opposing 
> viewpoints" feeds out there in the world, and the SHOULD clearly 
> doesn't apply to them.   -Tim
>
This seems like something that should be in a best practices document.  
Anything stronger than "here's something you'll probably want to do if 
you control both the feed and its related website" just seems too 
strong.  And that kind of wording just seems more appropriate for best 
practices than the core spec. That's my opinion.



From owner-atom-syntax@mail.imc.org  Fri Jul 30 13:47: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 NAA21302
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 13:47: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 i6UHaOOh082200;
	Fri, 30 Jul 2004 10:36: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 i6UHaOkd082199;
	Fri, 30 Jul 2004 10:36: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-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 i6UHaNCd082192
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 10:36:24 -0700 (PDT)
	(envelope-from Tim.Bray@Sun.COM)
Received: from esunmail ([129.147.156.34])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i6UHY753007016
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 11:34:07 -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 <0I1O008HKE8QZA@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Fri, 30 Jul 2004 11:36:27 -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 <0I1O003OBE8QL2@mail.sun.net> for atom-syntax@imc.org; Fri,
 30 Jul 2004 11:36:26 -0600 (MDT)
Date: Fri, 30 Jul 2004 10:36:43 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceFeedEquivalence
In-reply-to: <14be96d3040730102157e3a17e@mail.gmail.com>
To: Mark Pilgrim <pilgrim@gmail.com>
Cc: Joe Gregorio <joe.gregorio@gmail.com>, Atom Syntax <atom-syntax@imc.org>
Message-id: <05B5FAC5-E24F-11D8-B278-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: <ED9ED1C6-E194-11D8-B732-000A95A51C9E@sun.com>
 <14be96d30407291338435fdef6@mail.gmail.com>
 <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com>
 <3f1451f50407292027201f90e1@mail.gmail.com>
 <763E5EDA-E1DE-11D8-B278-000A95A51C9E@sun.com>
 <3f1451f504073008454ca5f9b6@mail.gmail.com>
 <14be96d3040730102157e3a17e@mail.gmail.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 Jul 30, 2004, at 10:21 AM, Mark Pilgrim wrote:

> On Fri, 30 Jul 2004 11:45:49 -0400, Joe Gregorio 
> <joe.gregorio@gmail.com> wrote:
>> What kind of
>> URI normalizations should be used when comparing
>> atom:id URIs for equivalence?
>
> All of them except protocol normalization, which requires resource
> retrieval to verify equivalence.

Er, by "should" do you mean SHOULD?  I think it's OK for software to do 
simple string comparison - particularly resource-challenged 
implementations - and I think it's also OK to do all the other things 
outlined.  I think that we should document the fact that those who mint 
and copy URIs can't count on other software doing anything more than a 
string comparison, so, to use the vernacular,
(a) Always use the same code when you're generating your own URIs, and
(b) don't fuck with the URIs you're given, store and pass them on the 
way you got them.

Given that, shit happens, which is why (in particular) robots will go 
to great lengths to determine when to different-looking URIs are 
actually the same.

>> And if so should we
>> augment that canonicalization
>> to include a unicode normalization form?
>
> An excellent question.  Tim?

As above.  Don't require it, but don't try to forbid it either.  -Tim



From owner-atom-syntax@mail.imc.org  Fri Jul 30 13:58:58 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21708
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 13:58: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 i6UHk9s7082763;
	Fri, 30 Jul 2004 10:46: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 i6UHk9nE082762;
	Fri, 30 Jul 2004 10:46: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 i6UHk8BF082751
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 10:46: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 KAA04125
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 10:46:07 -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 KAA22421
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 10:46:06 -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, 30 Jul 2004 10:46:06 -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 <0I1O00IXWEOS01@shazam.verity.com> for atom-syntax@imc.org; Fri,
 30 Jul 2004 10:46:05 -0700 (PDT)
Date: Fri, 30 Jul 2004 10:46:03 -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: PaceLinkReflection - Close it
In-reply-to: <410A626E.1030700@intertwingly.net>
To: Atomlist <atom-syntax@imc.org>
Message-id: 
 <253266C77084423329557692@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: <20040730141631.5294.qmail@web41502.mail.yahoo.com>
 <1EDD60B7-E234-11D8-B278-000A95A51C9E@sun.com>
 <410A626E.1030700@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, July 30, 2004 10:59 AM -0400 Sam Ruby <rubys@intertwingly.net> wrote:
> Tim Bray wrote:
>>
>>> I think there's a lot of value in encouraging reflection.
>>
>> There's a lot of value in feed autodiscovery, thus the discussion around
>> MarkP's RFC.  But the decision as to which feed is autodiscovered out of
>> some HTML is entirely up to the author of the HTML.  You would be silly
>> not to use autodiscovery if you were able and you had a feed you wanted
>> to promote.  But you have no obligation ("SHOULD") whatever. -Tim
>
> I'm not sure how best to solve this problem, but putting a SHOULD in
> the document is the best solution I've seen to date.

Seems more like a MAY than a SHOULD to me. If you violate a SHOULD,
you can expect important features to not be available. It interoperates,
but with a loss of functionality.

This is a MAY, which adds additional, useful features which are
not core.

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Fri Jul 30 14:00: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 OAA21765
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 14:00: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 i6UHlWD4082802;
	Fri, 30 Jul 2004 10:47: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 i6UHlWTA082801;
	Fri, 30 Jul 2004 10:47:32 -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 i6UHlVr9082795
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 10:47:31 -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 i6UHjE53012418
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 11:45: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 <0I1O00CQBERAD4@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Fri, 30 Jul 2004 11:47:34 -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 <0I1O003SRER9L2@mail.sun.net> for atom-syntax@imc.org; Fri,
 30 Jul 2004 11:47:34 -0600 (MDT)
Date: Fri, 30 Jul 2004 10:47:51 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceLinkReflection - Close it
In-reply-to: <410A8357.3030403@intertwingly.net>
To: Sam Ruby <rubys@intertwingly.net>
Cc: Atomlist <atom-syntax@imc.org>
Message-id: <93DA22D2-E250-11D8-B278-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: <20040730141631.5294.qmail@web41502.mail.yahoo.com>
 <1EDD60B7-E234-11D8-B278-000A95A51C9E@sun.com>
 <410A626E.1030700@intertwingly.net>
 <8F1E1DF1-E23D-11D8-B278-000A95A51C9E@sun.com>
 <410A734D.4020402@intertwingly.net> <410A8357.3030403@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 Jul 30, 2004, at 10:20 AM, Sam Ruby wrote:

>> In the current draft, we are specifically talking about the URI 
>> contained in the atom:link element defined in section 4.2.2 where the 
>> type is "text/html" or "application/xhtml+xml" and the 
>> rel="alternate".  The resource that that URI identifies SHOULD 
>> contain an autodiscovery link specifying this feed.
>
> On further reflection, the last sentence should read:
>
> The URI SHOULD identify a resource that contains an autodiscovery link 
> specifying this feed.

I still don't think such a statement is really much use, but this is a 
much clearer and better  statement and if people want it, I guess it's 
not actively harmful. -Tim



From owner-atom-syntax@mail.imc.org  Fri Jul 30 14:15: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 OAA22459
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 14:15: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 i6UI8AtT083968;
	Fri, 30 Jul 2004 11:08:10 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6UI8AMD083967;
	Fri, 30 Jul 2004 11:08:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from localhost.localdomain (68-22-85-68.ded.ameritech.net [68.22.85.68])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UI888s083955
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 11:08:08 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net ([65.85.192.194])
	by localhost.localdomain (8.12.8/8.12.8) with ESMTP id i6UI2Vgm031890;
	Fri, 30 Jul 2004 14:02:32 -0400
Received: from *Unknown*-port10-SMSHGIBEAVERTON[10.42.1.27] by SMSHGIBEAVERTON[65.85.192.194]; Fri, 30 Jul 2004 13:47:51 -0000 (???)
Message-ID: <410A8E83.9040206@intertwingly.net>
Date: Fri, 30 Jul 2004 14:08:03 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <dorchard@bea.com>
CC: Dare Obasanjo <kpako@yahoo.com>, Atom Syntax <atom-syntax@imc.org>
Subject: Re: Relative URI references
References: <32D5845A745BFB429CBDBADA57CD41AF094A7B27@ussjex01.amer.bea.com>
In-Reply-To: <32D5845A745BFB429CBDBADA57CD41AF094A7B27@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: <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


David Orchard wrote:

> Sam,
> 
> Scheme specific comparisons of URIs already happen.  Rfc 2616 has
> section 3.2.3 which describes http specific URI comparison algorithms.
> 
> Cat's already out of the bag.

To put this in context, you are stating that the "or" clause that Dare 
mentions below is satisfied:

http://www.imc.org/atom-syntax/mail-archive/msg08066.html

I have seen a number of objections raised to relative URIs in id 
elements.  Each time, it seems to me that the objection was really to 
something else, and we wandered off into whether that objection was valid.

There does seem to be a general consensus that the use of http scheme 
and relative URIs are error prone and SHOULD (in the RFC 2119) sense of 
this word be avoided.  I'm uneasy with that in both cases, but would be 
willing to go along if that was the consensus.  MUST NOT in either case 
seems wrong.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Fri Jul 30 14:19:08 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22601
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 14:19:07 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UI6M5g083917;
	Fri, 30 Jul 2004 11: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 i6UI6MbL083916;
	Fri, 30 Jul 2004 11:06: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 i6UI6LJd083908
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 11:06: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 3DE197C0F3; Fri, 30 Jul 2004 21:01:31 +0200 (CEST)
Date: Fri, 30 Jul 2004 20:10:06 +0200
To: "Antone Roundy" <antone@geckotribe.com>
Subject: Re: PaceDates
References: <57BCFB8C-E1A3-11D8-9043-003065EA6144@geckotribe.com>
Cc: Atom-Syntax <atom-syntax@imc.org>
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: <opsbyp24y0uvpchu@quark>
In-Reply-To: <57BCFB8C-E1A3-11D8-9043-003065EA6144@geckotribe.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Thu, 29 Jul 2004 15:07:47 -0600, Antone Roundy <antone@geckotribe.com>  
wrote:

> I don't see any value in grouping under a <date> element.  Anyone else?  
> If there's no value in it, then let's be less verbose.

Yes.

> I DO like the idea of grouping the date elements within the spec--I think
> it improves spec readability.

Yes, it does. Do you like the way they're grouped in PaceDates now?

> -1.  The subjective date is not only for legacy support--it also enables  
> the author to indicate a date related to the CONTENT or MEANING of the  
> entry, as opposed to timestamping the events that occurred in the  
> process of PUBLISHING the entry.

I kind of agree that such a date is needed, I'm just not sure how we can  
say that tools SHOULD NOT use this date and instead match their semantics  
with either 'issued', 'modified' or 'created' and use those instead. I'm  
all +1 for having atom:date being totally subjective, however, that's not  
the current practice -- it can be both.

> My impression was that it is MORE accurate to use "-00:00" than "+00:00"  
> or "Z" when normalizing from some other timezone to UTC.

No, I don't think so. If you normalize, you would need to normalise _from_  
something. Thus, you would need to know the original local time.  
Normalizing 2004-30-07T08:41:30+04:00 to 2004-30-07T04:41:30Z is ceirtanly  
data loss, but the original time zone is known, and the date is explicitly  
normalized to UTC, and thus isn't '-00:00' appropriate. I think.

 From RFC 3999:

    If the time in UTC is known, but the offset to local time is unknown,
    this can be represented with an offset of "-00:00".  This differs
    semantically from an offset of "Z" or "+00:00", which imply that UTC
    is the preferred reference point for the specified time.  RFC2822
    [IMAIL-UPDATE] describes a similar convention for email.

> I can't imagine that it means "I looked at the clock with the local time
> and computed the UTC time, but I have no clue what timezone I'm in."

No, that's not what it means. What it could be useful for, is in  
situations when a server is e.g. placed on the moon (e.g. wherever) and  
the user in Taiwan, but the date of the server is (synchronized and  
correct) UTC time. The server knows it's UTC, but have no idea about what  
the user's local offset is.

> If your clock reads local time and you can compute UTC, you DO know
> what timezone you're in.

Yes, but I doubt "-00:00" is intended for humans to provide.

> I don't think it's terribly important whether "+00:00", "-00:00" or "Z"  
> is used, but if we ARE going to encourage one or two over the other(s),  
> then let's be sure we're doing the most correct thing.

Absolutely.

-- 
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 Jul 30 14:19: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 OAA22633
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 14:19: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 i6UI95iD084035;
	Fri, 30 Jul 2004 11:09: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 i6UI95xV084034;
	Fri, 30 Jul 2004 11:09: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 (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UI93MZ084025
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 11:09: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 373A27C0F3; Fri, 30 Jul 2004 21:04:16 +0200 (CEST)
Date: Fri, 30 Jul 2004 20:12:51 +0200
To: "Eric Scheid" <eric.scheid@ironclad.net.au>
Subject: Re: PaceDates
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <BD302F1E.23A49%eric.scheid@ironclad.net.au>
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: <opsbyp7pmvuvpchu@quark>
In-Reply-To: <BD302F1E.23A49%eric.scheid@ironclad.net.au>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 30 Jul 2004 17:00:14 +1000, Eric Scheid  
<eric.scheid@ironclad.net.au> wrote:

>> Why can't 'issued' be set to when the report is published to the web?
>
> that's what I said, isn't it?

Yes. ;-)

> I'm saying the weather report, as issued by the BoM this afternoon, for
> this coming Sunday should have:
>
>     <issued>2004-07-30T16:00+10:00</issued>
>     <date>2004-08-01T00:00+10:00</date>

+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  Fri Jul 30 14:20:43 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22680
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 14:20:42 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UI8QXG084002;
	Fri, 30 Jul 2004 11:08: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 i6UI8Q0u084001;
	Fri, 30 Jul 2004 11:08:26 -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 i6UI8PDc083991
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 11:08:25 -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 i6UI8NJ6001378
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 11:08:24 -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 <0I1O00401FJYNR@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com)
 for atom-syntax@imc.org; Fri, 30 Jul 2004 14:08:23 -0400 (EDT)
Received: from mercury (vpn-129-150-34-27.Central.Sun.COM [129.150.34.27])
 by bur-mail1.east.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
 with ESMTP id <0I1O00F00FPZ7G@bur-mail1.east.sun.com> for atom-syntax@imc.org;
 Fri, 30 Jul 2004 14:08:23 -0400 (EDT)
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1Bqbnk-0007BC-00	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 14:08:16 -0400
X-URL: http://nwalsh.com/
Date: Fri, 30 Jul 2004 14:08:13 -0400
From: Norman Walsh <ndw@nwalsh.com>
Subject: Identity conundrum
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <87fz79xt9u.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)
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-Type: text/plain

I thought of this while flying home from RDU last night. I haven't
caught up on the mail, so apologies in advance if it's been said
before.

I was thinking about what Dare said about his aggregator and the fact
that if it sees a "republished" entry with the same atom:id, it
continues to sort by the original date, not the new date. (I'm not
suggesting that Dare is alone or that he's wrong, it just happens to
be his message that got me thinking along these lines.)

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.

One idea of identity is that entries have immutable identity. That is,
an atom:id identifies an atom:entry that cannot change. Publishing a
different atom:entry with the same atom:id is logically an error. In
this view, an aggregator that notices an atom:entry with the same
atom:id as one it's already seen can disregard it without another
thought. It's either exactly the same as the one that's already been
seen, or it has changes that are erroneous and it can recover from
this error by ignoring the new entry.

Another view of identity is that entries are snapshots of an
abstraction that has identity. That is, an atom:id identifies an
abstraction that might or might not change. Publishing a different
atom:entry with the same atom:id represents some sort of change in the
underlying abstraction that's being reflected in the Atom world by
posting a new atom:entry. In this view, an aggregator that notices an
atom:entry with the same atom:id as one it's already seen might choose
to merge them, or pick one, or pick the one with the most recent
atom:modified date, or do something to "harmonize" the two entries.
The only thing it would never do is present both the atom:entries to
the user as if they were two different entries.

Choosing the former view suggests that Tim's idea of "a permanent
status page" for a project (like GenX or my own sxpipe) is an abuse of
Atom unless the atom:id is changed everytime the status page is
updated.

Choosing the latter view suggests that Dare's aggregator (and other
aggregators built along the same lines) should be changed. Exactly
what they should do probably need more discussion.

I think I lean towards the latter view, but there's definitely
something appealing about the simplicity of the former view.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | On the other hand, you have different
http://nwalsh.com/            | fingers.

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBBCo6POyltUcwYWjsRAnGlAJ4oPs4tBk0qBRNcCDC1uDoeISJE3gCdFVvq
gPLTSCh1+r/T1KWU8ur5mEw=
=j1zu
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Fri Jul 30 14: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 OAA22952
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 14: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 i6UIAwvT084131;
	Fri, 30 Jul 2004 11:10: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 i6UIAwcW084130;
	Fri, 30 Jul 2004 11:10:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from localhost.localdomain (68-22-85-68.ded.ameritech.net [68.22.85.68])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UIAvpA084124
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 11:10:57 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net ([65.85.192.194])
	by localhost.localdomain (8.12.8/8.12.8) with ESMTP id i6UI5Mgm031913;
	Fri, 30 Jul 2004 14:05:23 -0400
Received: from *Unknown*-port10-SMSHGIBEAVERTON[10.42.1.27] by SMSHGIBEAVERTON[65.85.192.194]; Fri, 30 Jul 2004 13:50:41 -0000 (???)
Message-ID: <410A8F30.8060606@intertwingly.net>
Date: Fri, 30 Jul 2004 14:10:56 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <wunder@verity.com>
CC: Atomlist <atom-syntax@imc.org>
Subject: Re: PaceLinkReflection - Close it
References: <20040730141631.5294.qmail@web41502.mail.yahoo.com> <1EDD60B7-E234-11D8-B278-000A95A51C9E@sun.com> <410A626E.1030700@intertwingly.net> <253266C77084423329557692@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
In-Reply-To: <253266C77084423329557692@adsl-64-166-133-244.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 Friday, July 30, 2004 10:59 AM -0400 Sam Ruby 
> <rubys@intertwingly.net> wrote:
> 
>> Tim Bray wrote:
>>
>>>> I think there's a lot of value in encouraging reflection.
>>>
>>> There's a lot of value in feed autodiscovery, thus the discussion around
>>> MarkP's RFC.  But the decision as to which feed is autodiscovered out of
>>> some HTML is entirely up to the author of the HTML.  You would be silly
>>> not to use autodiscovery if you were able and you had a feed you wanted
>>> to promote.  But you have no obligation ("SHOULD") whatever. -Tim
>>
>> I'm not sure how best to solve this problem, but putting a SHOULD in
>> the document is the best solution I've seen to date.
> 
> Seems more like a MAY than a SHOULD to me. If you violate a SHOULD,
> you can expect important features to not be available. It interoperates,
> but with a loss of functionality.
> 
> This is a MAY, which adds additional, useful features which are
> not core.

Is autodiscovery an important feature?  If not, lets not pursue an RFC. 
  If so, let's identify where it MUST or SHOULD be used.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Fri Jul 30 14: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 OAA22982
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 14: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 i6UIGPGA084500;
	Fri, 30 Jul 2004 11:16:25 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6UIGPBe084499;
	Fri, 30 Jul 2004 11:16:25 -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 i6UIGPuE084488
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 11:16:25 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040730181618.43216.qmail@web41201.mail.yahoo.com>
Received: from [67.168.158.47] by web41201.mail.yahoo.com via HTTP; Fri, 30 Jul 2004 11:16:18 PDT
Date: Fri, 30 Jul 2004 11:16:18 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Relative URI references
To: Sam Ruby <rubys@intertwingly.net>, David Orchard <dorchard@bea.com>
Cc: Dare Obasanjo <kpako@yahoo.com>, Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <410A8E83.9040206@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:
> 
> > Sam,
> > 
> > Scheme specific comparisons of URIs already
> happen.  Rfc 2616 has
> > section 3.2.3 which describes http specific URI
> comparison algorithms.
> > 
> > Cat's already out of the bag.

I'm not sure what this statement has to do with
anything. No one is disputing that scheme specific
comparisons already exist. The point is that it is
infeasible to expect clients to know every scheme
specific comparison so you can't create a technology
that can utilize any URI scheme AND creates situations
where scheme specific comparisons should be made.

Why else do you think the XML namespaces
recommendation specifies that namespace names are to
be compared character by character instead of
according to the algorithm of the specified scheme? 


> To put this in context, you are stating that the
> "or" clause that Dare 
> mentions below is satisfied:
> 
>
http://www.imc.org/atom-syntax/mail-archive/msg08066.html
> 
> I have seen a number of objections raised to
> relative URIs in id 
> elements.  Each time, it seems to me that the
> objection was really to 
> something else, and we wandered off into whether
> that objection was valid.
> 
> There does seem to be a general consensus that the
> use of http scheme 
> and relative URIs are error prone and SHOULD (in the
> RFC 2119) sense of 
> this word be avoided.  I'm uneasy with that in both
> cases, but would be 
> willing to go along if that was the consensus.  MUST
> NOT in either case 
> seems wrong.

Why do you keep focusing this argument on HTTP. The
consensus I've seen is that there relative URIs in IDs
are a bad idea. You are the only one on this list so
far sticking up for them. I've seen lots of +1 against
them since this topic began. The cost/benefit of this
feature is too skewed to make this a worthwhile
addition to Atom. 



=====
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 Jul 30 14:28: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 OAA23017
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 14:28: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 i6UIILQW084589;
	Fri, 30 Jul 2004 11:18: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 i6UIILiT084588;
	Fri, 30 Jul 2004 11:18:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from localhost.localdomain (68-22-85-68.ded.ameritech.net [68.22.85.68])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UIIKVw084582
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 11:18:20 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net ([65.85.192.194])
	by localhost.localdomain (8.12.8/8.12.8) with ESMTP id i6UICigm031941;
	Fri, 30 Jul 2004 14:12:44 -0400
Received: from *Unknown*-port10-SMSHGIBEAVERTON[10.42.1.27] by SMSHGIBEAVERTON[65.85.192.194]; Fri, 30 Jul 2004 13:58:04 -0000 (???)
Message-ID: <410A90E7.5060302@intertwingly.net>
Date: Fri, 30 Jul 2004 14:18:15 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <Tim.Bray@Sun.COM>
CC: Mark Pilgrim <pilgrim@gmail.com>, Joe Gregorio <joe.gregorio@gmail.com>,
        Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceFeedEquivalence
References: <ED9ED1C6-E194-11D8-B732-000A95A51C9E@sun.com> <14be96d30407291338435fdef6@mail.gmail.com> <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com> <3f1451f50407292027201f90e1@mail.gmail.com> <763E5EDA-E1DE-11D8-B278-000A95A51C9E@sun.com> <3f1451f504073008454ca5f9b6@mail.gmail.com> <14be96d3040730102157e3a17e@mail.gmail.com> <05B5FAC5-E24F-11D8-B278-000A95A51C9E@sun.com>
In-Reply-To: <05B5FAC5-E24F-11D8-B278-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 Jul 30, 2004, at 10:21 AM, Mark Pilgrim wrote:
> 
>> On Fri, 30 Jul 2004 11:45:49 -0400, Joe Gregorio 
>> <joe.gregorio@gmail.com> wrote:
>>
>>> What kind of
>>> URI normalizations should be used when comparing
>>> atom:id URIs for equivalence?
>>
>> All of them except protocol normalization, which requires resource
>> retrieval to verify equivalence.
> 
> Er, by "should" do you mean SHOULD?  I think it's OK for software to do 
> simple string comparison - particularly resource-challenged 
> implementations - and I think it's also OK to do all the other things 
> outlined.  I think that we should document the fact that those who mint 
> and copy URIs can't count on other software doing anything more than a 
> string comparison, so, to use the vernacular,
> (a) Always use the same code when you're generating your own URIs, and
> (b) don't fuck with the URIs you're given, store and pass them on the 
> way you got them.
> 
> Given that, shit happens, which is why (in particular) robots will go to 
> great lengths to determine when to different-looking URIs are actually 
> the same.
> 
>>> And if so should we
>>> augment that canonicalization
>>> to include a unicode normalization form?
>>
>> An excellent question.  Tim?
> 
> As above.  Don't require it, but don't try to forbid it either.  -Tim

Let's look at this from a producer side.  If "PlanetSun" ever has an 
Atom 1.0 feed, MUST the ids be byte for byte identical to the ones that 
these entries were based off of, or merely equivalent?

If we don't mandate byte for byte correspondence, then it is NOT OK for 
sofware to do simple string comparisons.  They must check for equivalence.

If we mandate byte for byte correspondence, then there is no need for 
clients to do anything other than byte for byte comparisons.  In fact, 
if they attempt to cannonicalize, then they may identify false matches.

I think we need to pick one.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Fri Jul 30 14: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 OAA24156
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 14:48: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 i6UIa6h7085700;
	Fri, 30 Jul 2004 11:36: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 i6UIa6QZ085696;
	Fri, 30 Jul 2004 11:36:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UIa5FX085688
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 11:36: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 F41047C130; Fri, 30 Jul 2004 21:31:17 +0200 (CEST)
Date: Fri, 30 Jul 2004 20:39:59 +0200
To: "Walter Underwood" <wunder@verity.com>
Subject: Re: Date Options Analysis: Issued
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <D72A9E13D73D4464964DA4DED2881E.MAI@journurl.com> <opsbtb2mnquvpchu@quark> <9380611B31E34A21867566DE@adsl-64-166-133-244.dsl.snfc21.pacbell.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: <opsbyrgxn6uvpchu@quark>
In-Reply-To: <9380611B31E34A21867566DE@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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 Thu, 29 Jul 2004 15:57:10 -0700, Walter Underwood <wunder@verity.com>  
wrote:

> It isn't high-quality and low-quality, it is professional and
> casual publishing.

To me, professional publishing provides higher quality, at least for these  
dates. Whenever I find a date in current feeds, there is absolutely no way  
to know what that date actually means. When I find a 'created' date in  
more professional formats, I know _exactly_ what it means. The former  
gives me lower quality, the latter higher.

But this is nitpicking. It doesn't matter.

> How about an immutable='true' attribute? That allows professional
> publishers to assert their policy of immutable issuance dates.

I'm much more +1 for defining profiles. Ken MacLeod has proposed something  
in this direction (though not syntactically identical to it):

   <feed version="1.0">
     <profile xmlns="http://purl.org/profiles/professional-publishing" />

     [....]
   </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  Fri Jul 30 14:53:15 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24363
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 14: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 i6UIedPh085942;
	Fri, 30 Jul 2004 11:40: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 i6UIedgu085941;
	Fri, 30 Jul 2004 11:40:39 -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 i6UIed1X085925
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 11:40: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 (rwcrmhc13) with SMTP
          id <2004073018403701500jsqlde>; Fri, 30 Jul 2004 18:40:37 +0000
Date: Fri, 30 Jul 2004 12:40:36 -0600
Subject: Re: PaceDates
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: <opsbyp24y0uvpchu@quark>
Message-Id: <F23B455A-E257-11D8-BDD2-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 i6UIed1X085936
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 Friday, July 30, 2004, at 12:10  PM, Asbjørn Ulsberg wrote:
>> I DO like the idea of grouping the date elements within the spec--I 
>> think
>> it improves spec readability.
>
> Yes, it does. Do you like the way they're grouped in PaceDates now?
Yes.

>> -1.  The subjective date is not only for legacy support--it also 
>> enables the author to indicate a date related to the CONTENT or 
>> MEANING of the entry, as opposed to timestamping the events that 
>> occurred in the process of PUBLISHING the entry.
>
> I kind of agree that such a date is needed, I'm just not sure how we 
> can say that tools SHOULD NOT use this date and instead match their 
> semantics with either 'issued', 'modified' or 'created' and use those 
> instead. I'm all +1 for having atom:date being totally subjective, 
> however, that's not the current practice -- it can be both.
>
The point is that if the date a tool is publishing actually fits into 
issued, modified, created, or whatever objective dates end up in the 
spec, they should put it on those elements rather than in the 
subjective element (at least not ONLY in the subjective date element).  
I really don't think we need to prompt anyone to do that.  If we say 
"these are the date elements, and this is what belongs in each", then 
developers who see a date element that specifically fits what they have 
available are going to use it without us saying "if the date you're 
publishing fits this description of the atom:issued, you SHOULD NOT put 
it in atom:date".

Given that there are entirely legitimate uses for atom:date, any 
language that implies that its use should be avoided is, I think, 
inappropriate and unnecessary.  We can encourage the use of the other 
date elements without discouraging the use of atom:date.



From owner-atom-syntax@mail.imc.org  Fri Jul 30 14:54: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 OAA24430
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 14:54: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 i6UIYQdk085647;
	Fri, 30 Jul 2004 11:34: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 i6UIYQYw085646;
	Fri, 30 Jul 2004 11:34:26 -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 i6UIYQCl085628
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 11:34:26 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040730183424.84987.qmail@web41208.mail.yahoo.com>
Received: from [67.168.158.47] by web41208.mail.yahoo.com via HTTP; Fri, 30 Jul 2004 11:34:24 PDT
Date: Fri, 30 Jul 2004 11:34:24 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Identity conundrum
To: Norman Walsh <ndw@nwalsh.com>, Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <87fz79xt9u.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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>



--- Norman Walsh <ndw@nwalsh.com> wrote:

> I thought of this while flying home from RDU last
> night. I haven't
> caught up on the mail, so apologies in advance if
> it's been said
> before.
> 
> I was thinking about what Dare said about his
> aggregator and the fact
> that if it sees a "republished" entry with the same
> atom:id, it
> continues to sort by the original date, not the new
> date. (I'm not
> suggesting that Dare is alone or that he's wrong, it
> just happens to
> be his message that got me thinking along these
> lines.)
> 
> 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.
> 
> One idea of identity is that entries have immutable
> identity. That is,
> an atom:id identifies an atom:entry that cannot
> change. Publishing a
> different atom:entry with the same atom:id is
> logically an error. In
> this view, an aggregator that notices an atom:entry
> with the same
> atom:id as one it's already seen can disregard it
> without another
> thought. It's either exactly the same as the one
> that's already been
> seen, or it has changes that are erroneous and it
> can recover from
> this error by ignoring the new entry.
> 
> Another view of identity is that entries are
> snapshots of an
> abstraction that has identity. That is, an atom:id
> identifies an
> abstraction that might or might not change.
> Publishing a different
> atom:entry with the same atom:id represents some
> sort of change in the
> underlying abstraction that's being reflected in the
> Atom world by
> posting a new atom:entry. In this view, an
> aggregator that notices an
> atom:entry with the same atom:id as one it's already
> seen might choose
> to merge them, or pick one, or pick the one with the
> most recent
> atom:modified date, or do something to "harmonize"
> the two entries.
> The only thing it would never do is present both the
> atom:entries to
> the user as if they were two different entries.
> 
> Choosing the former view suggests that Tim's idea of
> "a permanent
> status page" for a project (like GenX or my own
> sxpipe) is an abuse of
> Atom unless the atom:id is changed everytime the
> status page is
> updated.
> 
> Choosing the latter view suggests that Dare's
> aggregator (and other
> aggregators built along the same lines) should be
> changed. Exactly
> what they should do probably need more discussion.

RSS Bandit already does what you suggest in the latter
view. I use the most recent version of the content
(title/description/summary/content) I just don't
change the date because to me the issued date should
not change. 

I think you've misinterpreted the discussion and
created two points of view that don't mesh with
reality. 


=====
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  Fri Jul 30 14:55: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 OAA24454
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 14:55: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 i6UIci42085855;
	Fri, 30 Jul 2004 11: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 i6UIciK9085854;
	Fri, 30 Jul 2004 11:38:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from localhost.localdomain (68-22-85-68.ded.ameritech.net [68.22.85.68])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UIch0e085848
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 11:38:43 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from intertwingly.net ([65.85.192.194])
	by localhost.localdomain (8.12.8/8.12.8) with ESMTP id i6UIX7gm032133;
	Fri, 30 Jul 2004 14:33:08 -0400
Received: from *Unknown*-port10-SMSHGIBEAVERTON[10.42.1.27] by SMSHGIBEAVERTON[65.85.192.194]; Fri, 30 Jul 2004 14:18:27 -0000 (???)
Message-ID: <410A95B1.5020305@intertwingly.net>
Date: Fri, 30 Jul 2004 14:38:41 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Dare Obasanjo <kpako@yahoo.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Relative URI references
References: <20040730181618.43216.qmail@web41201.mail.yahoo.com>
In-Reply-To: <20040730181618.43216.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: <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:
> 
> Why do you keep focusing this argument on HTTP. The
> consensus I've seen is that there relative URIs in IDs
> are a bad idea. You are the only one on this list so
> far sticking up for them. I've seen lots of +1 against
> them since this topic began. The cost/benefit of this
> feature is too skewed to make this a worthwhile
> addition to Atom. 

If we decide that IDs are to be compared byte for byte for equality, 
then (1) I'm not sure that they need to be URIs and (2) I would agree 
that the requirement to require relative URIs to be resolved seems 
counter to this.

If we decide that IDs need to be normalized before comparision, and we 
have other places where xml:base is part of the normalization, then it 
seems inconsistent to rule out this one case.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Fri Jul 30 14:55: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 OAA24476
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 14:55:19 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UIbZwd085786;
	Fri, 30 Jul 2004 11: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 i6UIbZvb085785;
	Fri, 30 Jul 2004 11:37: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.199])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UIbYBq085779
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 11:37:34 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id 75so51026rnl
        for <atom-syntax@imc.org>; Fri, 30 Jul 2004 11:37:37 -0700 (PDT)
Received: by 10.38.3.79 with SMTP id 79mr28198rnc;
        Fri, 30 Jul 2004 11:37:37 -0700 (PDT)
Message-ID: <14be96d3040730113729acf17e@mail.gmail.com>
Date: Fri, 30 Jul 2004 14:37:37 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Relative URI references
Cc: Sam Ruby <rubys@intertwingly.net>, Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <20040730181618.43216.qmail@web41201.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <20040730181618.43216.qmail@web41201.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 Fri, 30 Jul 2004 11:16:18 -0700 (PDT), Dare Obasanjo <kpako@yahoo.com> wrote:
> The consensus I've seen is that there relative URIs in IDs
> are a bad idea.

As much as I hate to admit it, Dare is right that there is consensus. 
I just re-read the thread, and the following people have stated that
atom:id MUST be an absolute URI:

- Dare
- Asbjorn
- Elias
- James
- Julian
- Andreas
- Eric
- Toru Marumoto
- Bill
- Graham

I bow to the will of the majority.

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Fri Jul 30 14:56: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 OAA24581
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 14:56: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 i6UIeZ9e085934;
	Fri, 30 Jul 2004 11:40:35 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6UIeZRc085933;
	Fri, 30 Jul 2004 11:40: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 (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UIeY6Q085919
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 11:40: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 B81E27C130; Fri, 30 Jul 2004 21:35:46 +0200 (CEST)
Date: Fri, 30 Jul 2004 20:44:28 +0200
To: "Walter Underwood" <wunder@verity.com>
Subject: Re: PaceLinkReflection - Close it
References: <20040730141631.5294.qmail@web41502.mail.yahoo.com> <1EDD60B7-E234-11D8-B278-000A95A51C9E@sun.com> <410A626E.1030700@intertwingly.net> <253266C77084423329557692@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
Cc: Atom-Syntax <atom-syntax@imc.org>
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: <opsbyroeb0uvpchu@quark>
In-Reply-To: <253266C77084423329557692@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 30 Jul 2004 10:46:03 -0700, Walter Underwood <wunder@verity.com>  
wrote:

> Seems more like a MAY than a SHOULD to me.

What if the text was moved to a third Atom specification document  
alongside with Mark Pilgrim's autodiscovery mechanism? Would it be too  
much to mandate SHOULD then as well?

> This is a MAY, which adds additional, useful features which are
> not core.

If this was moved to another specification, that whole specification would  
be «outside the core» and thus optional. I also feel that this belongs  
with the «Introspection and Discovery-services» more than with the format  
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 Jul 30 15: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 PAA24848
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 15: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 i6UImCrF086381;
	Fri, 30 Jul 2004 11: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 i6UImCNH086380;
	Fri, 30 Jul 2004 11:48:12 -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 i6UImBJ1086359
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 11:48: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 i6UIm953013446
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 13:48:09 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6UIm95O013442;
	Fri, 30 Jul 2004 13:48:09 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceDates
Summary: I believe we would be much better off using the long
	descriptions of fields, like "the date which the aggregator
	primarily displays to the user".
References: <BD2FE620.23929%eric.scheid@ironclad.net.au>
	<opsbxtmmcguvpchu@quark>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 30 Jul 2004 13:48:08 -0500
In-Reply-To: <opsbxtmmcguvpchu@quark>
Message-ID: <m3hdrp2uxj.fsf@bitsko.slc.ut.us>
Lines: 36
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 i6UImBJ1086374
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 <asbjorn@tigerstaden.no> writes:

> On Fri, 30 Jul 2004 11:48:48 +1000, Eric Scheid
> <eric.scheid@ironclad.net.au> wrote:
> 
> > disagree there is consensus ... the question of future dates being
> > an  issue hasn't been discussed at all, or only in passing.
> 
> It has been discussed in #atom, and the ones discussing it seemed to
> agree that future dates were more of a bug than a feature. At least
> for the more formal dates of 'issued', 'modified' and 'created'.

Gah.  "At least for the more formal dates of 'issued', 'modified' and
'created'."  There's no concensus on the meaning of those terms, and
you didn't specify the Dublin Core definitions, therefore those terms
are meaningless, and therefore we couldn't have agreed about anything
on them.

Pedantic, yes, but absolutely critical in this conversation.

"Future dates" are a *current practice*, regardless of the field, or
the name of the field, we choose to put it in.  And surprisingly
enough, depending on concensus, it could go into a field with one of
those names when used in certain roles.  And we came to local
agreement on that in #atom too.

If people continue to bandy about the "labels" or "terms" that no one
agrees has the same definition anyway, we will continue to have this
problem.

I believe we would be much better off using the long descriptions of
fields, like "the date which the aggregator primarily displays to the
user", than using these damnable terms which everyone thinks mean
something, different than what the next person thinks.

  -- Ken



From owner-atom-syntax@mail.imc.org  Fri Jul 30 15: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 PAA25710
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 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 i6UJ0rWo087111;
	Fri, 30 Jul 2004 12:00: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 i6UJ0r3j087110;
	Fri, 30 Jul 2004 12:00: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 i6UJ0qv1087102
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 12:00: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 942E27C130; Fri, 30 Jul 2004 21:56:05 +0200 (CEST)
Date: Fri, 30 Jul 2004 21:04:51 +0200
To: "Antone Roundy" <antone@geckotribe.com>
Subject: Re: Relative URI references
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <9BFE6EB2-E23A-11D8-BDD2-003065EA6144@geckotribe.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: <opsbysmdtduvpchu@quark>
In-Reply-To: <9BFE6EB2-E23A-11D8-BDD2-003065EA6144@geckotribe.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 30 Jul 2004 09:10:36 -0600, Antone Roundy <antone@geckotribe.com>  
wrote:

> This has nothing to do with the entries moving.  As long as xml:base  
> continues to point to the old base URI, the atom:id's won't be changed.

So, what this basically means is that authors must put xml:base on the  
atom:id element:

   <atom:id xml:base="http://example.com/blog/">3287234</atom:id>

Because the base URI for the rest of the document could (or would, if it  
has moved) be 'http://example.com/blog/moved/here'. Now, what does anyone  
gain from this? The only «gain» I see, is problems. Problems with making  
it much more difficult to process the ID and preserving and retaining it  
immutable and unique.

> What you're talking about it the problem with atom:id being deferencable,
> not with using xml:base to avoid repeating the same base portion of the
> URI in each id (or whatever other reasons it might be used for).

No, I'm not talking about deferencability, although relative URI's in  
atom:id very often could be deferencable.

-- 
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 Jul 30 15: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 PAA26823
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 15:25: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 i6UJJQwZ087998;
	Fri, 30 Jul 2004 12: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 i6UJJQv4087997;
	Fri, 30 Jul 2004 12:19:26 -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 i6UJJPme087990
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 12:19:25 -0700 (PDT)
	(envelope-from antone@geckotribe.com)
Received: from geckotribe.com (c-67-169-250-134.client.comcast.net[67.169.250.134])
          by comcast.net (rwcrmhc11) with SMTP
          id <2004073019192401300bdrq2e>; Fri, 30 Jul 2004 19:19:24 +0000
Date: Fri, 30 Jul 2004 13:19:23 -0600
Subject: Re: Relative URI references
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: <opsbysmdtduvpchu@quark>
Message-Id: <5D441634-E25D-11D8-BDD2-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 i6UJJPme087992
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 Friday, July 30, 2004, at 01:04  PM, Asbjørn Ulsberg wrote:
>> This has nothing to do with the entries moving.  As long as xml:base 
>> continues to point to the old base URI, the atom:id's won't be 
>> changed.
>
> So, what this basically means is that authors must put xml:base on the 
> atom:id element:
>
>   <atom:id xml:base="http://example.com/blog/">3287234</atom:id>
>
> Because the base URI for the rest of the document could (or would, if 
> it has moved) be 'http://example.com/blog/moved/here'. Now, what does 
> anyone gain from this? The only «gain» I see, is problems. Problems 
> with making it much more difficult to process the ID and preserving 
> and retaining it immutable and unique.
>
If a feed is only using relative URIs for atom:id, and if they're going 
to continue using the same base for new entries after the move, they 
could conceivably still use the old xml:base.  That would be a bit odd 
though.

A more practical approach than specifying xml:base for every old entry 
would be to write out the entire ID explicitly for old entries:

<atom:id>http://example.com/blog/3287234</atom:id>

They'd have to have some way to determine which entries were old, and 
thus had the old base URI (unless they'd always been storing the whole 
thing locally but shortening it when publishing the feed).

But once again, I'm not necessarily advocating relative URIs for 
atom:id.  The arguments against seem stronger than the arguments for, 
but perhaps not strong enough to forbid it.  It may be that clearly 
pointing out the risks of doing so, and what one might have to do if 
their base URI changes would be enough.



From owner-atom-syntax@mail.imc.org  Fri Jul 30 15:42: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 PAA27467
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 15:42: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 i6UJSkqN088409;
	Fri, 30 Jul 2004 12: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 i6UJSkij088408;
	Fri, 30 Jul 2004 12:28:46 -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 i6UJSkQY088400
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 12:28:46 -0700 (PDT)
	(envelope-from kpako@yahoo.com)
Message-ID: <20040730192845.32022.qmail@web41204.mail.yahoo.com>
Received: from [67.168.158.47] by web41204.mail.yahoo.com via HTTP; Fri, 30 Jul 2004 12:28:45 PDT
Date: Fri, 30 Jul 2004 12:28:45 -0700 (PDT)
From: Dare Obasanjo <kpako@yahoo.com>
Subject: Re: Relative URI references
To: Sam Ruby <rubys@intertwingly.net>
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <410A95B1.5020305@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:
>
>
> If we decide that IDs are to be compared byte for
> byte for equality, 
> then (1) I'm not sure that they need to be URIs and
> (2) I would agree 
> that the requirement to require relative URIs to be
> resolved seems 
> counter to this.

(1) IDs don't need to be URIs the same way XML
namespace names didn't have to be URIs. However there
is a certain contingent in the Web standards world
that believes a cheap way to create unique identifiers
is for them to be URIs. A lot of that contingent are
subscribed to the atom-syntax list. 

(2) Which is why the XML Plenary on relative URIs in
namespace names[0] deprecated the use of relative URIs
in namespace names. The discussion we are having now
is a mirror of the same exact discussion people had
four years ago about relative URIs and namespace
names. 

> If we decide that IDs need to be normalized before
> comparision, and we 
> have other places where xml:base is part of the
> normalization, then it 
> seems inconsistent to rule out this one case.

It is already spelled out where xml:base processing
should be applied in the spec. I don't see why it
can't be explicitly mentioned that it does NOT apply
to atom:id elements and that atom:id elements MUST be
absolute URI values. 


[0] http://www.xmlhack.com/read.php?item=758 


=====
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 Jul 30 15:44:39 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27538
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 15:44:38 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UJW9uo088558;
	Fri, 30 Jul 2004 12:32: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 i6UJW992088557;
	Fri, 30 Jul 2004 12:32: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 i6UJW8Ef088549
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 12:32: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 MAA11107
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 12:32:07 -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 MAA07853
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 12:32:07 -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, 30 Jul 2004 12:32:06 -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 <0I1O00IKOJLG01@shazam.verity.com> for atom-syntax@imc.org; Fri,
 30 Jul 2004 12:32:06 -0700 (PDT)
Date: Fri, 30 Jul 2004 12:32:04 -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: Date attributes
In-reply-to: <41099F2B.4090003@intertwingly.net>
To: atom-syntax@imc.org
Message-id: 
 <6630066AD21DE6A646CD765C@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: <41099F2B.4090003@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 Thursday, July 29, 2004 9:06 PM -0400 Sam Ruby <rubys@intertwingly.net> wrote:
>
> If you look at ISO 8601[1], section 5.3.1, you will see that there is a
> syntax for defining local times: one simply omits the time zone information.
>
> Another reference worth reading is in the XML Schema Part 2: Datatypes[2].

Excellent. Let's do that. The XML Schema document is also clear
about how to compare local times with unknown time zone, in section
"3.2.7.3 Order relation on dateTime". That should be normative
for Atom.

Should local times should be allowed when publishing entries?
We need them in feeds and archiving, because of older databases,
but can we forbid them for new content?

wunder
--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Fri Jul 30 16:27:07 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28927
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 16: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 i6UKHvt6092147;
	Fri, 30 Jul 2004 13:17: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 i6UKHv0O092146;
	Fri, 30 Jul 2004 13:17: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 i6UKHuZI092132
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 13:17: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 1BFB77C0F3; Fri, 30 Jul 2004 23:13:04 +0200 (CEST)
Date: Fri, 30 Jul 2004 22:22:04 +0200
To: "Antone Roundy" <antone@geckotribe.com>
Subject: Re: Relative URI references
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <5D441634-E25D-11D8-BDD2-003065EA6144@geckotribe.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: <opsbyv62u4uvpchu@quark>
In-Reply-To: <5D441634-E25D-11D8-BDD2-003065EA6144@geckotribe.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 30 Jul 2004 13:19:23 -0600, Antone Roundy <antone@geckotribe.com>  
wrote:

> If a feed is only using relative URIs for atom:id, and if they're going  
> to continue using the same base for new entries after the move, they  
> could conceivably still use the old xml:base.  That would be a bit odd  
> though.

Yes, it's odd. Everything regarding relative URI's in atom:id is imho odd.

> A more practical approach than specifying xml:base for every old entry  
> would be to write out the entire ID explicitly for old entries:
>
> <atom:id>http://example.com/blog/3287234</atom:id>

Of course. But then what's the point in not doing that in the first place?  
E.g., what is gained by not providing an absolute URI to begin with? I  
know what's «lost»:

   1. All consumers need to process the ID to make it absolute.

   2. All consumers need to know that any URI in atom:id that isnt't
      prefixed with a scheme, is relative.

   3. The publisher needs to provide either Content-Location or xml:base
      to make it possible for the consumer to process atom:id.

   4. When the author moves a feed or entry, she will have to either
      resolve all relative ID's and make them absolute, or apply the
      correct xml:base on all atom:id's that are affected by the
      relocation.

   5. The author needs to find out which ID's are affected by the
      relocation.

There are so many things that can go wrong in the above 5 points that I  
don't even know where to start. So, I'll start from top:

   1. Not all consumers know that this is needed. It's not stated
      anywhere that it is, and even if it was, you have no guarantee
      that they will read it. If they needn't process the ID, no
      such statement would be necessary.

   2. Few consumers know this. It's a simple rule, but it's not
      stated anywhere in the Atom specification, and even if it was,
      you have no guarantee that they will read it. If they needn't
      process the ID, no such statement would be necessary.

   3. Many authors just can't provide Content-Location, since
      the feeds are served statically. Having to provide xml:base
      also isn't stated explicitly anywhere, and even if it was,
      you have no guarantee that they will read it. If they needn't
      apply an URI base to the ID, no such statement would be
      necesarry.

   4. Authors will get this wrong or forget it. Either way, it needs
      to be explicitly stated in the specification. Even if it was,
      you have no guarantee that they will read it. If they just
      used an absolute URI to begin with, this wouldn't be an issue.

   5. This can be quite a hassle, and if entries are forgotten,
      they will have mutated ID's.

None of the above points would be an issue if the ID was absolute to begin  
with.

> They'd have to have some way to determine which entries were old, and  
> thus had the old base URI (unless they'd always been storing the whole  
> thing locally but shortening it when publishing the feed).

Yes. Isn't this begging for mutable and non-unique ID's?

> But once again, I'm not necessarily advocating relative URIs for  
> atom:id.  The arguments against seem stronger than the arguments for

What arguments exists for relative URI's in atom:id? Maybe I haven't read  
every mail as thorough as I should, but the only I've seen so far, is  
consistency. E.g., if we allow for xml:base and relative URI's everywhere  
else in Atom, we should allow for it in atom:id as well, because it's an  
URI like every other.

-- 
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 Jul 30 16:42: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 QAA29598
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 16:42:25 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UKUpva092861;
	Fri, 30 Jul 2004 13: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 i6UKUp5V092860;
	Fri, 30 Jul 2004 13:30: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 i6UKUoJf092850
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 13:30:50 -0700 (PDT)
	(envelope-from ndw@nwalsh.com)
Received: from phys-bur-2 ([129.148.9.73])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i6UKUqil017907
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 14:30:52 -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 <0I1O00F01MAREV@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com)
 for atom-syntax@imc.org; Fri, 30 Jul 2004 16:30:52 -0400 (EDT)
Received: from mercury (vpn-129-150-34-27.Central.Sun.COM [129.150.34.27])
 by bur-mail1.east.sun.com
 (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003))
 with ESMTP id <0I1O004VZMBCZ6@bur-mail1.east.sun.com> for atom-syntax@imc.org;
 Fri, 30 Jul 2004 16:30:52 -0400 (EDT)
Received: from ndw by mercury with local (Exim 3.36 #1 (Debian))
	id 1Bqe1Z-0000oc-00	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 16:30:41 -0400
X-URL: http://nwalsh.com/
Date: Fri, 30 Jul 2004 16:30:30 -0400
From: Norman Walsh <ndw@nwalsh.com>
Subject: Re: Identity conundrum
In-reply-to: <20040730183424.84987.qmail@web41208.mail.yahoo.com>
To: Atom Syntax <atom-syntax@imc.org>
Message-id: <87zn5hutjt.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: <20040730183424.84987.qmail@web41208.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-Type: text/plain

/ Dare Obasanjo <kpako@yahoo.com> was heard to say:
| I think you've misinterpreted the discussion and
| created two points of view that don't mesh with
| reality. 

Ah well. Best to ignore me then. :-)

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | If you run after wit you will succeed
http://nwalsh.com/            | in catching folly.-- Montesquieu

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBBCq/mOyltUcwYWjsRAod7AJ4xLwYm8WZckMOxCM1463cILMtz2QCdE3ps
ywLtR0G8FeinJSqJO+nlXX0=
=EBPt
-----END PGP SIGNATURE-----
--=-=-=--



From owner-atom-syntax@mail.imc.org  Fri Jul 30 16:59: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 QAA00203
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 16:59: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 i6UKp8AO094143;
	Fri, 30 Jul 2004 13:51: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 i6UKp70J094142;
	Fri, 30 Jul 2004 13:51:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UKp6hF094100
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 13:51: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 453747C130; Fri, 30 Jul 2004 23:46:19 +0200 (CEST)
Date: Fri, 30 Jul 2004 22:55:25 +0200
To: "Eric Scheid" <eric.scheid@ironclad.net.au>
Subject: Re: PaceDates
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <BD2FE2E1.23922%eric.scheid@ironclad.net.au>
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: <opsbyxqnlzuvpchu@quark>
In-Reply-To: <BD2FE2E1.23922%eric.scheid@ironclad.net.au>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 30 Jul 2004 11:34:57 +1000, Eric Scheid  
<eric.scheid@ironclad.net.au> wrote:

>> That is UTC. The only difference is that the local timezone is unknown.  
>> If you think the specification text could make this clearer, please  
>> feel free to suggest what such language might look like.
>
> my point is you've SHOULD'd against it.

Okay.

> append: <<, or "-00:00" if the UTC time is known but the local time zone  
> is unknown (eg. as a centralised hosting service might know)>>

Done. Tell me if it's appended or implemented incorrectly.

> <summary is also a wildcard element - it contains arbitrary, subjective,  
> and mutable content, and no one will know a priori whether
> it will be a truncated first paragraph, a hand written summary, a
> machine written summary, a bunch of keywords mushed together.

That's different, since the content of <summary won't be parsed and
_understood_ in any way by a tool.

> Nonetheless, it's a very useful thing. Ditto 'dateline' aka 'date'. It's
> content, and it's valuable.

I can agree to atom:date being a 100% author-provided, subjective,
human-eye-intended date, but don't know how that can be specified to
cater for the current practice at the same time.

>> Who wants it, really? I know that Dare have written several times that  
>> he has never seen or heard a use case for it, but if the consensus is
>> that this date should be available, then okay. I think that major
>> changes should be signified with another mechanism than a date, though.
>
> I want it. I asked Brent Simmons (of NNW fame) and he'd love to have it.

Okay. I feel that this is such a far stretch after a more professional
publishing model that I don't understand why the course isn't followed
completely. If you want the perks of a professional publishing model,
why don't you just conform to one? 'Updated' is a shortcut to some of
the benefits of a professional, revisioned publishing model, but leaves
so many things «out in the blue» that it's still a hobby-publishing
model.

(I'm sorry if the word «hobby» is offending -- my intention is not to
offend anyone, it's just used to separate the two models.)

What happens when people wants another little piece of the professional
publishing model? And another piece? Should it be implemented into Atom
piece by piece, or should we instead just slam the stake in the ground
and create a really clear separation between the «hobby» and the
«professional» model?

> Others can see the utility of it. People are hacking current values of
> <pubDate to get the same effect today because they don't have it.

Atom doesn't have <pubDate>. If PaceDates gets consensus and is rolled
into the specification, Atom will have the equivalent 'date', which can,
but SHOULD NOT, be used for this purpose. 'modified' should. If the
changes you have made are so uninteresting that the entry is not worth
seeing again, don't change modified. If it is, change modified.

If you want a way to separate minor from major changes, apply a
professional publishing model with revisioning. Then you get version
control as a bonus.

> 'updated' would also be used when an entry has major changes made in
> lieu of munging 'issued', which I thought was a goal of yours.

'issued' will in any case never mean 'first-issued' in a hobby
publishing model, which is why I have suggested 'first-issued' to be
used. I'm beginning to think that 'first-issued' should be withdrawn,
however, and rather have 'issued' change semantics depending on what
profile the feed conforms to.

The feed conforms to Atom Core when no profile is specified. If one or
more are specified, it conforms to them. A profile can change the
semantics of existing elements (although not so much that it makes them
backwards incompatible) and introduce new elements. Ken's suggestion on
how to apply a profile to a feed, is this:

<feed version="1.0">
   <profile xmlns="http://purl.org/atom/ns#professional-publishing" />
   [...]
</feed>

A nice thing about this mechanism is that the 'profile' element would
reside in the non-core Atom namespace. When provided, it says that «This
feed conforms to the profile "Professional Publishing"», which e.g. will
change the semantic of atom:issued to be «The issuance of this
particular revision of a resource» and atom:id to require a  revision-
supportive URI scheme.

This is only an example, but I hope it gives you an idea of how it
might work. The point of not just applying the "Professional Publishing"
namespace to the whole Atom feed, is because everything SHOULD (or MUST)
be backwards compatible with Atom Core, and thus won't not understanding
this profile break clients (badly).

-- 
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 Jul 30 17:09: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 RAA00653
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 17:09: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 i6UL1RRB094675;
	Fri, 30 Jul 2004 14:01:27 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6UL1RFI094674;
	Fri, 30 Jul 2004 14:01:27 -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 i6UL1OfW094668
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 14:01:26 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p06110474bd3067782a4f@[10.20.30.249]>
Date: Fri, 30 Jul 2004 14:01:27 -0700
To: Atom WG <atom-syntax@imc.org>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Moratorium on dates discussion, starting now
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>


Greetings again. The current threads on dates are not going anywhere. 
Lots of things are being said, but not much is being heard. And we're 
not getting any closer to a widely-held consensus, yet that is our 
only way forward.

So, as of this message, Tim and I are calling a ONE-WEEK MORATORIUM 
on any date-related discussion on the mailing list. No rehashing, no 
new ideas, no new paces. The purpose of this moratorium on speaking 
on the list is to get everyone to think to themselves:

- what do I want for dates in Atom?

- what do I *really* need for dates in Atom?

There is a big difference between these two questions, and that 
difference is going to be the thing that will help us come to 
consensus. The act of thinking about it silently for a week should 
help each of us (even those who don't have strong opinions) to figure 
out what it is we most care about. That will, in turn, help us work 
towards a consensus.

Note that this a moratorium on mailing-list traffic. It is fine if 
you want to talk to individuals off-line if that will help your 
thought process on what you want, and what you need, for dates.

And, yes, Tim and I have a plan of what we will announce next Friday 
as the way forward. What we do is not relevant to how you should be 
thinking about this, but rest assured that the next step will be one 
that will focus on consensus-building.

So, even if some has just posted something that you really, really 
want to respond to: don't. Sit and think about dates for a week. And 
please participate in the other active non-date topics on the list. 
Thanks!

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Fri Jul 30 17:10:44 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00745
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 17:10: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 i6UL4TKe094850;
	Fri, 30 Jul 2004 14: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 i6UL4Tui094849;
	Fri, 30 Jul 2004 14:04: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 i6UL4SX4094842
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 14:04: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 1DB9E7C130; Fri, 30 Jul 2004 23:59:41 +0200 (CEST)
Date: Fri, 30 Jul 2004 23:08:50 +0200
To: "Martin Duerst" <duerst@w3.org>
Subject: Re: PaceRecommendIdScheme
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <4.2.0.58.J.20040729172140.05b23408@localhost> <4.2.0.58.J.20040729172140.05b23408@localhost> <4.2.0.58.J.20040730142059.04e8fcb0@localhost>
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: <opsbyyc00buvpchu@quark>
In-Reply-To: <4.2.0.58.J.20040730142059.04e8fcb0@localhost>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 30 Jul 2004 14:30:24 +0900, Martin Duerst <duerst@w3.org> wrote:

> My guess is that if we just recomment a scheme, then we will
> just get something hard-coded, with some assumptions that easily
> may break the properties we need.

I'm not saying recommending a scheme is enough. Please read  
PaceRecommendIdScheme if you haven't, because that pace does a lot more  
than just recommending a scheme. It still doesn't do enough to prevent bad  
ID's, though, so any language on how to improve it is appreciated.

> We really have to get the message out there that it's not the
> scheme that counts, it's how the ids are created and maintained
> properly.

Definately. Though, recommending a scheme other than HTTP will make people  
stop thinking that the URI is dereferencable, and thus make it a lot less  
transient. It has been said that the problem with HTTP URI's is not that  
they're HTTP URI's, but the way people think about HTTP URI's. It's this  
line of thought we need to fight and prevent, and the most effective way  
to do it, is to recommend another scheme.

> How long do you think it might take the IPTC to 'perhaps study if
> NewsML URN are of interest for a broad range of users'? Do you
> want to wait that long for the Atom spec to finish? I don't.

If we agree that it's a good idea to recommend a scheme, it's just to  
begin pushing on LSID and 'tag' to finish, and IPTC to widen NewsML URN's  
application space. If either of this is done by the time Atom goes 1.0, we  
will have to reconsider recommending a scheme, but if one or more of them  
are, there's no problem.

> Nobody is telling anybody that we should refrain from using it.
> But if we make it the only scheme, or the 'recommended' scheme,
> we are bound to put additional requirements and pressure on that
> scheme, which may not work out well in the long range.

Maybe, maybe not. I'm not all that worried about the impact Atom's  
recommended URI scheme will have on the picked scheme, though.

> As a (theoretical) example, assume that currently newsml:
> would be allowed to point to anything, but for certain
> reasons, the IPTC wanted to change the definition so that
> new ids created would only refer to NewsML items.

Maybe, and just maybe, this is a good point and example. I'd like to note,  
though, that it's perfectly fine for Atom to specify its own URI scheme.  
It's also no problem changing the recommended scheme whenever this happens.

>>> With the language above, there is a risk some blogging tools hard-code
>>> newsml into their code. That would be bad.
>>
>> Although I don't necessarily think that it's a very good idea; why would
>> that be bad, exactly?
>
> Because some people may want to use different ids, or may want to use
> different ids because their content comes from somewhere else and
> already has an id.

I'd say that most existing ID's don't conform to atom:id's requirements  
anyway, so that's not something I'm concerned about. atom:id is probably  
the most important facet of Atom publishers needs to conform to, and I  
don't think any tool conforms to it today.

-- 
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 Jul 30 17:29: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 RAA01581
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 17: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 i6ULHUTW096212;
	Fri, 30 Jul 2004 14:17: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 i6ULHUWS096211;
	Fri, 30 Jul 2004 14:17:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtpgateway.itweb.no ([213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ULHTbZ096203
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 14:17: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 135C67C130; Sat, 31 Jul 2004 00:12:42 +0200 (CEST)
Date: Fri, 30 Jul 2004 23:21:54 +0200
To: "Walter Underwood" <wunder@verity.com>
Subject: Re: PaceDates
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <EB08F534-E1A8-11D8-9043-003065EA6144@geckotribe.com> <opsbxt1gjeuvpchu@quark> <0923D16D8E7A4D65D7927A8A@adsl-64-166-133-244.dsl.snfc21.pacbell.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: <opsbyyysxauvpchu@quark>
In-Reply-To: <0923D16D8E7A4D65D7927A8A@adsl-64-166-133-244.dsl.snfc21.pacbell.net>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 30 Jul 2004 10:27:39 -0700, Walter Underwood <wunder@verity.com>  
wrote:

> We cannot talk about future dates without choosing a reference
> clock.

Good point. «Future date» should be UTC-normalized and compared with the  
current UTC datetime, on the server.

> NNTP got this wrong, using a client date to select server-dated
> items, so articles are consistently missed or double-fetched,
> depending on the sign of the clock skew.

Yes. Clients are very unreliable. Every now and then, someone on USENET  
gets thoroughly spanked because they've misconfigured their date in the  
operating system. User's screwups should as far as possible not influence  
the reliability of the information provided in the format or protocol.

-- 
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 Jul 30 17:44: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 RAA02288
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 17:44: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 i6ULYZnw097931;
	Fri, 30 Jul 2004 14: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 i6ULYZ0F097930;
	Fri, 30 Jul 2004 14:34: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 (smtpgateway.itweb.no [213.236.233.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6ULYY2E097918;
	Fri, 30 Jul 2004 14:34:35 -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 46D147C130; Sat, 31 Jul 2004 00:29:47 +0200 (CEST)
Date: Fri, 30 Jul 2004 23:39:02 +0200
To: "Paul Hoffman / IMC" <phoffman@imc.org>
Subject: Re: Moratorium on dates discussion, starting now
References: <p06110474bd3067782a4f@[10.20.30.249]>
Cc: Atom-Syntax <atom-syntax@imc.org>
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: <opsbyzrcdruvpchu@quark>
In-Reply-To: <p06110474bd3067782a4f@[10.20.30.249]>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 30 Jul 2004 14:01:27 -0700, Paul Hoffman / IMC <phoffman@imc.org>  
wrote:

> So, as of this message, Tim and I are calling a ONE-WEEK MORATORIUM on  
> any date-related discussion on the mailing list. No rehashing, no new  
> ideas, no new paces.

PaceDates[1] is not a new wiki page, but the pace was very recently  
heavily rewritten to capture some of the ideas I've received from the  
discussion. And  believe that I've read every single message written on  
the subject, so I have a pretty good idea about what people thinks and  
wants.

The pace still needs work, but it seems to get more traction than other  
paces about the subject, and if not, I would really like to know what  
problems people have with it.

> There is a big difference between these two questions, and that  
> difference is going to be the thing that will help us come to consensus.

PaceDates is a huge compromise on my part (and others that support my  
view). It tries to capture everything mentioned so far, and tries not to  
discriminate anyone. If this is wrong, please let me know what's not  
captured and what opinion is discriminated, and we can work on that.

Another move in the right direction, is BlogToolDateSurvey[2]. It tries to  
provide a matrix and detailed view of what dates are available in current  
weblog publishing tools, and what the different aggregators do with them.

> So, even if some has just posted something that you really, really want  
> to respond to: don't. Sit and think about dates for a week. And please  
> participate in the other active non-date topics on the list. Thanks!

That's something I can live with, but I will continue with my date  
discussions off-list, on #atom and on the Wiki, because there's still a  
lot that needs to be done, and halting that work and those discussions for  
a week will only make me forget it, not give me a deeper understanding  
about anything.

____
[1] <url: http://intertwingly.net/wiki/pie/PaceDates>
[2] <url: http://intertwingly.net/wiki/pie/BlogToolDateSurvey>


-- 
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 Jul 30 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 TAA07651
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 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 i6UN05Dp004350;
	Fri, 30 Jul 2004 16: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 i6UN05Ww004349;
	Fri, 30 Jul 2004 16:00: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 i6UN04ee004330
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 16:00: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 1CDF57C130; Sat, 31 Jul 2004 01:55:10 +0200 (CEST)
Date: Sat, 31 Jul 2004 01:04:43 +0200
To: "Martin Duerst" <duerst@w3.org>
Subject: Re: PaceBasicAtomID - maybe we're done
Cc: Atom-Syntax <atom-syntax@imc.org>
References: <4.2.0.58.J.20040729172524.04af9780@localhost> <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com> <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com> <4.2.0.58.J.20040729172524.04af9780@localhost> <4.2.0.58.J.20040730143145.04b4fda0@localhost>
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: <opsby3p5o1uvpchu@quark>
In-Reply-To: <4.2.0.58.J.20040730143145.04b4fda0@localhost>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 30 Jul 2004 14:45:24 +0900, Martin Duerst <duerst@w3.org> wrote:

> If I think that on the system I'm setting up, I can guarantee
> persistence of http: as well or better than persistence of some
> other scheme, why do you think you can tell me that it will
> not be consistent?

HTTP URI's are by default transient in that they aren't owned by an  
entity, but just rented. HTTP URI's would only be stable identifiers if  
they could just be bought once by one entity, and if the exipry of that  
entity also expired the URI.

That doesn't mean that an HTTP URI can be sufficiently stable and unique,  
though. An HTTP URI containing the date a given resource was issued would  
most certainly be glboally unique at the time of creation, and almost  
certainly be universally unique for the future, even if the domain would  
be taken over by another entity.

The problem with HTTP URI's in this respect is not what they're not  
capable of providing, but what they're capable of not providing. A NewsML  
URI is actually invalid if it doesn't contain a date for when a resource  
was issued at a given internet domain.

This is not the case for HTTP URI's. Both  
'http://example.com/2004/07/31/23212.html' and  
'http://example.com/23212.html' are perfectly valid HTTP URI's. The former  
is very likely to be universally unique, the latter is very unlikely to  
be. The latter URI would be impossible to express in a NewsML URN.

-- 
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 Jul 30 19:36: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 TAA08613
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 19:36: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 i6UNU0GD006435;
	Fri, 30 Jul 2004 16:30: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 i6UNU0Dt006434;
	Fri, 30 Jul 2004 16:30: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-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 i6UNTxe5006418;
	Fri, 30 Jul 2004 16:30:00 -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 i6UNRj53000333;
	Fri, 30 Jul 2004 17:27:45 -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 <0I1O00850UM4ZA@edgemail1.Central.Sun.COM>; Fri,
 30 Jul 2004 17:30:05 -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 <0I1O00K8QUM43Q@mail.sun.net>; Fri,
 30 Jul 2004 17:30:04 -0600 (MDT)
Date: Fri, 30 Jul 2004 16:30:16 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Moratorium on dates discussion, starting now
In-reply-to: <opsbyzrcdruvpchu@quark>
To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
Cc: Paul Hoffman / IMC <phoffman@imc.org>, Atom-Syntax <atom-syntax@imc.org>
Message-id: <69C86F9B-E280-11D8-B278-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: <p06110474bd3067782a4f@[10.20.30.249]> <opsbyzrcdruvpchu@quark>
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


> Another move in the right direction, is BlogToolDateSurvey[2]. It 
> tries to provide a matrix and detailed view of what dates are 
> available in current weblog publishing tools, and what the different 
> aggregators do with them.

While we're staying away from this subject on the list, I think that 
filling in more rows on  BlogToolDateSurvey would be useful research 
for when we come back to it.  For example, I don't see LiveJournal, 
Roller, or Radio on there.  -Tim



From owner-atom-syntax@mail.imc.org  Fri Jul 30 19:45: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 TAA08905
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 19:45: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 i6UNdPnH006951;
	Fri, 30 Jul 2004 16:39: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 i6UNdPaq006950;
	Fri, 30 Jul 2004 16:39:25 -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 i6UNdPCb006944
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 16:39:25 -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 i6UNdV4Q000413;
	Fri, 30 Jul 2004 16:39:31 -0700
Received: from ussjex01.amer.bea.com ([172.16.120.50]) by ussjfe01.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Fri, 30 Jul 2004 16:39:30 -0700
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: PaceBasicAtomID - maybe we're done
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
Date: Fri, 30 Jul 2004 16:39:30 -0700
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF094A8052@ussjex01.amer.bea.com>
Thread-Topic: PaceBasicAtomID - maybe we're done
Thread-Index: AcR2iSz845r0CVbLRjK0oVNWYqB6/AABK37g
From: "David Orchard" <dorchard@bea.com>
To: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>,
        "Martin Duerst" <duerst@w3.org>
Cc: "Atom-Syntax" <atom-syntax@imc.org>
X-OriginalArrivalTime: 30 Jul 2004 23:39:30.0391 (UTC) FILETIME=[759D8E70:01C4768E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i6UNdPCb006945
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 don't understand this argument.  An HTTP URI is owned by the domain authority.  It's as persistent as that authority decides.  It is not "by default transient".  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.  

Dave

> -----Original Message-----
> From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-
> syntax@mail.imc.org] On Behalf Of Asbjørn Ulsberg
> Sent: Friday, July 30, 2004 4:05 PM
> To: Martin Duerst
> Cc: Atom-Syntax
> Subject: Re: PaceBasicAtomID - maybe we're done
> 
> 
> On Fri, 30 Jul 2004 14:45:24 +0900, Martin Duerst <duerst@w3.org> wrote:
> 
> > If I think that on the system I'm setting up, I can guarantee
> > persistence of http: as well or better than persistence of some
> > other scheme, why do you think you can tell me that it will
> > not be consistent?
> 
> HTTP URI's are by default transient in that they aren't owned by an
> entity, but just rented. HTTP URI's would only be stable identifiers if
> they could just be bought once by one entity, and if the exipry of that
> entity also expired the URI.
> 
> That doesn't mean that an HTTP URI can be sufficiently stable and unique,
> though. An HTTP URI containing the date a given resource was issued would
> most certainly be glboally unique at the time of creation, and almost
> certainly be universally unique for the future, even if the domain would
> be taken over by another entity.
> 
> The problem with HTTP URI's in this respect is not what they're not
> capable of providing, but what they're capable of not providing. A NewsML
> URI is actually invalid if it doesn't contain a date for when a resource
> was issued at a given internet domain.
> 
> This is not the case for HTTP URI's. Both
> 'http://example.com/2004/07/31/23212.html' and
> 'http://example.com/23212.html' are perfectly valid HTTP URI's. The former
> is very likely to be universally unique, the latter is very unlikely to
> be. The latter URI would be impossible to express in a NewsML URN.
> 
> --
> 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 Jul 30 20: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 UAA10030
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 20:07: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 i6UNvoBm008154;
	Fri, 30 Jul 2004 16:57: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 i6UNvoTb008153;
	Fri, 30 Jul 2004 16:57: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 i6UNvmTI008116;
	Fri, 30 Jul 2004 16:57: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 0001D7C0F3; Sat, 31 Jul 2004 02:53:00 +0200 (CEST)
Date: Sat, 31 Jul 2004 02:01:38 +0200
To: "Tim Bray" <Tim.Bray@sun.com>
Subject: Re: Moratorium on dates discussion, starting now
Cc: "Paul Hoffman / IMC" <phoffman@imc.org>, Atom-Syntax <atom-syntax@imc.org>
References: <p06110474bd3067782a4f@[10.20.30.249]> <opsbyzrcdruvpchu@quark> <69C86F9B-E280-11D8-B278-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: <opsby6c0g8uvpchu@quark>
In-Reply-To: <69C86F9B-E280-11D8-B278-000A95A51C9E@sun.com>
User-Agent: Opera M2/7.52 (Win32, build 3834)
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, 30 Jul 2004 16:30:16 -0700, Tim Bray <Tim.Bray@Sun.COM> wrote:

>> BlogToolDateSurvey[2].
>
> While we're staying away from this subject on the list, I think that  
> filling in more rows on  BlogToolDateSurvey would be useful research for  
> when we come back to it.

Yes.

> For example, I don't see LiveJournal, Roller, or Radio on there.

Correct. Anyone with experience with these tools, or any tools mentioned  
BlogToolDateSurvey, should consider themself «called for», and fill out  
whatever they know about the specific tool.

The same goes for aggregators, by the way. This is a huge canvas to paint,  
and we will never finish it if not as good as everyone chips in with some  
notes about their experiences.

-- 
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 Jul 30 22:56: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 WAA18144
	for <atompub-archive@lists.ietf.org>; Fri, 30 Jul 2004 22:56: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 i6V2l8Cm024010;
	Fri, 30 Jul 2004 19:47: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 i6V2l8Mp024009;
	Fri, 30 Jul 2004 19:47:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.200])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V2l7kH024001
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 19:47:08 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id 73so87816rnl
        for <atom-syntax@imc.org>; Fri, 30 Jul 2004 19:47:13 -0700 (PDT)
Received: by 10.38.3.58 with SMTP id 58mr75106rnc;
        Fri, 30 Jul 2004 19:47:13 -0700 (PDT)
Message-ID: <14be96d304073019473567cf52@mail.gmail.com>
Date: Fri, 30 Jul 2004 22:47:13 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: David Orchard <dorchard@bea.com>
Subject: Re: PaceBasicAtomID - maybe we're done
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <32D5845A745BFB429CBDBADA57CD41AF094A8052@ussjex01.amer.bea.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <32D5845A745BFB429CBDBADA57CD41AF094A8052@ussjex01.amer.bea.com>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
Content-Transfer-Encoding: 7bit


On Fri, 30 Jul 2004 16:39:30 -0700, David Orchard <dorchard@bea.com> 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  Sat Jul 31 00:26: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 AAA21979
	for <atompub-archive@lists.ietf.org>; Sat, 31 Jul 2004 00:26: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 i6V4ITfE033404;
	Fri, 30 Jul 2004 21:18: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 i6V4ITXl033403;
	Fri, 30 Jul 2004 21:18:29 -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 i6V4ISKV033396
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 21:18:28 -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 16BC64F030;
	Sat, 31 Jul 2004 00:18:30 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040731091629.00b7ba10@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Sat, 31 Jul 2004 09:21:38 +0900
To: Joe Gregorio <joe.gregorio@gmail.com>, Tim Bray <tim.bray@sun.com>
From: Martin Duerst <duerst@w3.org>
Subject: Re: PaceFeedEquivalence
Cc: Atom Syntax <atom-syntax@imc.org>, Mark Pilgrim <pilgrim@gmail.com>
In-Reply-To: <3f1451f504073008454ca5f9b6@mail.gmail.com>
References: <763E5EDA-E1DE-11D8-B278-000A95A51C9E@sun.com>
 <ED9ED1C6-E194-11D8-B732-000A95A51C9E@sun.com>
 <14be96d30407291338435fdef6@mail.gmail.com>
 <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com>
 <3f1451f50407292027201f90e1@mail.gmail.com>
 <763E5EDA-E1DE-11D8-B278-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>


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.

At 11:45 04/07/30 -0400, Joe Gregorio wrote:

>I'll answer both of the above with a question: What kind of
>URI normalizations should be used when comparing
>atom:id URIs for equivalence?
>
>"Case Normalization"
>"Percent-Encoding Normalization"
>"Path Segment Normalization"
>"Scheme-based Normalization"
>"Protocol-based Normalization"
>
>That is for the *consumer* side of
>atom:id. On the producer side should
>we suggest/require the canonical form
>of URIs[1]? And if so should we
>augment that canonicalization
>to include a unicode normalization form?

No. If Atom is using URIs (which is still the case according
to the current spec), then that wouldn't work, because there
is no way for URIs to know about Unicode characters. If we
change to IRIs (which I hope we will soon), then the IRI
spec explicitly says that senders should get this right
(except for some very specific cases of dealing with legacy
encodings).

Regards,    Martin.



From owner-atom-syntax@mail.imc.org  Sat Jul 31 00: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 AAA21999
	for <atompub-archive@lists.ietf.org>; Sat, 31 Jul 2004 00:26: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 i6V4IbnL033420;
	Fri, 30 Jul 2004 21: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 i6V4IbCs033419;
	Fri, 30 Jul 2004 21:18:37 -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 i6V4IbUt033413
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 21:18:37 -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 1EEA24F009;
	Sat, 31 Jul 2004 00:18:35 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040731092223.050e5f10@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Sat, 31 Jul 2004 09:26:53 +0900
To: Sam Ruby <rubys@intertwingly.net>, Tim Bray <Tim.Bray@Sun.COM>
From: Martin Duerst <duerst@w3.org>
Subject: Re: PaceFeedEquivalence
Cc: Mark Pilgrim <pilgrim@gmail.com>, Joe Gregorio <joe.gregorio@gmail.com>,
        Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <410A90E7.5060302@intertwingly.net>
References: <05B5FAC5-E24F-11D8-B278-000A95A51C9E@sun.com>
 <ED9ED1C6-E194-11D8-B732-000A95A51C9E@sun.com>
 <14be96d30407291338435fdef6@mail.gmail.com>
 <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com>
 <3f1451f50407292027201f90e1@mail.gmail.com>
 <763E5EDA-E1DE-11D8-B278-000A95A51C9E@sun.com>
 <3f1451f504073008454ca5f9b6@mail.gmail.com>
 <14be96d3040730102157e3a17e@mail.gmail.com>
 <05B5FAC5-E24F-11D8-B278-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>


At 14:18 04/07/30 -0400, Sam Ruby wrote:

>Let's look at this from a producer side.  If "PlanetSun" ever has an Atom 
>1.0 feed, MUST the ids be byte for byte identical to the ones that these 
>entries were based off of, or merely equivalent?
>
>If we don't mandate byte for byte correspondence, then it is NOT OK for 
>sofware to do simple string comparisons.  They must check for equivalence.
>
>If we mandate byte for byte correspondence, then there is no need for 
>clients to do anything other than byte for byte comparisons.  In fact, if 
>they attempt to cannonicalize, then they may identify false matches.

Sam, I'm not sure what you are talking about here.

This is XML, there is no room for byte-for-byte equivalence at all.
The same ID can once be published in ASCII, once in UTF-16, and
once in EBCDIC, which will be different byte sequences, but for
XML, and also for URIs, they nevertheless will be the same sequence
of characters. The sequence of characters (also called codepoints)
is the absolute minimum we need, and it's what people mean when
they talk about simple string comparison, because in every parser
we know, the input gets converted to a single encoding before
any further work.

Regards,    Martin.



From owner-atom-syntax@mail.imc.org  Sat Jul 31 00: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 AAA22083
	for <atompub-archive@lists.ietf.org>; Sat, 31 Jul 2004 00:29: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 i6V4NUSb033829;
	Fri, 30 Jul 2004 21:23: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 i6V4NUUC033828;
	Fri, 30 Jul 2004 21:23: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 i6V4NTuw033821
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 21:23: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 i6V4LG53022786
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 22:21:16 -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 <0I1P0050O87BGU@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Fri, 30 Jul 2004 22:23:36 -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 <0I1P00KV687A3Q@mail.sun.net> for atom-syntax@imc.org; Fri,
 30 Jul 2004 22:23:35 -0600 (MDT)
Date: Fri, 30 Jul 2004 21:23:53 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceFeedEquivalence
In-reply-to: <4.2.0.58.J.20040731091629.00b7ba10@localhost>
To: Martin Duerst <duerst@w3.org>
Cc: Joe Gregorio <joe.gregorio@gmail.com>, Atom Syntax <atom-syntax@imc.org>,
        Mark Pilgrim <pilgrim@gmail.com>
Message-id: <6E2041D2-E2A9-11D8-B278-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: <763E5EDA-E1DE-11D8-B278-000A95A51C9E@sun.com>
 <ED9ED1C6-E194-11D8-B732-000A95A51C9E@sun.com>
 <14be96d30407291338435fdef6@mail.gmail.com>
 <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com>
 <3f1451f50407292027201f90e1@mail.gmail.com>
 <763E5EDA-E1DE-11D8-B278-000A95A51C9E@sun.com>
 <4.2.0.58.J.20040731091629.00b7ba10@localhost>
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 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



From owner-atom-syntax@mail.imc.org  Sat Jul 31 00: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 AAA22463
	for <atompub-archive@lists.ietf.org>; Sat, 31 Jul 2004 00:34: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 i6V4QH7L033961;
	Fri, 30 Jul 2004 21:26: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 i6V4QHQE033960;
	Fri, 30 Jul 2004 21:26:17 -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 i6V4QGat033953
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 21:26:16 -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 i6V4O353023946
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 22:24:03 -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 <0I1P00C5H8BYD4@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Fri, 30 Jul 2004 22:26:23 -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 <0I1P00KVB8BY3Q@mail.sun.net> for atom-syntax@imc.org; Fri,
 30 Jul 2004 22:26:22 -0600 (MDT)
Date: Fri, 30 Jul 2004 21:26:39 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceFeedEquivalence
In-reply-to: <4.2.0.58.J.20040731092223.050e5f10@localhost>
To: Martin Duerst <duerst@w3.org>
Cc: Joe Gregorio <joe.gregorio@gmail.com>, Mark Pilgrim <pilgrim@gmail.com>,
        Sam Ruby <rubys@intertwingly.net>, Atom Syntax <atom-syntax@imc.org>
Message-id: <D12669C4-E2A9-11D8-B278-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: <05B5FAC5-E24F-11D8-B278-000A95A51C9E@sun.com>
 <ED9ED1C6-E194-11D8-B732-000A95A51C9E@sun.com>
 <14be96d30407291338435fdef6@mail.gmail.com>
 <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com>
 <3f1451f50407292027201f90e1@mail.gmail.com>
 <763E5EDA-E1DE-11D8-B278-000A95A51C9E@sun.com>
 <3f1451f504073008454ca5f9b6@mail.gmail.com>
 <14be96d3040730102157e3a17e@mail.gmail.com>
 <05B5FAC5-E24F-11D8-B278-000A95A51C9E@sun.com>
 <4.2.0.58.J.20040731092223.050e5f10@localhost>
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 Jul 30, 2004, at 5:26 PM, Martin Duerst wrote:

> This is XML, there is no room for byte-for-byte equivalence at all.

I know I've said this too often, but anyone who cares please go read 
read http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#comparison 
- section 6.2.1 covers this issue in great detail.  -Tim



From owner-atom-syntax@mail.imc.org  Sat Jul 31 01:47: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 BAA25331
	for <atompub-archive@lists.ietf.org>; Sat, 31 Jul 2004 01:47: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 i6V5SE1t045402;
	Fri, 30 Jul 2004 22:28:14 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6V5SEUQ045401;
	Fri, 30 Jul 2004 22:28:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from homer.w3.org (homer.w3.org [18.29.0.30])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6V5SEVZ045391
	for <atom-syntax@imc.org>; Fri, 30 Jul 2004 22:28:14 -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 D876E4F009;
	Sat, 31 Jul 2004 01:28:19 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040731085512.04f51380@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Sat, 31 Jul 2004 14:28:31 +0900
To: Mark Pilgrim <pilgrim@gmail.com>
From: Martin Duerst <duerst@w3.org>
Subject: Re: URI equivalence (was Re: PaceFeedEquivalence)
Cc: Tim Bray <tim.bray@sun.com>, Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <14be96d304073005255215e0d1@mail.gmail.com>
References: <4.2.0.58.J.20040730141415.04b525c8@localhost>
 <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com>
 <ED9ED1C6-E194-11D8-B732-000A95A51C9E@sun.com>
 <14be96d30407291338435fdef6@mail.gmail.com>
 <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com>
 <4.2.0.58.J.20040730141415.04b525c8@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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:25 04/07/30 -0400, Mark Pilgrim wrote:

>On Fri, 30 Jul 2004 14:15:06 +0900, Martin Duerst <duerst@w3.org> wrote:
> > It would be good if your test cases were available without having
> > to log in on sourceforge.
>
>http://feedvalidator.org/testcases/atom/must/

Thanks. Below is my take on each test.


>The specific tests in question are
>
>http://feedvalidator.org/testcases/atom/must/entry_id_duplicate_value_2.xml

slash after authority: scheme-specific, correct

>http://feedvalidator.org/testcases/atom/must/entry_id_duplicate_value_3.xml

colon but no port number: correct


>http://feedvalidator.org/testcases/atom/must/entry_id_duplicate_value_4.xml

default port: scheme-specific, correct


>http://feedvalidator.org/testcases/atom/must/entry_id_duplicate_value_5.xml

casing difference in reg-name: correct


>http://feedvalidator.org/testcases/atom/must/entry_id_duplicate_value_6.xml

percent-encoding difference (~ vs. %7E): correct


>http://feedvalidator.org/testcases/atom/must/entry_id_duplicate_value_7.xml

percent-encoding difference (~ vs. %7e): correct


>http://feedvalidator.org/testcases/atom/must/entry_id_duplicate_value_8.xml

http://example.com/%c7 http://example.com/C%cc%a7

I understand the intention: testing equivalence between precomposed
and decomposed C-cedilla. But that won't work. First, %c7 is a
C-cedilla encoded in iso-8859-1. Using iso-8859-1 in URIs is not
forbidden, but highly discouraged, and in any case, the URI has no
clue what the encoding is. The corresponding UTF-8 would be %C3%87.
[no, iso-8859-1 and UTF-8 are not the same, only US-ASCII is the
same in UTF-8]

Because URIs don't know what encoding is used, there is also absolutely
no way for them to try and do some equivalence between precomposed
and decomposed Unicode characters.

And even for IRIs, the spec is clear that the sender should use
NFC (or even NFKC) as much as possible, i.e. the IRI equivalent of
http://example.com/%C3%87 in the above case, and if that doesn't
happen, these are not treated as equivalent.


Regards,    Martin.



From owner-atom-syntax@mail.imc.org  Sat Jul 31 09:50: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 JAA27808
	for <atompub-archive@lists.ietf.org>; Sat, 31 Jul 2004 09:50: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 i6VDgDKM069691;
	Sat, 31 Jul 2004 06:42: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 i6VDgDp2069690;
	Sat, 31 Jul 2004 06:42:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.196])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VDgCFL069683
	for <atom-syntax@imc.org>; Sat, 31 Jul 2004 06:42:12 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id 73so95877rnl
        for <atom-syntax@imc.org>; Sat, 31 Jul 2004 06:42:11 -0700 (PDT)
Received: by 10.38.88.37 with SMTP id l37mr190761rnb;
        Sat, 31 Jul 2004 06:42:11 -0700 (PDT)
Message-ID: <14be96d3040731064230b356da@mail.gmail.com>
Date: Sat, 31 Jul 2004 09:42:11 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Martin Duerst <duerst@w3.org>
Subject: Re: URI equivalence (was Re: PaceFeedEquivalence)
Cc: Tim Bray <tim.bray@sun.com>, Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <4.2.0.58.J.20040731085512.04f51380@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <4.2.0.58.J.20040730141415.04b525c8@localhost>
 <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com>
 <ED9ED1C6-E194-11D8-B732-000A95A51C9E@sun.com>
 <14be96d30407291338435fdef6@mail.gmail.com>
 <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com>
 <4.2.0.58.J.20040730141415.04b525c8@localhost> <4.2.0.58.J.20040731085512.04f51380@localhost>
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, 31 Jul 2004 14:28:31 +0900, Martin Duerst <duerst@w3.org> wrote:
> >http://feedvalidator.org/testcases/atom/must/entry_id_duplicate_value_8.xml
> 
> http://example.com/%c7 http://example.com/C%cc%a7
> 
> I understand the intention: testing equivalence between precomposed
> and decomposed C-cedilla. But that won't work. First, %c7 is a
> C-cedilla encoded in iso-8859-1.

You're right, this was my mistake in constructing the test.  However,
you correctly determined my intention, so let me reconstruct the test
and ask again.

[1] http://example.com/%C3%87
[2] http://example.com/C%CC%A7

1 unescapes to two bytes, \xc3 \x87, which is the UTF-8 representation
of the Unicode code point U+00C7, which is the NFC form of the
character C-cedilla.

2 unescapes to three bytes, C \xcc \xa7, which is the UTF-8
representation of the Unicode code points U+0043 U+0327, which is the
NFKC form of the character C-cedilla.

After percent-decoding, converting from UTF-8 to Unicode, and
normalizing to Unicode Normalization Form C, these URIs are identical.

Assuming I got this test right this time (and used all the right
terminology, please correct me if I didn't), which of the following
statements are we making:

A) Everyone is expected to perform all of these steps, and therefore
everyone is required to treat these URIs as identical.
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.
C) No one should perform all of these steps, and therefore everyone is
required to treat these URIs as different.

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Sat Jul 31 10:19: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 KAA29940
	for <atompub-archive@lists.ietf.org>; Sat, 31 Jul 2004 10:19: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 i6VE7BUP071329;
	Sat, 31 Jul 2004 07:07:11 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6VE7BET071328;
	Sat, 31 Jul 2004 07:07:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.193])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VE7Ac5071314
	for <atom-syntax@imc.org>; Sat, 31 Jul 2004 07:07:10 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id 73so96142rnl
        for <atom-syntax@imc.org>; Sat, 31 Jul 2004 07:07:09 -0700 (PDT)
Received: by 10.38.3.58 with SMTP id 58mr181985rnc;
        Sat, 31 Jul 2004 07:07:09 -0700 (PDT)
Message-ID: <14be96d304073107076271fe7c@mail.gmail.com>
Date: Sat, 31 Jul 2004 10:07:09 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Tim Bray <tim.bray@sun.com>
Subject: Re: PaceFeedEquivalence
Cc: Martin Duerst <duerst@w3.org>, Joe Gregorio <joe.gregorio@gmail.com>,
        Sam Ruby <rubys@intertwingly.net>, Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <D12669C4-E2A9-11D8-B278-000A95A51C9E@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <05B5FAC5-E24F-11D8-B278-000A95A51C9E@sun.com>
 <ED9ED1C6-E194-11D8-B732-000A95A51C9E@sun.com>
 <14be96d30407291338435fdef6@mail.gmail.com>
 <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com>
 <3f1451f50407292027201f90e1@mail.gmail.com>
 <763E5EDA-E1DE-11D8-B278-000A95A51C9E@sun.com>
 <3f1451f504073008454ca5f9b6@mail.gmail.com>
 <14be96d3040730102157e3a17e@mail.gmail.com>
 <05B5FAC5-E24F-11D8-B278-000A95A51C9E@sun.com>
 <4.2.0.58.J.20040731092223.050e5f10@localhost> <D12669C4-E2A9-11D8-B278-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 Fri, 30 Jul 2004 21:26:39 -0700, Tim Bray <tim.bray@sun.com> wrote:
> On Jul 30, 2004, at 5:26 PM, Martin Duerst wrote:
> 
> > This is XML, there is no room for byte-for-byte equivalence at all.
> 
> I know I've said this too often, but anyone who cares please go read
> read http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#comparison
> - section 6.2.1 covers this issue in great detail.  -Tim

I've read it, and it doesn't mention Unicode normalization forms,
hence my question in the other "URI equivalence" thread.

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Sat Jul 31 10:22: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 KAA00163
	for <atompub-archive@lists.ietf.org>; Sat, 31 Jul 2004 10: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 i6VE9hkE071478;
	Sat, 31 Jul 2004 07: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 i6VE9hmX071477;
	Sat, 31 Jul 2004 07: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.203])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VE9gPX071471
	for <atom-syntax@imc.org>; Sat, 31 Jul 2004 07:09:42 -0700 (PDT)
	(envelope-from eliast@gmail.com)
Received: by mproxy.gmail.com with SMTP id 78so134867rnl
        for <atom-syntax@imc.org>; Sat, 31 Jul 2004 07:09:44 -0700 (PDT)
Received: by 10.38.12.77 with SMTP id 77mr150733rnl;
        Sat, 31 Jul 2004 07:09:44 -0700 (PDT)
Message-ID: <905f7c910407310709c271d62@mail.gmail.com>
Date: Sat, 31 Jul 2004 10:09:44 -0400
From: Elias Torres <eliast@gmail.com>
Reply-To: elias@torrez.us
To: Norman Walsh <ndw@nwalsh.com>
Subject: Re: Identity conundrum
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <87zn5hutjt.fsf@nwalsh.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <20040730183424.84987.qmail@web41208.mail.yahoo.com> <87zn5hutjt.fsf@nwalsh.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


Although I'm not the god of aggregators, like Dare, I think you did
capture in essence the two major point of views in identity.

I also stand with you on the latter. Every change to an entry, makes
it a new entry. Except that when using LSID the identifier just
changes by a version attribute in the LSID.

urn:torrez.us:2004-blog:entry1 -- First Published
urn:torrez.us:2004-blog:entry1:2 -- Typo Fixed or GenX status changed.

So if you compare the two, they are different unique identifiers, but
we can go a step further and from the LSID spec, we can tell that they
both point to the same concept, just different versions of it.

Anyways, it seems that this is very controversial and most likely the
spec will stay the way it is and hopefully some extra wording for
instructing people. At least it accommodates every publisher, but will
make consumers' life more complicated.

Regards,

Elias


On Fri, 30 Jul 2004 16:30:30 -0400, Norman Walsh <ndw@nwalsh.com> wrote:
> / Dare Obasanjo <kpako@yahoo.com> was heard to say:
> | I think you've misinterpreted the discussion and
> | created two points of view that don't mesh with
> | reality.
> 
> Ah well. Best to ignore me then. :-)
> 
>                                         Be seeing you,
>                                           norm
> 
> --
> Norman Walsh <ndw@nwalsh.com> | If you run after wit you will succeed
> http://nwalsh.com/            | in catching folly.-- Montesquieu
> 
> 
>



From owner-atom-syntax@mail.imc.org  Sat Jul 31 11:07: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 LAA01687
	for <atompub-archive@lists.ietf.org>; Sat, 31 Jul 2004 11:07: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 i6VEvbr2073828;
	Sat, 31 Jul 2004 07:57:37 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6VEvbpZ073827;
	Sat, 31 Jul 2004 07:57: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 i6VEvaKt073819
	for <atom-syntax@imc.org>; Sat, 31 Jul 2004 07:57: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 i6VEvcil029325
	for <atom-syntax@imc.org>; Sat, 31 Jul 2004 08:57:38 -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 <0I1Q007041K2DD@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sat, 31 Jul 2004 08:57:38 -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 <0I1Q00CZX1K1E1@mail.sun.net> for atom-syntax@imc.org; Sat,
 31 Jul 2004 08:57:38 -0600 (MDT)
Date: Sat, 31 Jul 2004 07:57:56 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: URI equivalence (was Re: PaceFeedEquivalence)
In-reply-to: <14be96d3040731064230b356da@mail.gmail.com>
To: Mark Pilgrim <pilgrim@gmail.com>
Cc: Atom Syntax <atom-syntax@imc.org>, Martin Duerst <duerst@w3.org>
Message-id: <01E063DE-E302-11D8-B278-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: <4.2.0.58.J.20040730141415.04b525c8@localhost>
 <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com>
 <ED9ED1C6-E194-11D8-B732-000A95A51C9E@sun.com>
 <14be96d30407291338435fdef6@mail.gmail.com>
 <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com>
 <4.2.0.58.J.20040730141415.04b525c8@localhost>
 <4.2.0.58.J.20040731085512.04f51380@localhost>
 <14be96d3040731064230b356da@mail.gmail.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 Jul 31, 2004, at 6:42 AM, Mark Pilgrim wrote:

> A) Everyone is expected to perform all of these steps, and therefore
> everyone is required to treat these URIs as identical.
> 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.
> C) No one should perform all of these steps, and therefore everyone is
> required to treat these URIs as different.

B, so producers SHOULD NOT produce variant spellings of the same URI.  
(B is what will happen regardless of what we write down, so we might as 
well live with that).  We could try for "MUST NOT produce variant 
spellings" if people are comfortable with that. -Tim



From owner-atom-syntax@mail.imc.org  Sat Jul 31 11: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 LAA02977
	for <atompub-archive@lists.ietf.org>; Sat, 31 Jul 2004 11: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 i6VFb9s2076440;
	Sat, 31 Jul 2004 08:37: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 i6VFb963076439;
	Sat, 31 Jul 2004 08:37: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 i6VFb8Hl076432
	for <atom-syntax@imc.org>; Sat, 31 Jul 2004 08:37: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 i6VFcJU9019708;
	Sat, 31 Jul 2004 11:38:21 -0400
Message-ID: <410BBCA1.7080802@intertwingly.net>
Date: Sat, 31 Jul 2004 11:37:05 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: Dare Obasanjo <kpako@yahoo.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Relative URI references
References: <20040730192845.32022.qmail@web41204.mail.yahoo.com>
In-Reply-To: <20040730192845.32022.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: <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:
> 
> (2) Which is why the XML Plenary on relative URIs in
> namespace names[0] deprecated the use of relative URIs
> in namespace names. The discussion we are having now
> is a mirror of the same exact discussion people had
> four years ago about relative URIs and namespace
> names. 

... and since our intentions are to create a 1.0, we don't have to 
deprecate.

OK, I yield to consensus: ID elements need to be absolute.

I've updated my unadvertized atom feed to use the tag scheme for ID 
elements.  At the present time, my link elements remain as relative URIs.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Sat Jul 31 11: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 LAA03100
	for <atompub-archive@lists.ietf.org>; Sat, 31 Jul 2004 11: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 i6VFft85076665;
	Sat, 31 Jul 2004 08:41: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 i6VFftiY076664;
	Sat, 31 Jul 2004 08:41:55 -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 i6VFfsJa076656
	for <atom-syntax@imc.org>; Sat, 31 Jul 2004 08:41:54 -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 i6VFhAbg019871;
	Sat, 31 Jul 2004 11:43:10 -0400
Message-ID: <410BBDC4.2000008@intertwingly.net>
Date: Sat, 31 Jul 2004 11:41:56 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: elias@torrez.us
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Identity conundrum
References: <20040730183424.84987.qmail@web41208.mail.yahoo.com> <87zn5hutjt.fsf@nwalsh.com> <905f7c910407310709c271d62@mail.gmail.com>
In-Reply-To: <905f7c910407310709c271d62@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


Elias Torres wrote:
> Although I'm not the god of aggregators, like Dare, I think you did
> capture in essence the two major point of views in identity.
> 
> I also stand with you on the latter. Every change to an entry, makes
> it a new entry. Except that when using LSID the identifier just
> changes by a version attribute in the LSID.
> 
> urn:torrez.us:2004-blog:entry1 -- First Published
> urn:torrez.us:2004-blog:entry1:2 -- Typo Fixed or GenX status changed.

Going back to Norm's original email:

http://www.imc.org/atom-syntax/mail-archive/msg08148.html

     One idea of identity is that entries have immutable identity. That
     is, an atom:id identifies an atom:entry that cannot change...

     Another view of identity is that entries are snapshots of an
     abstraction that has identity. That is, an atom:id identifies an
     abstraction that might or might not change.

It seems to me that Elias, your notions correspond to the former.  If 
so, this reinforces Norm's observation that there are two points of view.

- Sam Ruby





From owner-atom-syntax@mail.imc.org  Sat Jul 31 12:36: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 MAA04943
	for <atompub-archive@lists.ietf.org>; Sat, 31 Jul 2004 12: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 i6VGQYOT078880;
	Sat, 31 Jul 2004 09:26:34 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6VGQYuX078879;
	Sat, 31 Jul 2004 09:26:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VGQXfb078868;
	Sat, 31 Jul 2004 09:26:33 -0700 (PDT)
	(envelope-from jasnell@us.ibm.com)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11])
	by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i6VGQOu3551474;
	Sat, 31 Jul 2004 12:26:24 -0400
Received: from d03nm122.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170])
	by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6VGQO2B407274;
	Sat, 31 Jul 2004 10:26:24 -0600
In-Reply-To: <410BBDC4.2000008@intertwingly.net>
To: Sam Ruby <rubys@intertwingly.net>
Cc: Atom Syntax <atom-syntax@imc.org>, elias@torrez.us,
        owner-atom-syntax@mail.imc.org
MIME-Version: 1.0
Subject: Re: Identity conundrum
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
From: James M Snell <jasnell@us.ibm.com>
X-MIMETrack: S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/31/2004 09:26:05 AM,
	Serialize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/31/2004 09:26:05 AM,
	Serialize complete at 07/31/2004 09:26:05 AM,
	Itemize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/31/2004 09:26:05 AM,
	S/MIME Sign complete at 07/31/2004 09:26:05 AM,
	S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/31/2004 09:26:22 AM,
	S/MIME Sign complete at 07/31/2004 09:26:22 AM,
	Serialize by Router on D03NM122/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at
 07/31/2004 10:26:24,
	Serialize complete at 07/31/2004 10:26:24
Message-ID: <OF0F3762D8.79BA0EF1-ON88256EE2.005936ED-88256EE2.005A4DEC@us.ibm.com>
Date: Sat, 31 Jul 2004 10:26:22 -0600
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z10896_boundary_sign
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>


This is an S/MIME signed message.

---------z10896_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 005A478688256EE2_="

This is a multipart message in MIME format.
--=_alternative 005A478688256EE2_=
Content-Type: text/plain; charset="US-ASCII"

owner-atom-syntax@mail.imc.org wrote on 07/31/2004 08:41:56 AM:

> 
> Elias Torres wrote:
> > Although I'm not the god of aggregators, like Dare, I think you did
> > capture in essence the two major point of views in identity.
> > 
> > I also stand with you on the latter. Every change to an entry, makes
> > it a new entry. Except that when using LSID the identifier just
> > changes by a version attribute in the LSID.
> > 
> > urn:torrez.us:2004-blog:entry1 -- First Published
> > urn:torrez.us:2004-blog:entry1:2 -- Typo Fixed or GenX status changed.
> 
> Going back to Norm's original email:
> 
> http://www.imc.org/atom-syntax/mail-archive/msg08148.html
> 
>      One idea of identity is that entries have immutable identity. That
>      is, an atom:id identifies an atom:entry that cannot change...
> 
>      Another view of identity is that entries are snapshots of an
>      abstraction that has identity. That is, an atom:id identifies an
>      abstraction that might or might not change.
> 
> It seems to me that Elias, your notions correspond to the former.  If 
> so, this reinforces Norm's observation that there are two points of 
view.
> 

This has the potential of going even further down a rabbit hole without 
any chance of gaining consensus.  Yes, there are two points of view: 1) a 
single identity regardless of version and 2) a unique identity for each 
version.  Which is the correct view?  Well, both are valid and, IMHO, Atom 
shouldn't have to care which view a publisher decides to adhere to.  I'd 
say that items in an Atom feed MUST have a single unique URI.  A person 
subscribing to the first option will have an atom feed in which a single 
item may change over time.  A person subscribing to the second option will 
have an atom feed that contains a new item for each version of the 
content.

Option 1:
  <feed>
    <entry>
      <id>urn:myentry</id>
      <content>Hello</content>
    </entry>
  </feed>

  <feed>
    <entry>
      <id>urn:myentry</id>
      <content>Hello There</content>
    </entry>
  </feed>

Option 2:

  <feed>
    <entry>
      <id>urn:myentry:2</id>
      <content>Hello There</content>
    </entry>
    <entry>
      <id>urn:myentry:1</id>
      <content>Hello</content>
    </entry>
  </feed>

Unless we either: choose to allow both points of view or force one side to 
compromise, we're not going to achieve consensus on this issue.

> - Sam Ruby
> 
> 
> 


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

--=_alternative 005A478688256EE2_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>owner-atom-syntax@mail.imc.org wrote on 07/31/2004
08:41:56 AM:<br>
<br>
&gt; <br>
&gt; Elias Torres wrote:<br>
&gt; &gt; Although I'm not the god of aggregators, like Dare, I think you
did<br>
&gt; &gt; capture in essence the two major point of views in identity.<br>
&gt; &gt; <br>
&gt; &gt; I also stand with you on the latter. Every change to an entry,
makes<br>
&gt; &gt; it a new entry. Except that when using LSID the identifier just<br>
&gt; &gt; changes by a version attribute in the LSID.<br>
&gt; &gt; <br>
&gt; &gt; urn:torrez.us:2004-blog:entry1 -- First Published<br>
&gt; &gt; urn:torrez.us:2004-blog:entry1:2 -- Typo Fixed or GenX status
changed.<br>
&gt; <br>
&gt; Going back to Norm's original email:<br>
&gt; <br>
&gt; http://www.imc.org/atom-syntax/mail-archive/msg08148.html<br>
&gt; <br>
&gt; &nbsp; &nbsp; &nbsp;One idea of identity is that entries have immutable
identity. That<br>
&gt; &nbsp; &nbsp; &nbsp;is, an atom:id identifies an atom:entry that cannot
change...<br>
&gt; <br>
&gt; &nbsp; &nbsp; &nbsp;Another view of identity is that entries are snapshots
of an<br>
&gt; &nbsp; &nbsp; &nbsp;abstraction that has identity. That is, an atom:id
identifies an<br>
&gt; &nbsp; &nbsp; &nbsp;abstraction that might or might not change.<br>
&gt; <br>
&gt; It seems to me that Elias, your notions correspond to the former.
&nbsp;If <br>
&gt; so, this reinforces Norm's observation that there are two points of
view.<br>
&gt; </tt></font>
<br>
<br><font size=2><tt>This has the potential of going even further down
a rabbit hole without any chance of gaining consensus. &nbsp;Yes, there
are two points of view: 1) a single identity regardless of version and
2) a unique identity for each version. &nbsp;Which is the correct view?
&nbsp;Well, both are valid and, IMHO, Atom shouldn't have to care which
view a publisher decides to adhere to. &nbsp;I'd say that items in an Atom
feed MUST have a single unique URI. &nbsp;A person subscribing to the first
option will have an atom feed in which a single item may change over time.
&nbsp;A person subscribing to the second option will have an atom feed
that contains a new item for each version of the content.</tt></font>
<br>
<br><font size=2><tt>Option 1:</tt></font>
<br><font size=2><tt>&nbsp; &lt;feed&gt;</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &lt;entry&gt;</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; &lt;id&gt;urn:myentry&lt;/id&gt;</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; &lt;content&gt;Hello&lt;/content&gt;</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &lt;/entry&gt;</tt></font>
<br><font size=2><tt>&nbsp; &lt;/feed&gt;</tt></font>
<br>
<br><font size=2><tt>&nbsp; &lt;feed&gt;</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &lt;entry&gt;</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; &lt;id&gt;urn:myentry&lt;/id&gt;</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; &lt;content&gt;Hello There&lt;/content&gt;</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &lt;/entry&gt;</tt></font>
<br><font size=2><tt>&nbsp; &lt;/feed&gt;</tt></font>
<br>
<br><font size=2><tt>Option 2:</tt></font>
<br>
<br><font size=2><tt>&nbsp; &lt;feed&gt;</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &lt;entry&gt;</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; &lt;id&gt;urn:myentry:2&lt;/id&gt;</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; &lt;content&gt;Hello There&lt;/content&gt;</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &lt;/entry&gt;</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &lt;entry&gt;</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; &lt;id&gt;urn:myentry:1&lt;/id&gt;</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; &lt;content&gt;Hello&lt;/content&gt;</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &lt;/entry&gt;</tt></font>
<br><font size=2><tt>&nbsp; &lt;/feed&gt;</tt></font>
<br>
<br><font size=2><tt>Unless we either: choose to allow both points of view
or force one side to compromise, we're not going to achieve consensus on
this issue.</tt></font>
<br><font size=2><tt><br>
&gt; - Sam Ruby<br>
&gt; <br>
&gt; <br>
&gt; <br>
</tt></font>
<br>
<br><font size=2 face="sans-serif">- James M Snell<br>
 &nbsp;jasnell@us.ibm.com<br>
 &nbsp;http://www.ibm.com<br>
 &nbsp;(877) 511-5082 / Office<br>
 &nbsp;930-1979 / Tie Line</font>
<br>
--=_alternative 005A478688256EE2_=--

---------z10896_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIIUOAIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIISWDCCAtow
ggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1
aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAy
MDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA629xc49NpAPz
cAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7glzJKgPkPzlTZZfznznGbmAWVnNBQ
lyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnwNclOnnP2sKufuPzbTImQTTi5c8JZNZcM
J0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEEBAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1Ud
DgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAPBgNVHRMBAf8EBTADAQH/MDEGA1UdJQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUH
AwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvu
jQupk2oCScMd3FIHLE7hOfu8YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14ke
McF9ViNdewEoBGiAycUq8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIC2jCCAkOgAwIB
AgIDAxS2MA0GCSqGSIb3DQEBBAUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwMTE0MjIw
NzExWhcNMTExMjMxMjIwNzExWjBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25h
bCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrb3Fzj02kA/NwCy5KFMiY
tFgyTJ6kMSQLVSs9uwVHIAVkqy/enDQwZ9b/7uCXMkqA+Q/OVNll/OfOcZuYBZWc0FCXI9qw60KO
J/rTd65FdF4dwp8cw8si0qjOJtYg8cm46fA1yU6ec/awq5+4/NtMiZBNOLlzwlk1lwwnRgXNNwID
AQABo4GqMIGnMBEGCWCGSAGG+EIBAQQEAwIAhzAOBgNVHQ8BAf8EBAMCAcYwHQYDVR0OBBYEFK5U
DpLqqDOpKyQtx8hvMNze80pAMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMA8GA1Ud
EwEB/wQFMAMBAf8wMQYDVR0lBCowKAYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYB
BQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAMnJ7c2YLyrY/PKlFl+7sm8NENfWtFxqdm+6NC6mTagJJ
wx3cUgcsTuE5+7xh9+/G0tTfLzA1qZAQ5GNMPXvmoB9+vJfKnC2JWMFQpIOUEJDXiR4xwX1WI117
ASgEaIDJxSrxHcuuV/hMIO9bgZ6C41MUVmdLTKBgBOImTuIPK8QwggMgMIICiaADAgECAgQ13vTP
MA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQL
EyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0MTUxWhcN
MTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMk
RXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKKlQRkrPFr
U18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkwrFEeO68r
1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOgYaRfMF0x
CzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBD
ZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAxODA4MjIx
NjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAdBgNV
HQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0HQQAEDTAL
GwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwlMQ0AppJu
f7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn00DbOyZY
sih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMgMIICiaADAgEC
AgQ13vTPMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0
MTUxWhcNMTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsG
A1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKK
lQRkrPFrU18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkw
rFEeO68r1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOg
YaRfMF0xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNl
Y3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAx
ODA4MjIxNjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAdBgNVHQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0H
QQAEDTALGwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwl
MQ0AppJuf7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn
00DbOyZYsih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMmMIIC
j6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIxNjM2NTRaMIGFMQsw
CQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEXMBUGA1UEAxMOSmFt
ZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkqhkiG9w0BCQEWEmph
c25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwKpbDG3zMatEuuOT
FYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSyd+7nwqAvbBfPj+0S
vcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7tBJlLrwDRCMoNlPuQ
Kg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQW
BBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOgFAwSamFzbmVs
bEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pAMCcGA1UdJQQgMB4G
CCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAZMKevB7dFfb9
23OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY8BjwVHxiYgG4xkxf
B1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOIzj3lz3xd+uOzqRFg
/Wsg/VMwggMmMIICj6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAy
BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNV
BAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIx
NjM2NTRaMIGFMQswCQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEX
MBUGA1UEAxMOSmFtZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkq
hkiG9w0BCQEWEmphc25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
wKpbDG3zMatEuuOTFYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSy
d+7nwqAvbBfPj+0SvcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7t
BJlLrwDRCMoNlPuQKg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQD
AgXgMB0GA1UdDgQWBBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcU
AgOgFAwSamFzbmVsbEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA
MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQAD
gYEAZMKevB7dFfb923OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY
8BjwVHxiYgG4xkxfB1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOI
zj3lz3xd+uOzqRFg/Wsg/VMxggG7MIIBtwIBATBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJ
bnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0g
Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwF+kzAJBgUrDgMCGgUAoIGiMBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDczMTE2MjYwNVowIwYJKoZIhvcNAQkEMRYE
FK6dpsbXxPCRhzOizK9xzTfuSnUXMEMGCSqGSIb3DQEJDzE2MDQwBwYFKw4DAh0wDgYIKoZIhvcN
AwICAgCAMAoGCCqGSIb3DQMHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAZz376Cp9
fPfsLgj9D1Wq9woyL3yO0P59yqq7Bnyo2n+wXkZ7JQUuChbcKCoraStyJZu/bQ3M3ZsEcoH+dCVA
II6hgAlCcLP95W9xleH0rJ5q4KRKqWzAaJUtG9WCr3Pzmsc7oS5yYbz65SVEowwGarLDeUs42LYy
60juNOsln9sAAAAA

---------z10896_boundary_sign--



From owner-atom-syntax@mail.imc.org  Sat Jul 31 12:54: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 MAA05842
	for <atompub-archive@lists.ietf.org>; Sat, 31 Jul 2004 12: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 i6VGgEck079753;
	Sat, 31 Jul 2004 09:42:14 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6VGgEMJ079752;
	Sat, 31 Jul 2004 09:42:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail06.svc.cra.dublin.eircom.net (mail06.svc.cra.dublin.eircom.net [159.134.118.22])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6VGgDk4079722
	for <atom-syntax@imc.org>; Sat, 31 Jul 2004 09:42:14 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 42605 messnum 2865635 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 31 Jul 2004 16:32:53 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.33.112)
  by mail06.svc.cra.dublin.eircom.net (qp 42605) with SMTP; 31 Jul 2004 16:32:53 -0000
Message-ID: <410BC9B2.9070600@dehora.net>
Date: Sat, 31 Jul 2004 17:32:50 +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: Norman Walsh <ndw@nwalsh.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Identity conundrum
References: <87fz79xt9u.fsf@nwalsh.com>
In-Reply-To: <87fz79xt9u.fsf@nwalsh.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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


Norman Walsh wrote:

> I think I lean towards the latter view, but there's definitely
> something appealing about the simplicity of the former view.

Neither view is simple. And people tend to want to have both views.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Sat Jul 31 12:55: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 MAA05879
	for <atompub-archive@lists.ietf.org>; Sat, 31 Jul 2004 12:55:19 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VGiQIt079901;
	Sat, 31 Jul 2004 09:44: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 i6VGiQX8079900;
	Sat, 31 Jul 2004 09:44:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.195])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VGiNZw079894
	for <atom-syntax@imc.org>; Sat, 31 Jul 2004 09:44:25 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id 74so141796rnk
        for <atom-syntax@imc.org>; Sat, 31 Jul 2004 09:44:26 -0700 (PDT)
Received: by 10.38.9.5 with SMTP id 5mr494275rni;
        Sat, 31 Jul 2004 09:44:26 -0700 (PDT)
Message-ID: <14be96d304073109443d7df1b6@mail.gmail.com>
Date: Sat, 31 Jul 2004 12:44:26 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Tim Bray <tim.bray@sun.com>
Subject: Re: URI equivalence (was Re: PaceFeedEquivalence)
Cc: Atom Syntax <atom-syntax@imc.org>, Martin Duerst <duerst@w3.org>
In-Reply-To: <01E063DE-E302-11D8-B278-000A95A51C9E@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <4.2.0.58.J.20040730141415.04b525c8@localhost>
 <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com>
 <ED9ED1C6-E194-11D8-B732-000A95A51C9E@sun.com>
 <14be96d30407291338435fdef6@mail.gmail.com>
 <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com>
 <4.2.0.58.J.20040730141415.04b525c8@localhost>
 <4.2.0.58.J.20040731085512.04f51380@localhost>
 <14be96d3040731064230b356da@mail.gmail.com> <01E063DE-E302-11D8-B278-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 Sat, 31 Jul 2004 07:57:56 -0700, Tim Bray <tim.bray@sun.com> wrote:
> On Jul 31, 2004, at 6:42 AM, Mark Pilgrim wrote:
> 
> > A) Everyone is expected to perform all of these steps, and therefore
> > everyone is required to treat these URIs as identical.
> > 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.
> > C) No one should perform all of these steps, and therefore everyone is
> > required to treat these URIs as different.
> 
> B

Oh. My. God.

> , so producers SHOULD NOT produce variant spellings of the same URI.
> (B is what will happen regardless of what we write down, so we might as
> well live with that).  We could try for "MUST NOT produce variant
> spellings" if people are comfortable with that. -Tim

Or we could try mandating a URI scheme that is specifically designed
to be used as an identifier, not a
resource-location-and-oh-by-the-way-wouldn't-it-be-cool-to-use-it-as-an-identifer-too.
 I know I said just a few days ago that I was in favor of using any
URI scheme, but Jesus, http:// URIs are incredibly complex.  And then
saying that clients are free to pick and choose their own rules for
comparing them, is just ridiculous.

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Sat Jul 31 12:55: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 MAA05881
	for <atompub-archive@lists.ietf.org>; Sat, 31 Jul 2004 12:55: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 i6VGgYD0079839;
	Sat, 31 Jul 2004 09: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 i6VGgY7Y079838;
	Sat, 31 Jul 2004 09:42: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 i6VGgXI1079832
	for <atom-syntax@imc.org>; Sat, 31 Jul 2004 09:42: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 i6VGhnWT022353;
	Sat, 31 Jul 2004 12:43:49 -0400
Message-ID: <410BCBFC.9000108@intertwingly.net>
Date: Sat, 31 Jul 2004 12:42:36 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 Pilgrim <pilgrim@gmail.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: PaceFeedEquivalence
References: <05B5FAC5-E24F-11D8-B278-000A95A51C9E@sun.com> <ED9ED1C6-E194-11D8-B732-000A95A51C9E@sun.com> <14be96d30407291338435fdef6@mail.gmail.com> <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com> <3f1451f50407292027201f90e1@mail.gmail.com> <763E5EDA-E1DE-11D8-B278-000A95A51C9E@sun.com> <3f1451f504073008454ca5f9b6@mail.gmail.com> <14be96d3040730102157e3a17e@mail.gmail.com> <05B5FAC5-E24F-11D8-B278-000A95A51C9E@sun.com> <4.2.0.58.J.20040731092223.050e5f10@localhost> <D12669C4-E2A9-11D8-B278-000A95A51C9E@sun.com> <14be96d304073107076271fe7c@mail.gmail.com>
In-Reply-To: <14be96d304073107076271fe7c@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


Mark Pilgrim wrote:

> On Fri, 30 Jul 2004 21:26:39 -0700, Tim Bray <tim.bray@sun.com> wrote:
> 
>>On Jul 30, 2004, at 5:26 PM, Martin Duerst wrote:
>>
>>>This is XML, there is no room for byte-for-byte equivalence at all.
>>
>>I know I've said this too often, but anyone who cares please go read
>>read http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#comparison
>>- section 6.2.1 covers this issue in great detail.  -Tim
> 
> I've read it, and it doesn't mention Unicode normalization forms,
> hence my question in the other "URI equivalence" thread.

First, a relatively recent experience with unicode normalization forms 
and URIs: http://earthlingsoft.net/ssp/blog/2004/05/decomposition

Second, from rfc2396bis:

     URI comparison is performed in respect to some particular purpose,
     and software with differing purposes will often be subject to
     differing design trade-offs in regards to how much effort should be
     spent in reducing duplicate identifiers

Apparently, after weighing a similar set of tradeoffs, XML Namespaces 
opted for "Simple String Comparison".  In the context of atom:id, what 
are the costs and benefits of requiring anything more?

- Sam Ruby





From owner-atom-syntax@mail.imc.org  Sat Jul 31 13:17: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 NAA06519
	for <atompub-archive@lists.ietf.org>; Sat, 31 Jul 2004 13:17: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 i6VH9uVh081006;
	Sat, 31 Jul 2004 10:09: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 i6VH9uKg081005;
	Sat, 31 Jul 2004 10:09:56 -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 i6VH9tCp080993
	for <atom-syntax@imc.org>; Sat, 31 Jul 2004 10:09:55 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 55134 messnum 5275359 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 31 Jul 2004 16:37:38 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.33.112)
  by mail13.svc.cra.dublin.eircom.net (qp 55134) with SMTP; 31 Jul 2004 16:37:38 -0000
Message-ID: <410BCAD0.3040501@dehora.net>
Date: Sat, 31 Jul 2004 17:37:36 +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: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
CC: Martin Duerst <duerst@w3.org>, Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceBasicAtomID - maybe we're done
References: <4.2.0.58.J.20040729172524.04af9780@localhost> <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com> <F803A7BC-E0EF-11D8-B732-000A95A51C9E@sun.com> <4.2.0.58.J.20040729172524.04af9780@localhost> <4.2.0.58.J.20040730143145.04b4fda0@localhost> <opsby3p5o1uvpchu@quark>
In-Reply-To: <opsby3p5o1uvpchu@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:

> This is not the case for HTTP URI's. Both  
> 'http://example.com/2004/07/31/23212.html' and  
> 'http://example.com/23212.html' are perfectly valid HTTP URI's. The 
> former  is very likely to be universally unique, the latter is very 
> unlikely to  be.

Nit: you can't make that claim by looking at URIs alone; you have to 
know something about policy and algorithms underpinning their 
generation.

cheers
Bill




From owner-atom-syntax@mail.imc.org  Sat Jul 31 13:19: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 NAA06566
	for <atompub-archive@lists.ietf.org>; Sat, 31 Jul 2004 13:19: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 i6VHCJdP081273;
	Sat, 31 Jul 2004 10:12:19 -0700 (PDT)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i6VHCJMc081272;
	Sat, 31 Jul 2004 10:12: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 i6VHCIBq081255
	for <atom-syntax@imc.org>; Sat, 31 Jul 2004 10:12: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 i6VHCD53027804
	for <atom-syntax@imc.org>; Sat, 31 Jul 2004 12:12:14 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6VHCDjW027800;
	Sat, 31 Jul 2004 12:12:13 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Identity conundrum
References: <OF0F3762D8.79BA0EF1-ON88256EE2.005936ED-88256EE2.005A4DEC@us.ibm.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 31 Jul 2004 12:12:13 -0500
In-Reply-To: <OF0F3762D8.79BA0EF1-ON88256EE2.005936ED-88256EE2.005A4DEC@us.ibm.com>
Message-ID: <m3fz78t82a.fsf@bitsko.slc.ut.us>
Lines: 83
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


James M Snell <jasnell@us.ibm.com> writes:

> [Sam Ruby] wrote on 07/31/2004 08:41:56 AM:
> 
> > Going back to Norm's original email:
> > 
> > http://www.imc.org/atom-syntax/mail-archive/msg08148.html
> > 
> >      One idea of identity is that entries have immutable
> >      identity. That is, an atom:id identifies an atom:entry that
> >      cannot change...
> > 
> >      Another view of identity is that entries are snapshots of an
> >      abstraction that has identity. That is, an atom:id identifies
> >      an abstraction that might or might not change.
> > 
> > It seems to me that Elias, your notions correspond to the former.
> > If so, this reinforces Norm's observation that there are two
> > points of view.
> > 
> 
> This has the potential of going even further down a rabbit hole without 
> any chance of gaining consensus.  Yes, there are two points of view: 1) a 
> single identity regardless of version and 2) a unique identity for each 
> version.  Which is the correct view?  Well, both are valid and, IMHO, Atom 
> shouldn't have to care which view a publisher decides to adhere to.  I'd 
> say that items in an Atom feed MUST have a single unique URI.  A person 
> subscribing to the first option will have an atom feed in which a single 
> item may change over time.  A person subscribing to the second option will 
> have an atom feed that contains a new item for each version of the 
> content.

> Unless we either: choose to allow both points of view or force one side to 
> compromise, we're not going to achieve consensus on this issue.

There is no reason why both models cannot be satisfied with the
current format.

The crux of the issue appears to be a combination of what <id> is
identifying and whether or not an entry (or resource in general) can
have more than one identifier.

The current model, and that of RSS 1.0 and RSS 2.0, is Norm's latter:
<id> identifies the abstraction of "an entry that may have multiple
versions".  It's not really an abstraction, because aggregators
concretely replace all or portions of their previous contents of the
entry when a new entry with the same <id> arrives.

There *may* exist *another* identifier that can identify a specific
instance or version of "an entry that may have multiple versions".
Atom does not specify where this other identifier is stored, and given
all of the possible means for associating these other identifiers with
"replaces" or "updates", etc., it makes sense for this other
identifier and its corresponding relations to be specified in a
"module" or "extension".  This works exceedingly well over the core
Atom model because the clients not interested in "managed versions"
see only streams of new versions of the same entry.

There is a lesser issue of whether "the identifier" can be "parsed" so
that it can serve both purposes simultaneously, both the identifier
for "an entry that may have multiple versions" and an instance or
version of that entry.  Since only a small number of URI schemes have
explicit support for versioning, it would be preferable for the format
to have two separate locations for the two different identifiers.


Option 3:

  <feed>
    <entry>
      <id>urn:myentry</id>
      <version:id>urn:myentry:2</version:id>
      <content>Hello There</content>
    </entry>
    <entry>
      <id>urn:myentry</id>
      <version:id>urn:myentry:1</version:id>
      <content>Hello</content>
    </entry>
  </feed>


  -- Ken



From owner-atom-syntax@mail.imc.org  Sat Jul 31 13:21: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 NAA06654
	for <atompub-archive@lists.ietf.org>; Sat, 31 Jul 2004 13:21: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 i6VHCBC3081262;
	Sat, 31 Jul 2004 10:12: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 i6VHCBaP081261;
	Sat, 31 Jul 2004 10:12: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 i6VHCA6w081254
	for <atom-syntax@imc.org>; Sat, 31 Jul 2004 10:12: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 i6VH9s53006244
	for <atom-syntax@imc.org>; Sat, 31 Jul 2004 11:09:54 -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 <0I1Q0040O7SD58@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sat, 31 Jul 2004 11:12:13 -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 <0I1Q00C377SCE1@mail.sun.net> for atom-syntax@imc.org; Sat,
 31 Jul 2004 11:12:13 -0600 (MDT)
Date: Sat, 31 Jul 2004 10:12:31 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: URI equivalence (was Re: PaceFeedEquivalence)
In-reply-to: <14be96d304073109443d7df1b6@mail.gmail.com>
To: Mark Pilgrim <pilgrim@gmail.com>
Cc: Atom Syntax <atom-syntax@imc.org>, Martin Duerst <duerst@w3.org>
Message-id: <CEE982D9-E314-11D8-B278-000A95A51C9E@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.618)
Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Content-transfer-encoding: 7BIT
References: <4.2.0.58.J.20040730141415.04b525c8@localhost>
 <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com>
 <ED9ED1C6-E194-11D8-B732-000A95A51C9E@sun.com>
 <14be96d30407291338435fdef6@mail.gmail.com>
 <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com>
 <4.2.0.58.J.20040730141415.04b525c8@localhost>
 <4.2.0.58.J.20040731085512.04f51380@localhost>
 <14be96d3040731064230b356da@mail.gmail.com>
 <01E063DE-E302-11D8-B278-000A95A51C9E@sun.com>
 <14be96d304073109443d7df1b6@mail.gmail.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 Jul 31, 2004, at 9:44 AM, Mark Pilgrim wrote:

> Or we could try mandating a URI scheme that is specifically designed
> to be used as an identifier, not a
> resource-location-and-oh-by-the-way-wouldn't-it-be-cool-to-use-it-as- 
> an-identifer-too.
>  I know I said just a few days ago that I was in favor of using any
> URI scheme, but Jesus, http:// URIs are incredibly complex.  And then
> saying that clients are free to pick and choose their own rules for
> comparing them, is just ridiculous.

Actually, a lot of the normalizations are not dependent on HTTP.  These  
include at least monocasing the scheme and identity components,  
crushing a/./b and /a/../a/ in the path component, and %-escaping.   
HTTP adds knowledge about port 80 and some trailing-slash semantics  
(see 2396bis 6.2.3), not that much.  So if there's a problem here, it's  
not an HTTP problem.

I think that we can say that software MAY use straight  
codepoint-by-codepoint comparison and for that reason producers SHOULD  
(MUST?) consistently spell the URIs they generate and intermediate  
parties SHOULD (MUST?) NOT change the spelling of URIs they deal with.   
However, humans are in the loop: URIs are scribbled on napkins and  
painted on the side of buses and read out by politicians during their  
keynote acceptance speeches.  So spelling variations will inevitably  
creep in, and I guarantee that spider-class software will use extreme  
aggressiveness in normalizing the suckers, so there's no point issuing  
any MUST NOTs. -Tim



From owner-atom-syntax@mail.imc.org  Sat Jul 31 13:22: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 NAA06694
	for <atompub-archive@lists.ietf.org>; Sat, 31 Jul 2004 13: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 i6VHFII8081515;
	Sat, 31 Jul 2004 10:15: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 i6VHFI3W081514;
	Sat, 31 Jul 2004 10:15:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-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 i6VHFHk4081506
	for <atom-syntax@imc.org>; Sat, 31 Jul 2004 10:15:18 -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 i6VHD153006967
	for <atom-syntax@imc.org>; Sat, 31 Jul 2004 11:13:01 -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 <0I1Q007M57XKDD@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sat, 31 Jul 2004 11:15:21 -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 <0I1Q00C3N7XKE1@mail.sun.net> for atom-syntax@imc.org; Sat,
 31 Jul 2004 11:15:20 -0600 (MDT)
Date: Sat, 31 Jul 2004 10:15:39 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: PaceFeedEquivalence
In-reply-to: <410BCBFC.9000108@intertwingly.net>
To: Sam Ruby <rubys@intertwingly.net>
Cc: Atom Syntax <atom-syntax@imc.org>, Mark Pilgrim <pilgrim@gmail.com>
Message-id: <3ED62BAC-E315-11D8-B278-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: <05B5FAC5-E24F-11D8-B278-000A95A51C9E@sun.com>
 <ED9ED1C6-E194-11D8-B732-000A95A51C9E@sun.com>
 <14be96d30407291338435fdef6@mail.gmail.com>
 <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com>
 <3f1451f50407292027201f90e1@mail.gmail.com>
 <763E5EDA-E1DE-11D8-B278-000A95A51C9E@sun.com>
 <3f1451f504073008454ca5f9b6@mail.gmail.com>
 <14be96d3040730102157e3a17e@mail.gmail.com>
 <05B5FAC5-E24F-11D8-B278-000A95A51C9E@sun.com>
 <4.2.0.58.J.20040731092223.050e5f10@localhost>
 <D12669C4-E2A9-11D8-B278-000A95A51C9E@sun.com>
 <14be96d304073107076271fe7c@mail.gmail.com> <410BCBFC.9000108@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 Jul 31, 2004, at 9:42 AM, Sam Ruby wrote:

> Apparently, after weighing a similar set of tradeoffs, XML Namespaces 
> opted for "Simple String Comparison".  In the context of atom:id, what 
> are the costs and benefits of requiring anything more?

There is no benefit whatever in *requiring* anything more.  There is 
similarly no benefit in trying to rule out more aggressive 
normalization for those instances in which it is cost-effective. -Tim



From owner-atom-syntax@mail.imc.org  Sat Jul 31 13:29: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 NAA06914
	for <atompub-archive@lists.ietf.org>; Sat, 31 Jul 2004 13:29: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 i6VHLRr0081845;
	Sat, 31 Jul 2004 10:21: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 i6VHLR0D081844;
	Sat, 31 Jul 2004 10:21: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 i6VHLQ7C081834
	for <atom-syntax@imc.org>; Sat, 31 Jul 2004 10:21: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 i6VHLO53027911
	for <atom-syntax@imc.org>; Sat, 31 Jul 2004 12:21:24 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6VHLOcS027907;
	Sat, 31 Jul 2004 12:21:24 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: atom-syntax@imc.org
Subject: Re: Identity conundrum
References: <87fz79xt9u.fsf@nwalsh.com> <410BC9B2.9070600@dehora.net>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 31 Jul 2004 12:21:24 -0500
In-Reply-To: <410BC9B2.9070600@dehora.net>
Message-ID: <m3brhwt7mz.fsf@bitsko.slc.ut.us>
Lines: 18
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 i6VHLR7C081839
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 <bill@dehora.net> writes:

> Norman Walsh wrote:
> 
> > I think I lean towards the latter view, but there's definitely
> > something appealing about the simplicity of the former view.
> 
> Neither view is simple. And people tend to want to have both views.

We can do both.

Please take a moment to look at the longer message I just sent.  I
wanted to call attention to it because even though it is longer it
deserves more than a quick skim.  It's a summary of longer discussion
that Asbjørn, Arve, others, and I have had on #atom specifically
addressing this issue.

  -- Ken



From owner-atom-syntax@mail.imc.org  Sat Jul 31 13:42: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 NAA07288
	for <atompub-archive@lists.ietf.org>; Sat, 31 Jul 2004 13:42: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 i6VHYNMI082627;
	Sat, 31 Jul 2004 10:34: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 i6VHYNQQ082626;
	Sat, 31 Jul 2004 10:34: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 i6VHYMQh082609
	for <atom-syntax@imc.org>; Sat, 31 Jul 2004 10:34: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 i6VHZc4m024562;
	Sat, 31 Jul 2004 13:35:38 -0400
Message-ID: <410BD820.7080600@intertwingly.net>
Date: Sat, 31 Jul 2004 13:34:24 -0400
From: Sam Ruby <rubys@intertwingly.net>
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 <Tim.Bray@Sun.COM>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: URI equivalence (was Re: PaceFeedEquivalence)
References: <4.2.0.58.J.20040730141415.04b525c8@localhost> <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com> <ED9ED1C6-E194-11D8-B732-000A95A51C9E@sun.com> <14be96d30407291338435fdef6@mail.gmail.com> <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com> <4.2.0.58.J.20040730141415.04b525c8@localhost> <4.2.0.58.J.20040731085512.04f51380@localhost> <14be96d3040731064230b356da@mail.gmail.com> <01E063DE-E302-11D8-B278-000A95A51C9E@sun.com> <14be96d304073109443d7df1b6@mail.gmail.com> <CEE982D9-E314-11D8-B278-000A95A51C9E@sun.com>
In-Reply-To: <CEE982D9-E314-11D8-B278-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:
> 
> I think that we can say that software MAY use straight  
> codepoint-by-codepoint comparison and for that reason producers SHOULD  
> (MUST?) consistently spell the URIs they generate and intermediate  
> parties SHOULD (MUST?) NOT change the spelling of URIs they deal with.   
> However, humans are in the loop: URIs are scribbled on napkins and  
> painted on the side of buses and read out by politicians during their  
> keynote acceptance speeches.  So spelling variations will inevitably  
> creep in, and I guarantee that spider-class software will use extreme  
> aggressiveness in normalizing the suckers, so there's no point issuing  
> any MUST NOTs. -Tim

 From a feedvalidator perspective, if we agree on enabling consumers to 
rely solely codepoint-by-codepoint comparisons to determine equality, it 
makes sense for the feedvalidator to produce:

1) an informational message (or perhaps a warning?) if an id does not
    match a canonical form (perhaps Atom should adopt rules that are
    consistent with rfc2396bis[1]?).

2) a stronger warning (or perhaps even an error?) if two ids are present
    in a feed that differ only based on one or more normalization rules.

I'm inclined to support the stronger (parenthetical) versions of all the 
above rules.

- Sam Ruby

[1]<http://www.gbiv.com/protocols/uri/rev-2002/draft-fielding-uri-rfc2396bis-03.html#canonical-form>






From owner-atom-syntax@mail.imc.org  Sat Jul 31 13:46: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 NAA07428
	for <atompub-archive@lists.ietf.org>; Sat, 31 Jul 2004 13:46: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 i6VHccxm082793;
	Sat, 31 Jul 2004 10:38: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 i6VHcc5u082792;
	Sat, 31 Jul 2004 10:38:38 -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 i6VHccWs082786
	for <atom-syntax@imc.org>; Sat, 31 Jul 2004 10:38:38 -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 <2004073117383301200fn0fce>; Sat, 31 Jul 2004 17:38:34 +0000
Date: Sat, 31 Jul 2004 11:38:32 -0600
Subject: Re: Identity conundrum
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: <OF0F3762D8.79BA0EF1-ON88256EE2.005936ED-88256EE2.005A4DEC@us.ibm.com>
Message-Id: <70F90BE2-E318-11D8-AE00-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 i6VHccWs082787
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, July 31, 2004, at 10:26  AM, James M Snell wrote:
> >      One idea of identity is that entries have immutable identity. 
> That
> >      is, an atom:id identifies an atom:entry that cannot change...
> >
> >      Another view of identity is that entries are snapshots of an
> >      abstraction that has identity. That is, an atom:id identifies an
> >      abstraction that might or might not change.
>
> This has the potential of going even further down a rabbit hole 
> without any chance of gaining consensus.  Yes, there are two points of 
> view: 1) a single identity regardless of version and 2) a unique 
> identity for each version.  Which is the correct view?  Well, both are 
> valid and, IMHO, Atom shouldn't have to care which view a publisher 
> decides to adhere to.  I'd say that items in an Atom feed MUST have a 
> single unique URI.  A person subscribing to the first option will have 
> an atom feed in which a single item may change over time.  A person 
> subscribing to the second option will have an atom feed that contains 
> a new item for each version of the content.
>
> Option 1:
>   <feed>
>     <entry>
>       <id>urn:myentry</id>
>       <content>Hello</content>
>     </entry>
>   </feed>
>
>   <feed>
>     <entry>
>       <id>urn:myentry</id>
>       <content>Hello There</content>
>     </entry>
>   </feed>
>
> Option 2:
>
>   <feed>
>     <entry>
>       <id>urn:myentry:2</id>
>       <content>Hello There</content>
>     </entry>
>     <entry>
>       <id>urn:myentry:1</id>
>       <content>Hello</content>
>     </entry>
>   </feed>

I don't particularly like the idea of overloading the id element with 
both identity and versioning.  If we were to, for example, mandate that 
anything following the trailing colon in an id is a version number, no 
one would be able to use ids with colons in them without including a 
version number--which would take us closer to mandating a single 
scheme.  Another option would be something like <id 
version="2">urn:myentry</id>.  Yet another would be <id 
extension-ns:version="2">urn:myentry</d>.  The problem with either of 
those would be that the id would not be unique (ignoring @*:version), 
which in the case of @atom:version would require everyone to support 
it, even though it seems likely that most people won't be interested in 
doing so.

As you might infer, my preference/POV is that an entry keeps the same 
identity, and the same ID, regardless of version.  This matches the 
current usage of feeds.  People could always tack some kind of 
versioning on to the id, since it wouldn't exactly violate the spec, 
but I would HOPE that it wouldn't become common enough practice that 
aggregators would be expected to support it by not displaying entries 
who's id's version had been bumped.



From owner-atom-syntax@mail.imc.org  Sat Jul 31 13:52: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 NAA07769
	for <atompub-archive@lists.ietf.org>; Sat, 31 Jul 2004 13:52: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 i6VHhXwd083038;
	Sat, 31 Jul 2004 10:43: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 i6VHhX0t083037;
	Sat, 31 Jul 2004 10:43:33 -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 i6VHhWjp083031
	for <atom-syntax@imc.org>; Sat, 31 Jul 2004 10:43:33 -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 i6VHfG53012876
	for <atom-syntax@imc.org>; Sat, 31 Jul 2004 11:41:16 -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 <0I1Q007NM98NDD@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sat, 31 Jul 2004 11:43:36 -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 <0I1Q00C5B98NE1@mail.sun.net> for atom-syntax@imc.org; Sat,
 31 Jul 2004 11:43:35 -0600 (MDT)
Date: Sat, 31 Jul 2004 10:43:54 -0700
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: URI equivalence (was Re: PaceFeedEquivalence)
In-reply-to: <410BD820.7080600@intertwingly.net>
To: Sam Ruby <rubys@intertwingly.net>
Cc: Atom Syntax <atom-syntax@imc.org>
Message-id: <313769F7-E319-11D8-B278-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: <4.2.0.58.J.20040730141415.04b525c8@localhost>
 <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com>
 <ED9ED1C6-E194-11D8-B732-000A95A51C9E@sun.com>
 <14be96d30407291338435fdef6@mail.gmail.com>
 <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com>
 <4.2.0.58.J.20040730141415.04b525c8@localhost>
 <4.2.0.58.J.20040731085512.04f51380@localhost>
 <14be96d3040731064230b356da@mail.gmail.com>
 <01E063DE-E302-11D8-B278-000A95A51C9E@sun.com>
 <14be96d304073109443d7df1b6@mail.gmail.com>
 <CEE982D9-E314-11D8-B278-000A95A51C9E@sun.com>
 <410BD820.7080600@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 Jul 31, 2004, at 10:34 AM, Sam Ruby wrote:

> From a feedvalidator perspective, if we agree on enabling consumers to 
> rely solely codepoint-by-codepoint comparisons to determine equality, 
> it makes sense for the feedvalidator to produce:
>
> 1) an informational message (or perhaps a warning?) if an id does not
>    match a canonical form (perhaps Atom should adopt rules that are
>    consistent with rfc2396bis[1]?).
>
> 2) a stronger warning (or perhaps even an error?) if two ids are 
> present
>    in a feed that differ only based on one or more normalization rules.
>
> I'm inclined to support the stronger (parenthetical) versions of all 
> the above rules.

Me too. -Tim



From owner-atom-syntax@mail.imc.org  Sat Jul 31 14:07:25 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08296
	for <atompub-archive@lists.ietf.org>; Sat, 31 Jul 2004 14:07:25 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VHvuDo083795;
	Sat, 31 Jul 2004 10:57: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 i6VHvuO4083794;
	Sat, 31 Jul 2004 10:57:56 -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 i6VHvtYi083785
	for <atom-syntax@imc.org>; Sat, 31 Jul 2004 10:57:56 -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 i6VHvr53028325
	for <atom-syntax@imc.org>; Sat, 31 Jul 2004 12:57:54 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6VHvrsm028321;
	Sat, 31 Jul 2004 12:57:53 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Identity conundrum
References: <OF0F3762D8.79BA0EF1-ON88256EE2.005936ED-88256EE2.005A4DEC@us.ibm.com>
	<m3fz78t82a.fsf@bitsko.slc.ut.us>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 31 Jul 2004 12:57:53 -0500
In-Reply-To: <m3fz78t82a.fsf@bitsko.slc.ut.us>
Message-ID: <m33c38t5y6.fsf@bitsko.slc.ut.us>
Lines: 30
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


Ken MacLeod <ken@bitsko.slc.ut.us> writes:

> Option 3:
> 
>   <feed>
>     <entry>
>       <id>urn:myentry</id>
>       <version:id>urn:myentry:2</version:id>
>       <content>Hello There</content>
>     </entry>
>     <entry>
>       <id>urn:myentry</id>
>       <version:id>urn:myentry:1</version:id>
>       <content>Hello</content>
>     </entry>
>   </feed>

A smaller, follow-on issue.  I checked format-01 for the spec text
that indicates that a feed can only contain one entry with the same
<id>, and notice it doesn't say that (I thought I recalled that it
did).  The spec does say clearly that "same <id> is same entry".

However, to support both models, the spec should clarify:

    Multiple instances or versions of the same entry MAY appear in a
    feed, index, or archive.  Consumers MAY choose to present or
    record only the instance or version of the entry with the most
    recent [[date that indicates change]].

  -- Ken



From owner-atom-syntax@mail.imc.org  Sat Jul 31 14:55: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 OAA09917
	for <atompub-archive@lists.ietf.org>; Sat, 31 Jul 2004 14:55:30 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VIjenP086358;
	Sat, 31 Jul 2004 11:45: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 i6VIjenl086357;
	Sat, 31 Jul 2004 11:45:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VIjdZ1086347;
	Sat, 31 Jul 2004 11:45:39 -0700 (PDT)
	(envelope-from jasnell@us.ibm.com)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11])
	by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i6VIjZmL840266;
	Sat, 31 Jul 2004 14:45:35 -0400
Received: from d03nm122.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 i6VIjY2B407926;
	Sat, 31 Jul 2004 12:45:34 -0600
In-Reply-To: <m3fz78t82a.fsf@bitsko.slc.ut.us>
To: Ken MacLeod <ken@bitsko.slc.ut.us>
Cc: Atom Syntax <atom-syntax@imc.org>, owner-atom-syntax@mail.imc.org
MIME-Version: 1.0
Subject: Re: Identity conundrum
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
From: James M Snell <jasnell@us.ibm.com>
X-MIMETrack: S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/31/2004 11:45:23 AM,
	Serialize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/31/2004 11:45:23 AM,
	Serialize complete at 07/31/2004 11:45:23 AM,
	Itemize by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/31/2004 11:45:23 AM,
	S/MIME Sign complete at 07/31/2004 11:45:23 AM,
	S/MIME Sign by Notes Client on James M Snell/Fresno/IBM(Release 6.5|September
 26, 2003) at 07/31/2004 11:45:30 AM,
	S/MIME Sign complete at 07/31/2004 11:45:30 AM,
	Serialize by Router on D03NM122/03/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at
 07/31/2004 12:45:35,
	Serialize complete at 07/31/2004 12:45:35
Message-ID: <OF559EB364.88C61375-ON88256EE2.0065F4A9-88256EE2.00670B23@us.ibm.com>
Date: Sat, 31 Jul 2004 12:45:31 -0600
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z53203_boundary_sign
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>


This is an S/MIME signed message.

---------z53203_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 0067083788256EE2_="

This is a multipart message in MIME format.
--=_alternative 0067083788256EE2_=
Content-Type: text/plain; charset="US-ASCII"

owner-atom-syntax@mail.imc.org wrote on 07/31/2004 10:12:13 AM:

> 
> James M Snell <jasnell@us.ibm.com> writes:
> 
> > [Sam Ruby] wrote on 07/31/2004 08:41:56 AM:
> > 
> > > Going back to Norm's original email:
> > > 
> > > http://www.imc.org/atom-syntax/mail-archive/msg08148.html
> > > 
> > >      One idea of identity is that entries have immutable
> > >      identity. That is, an atom:id identifies an atom:entry that
> > >      cannot change...
> > > 
> > >      Another view of identity is that entries are snapshots of an
> > >      abstraction that has identity. That is, an atom:id identifies
> > >      an abstraction that might or might not change.
> > > 
> > > It seems to me that Elias, your notions correspond to the former.
> > > If so, this reinforces Norm's observation that there are two
> > > points of view.
> > > 
> > 
> > This has the potential of going even further down a rabbit hole 
without 
> > any chance of gaining consensus.  Yes, there are two points of view: 
1) a 
> > single identity regardless of version and 2) a unique identity for 
each 
> > version.  Which is the correct view?  Well, both are valid and, IMHO, 
Atom 
> > shouldn't have to care which view a publisher decides to adhere to. 
I'd 
> > say that items in an Atom feed MUST have a single unique URI.  A 
person 
> > subscribing to the first option will have an atom feed in which a 
single 
> > item may change over time.  A person subscribing to the second option 
will 
> > have an atom feed that contains a new item for each version of the 
> > content.
> 
> > Unless we either: choose to allow both points of view or force one 
side to 
> > compromise, we're not going to achieve consensus on this issue.
> 
> There is no reason why both models cannot be satisfied with the
> current format.
> 

Agreed

> The crux of the issue appears to be a combination of what <id> is
> identifying and whether or not an entry (or resource in general) can
> have more than one identifier.
> 
> The current model, and that of RSS 1.0 and RSS 2.0, is Norm's latter:
> <id> identifies the abstraction of "an entry that may have multiple
> versions".  It's not really an abstraction, because aggregators
> concretely replace all or portions of their previous contents of the
> entry when a new entry with the same <id> arrives.
> 
> There *may* exist *another* identifier that can identify a specific
> instance or version of "an entry that may have multiple versions".
> Atom does not specify where this other identifier is stored, and given
> all of the possible means for associating these other identifiers with
> "replaces" or "updates", etc., it makes sense for this other
> identifier and its corresponding relations to be specified in a
> "module" or "extension".  This works exceedingly well over the core
> Atom model because the clients not interested in "managed versions"
> see only streams of new versions of the same entry.
> 
> There is a lesser issue of whether "the identifier" can be "parsed" so
> that it can serve both purposes simultaneously, both the identifier
> for "an entry that may have multiple versions" and an instance or
> version of that entry.  Since only a small number of URI schemes have
> explicit support for versioning, it would be preferable for the format
> to have two separate locations for the two different identifiers.
> 
> 
> Option 3:
> 
>   <feed>
>     <entry>
>       <id>urn:myentry</id>
>       <version:id>urn:myentry:2</version:id>
>       <content>Hello There</content>
>     </entry>
>     <entry>
>       <id>urn:myentry</id>
>       <version:id>urn:myentry:1</version:id>
>       <content>Hello</content>
>     </entry>
>   </feed>
> 


This is close. I was thinking about something along these lines:

  <feed>
    <entry>
      <id>urn:myentry2</id>
      <supercedes>urn:myentry1</supercedes>
      <revision>1</revision>
      <content>Hello There</content>
    </entry>
    <entry>
      <id>urn:myentry1</id>
      <revision>1</revision>
      <content>Hello</content>
    </entry>
  </feed>

This assumes every distinct entry in the feed MUST have a unique 
<atom:id>.

This introduces two new elements, <atom:supercedes> and <atom:revision>.

<atom:supercedes> references the ID of another item which this entry 
supercedes/replaces
<atom:revision> specifies an unsigned integer value specifying the 
revision number of this entry.  Every edit to the entry requires the 
revision number to be incremented.  <atom:revision> is not intended to 
provide full featured versioning functions... just the ability to specify 
how many times the entry has been modified.  Any change in content or 
metadata would count as a "revision".

Both elements would be optional. 

This approach would allow us to cleanly support both models.

Again, I know there are folks who would *rather* see us *only* support the 
model where an entry can keep the same identity regardless of changes; and 
there are folks who would *rather* see us *only* support the model where 
each change to an entry requires a change in the id.  This proposal seeks 
to find a compromise between the two by allowing us to support both in a 
rather simple way.

> 
>   -- Ken
> 


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

--=_alternative 0067083788256EE2_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>owner-atom-syntax@mail.imc.org wrote on 07/31/2004
10:12:13 AM:<br>
<br>
&gt; <br>
&gt; James M Snell &lt;jasnell@us.ibm.com&gt; writes:<br>
&gt; <br>
&gt; &gt; [Sam Ruby] wrote on 07/31/2004 08:41:56 AM:<br>
&gt; &gt; <br>
&gt; &gt; &gt; Going back to Norm's original email:<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; http://www.imc.org/atom-syntax/mail-archive/msg08148.html<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp;One idea of identity is that entries
have immutable<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp;identity. That is, an atom:id identifies
an atom:entry that<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp;cannot change...<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp;Another view of identity is that entries
are snapshots of an<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp;abstraction that has identity. That
is, an atom:id identifies<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp;an abstraction that might or might not
change.<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; It seems to me that Elias, your notions correspond to the
former.<br>
&gt; &gt; &gt; If so, this reinforces Norm's observation that there are
two<br>
&gt; &gt; &gt; points of view.<br>
&gt; &gt; &gt; <br>
&gt; &gt; <br>
&gt; &gt; This has the potential of going even further down a rabbit hole
without <br>
&gt; &gt; any chance of gaining consensus. &nbsp;Yes, there are two points
of view: 1) a <br>
&gt; &gt; single identity regardless of version and 2) a unique identity
for each <br>
&gt; &gt; version. &nbsp;Which is the correct view? &nbsp;Well, both are
valid and, IMHO, Atom <br>
&gt; &gt; shouldn't have to care which view a publisher decides to adhere
to. &nbsp;I'd <br>
&gt; &gt; say that items in an Atom feed MUST have a single unique URI.
&nbsp;A person <br>
&gt; &gt; subscribing to the first option will have an atom feed in which
a single <br>
&gt; &gt; item may change over time. &nbsp;A person subscribing to the
second option will <br>
&gt; &gt; have an atom feed that contains a new item for each version of
the <br>
&gt; &gt; content.<br>
&gt; <br>
&gt; &gt; Unless we either: choose to allow both points of view or force
one side to <br>
&gt; &gt; compromise, we're not going to achieve consensus on this issue.<br>
&gt; <br>
&gt; There is no reason why both models cannot be satisfied with the<br>
&gt; current format.<br>
&gt; </tt></font>
<br>
<br><font size=2><tt>Agreed</tt></font>
<br><font size=2><tt><br>
&gt; The crux of the issue appears to be a combination of what &lt;id&gt;
is<br>
&gt; identifying and whether or not an entry (or resource in general) can<br>
&gt; have more than one identifier.<br>
&gt; <br>
&gt; The current model, and that of RSS 1.0 and RSS 2.0, is Norm's latter:<br>
&gt; &lt;id&gt; identifies the abstraction of &quot;an entry that may have
multiple<br>
&gt; versions&quot;. &nbsp;It's not really an abstraction, because aggregators<br>
&gt; concretely replace all or portions of their previous contents of the<br>
&gt; entry when a new entry with the same &lt;id&gt; arrives.<br>
&gt; <br>
&gt; There *may* exist *another* identifier that can identify a specific<br>
&gt; instance or version of &quot;an entry that may have multiple versions&quot;.<br>
&gt; Atom does not specify where this other identifier is stored, and given<br>
&gt; all of the possible means for associating these other identifiers
with<br>
&gt; &quot;replaces&quot; or &quot;updates&quot;, etc., it makes sense
for this other<br>
&gt; identifier and its corresponding relations to be specified in a<br>
&gt; &quot;module&quot; or &quot;extension&quot;. &nbsp;This works exceedingly
well over the core<br>
&gt; Atom model because the clients not interested in &quot;managed versions&quot;<br>
&gt; see only streams of new versions of the same entry.<br>
&gt; <br>
&gt; There is a lesser issue of whether &quot;the identifier&quot; can
be &quot;parsed&quot; so<br>
&gt; that it can serve both purposes simultaneously, both the identifier<br>
&gt; for &quot;an entry that may have multiple versions&quot; and an instance
or<br>
&gt; version of that entry. &nbsp;Since only a small number of URI schemes
have<br>
&gt; explicit support for versioning, it would be preferable for the format<br>
&gt; to have two separate locations for the two different identifiers.<br>
&gt; <br>
&gt; <br>
&gt; Option 3:<br>
&gt; <br>
&gt; &nbsp; &lt;feed&gt;<br>
&gt; &nbsp; &nbsp; &lt;entry&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &lt;id&gt;urn:myentry&lt;/id&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &lt;version:id&gt;urn:myentry:2&lt;/version:id&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &lt;content&gt;Hello There&lt;/content&gt;<br>
&gt; &nbsp; &nbsp; &lt;/entry&gt;<br>
&gt; &nbsp; &nbsp; &lt;entry&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &lt;id&gt;urn:myentry&lt;/id&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &lt;version:id&gt;urn:myentry:1&lt;/version:id&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &lt;content&gt;Hello&lt;/content&gt;<br>
&gt; &nbsp; &nbsp; &lt;/entry&gt;<br>
&gt; &nbsp; &lt;/feed&gt;<br>
&gt; </tt></font>
<br>
<br>
<br><font size=2><tt>This is close. I was thinking about something along
these lines:</tt></font>
<br>
<br><font size=2><tt>&nbsp; &lt;feed&gt;</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &lt;entry&gt;<br>
 &nbsp; &nbsp; &nbsp;&lt;id&gt;urn:myentry2&lt;/id&gt;</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; &lt;supercedes&gt;urn:myentry1&lt;/supercedes&gt;</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; &lt;revision&gt;1&lt;/revision&gt;<br>
 &nbsp; &nbsp; &nbsp;&lt;content&gt;Hello There&lt;/content&gt;<br>
 &nbsp; &nbsp;&lt;/entry&gt;<br>
 &nbsp; &nbsp;&lt;entry&gt;<br>
 &nbsp; &nbsp; &nbsp;&lt;id&gt;urn:myentry1&lt;/id&gt;</tt></font>
<br><font size=2><tt>&nbsp; &nbsp; &nbsp; &lt;revision&gt;1&lt;/revision&gt;<br>
 &nbsp; &nbsp; &nbsp;&lt;content&gt;Hello&lt;/content&gt;<br>
 &nbsp; &nbsp;&lt;/entry&gt;</tt></font>
<br><font size=2><tt>&nbsp; &lt;/feed&gt;</tt></font>
<br>
<br><font size=2><tt>This assumes every distinct entry in the feed MUST
have a unique &lt;atom:id&gt;.</tt></font>
<br>
<br><font size=2><tt>This introduces two new elements, &lt;atom:supercedes&gt;
and &lt;atom:revision&gt;.</tt></font>
<br>
<br><font size=2><tt>&lt;atom:supercedes&gt; references the ID of another
item which this entry supercedes/replaces</tt></font>
<br><font size=2><tt>&lt;atom:revision&gt; specifies an unsigned integer
value specifying the revision number of this entry. &nbsp;Every edit to
the entry requires the revision number to be incremented. &nbsp;&lt;atom:revision&gt;
is not intended to provide full featured versioning functions... just the
ability to specify how many times the entry has been modified. &nbsp;Any
change in content or metadata would count as a &quot;revision&quot;.</tt></font>
<br>
<br><font size=2><tt>Both elements would be optional. </tt></font>
<br>
<br><font size=2><tt>This approach would allow us to cleanly support both
models.</tt></font>
<br>
<br><font size=2><tt>Again, I know there are folks who would *rather* see
us *only* support the model where an entry can keep the same identity regardless
of changes; and there are folks who would *rather* see us *only* support
the model where each change to an entry requires a change in the id. &nbsp;This
proposal seeks to find a compromise between the two by allowing us to support
both in a rather simple way.</tt></font>
<br><font size=2><tt><br>
&gt; <br>
&gt; &nbsp; -- Ken<br>
&gt; <br>
</tt></font>
<br>
<br><font size=2 face="sans-serif">- James M Snell<br>
 &nbsp;jasnell@us.ibm.com<br>
 &nbsp;http://www.ibm.com<br>
 &nbsp;(877) 511-5082 / Office<br>
 &nbsp;930-1979 / Tie Line</font>
<br>
--=_alternative 0067083788256EE2_=--

---------z53203_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIIUOAIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIISWDCCAtow
ggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1
aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTAy
MDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA629xc49NpAPz
cAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7glzJKgPkPzlTZZfznznGbmAWVnNBQ
lyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnwNclOnnP2sKufuPzbTImQTTi5c8JZNZcM
J0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEEBAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1Ud
DgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAPBgNVHRMBAf8EBTADAQH/MDEGA1UdJQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUH
AwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvu
jQupk2oCScMd3FIHLE7hOfu8YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14ke
McF9ViNdewEoBGiAycUq8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIC2jCCAkOgAwIB
AgIDAxS2MA0GCSqGSIb3DQEBBAUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDIwMTE0MjIw
NzExWhcNMTExMjMxMjIwNzExWjBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25h
bCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrb3Fzj02kA/NwCy5KFMiY
tFgyTJ6kMSQLVSs9uwVHIAVkqy/enDQwZ9b/7uCXMkqA+Q/OVNll/OfOcZuYBZWc0FCXI9qw60KO
J/rTd65FdF4dwp8cw8si0qjOJtYg8cm46fA1yU6ec/awq5+4/NtMiZBNOLlzwlk1lwwnRgXNNwID
AQABo4GqMIGnMBEGCWCGSAGG+EIBAQQEAwIAhzAOBgNVHQ8BAf8EBAMCAcYwHQYDVR0OBBYEFK5U
DpLqqDOpKyQtx8hvMNze80pAMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMA8GA1Ud
EwEB/wQFMAMBAf8wMQYDVR0lBCowKAYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYB
BQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAMnJ7c2YLyrY/PKlFl+7sm8NENfWtFxqdm+6NC6mTagJJ
wx3cUgcsTuE5+7xh9+/G0tTfLzA1qZAQ5GNMPXvmoB9+vJfKnC2JWMFQpIOUEJDXiR4xwX1WI117
ASgEaIDJxSrxHcuuV/hMIO9bgZ6C41MUVmdLTKBgBOImTuIPK8QwggMgMIICiaADAgECAgQ13vTP
MA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQL
EyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0MTUxWhcN
MTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMk
RXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKKlQRkrPFr
U18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkwrFEeO68r
1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOgYaRfMF0x
CzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBD
ZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAxODA4MjIx
NjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAdBgNV
HQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0HQQAEDTAL
GwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwlMQ0AppJu
f7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn00DbOyZY
sih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMgMIICiaADAgEC
AgQ13vTPMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNOTgwODIyMTY0
MTUxWhcNMTgwODIyMTY0MTUxWjBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsG
A1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQDBXbFYZwhi7qCaLR8IbZEUaJgKHv7aBG8ThGIhw9F8zp8F4LgB8E407OKK
lQRkrPFrU18Fs8tngL9CAo7+3QEJ7OEAFE/8+/AM3UO6WyvhH4BwmRVXkxbxD5dqt8JoIxzMTVkw
rFEeO68r1u5jRXvF2V9Q0uNQDzqI578U/eDHuQIDAQABo4IBCTCCAQUwcAYDVR0fBGkwZzBloGOg
YaRfMF0xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNl
Y3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwGgYDVR0QBBMwEYEPMjAx
ODA4MjIxNjQxNTFaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf
1DAdBgNVHQ4EFgQUSOZo+SvSspXXR9gjIBBPM5iQn9QwDAYDVR0TBAUwAwEB/zAaBgkqhkiG9n0H
QQAEDTALGwVWMy4wYwMCBsAwDQYJKoZIhvcNAQEFBQADgYEAWM4p6vz33rXOArkXtYXRuePglcwl
MQ0AppJuf7aSY55QldGab+QR3mOFbpjuqP9ayNNVsmZxV97AIes9KqcjSQEEhkJ7/O5/ohZStWdn
00DbOyZYsih3Pa4Ud2HW+ipmJ6AN+qdzXOpw8ZQhZURf+vzvKWipood573nvT6wHdzgwggMmMIIC
j6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy
bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNVBAMTG0lCTSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIxNjM2NTRaMIGFMQsw
CQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEXMBUGA1UEAxMOSmFt
ZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkqhkiG9w0BCQEWEmph
c25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwKpbDG3zMatEuuOT
FYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSyd+7nwqAvbBfPj+0S
vcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7tBJlLrwDRCMoNlPuQ
Kg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQW
BBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOgFAwSamFzbmVs
bEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pAMCcGA1UdJQQgMB4G
CCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQADgYEAZMKevB7dFfb9
23OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY8BjwVHxiYgG4xkxf
B1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOIzj3lz3xd+uOzqRFg
/Wsg/VMwggMmMIICj6ADAgECAgMBfpMwDQYJKoZIhvcNAQEEBQAwaTELMAkGA1UEBhMCVVMxNDAy
BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAiBgNV
BAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNDA0MDgxNjM2NTRaFw0wNTA0MjIx
NjM2NTRaMIGFMQswCQYDVQQGEwJVUzEMMAoGA1UEChMDSUJNMREwDwYDVQQLEwhFTVBMT1lFRTEX
MBUGA1UEAxMOSmFtZXMgTS4gU25lbGwxGTAXBgoJkiaJk/IsZAEBEwk4QTExMjE4OTcxITAfBgkq
hkiG9w0BCQEWEmphc25lbGxAdXMuaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
wKpbDG3zMatEuuOTFYm02H46qgfG4TenPhSky9NPsuUzdSbjpQjxg5Des6E1Edp2adtcspYfcPSy
d+7nwqAvbBfPj+0SvcbIMo2AwhGEggPbkWRGhA1viWxJ/u2ZJAKn6kNqhIVcF8lgq+jn11IDOo7t
BJlLrwDRCMoNlPuQKg0CAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQD
AgXgMB0GA1UdDgQWBBS06fGju7amcbbDDOOUxLWlqaUUITAtBgNVHREEJjAkoCIGCisGAQQBgjcU
AgOgFAwSamFzbmVsbEB1cy5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA
MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEEBQAD
gYEAZMKevB7dFfb923OiK06TbIxVcBk49qHMxVLGSjWpqXrbPml3t+whVWeOr7vnFl2f0/mI+NFY
8BjwVHxiYgG4xkxfB1Ko2XczhhucuG6YzQac136gPlfdgPRUPS6wez+vGdMBCbx/VCC3KOFCRqOI
zj3lz3xd+uOzqRFg/Wsg/VMxggG7MIIBtwIBATBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJ
bnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0g
Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwF+kzAJBgUrDgMCGgUAoIGiMBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDczMTE4NDUyM1owIwYJKoZIhvcNAQkEMRYE
FOn5eT2h0ItwtR/dUjQS8bvkP5brMEMGCSqGSIb3DQEJDzE2MDQwBwYFKw4DAh0wDgYIKoZIhvcN
AwICAgCAMAoGCCqGSIb3DQMHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGABil+ucfb
hUacRaN2g6Zxux69ZVNoE9i1dyqn6ItO2a48CgVIUS5ueOkqJl2IPTG+SL3+u3YaaDHs03t2g/le
vx6LlBB99L7/pI/l93ms5N5mLJ7FnohqHGG7GAj9YDncbAwjhB/r/LaFjeJu9AKVAiMq5FTApg8x
vLomLSH6aLEAAAAA

---------z53203_boundary_sign--



From owner-atom-syntax@mail.imc.org  Sat Jul 31 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 PAA12537
	for <atompub-archive@lists.ietf.org>; Sat, 31 Jul 2004 15: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 i6VJ5t7Q087142;
	Sat, 31 Jul 2004 12:05: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 i6VJ5t4v087141;
	Sat, 31 Jul 2004 12:05:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail06.svc.cra.dublin.eircom.net (mail06.svc.cra.dublin.eircom.net [159.134.118.22])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i6VJ5sxf087134
	for <atom-syntax@imc.org>; Sat, 31 Jul 2004 12:05:54 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 33240 messnum 2911597 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 31 Jul 2004 18:57:59 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.33.112)
  by mail06.svc.cra.dublin.eircom.net (qp 33240) with SMTP; 31 Jul 2004 18:57:59 -0000
Message-ID: <410BEBB5.5030806@dehora.net>
Date: Sat, 31 Jul 2004 19:57:57 +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: Ken MacLeod <ken@bitsko.slc.ut.us>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Identity conundrum
References: <OF0F3762D8.79BA0EF1-ON88256EE2.005936ED-88256EE2.005A4DEC@us.ibm.com> <m3fz78t82a.fsf@bitsko.slc.ut.us>
In-Reply-To: <m3fz78t82a.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: <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


Ken MacLeod wrote:


> The crux of the issue appears to be a combination of what <id> is
> identifying and whether or not an entry (or resource in general) can
> have more than one identifier.
> 
> The current model, and that of RSS 1.0 and RSS 2.0, is Norm's latter:
> <id> identifies the abstraction of "an entry that may have multiple
> versions".  It's not really an abstraction, because aggregators
> concretely replace all or portions of their previous contents of the
> entry when a new entry with the same <id> arrives.
> 
> There *may* exist *another* identifier that can identify a specific
> instance or version of "an entry that may have multiple versions".

That would be a tuple that serves to identify (correlate) a stream 
(aka a delayed list) of entries - it's a set/bag membership 
function. If this is what we want I suggest we start with the HTTP 
resource/representation model until it's obviously inadequate.

It's not just another identifier, it's another model of identity 
altogether. See below.


> Atom does not specify where this other identifier is stored, and given
> all of the possible means for associating these other identifiers with
> "replaces" or "updates", etc., it makes sense for this other
> identifier and its corresponding relations to be specified in a
> "module" or "extension".  This works exceedingly well over the core
> Atom model because the clients not interested in "managed versions"
> see only streams of new versions of the same entry.

Fair enough.


> There is a lesser issue of whether "the identifier" can be "parsed" so
> that it can serve both purposes simultaneously, both the identifier
> for "an entry that may have multiple versions" and an instance or
> version of that entry.  Since only a small number of URI schemes have
> explicit support for versioning, it would be preferable for the format
> to have two separate locations for the two different identifiers.


Look, the thing that is needed for this identity stuff is a 
evaluation model ('semantics) that ranges over the set of 
identifiers or tuples of indetifiers or whatever -  this will trash 
need functions like equality or order, invariants, and so on so that 
we can implement the neccessary evaluators. Pointers to the literal 
values or tuples of literal values are not sufficient.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Sat Jul 31 15: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 PAA12714
	for <atompub-archive@lists.ietf.org>; Sat, 31 Jul 2004 15: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 i6VJ5xQd087152;
	Sat, 31 Jul 2004 12:05: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 i6VJ5x3A087151;
	Sat, 31 Jul 2004 12:05:59 -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 i6VJ5ww6087135
	for <atom-syntax@imc.org>; Sat, 31 Jul 2004 12:05:58 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 28864 messnum 1997433 invoked from network[83.70.33.112/83-70-33-112.bas2.prp.dublin.eircom.net]); 31 Jul 2004 19:05:56 -0000
Received: from 83-70-33-112.bas2.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.33.112)
  by mail09.svc.cra.dublin.eircom.net (qp 28864) with SMTP; 31 Jul 2004 19:05:56 -0000
Message-ID: <410BED92.1050906@dehora.net>
Date: Sat, 31 Jul 2004 20:05:54 +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>, Ken MacLeod <ken@bitsko.slc.ut.us>
Subject: Re: Identity conundrum
References: <OF0F3762D8.79BA0EF1-ON88256EE2.005936ED-88256EE2.005A4DEC@us.ibm.com> <m3fz78t82a.fsf@bitsko.slc.ut.us> <410BEBB5.5030806@dehora.net>
In-Reply-To: <410BEBB5.5030806@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:

> Look, the thing that is needed for this identity stuff is a evaluation 
> model ('semantics) that ranges over the set of identifiers or tuples of 
> indetifiers or whatever -  this will trash need functions like equality 
> or order, invariants, and so on so that we can implement the neccessary 
> evaluators. Pointers to the literal values or tuples of literal values 
> are not sufficient.

Good grief. In English this time:

Look, the thing that is required for any useful notion of identity 
is an evaluation model (a 'semantics') which ranges over the set of 
identifiers (or tuples of identifiers, or whatnot).  This will 
clearly define functions such as equality or order, invariants, and 
so on, so that we can implement the necessary evaluators in code and 
ask important questions like "are these two things the same thing?", 
or "are these things part of that thing?". Pointers to the literal 
values or tuples of literal values are not sufficient in themselves.

cheers
Bill



From owner-atom-syntax@mail.imc.org  Sat Jul 31 16:24: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 QAA15171
	for <atompub-archive@lists.ietf.org>; Sat, 31 Jul 2004 16: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 i6VKEt22090872;
	Sat, 31 Jul 2004 13:14: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 i6VKEtje090871;
	Sat, 31 Jul 2004 13:14: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 i6VKEsN2090864
	for <atom-syntax@imc.org>; Sat, 31 Jul 2004 13:14:54 -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 i6VKEr53001105
	for <atom-syntax@imc.org>; Sat, 31 Jul 2004 15:14:53 -0500
Received: (from ken@localhost)
	by localhost.localdomain (8.12.8/8.12.8/Submit) id i6VKErQt001099;
	Sat, 31 Jul 2004 15:14:53 -0500
X-Authentication-Warning: localhost.localdomain: ken set sender to ken@bitsko.slc.ut.us using -f
To: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Identity conundrum
References: <OF559EB364.88C61375-ON88256EE2.0065F4A9-88256EE2.00670B23@us.ibm.com>
From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 31 Jul 2004 15:14:52 -0500
In-Reply-To: <OF559EB364.88C61375-ON88256EE2.0065F4A9-88256EE2.00670B23@us.ibm.com>
Message-ID: <m3hdrorl1f.fsf@bitsko.slc.ut.us>
Lines: 108
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: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>


James M Snell <jasnell@us.ibm.com> writes:

> [Ken MacLeod] wrote on 07/31/2004 10:12:13 AM:

> > James M Snell <jasnell@us.ibm.com> writes:

> > There is no reason why both models cannot be satisfied with the
> > current format.
> > 
> 
> Agreed

> [copied to http://intertwingly.net/wiki/pie/PaceMinimalEntryVersioning]

> This is close. I was thinking about something along these lines:
> 
>   <feed>
>     <entry>
>       <id>urn:myentry2</id>
>       <supercedes>urn:myentry1</supercedes>
>       <revision>1</revision>
>       <content>Hello There</content>
>     </entry>
>     <entry>
>       <id>urn:myentry1</id>
>       <revision>1</revision>
>       <content>Hello</content>
>     </entry>
>   </feed>
> 
> This assumes every distinct entry in the feed MUST have a unique 
> <atom:id>.
> 
> This introduces two new elements, <atom:supercedes> and <atom:revision>.
> 
> <atom:supercedes> references the ID of another item which this entry
> supercedes/replaces

The list would have to include all previous versions that this entry
replaces, in the case where the "window of polling" the publisher
misses an "entry instance" in the middle, eg. offline readers.

> Again, I know there are folks who would *rather* see us *only*
> support the model where an entry can keep the same identity
> regardless of changes; and there are folks who would *rather* see us
> *only* support the model where each change to an entry requires a
> change in the id.  This proposal seeks to find a compromise between
> the two by allowing us to support both in a rather simple way.

As Graham put it as an aside once[1],

    (Also the idea that it's meant to be applied to different versions
    of the same entry isn't conveyed very well - some conceptual
    definition of an "entry" elsewhere might do that though)

Your definition of an entry above seems to be more precisely, "entry
instance", and the identifier is of that instance.  My definition, and
current practice (right or wrong), is that entry is, merging Norm and
my definitions, "the abstraction of an entry that has multiple
versions".

So an even simpler form (and I'm not proposing this, because it's
simply changing names for the sake of names), would be:

  <feed>
    <entry-instance>
      <id>urn:myentry:2</id>
      <is-version-of>urn:myentry</is-version-of>
      <content>Hello There</content>
    </entry-instance>
    <entry-instance>
      <id>urn:myentry:1</id>
      <is-version-of>urn:myentry</is-version-of>
      <content>Hello</content>
    </entry-instance>
  </feed>

So all we've done here is changed <entry> to <entry-instance>, and
moved the identifier of "the abstraction of an entry that has multiple
versions" from <id> (where it currently resides in practice) to the
destination URI of <is-version-of>.  A "new" <id> is now what I called
the <version:id> in my examples.

Current aggregators would therefore do a search-and-replace for
atom:entry and change it to atom:entry-instance, change code
references from atom:id to atom:is-version-of, and continue to work
the way they have.  They may ignore <id>, and any form of versioning
model is still left open for further specification (as it would need
to be anyway, versioning is a huge topic in and of itself, and I
suggest outside the scope of core Atom).

Note, this approach doesn't suffer the "window of polling" problem.

I would not want to make this change to the Atom format because:

  1) it is only *slightly* more precise in its terms,

  2) it contains two unique identifiers where we have a hard enough
     problem explaning one, and

  3) we don't need to do it, we can leave the "entry instance"
     identifier to another specification that can more easily apply
     its context above the Atom core context *and* be fully baked.

  -- Ken


[1] http://imc.org/atom-syntax/mail-archive/msg08004.html



From owner-atom-syntax@mail.imc.org  Sat Jul 31 16:30:23 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15345
	for <atompub-archive@lists.ietf.org>; Sat, 31 Jul 2004 16: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 i6VKOQbq091298;
	Sat, 31 Jul 2004 13: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 i6VKOQom091297;
	Sat, 31 Jul 2004 13:24:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.196])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6VKOPTe091291
	for <atom-syntax@imc.org>; Sat, 31 Jul 2004 13:24:25 -0700 (PDT)
	(envelope-from pilgrim@gmail.com)
Received: by mproxy.gmail.com with SMTP id 73so102152rnl
        for <atom-syntax@imc.org>; Sat, 31 Jul 2004 13:24:29 -0700 (PDT)
Received: by 10.38.5.73 with SMTP id 73mr438442rne;
        Sat, 31 Jul 2004 13:24:29 -0700 (PDT)
Message-ID: <14be96d304073113246a4fcbe4@mail.gmail.com>
Date: Sat, 31 Jul 2004 16:24:29 -0400
From: Mark Pilgrim <pilgrim@gmail.com>
To: Martin Duerst <duerst@w3.org>
Subject: Re: URI equivalence (was Re: PaceFeedEquivalence)
Cc: Tim Bray <tim.bray@sun.com>, Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <14be96d3040731064230b356da@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <4.2.0.58.J.20040730141415.04b525c8@localhost>
 <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com>
 <ED9ED1C6-E194-11D8-B732-000A95A51C9E@sun.com>
 <14be96d30407291338435fdef6@mail.gmail.com>
 <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com>
 <4.2.0.58.J.20040730141415.04b525c8@localhost> <4.2.0.58.J.20040731085512.04f51380@localhost> <14be96d3040731064230b356da@mail.gmail.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 Sat, 31 Jul 2004 09:42:11 -0400, Mark Pilgrim <pilgrim@gmail.com> wrote:
> [1] http://example.com/%C3%87
> [2] http://example.com/C%CC%A7
> 
> 1 unescapes to two bytes, \xc3 \x87, which is the UTF-8 representation
> of the Unicode code point U+00C7, which is the NFC form of the
> character C-cedilla.
> 
> 2 unescapes to three bytes, C \xcc \xa7, which is the UTF-8
> representation of the Unicode code points U+0043 U+0327, which is the
> NFKC form of the character C-cedilla.

Small correction to myself: #2 is the NFD form, not NFKC form.  See
http://www.unicode.org/charts/normalization/chart_Latin.html

-- 
Cheers,
-Mark



From owner-atom-syntax@mail.imc.org  Sat Jul 31 16:34: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 QAA15456
	for <atompub-archive@lists.ietf.org>; Sat, 31 Jul 2004 16:34: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 i6VKS6qx091561;
	Sat, 31 Jul 2004 13:28: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 i6VKS6nF091560;
	Sat, 31 Jul 2004 13:28: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 i6VKS5Zw091554
	for <atom-syntax@imc.org>; Sat, 31 Jul 2004 13:28:05 -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 i6VKTKgu031870
	for <atom-syntax@imc.org>; Sat, 31 Jul 2004 16:29:23 -0400
Message-ID: <410C00D5.9060606@intertwingly.net>
Date: Sat, 31 Jul 2004 16:28:05 -0400
From: Sam Ruby <rubys@intertwingly.net>
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: URI equivalence (was Re: PaceFeedEquivalence)
References: <4.2.0.58.J.20040730141415.04b525c8@localhost> <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com> <ED9ED1C6-E194-11D8-B732-000A95A51C9E@sun.com> <14be96d30407291338435fdef6@mail.gmail.com> <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com> <4.2.0.58.J.20040730141415.04b525c8@localhost> <4.2.0.58.J.20040731085512.04f51380@localhost> <14be96d3040731064230b356da@mail.gmail.com> <01E063DE-E302-11D8-B278-000A95A51C9E@sun.com> <14be96d304073109443d7df1b6@mail.gmail.com>
In-Reply-To: <14be96d304073109443d7df1b6@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


Mark Pilgrim wrote:
> 
> Or we could try mandating a URI scheme that is specifically designed
> to be used as an identifier, not a
> resource-location-and-oh-by-the-way-wouldn't-it-be-cool-to-use-it-as-an-identifer-too.
>  I know I said just a few days ago that I was in favor of using any
> URI scheme, but Jesus, http:// URIs are incredibly complex.  And then
> saying that clients are free to pick and choose their own rules for
> comparing them, is just ridiculous.

I took a look into the rules for how two existing client platforms 
compare uris, and I found the results to be surprising:

   http://www.intertwingly.net/blog/2004/07/31/URI-Equivalence

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Sat Jul 31 17:49: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 RAA17163
	for <atompub-archive@lists.ietf.org>; Sat, 31 Jul 2004 17:49: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 i6VLfYRF095538;
	Sat, 31 Jul 2004 14:41: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 i6VLfYNb095537;
	Sat, 31 Jul 2004 14:41: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 i6VLfWrE095512
	for <atom-syntax@imc.org>; Sat, 31 Jul 2004 14:41:33 -0700 (PDT)
	(envelope-from derhoermi@gmx.net)
Received: (qmail 2727 invoked by uid 65534); 31 Jul 2004 21:41:27 -0000
Received: from dsl-082-083-163-232.arcor-ip.net (EHLO localhost) (82.83.163.232)
  by mail.gmx.net (mp007) with SMTP; 31 Jul 2004 23:41:27 +0200
X-Authenticated: #723575
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= <asbjorn@tigerstaden.no>
Cc: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: PaceRecommendIdScheme
Date: Sat, 31 Jul 2004 23:41:14 +0200
Message-ID: <41300074.614590614@smtp.bjoern.hoehrmann.de>
References: <opsbvza1bkuvpchu@quark>
In-Reply-To: <opsbvza1bkuvpchu@quark>
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


* Asbjørn Ulsberg wrote:
>== Proposal ==
>
>Replace section 4.2.6 and 5.5 with:
>
>=== 4.2.6  "atom:id" Element ===
>
>The "atom:id" element's content conveys a permanent, universally unique  
>identifier for the feed.  It MUST be universally unique, which means that  
>it must be unique both at the time of creation and in the future. This  
>means that it SHOULD contain the date and time of when the ID was  
>created.  It MUST NOT change over time, even if the feed is relocated.  
>atom:head elements MAY contain an atom:id element, but MUST NOT contain  
>more than one.

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.

It is also not clear to me when two feeds are considered equivalent,
which would be necessary to determine whether the id changed. If the
author, title, tagline, and primary subject of the feed are changed, can
it still be the same feed? 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.

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
<id>tag:diveintomark.org,2001-07-29:/</id> it would render Mark's feed
non-conforming. I do not think it should.

It would be better to include an informational note that publishers
should take all reasonable steps to maintain the identifier. We can also
specify that entry <id>s MUST be locally unique, and that intermediaries
MUST NOT change <id>s, etc., but we should stick to things that are at
least reliably human-testable.

>The content of this element, when present, MUST be a URI. The URI scheme  
>of atom:id 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. The recommended URI scheme for  
>atom:id is [http://www.ietf.org/rfc/rfc3085.txt "NewsML ID"].

I do not understand what beeing expected to be a dereferencable URL
scheme means in this context. Maybe you want to state that Atom software
must not attempt to dereference the identifier? What is the use case for
empty <id> elements? Your text appears to allow that... I am opposed to
recommend a specific (list of) schemes.

>atom:id MUST NOT under any circumstance be relative. It MUST always be a  
>complete, opaque and absolute URI that does not require any  
>post-processing to fulfil the above requirements for persistency and  
>universally uniqueness.

I think it is okay to prohibe relative references, but I think fragment
identifiers should be allowed. I have no idea what the part about
post-processing could mean, could you elaborate?

>=== 5.5  "atom:id" Element ===

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.



From owner-atom-syntax@mail.imc.org  Sat Jul 31 21:59: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 VAA28407
	for <atompub-archive@lists.ietf.org>; Sat, 31 Jul 2004 21:59: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 i711nDlF010113;
	Sat, 31 Jul 2004 18:49: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 i711nDPe010112;
	Sat, 31 Jul 2004 18:49:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from homer.w3.org (homer.w3.org [18.29.0.30])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i711nCKj010106
	for <atom-syntax@imc.org>; Sat, 31 Jul 2004 18:49:13 -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 3CB5F4F02D;
	Sat, 31 Jul 2004 21:49:15 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040801082741.051ff160@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Sun, 01 Aug 2004 09:32:54 +0900
To: Mark Pilgrim <pilgrim@gmail.com>
From: Martin Duerst <duerst@w3.org>
Subject: Re: URI equivalence (was Re: PaceFeedEquivalence)
Cc: Tim Bray <tim.bray@sun.com>, Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <14be96d3040731064230b356da@mail.gmail.com>
References: <4.2.0.58.J.20040731085512.04f51380@localhost>
 <4.2.0.58.J.20040730141415.04b525c8@localhost>
 <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com>
 <ED9ED1C6-E194-11D8-B732-000A95A51C9E@sun.com>
 <14be96d30407291338435fdef6@mail.gmail.com>
 <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com>
 <4.2.0.58.J.20040730141415.04b525c8@localhost>
 <4.2.0.58.J.20040731085512.04f51380@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <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 09:42 04/07/31 -0400, Mark Pilgrim wrote:

>On Sat, 31 Jul 2004 14:28:31 +0900, Martin Duerst <duerst@w3.org> wrote:
> > >http://feedvalidator.org/testcases/atom/must/entry_id_duplicate_value_8. 
> xml
> >
> > http://example.com/%c7 http://example.com/C%cc%a7
> >
> > I understand the intention: testing equivalence between precomposed
> > and decomposed C-cedilla. But that won't work. First, %c7 is a
> > C-cedilla encoded in iso-8859-1.
>
>You're right, this was my mistake in constructing the test.  However,
>you correctly determined my intention, so let me reconstruct the test
>and ask again.
>
>[1] http://example.com/%C3%87
>[2] http://example.com/C%CC%A7
>
>1 unescapes to two bytes, \xc3 \x87, which is the UTF-8 representation
>of the Unicode code point U+00C7, which is the NFC form of the
>character C-cedilla.

Yes, this is the NFC form, and also the NFKC form.


>2 unescapes to three bytes, C \xcc \xa7, which is the UTF-8
>representation of the Unicode code points U+0043 U+0327, which is the
>NFKC form of the character C-cedilla.

No, this is the NFD form, and also the NFKD form (as you correctly
pointed out in a followup).


>After percent-decoding, converting from UTF-8 to Unicode, and
>normalizing to Unicode Normalization Form C, these URIs are identical.

Yes. But I don't know any server that would do this. I also don't
know any client that would do this.


>Assuming I got this test right this time (and used all the right
>terminology, please correct me if I didn't), which of the following
>statements are we making:
>
>A) Everyone is expected to perform all of these steps, and therefore
>everyone is required to treat these URIs as identical.

Wrong.


>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.

Wrong. No client should preform these steps, because they are
not sure whether servers would perform them or not.


>C) No one should perform all of these steps, and therefore everyone is
>required to treat these URIs as different.

Correct. It's very similar to http://example.com/C-CEDILLA
and http://example.com/c-cedilla. You have no clue whether the
server will treat them as the same, or as different. So just
treating them as the same on the client side would be totally
wrong. The IRI spec explains that in detail. See
http://www.w3.org/International/iri-edit/draft-duerst-iri.html#normalization.

The URI spec doesn't say anything about Unicode normalization,
because it only deals with US-ASCII. http://example.com/%C3%87
could be a C-cedilla encoded in UTF-8, or it could be windows-1252,
with an A-tilde followed by a double dagger. Or it could be some
other encoding. Even if we know this is an IRI, we can't assume
for sure that it's encoded as UTF-8, because for backwards
compatibility, all URIs are IRIs. We can only know what characters
these are if they appear directly (i.e. unescaped).

Regards,    Martin.




From owner-atom-syntax@mail.imc.org  Sat Jul 31 22:00: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 WAA28461
	for <atompub-archive@lists.ietf.org>; Sat, 31 Jul 2004 22:00: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 i711nGQw010126;
	Sat, 31 Jul 2004 18: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 i711nGU1010125;
	Sat, 31 Jul 2004 18:49:16 -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 i711nFFG010115
	for <atom-syntax@imc.org>; Sat, 31 Jul 2004 18:49:15 -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 4A3774F04A;
	Sat, 31 Jul 2004 21:49:18 -0400 (EDT)
Message-Id: <4.2.0.58.J.20040801083942.051f9a88@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J 
Date: Sun, 01 Aug 2004 09:34:21 +0900
To: Tim Bray <Tim.Bray@Sun.COM>, Mark Pilgrim <pilgrim@gmail.com>
From: Martin Duerst <duerst@w3.org>
Subject: Re: URI equivalence (was Re: PaceFeedEquivalence)
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <01E063DE-E302-11D8-B278-000A95A51C9E@sun.com>
References: <14be96d3040731064230b356da@mail.gmail.com>
 <4.2.0.58.J.20040730141415.04b525c8@localhost>
 <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com>
 <ED9ED1C6-E194-11D8-B732-000A95A51C9E@sun.com>
 <14be96d30407291338435fdef6@mail.gmail.com>
 <BC5132DE-E1A1-11D8-B732-000A95A51C9E@sun.com>
 <4.2.0.58.J.20040730141415.04b525c8@localhost>
 <4.2.0.58.J.20040731085512.04f51380@localhost>
 <14be96d3040731064230b356da@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 07:57 04/07/31 -0700, Tim Bray wrote:

>On Jul 31, 2004, at 6:42 AM, Mark Pilgrim wrote:
>
>>A) Everyone is expected to perform all of these steps, and therefore
>>everyone is required to treat these URIs as identical.
>>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.
>>C) No one should perform all of these steps, and therefore everyone is
>>required to treat these URIs as different.
>
>B, so producers SHOULD NOT produce variant spellings of the same URI.
>(B is what will happen regardless of what we write down, so we might as 
>well live with that).  We could try for "MUST NOT produce variant 
>spellings" if people are comfortable with that. -Tim

Well, Tim, maybe in the widest sense, you are right. 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,
even though no spec whatsoever licences that. In a spider context,
there is still some chance that these are the same, and therefore some
work can be saved and some other pages can be downloaded instead.
Spiders may take this risk. But that's a risk they should take on
their own, knowing for themselves that they may be wrong. There is
no spec that licenses it.

Similarly, there is no spec that licenses B above. Indeed, I do not
know any server or client that would behave according to B above.
(we probably have to get the Apple server to behave that way,
because they store filenames decomposed internally, but

The IRI spec is very clear that producers should not produce
variant spellings, and should use NFC, or even NFKC where applicable.

We can repeat that in the Atom spec once we have decided on IRIs.

Regards,    Martin.






From owner-atom-syntax@mail.imc.org  Sat Jul 31 22: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 WAA29790
	for <atompub-archive@lists.ietf.org>; Sat, 31 Jul 2004 22: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 i712RPO5013770;
	Sat, 31 Jul 2004 19:27: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 i712RP5X013769;
	Sat, 31 Jul 2004 19:27: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.204])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i712ROfc013763
	for <atom-syntax@imc.org>; Sat, 31 Jul 2004 19:27:24 -0700 (PDT)
	(envelope-from eliast@gmail.com)
Received: by mproxy.gmail.com with SMTP id 77so114118rnk
        for <atom-syntax@imc.org>; Sat, 31 Jul 2004 19:27:30 -0700 (PDT)
Received: by 10.38.164.38 with SMTP id m38mr93873rne;
        Sat, 31 Jul 2004 19:27:30 -0700 (PDT)
Message-ID: <905f7c91040731192766d02e5@mail.gmail.com>
Date: Sat, 31 Jul 2004 22:27:30 -0400
From: Elias Torres <eliast@gmail.com>
Reply-To: elias@torrez.us
To: Sam Ruby <rubys@intertwingly.net>
Subject: Re: Identity conundrum
Cc: elias@torrez.us, Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <410BBDC4.2000008@intertwingly.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <20040730183424.84987.qmail@web41208.mail.yahoo.com> <87zn5hutjt.fsf@nwalsh.com> <905f7c910407310709c271d62@mail.gmail.com> <410BBDC4.2000008@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


Right, Sam. I think I'm starting to see the issue more clearly and I
accept that the Atom spec must enable people to use it for both cases.
Now, let me just mention a similar issue that we've seen in LSID
use-cases in the field.

LSIDs when resolved contain two different parts of information: data
and metadata. Data must never change for a given LSID (including
version information). On the other hand, metadata has fewer
restrictions. Metadata can be modified as desired by the owner of the
information. One could attach metadata to the main LSID or to a
specific version, etc, etc. Why is this such a neat feature? Because,
we've already have had to solve the same issues we are having in Atom
in LSID deployments.

Basically, people either want to name data and they want to name metadata. 

Let me connect this to Norm's description of the problem. The idea of
an entry being immutable is the same as when the user wants to name a
picture, an output of algorithm, a movie, etc.  The owner always wants
the same data returned when resolving that LSID. So the data returned
by the LSID will always be the raw bytes and these should never
change. Now, the idea that entries are snapshots of an abstraction
that has identity, we think of it as a concept. What we do is simply
not attach data to the LSID, but only metadata. Since metadata can
always change, users can make changes to any field they might have
added to an entry at their leisure, such as title, description,
modified, etc.

In the case you've read this far, then I pose the following question?
What is an entry? Is it data or metadata? Is it both?

How can we help BOTH publishers and consumers understand what the
author intended with this entry? I see further in this thread, people
are starting to make the right suggestions (not that I personally like
the element name entry-instance). I would love to hear people's
opinions on the subject and if there's anything we could recommend
including  as part of the spec. I really think this will help us make
great progress in a few issues, such as dates, versioning and
identification.

Thanks Norm for making the issue clearer to see, so we stop discussing
URIs vs. URNs and HTTP vs. Non-HTTP and focus on the real needs people
have out there and how can Atom solve some of them.

- Elias Torres

On Sat, 31 Jul 2004 11:41:56 -0400, Sam Ruby <rubys@intertwingly.net> wrote:
> Elias Torres wrote:
> > Although I'm not the god of aggregators, like Dare, I think you did
> > capture in essence the two major point of views in identity.
> >
> > I also stand with you on the latter. Every change to an entry, makes
> > it a new entry. Except that when using LSID the identifier just
> > changes by a version attribute in the LSID.
> >
> > urn:torrez.us:2004-blog:entry1 -- First Published
> > urn:torrez.us:2004-blog:entry1:2 -- Typo Fixed or GenX status changed.
> 
> Going back to Norm's original email:
> 
> http://www.imc.org/atom-syntax/mail-archive/msg08148.html
> 
>      One idea of identity is that entries have immutable identity. That
>      is, an atom:id identifies an atom:entry that cannot change...
> 
>      Another view of identity is that entries are snapshots of an
>      abstraction that has identity. That is, an atom:id identifies an
>      abstraction that might or might not change.
> 
> It seems to me that Elias, your notions correspond to the former.  If
> so, this reinforces Norm's observation that there are two points of view.
> 
> - Sam Ruby
> 
>



From owner-atom-syntax@mail.imc.org  Sat Jul 31 22:52: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 WAA00211
	for <atompub-archive@lists.ietf.org>; Sat, 31 Jul 2004 22:52: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 i712iPYl014691;
	Sat, 31 Jul 2004 19: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 i712iPZ8014690;
	Sat, 31 Jul 2004 19:44: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.195])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i712iNX4014684
	for <atom-syntax@imc.org>; Sat, 31 Jul 2004 19:44:24 -0700 (PDT)
	(envelope-from eliast@gmail.com)
Received: by mproxy.gmail.com with SMTP id 79so76311rnk
        for <atom-syntax@imc.org>; Sat, 31 Jul 2004 19:44:27 -0700 (PDT)
Received: by 10.38.82.68 with SMTP id f68mr92132rnb;
        Sat, 31 Jul 2004 19:44:27 -0700 (PDT)
Message-ID: <905f7c91040731194418367c28@mail.gmail.com>
Date: Sat, 31 Jul 2004 22:44:27 -0400
From: Elias Torres <eliast@gmail.com>
Reply-To: elias@torrez.us
To: Ken MacLeod <ken@bitsko.slc.ut.us>
Subject: Re: Identity conundrum
Cc: Atom Syntax <atom-syntax@imc.org>
In-Reply-To: <m33c38t5y6.fsf@bitsko.slc.ut.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <OF0F3762D8.79BA0EF1-ON88256EE2.005936ED-88256EE2.005A4DEC@us.ibm.com>
	<m3fz78t82a.fsf@bitsko.slc.ut.us> <m33c38t5y6.fsf@bitsko.slc.ut.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


+1 

Ken,

I'm starting to like
http://intertwingly.net/wiki/pie/PaceMinimalEntryVersioning as a
possible solution to my original point of moving away from HTTP URIs
and using much better defined schemes for identification, not location
of objects on the network.

Since, it seems now that votes need to backed up with technical
reasons, here they are: I recommended LSIDs because the IDs themselves
had a well-defined structure, that I find extremely important to avoid
all the super technical discussions on URI comparisons like the ones
MarkP and Tim are having. Basically, I see in this pace a
"well-defined" structure spread over a few atom elements (maybe we can
group into a construct called atom:id :-)). We have an ID (URI), a
version and a date. LSID has these as well, just in different places.
The ID is obvious, the version is optional and the date is usually
found in the metadata. I like the date as part of the ID, because it
gives us a nice way to sort versions for latest w/o having to resolve
for metadata. In LSID, the version can be any format the owner likes,
but that's makes it impossible for people to sort on. I think NewsML
was better in that regard.

Elias Torres

On 31 Jul 2004 12:57:53 -0500, Ken MacLeod <ken@bitsko.slc.ut.us> wrote:
> 
> Ken MacLeod <ken@bitsko.slc.ut.us> writes:
> 
> > Option 3:
> >
> >   <feed>
> >     <entry>
> >       <id>urn:myentry</id>
> >       <version:id>urn:myentry:2</version:id>
> >       <content>Hello There</content>
> >     </entry>
> >     <entry>
> >       <id>urn:myentry</id>
> >       <version:id>urn:myentry:1</version:id>
> >       <content>Hello</content>
> >     </entry>
> >   </feed>
> 
> A smaller, follow-on issue.  I checked format-01 for the spec text
> that indicates that a feed can only contain one entry with the same
> <id>, and notice it doesn't say that (I thought I recalled that it
> did).  The spec does say clearly that "same <id> is same entry".
> 
> However, to support both models, the spec should clarify:
> 
>     Multiple instances or versions of the same entry MAY appear in a
>     feed, index, or archive.  Consumers MAY choose to present or
>     record only the instance or version of the entry with the most
>     recent [[date that indicates change]].
> 
>   -- Ken
> 
>